夜雨聆风背景
最近又开始折腾Openclaw配置本地模型了，取得了一点进展，记录一下。
在Qwen3.5-9b模型发布后，我通过Ollama拉取了模型，并成功配置给了Openclaw，也解决了默认的上下文过长导致的显存占用过大的问题。（见文章：【AI学习笔记】Openclaw配置Ollama本地大模型上下文窗口大小）
使用了一段时间后，直观感受是比Qwen3好了很多，完成基本的工具调用是没问题的。但是，Ollama拉取的模型，通过Openclaw使用的时候，经常出现对话无理由的戒断。就是我发出了一个指令过去，他执行到了一半，自己就停下来了，得我再去发指令，他才能有反应，体验很差。
我想这样不行啊，基本上还是用不了的状态，我就去找有没有更好的解决办法。后来，无意间刷到有博主说，Ollama框架下的大模型，不适配Openclaw这样的智能体框架，得换vLLM架构，体验会提升很多。
vLLM架构拉取大模型
我赶紧又开始研究怎么本地部署vLLM架构拉取模型。刚开始，我是按照vLLM官方文档的方式，在独立的Python环境中进行安装。可以成功安装vLLM框架，但是到了关键的模型拉取环节，出问题了，拉取下来的模型无法初始化，一直提示环境冲突，试了各种办法也解决不了。
这步卡了我好长时间，后来只能放弃直接在Python环境里安装这种方式了，改用Docker部署的方式（需要提前安装好Docker环境，Windows下可以安装桌面版Docker）。好在Docker部署没出什么大问题，但中间也踩了几次坑，包括国内访问不了默认的模型仓库地址，改用Modelscope地址，开始拉取的模型，参数不对，不支持工具调用，没有挂在Modelscope镜像默认缓存地址，导致每次修改参数都要重新下载一遍模型文件，非常耗时等等。
好不容易，Docker拉取模型搞定了，也在Openclaw里做完了配置，我很着急地做了测试。刚开始，整体的工具调用、运行体验，都比Ollama模型好了非常多，我还挺开心，觉得这下可以用这个做点事情了。突然在某一刻，我发现我发给Openclaw的指令，经常卡死，就是后台的大模型狂运行，就是不给任何的回复反馈。
我又去找原因，问各种AI，该怎么办，后来智谱清言告诉我，是我的显存太小了，只有24GB，魔塔社区的9B模型权重文件就18GB了，再加上其他的一些加载消耗，留给KV缓存的空间就非常小了，随便给一些上下文就把KV缓存撑爆了，然后就假死了。我去查阅了Docker的日志文件，发现确实如此，原生版本的9B模型，留给KV缓存的空间只有1.8GB了。
我想啊，既然9B版本的不行，那我弄4B的好了，于是又拉取4B模型，配置给Openclaw。这下KV缓存倒是够大了，也没有那种假死的情况出现了，但是4B版本的代码能力太差了，基本算是用不了的状态。这条路径又没折腾通。
我没啥好办法了，就又去问智谱清言怎么办。他告诉我，由于我的显存太小，只能考虑社区的4bit量化版了，而且那个量化版同样是在24GB的单卡上做的测试，运行没有什么压力，整体性能损失可接受。
受限于我的显卡，我也只能接受这个方案了，就开始拉取和部署量化版本。其实部署量化版本的过程也是踩了坑的。我开始是用下面这段命令拉取的模型权重文件：
docker run --runtime nvidia --gpus all --name vllm_9b_gptq -v ~/.cache/modelscope:/root/.cache/modelscope -e VLLM_USE_MODELSCOPE=true -e TZ=Asia/Shanghai -p 8001:8000 --ipc=host vllm/vllm-openai:latest DavidWen2025/Qwen3.5-9B-GPTQ-4bit --quantization gptq_marlin --dtype float16 --gpu-memory-utilization 0.90 --enable-prefix-caching --kv-cache-dtype fp8_e5m2 --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder --max-num-seqs 4拉取过程也是顺利结束的，但是加载镜像后，发现KV缓存仍然只有1.8GB，肯定是哪里有异常的。我就把问题又反馈给了智谱清言，他告诉我应该是默认读取了官方的元数据，并没有按照实际拉取的本地模型大小来加载模型空间。需要更换镜像的构建命令，没办法，只能把镜像删了再来一遍。
最终的构建命令如下：
docker run --runtime nvidia --gpus all --name vllm_9b_gptq -v ~/.cache/modelscope:/root/.cache/modelscope -e VLLM_USE_MODELSCOPE=true -e HF_HUB_OFFLINE=1 -e TRANSFORMERS_OFFLINE=1 -e TZ=Asia/Shanghai -p 8001:8000 --ipc=host vllm/vllm-openai:latest DavidWen2025/Qwen3.5-9B-GPTQ-4bit --quantization gptq_marlin --dtype float16 --gpu-memory-utilization 0.90 --enable-prefix-caching --kv-cache-dtype fp8_e5m2 --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder --max-num-seqs 4注意：上述命令加了两个离线的限制命令，需要先拉去完模型，才能用这个命令构建镜像。所以虽然有些无奈，但第一段的命令可能还是得先跑一遍。
Docker加载镜像时，模型文件及KV缓存空间占用情况（我没有继续折腾怎么压显存了，先用着再说了）
[default_loader.py:384] Loading weights took 3.89 seconds[gpu_model_runner.py:4566] Model loading took 8.12 GiB memory and 4.774454 seconds......[gpu_worker.py:456] Available KV cache memory: 11.46 GiB......[kv_cache_utils.py:1316] GPU KV cache size: 186,912 tokens[kv_cache_utils.py:1321] Maximum concurrency for 262,144 tokens per request: 2.79x
Openclaw配置
关键配置部分，就是关于models和agents部分需要修改一下，这里我用的是8001端口，需要根据自己的实际修改。大家主要参考一下里面的内容，括号数量我没有仔细核对，复制时注意。
"models": {"mode": "merge","providers": {"vllm": {"baseUrl": "http://localhost:8001/v1" ,"apiKey": "sk-local","api": "openai-completions","models": [{"id": "DavidWen2025/Qwen3.5-9B-GPTQ-4bit","name": "Qwen3.5-9B-GPTQ (Local vLLM)","contextWindow": 131072,"maxTokens": 32768,"cost": {"input": 0,"output": 0,"cacheRead": 0,"cacheWrite": 0}}]}}},"agents": {"defaults": {"model": {"primary": "vllm/DavidWen2025/Qwen3.5-9B-GPTQ-4bit"},"models": {"vllm/DavidWen2025/Qwen3.5-9B-GPTQ-4bit": {"alias": "qwen35-9b-gptq"}},}},
一些功能的测试（视频）
让Openclaw查询系统安装了哪些类型的Python包
查询自己有哪些技能
解析网页新闻内容
Docker后台日志显示的token生成速度最大约120 tokens/s。
throughput: 120.4 tokens/s, Running: 1 reqs, Waiting: 0 reqs, GPU KV cache usage: 6.5%, Prefix cache hit rate: 90.4%小结
社区量化版支持单卡4090日常使用是可以的，但由于是量化版，肯定是损失了一些什么的。但受限于显存限制，这也是没办法的事情，相对简单的工具调用是没有问题的。
稍微复杂一些或者长工具链的调用场景，还是会出现意外中止且无任何反馈的问题。
期待开源模型继续进化，同等智能水平下对硬件资源的要求越来越低，让普通人也用得了本地模型的智能体。
希望上面的内容对大家有帮助，大家如果有更好的本地模型智能体解决方案，也欢迎评论区告诉我，谢谢。
