双 16G V100 本地部署 Qwen3.6经过一番折腾，终于把 V100 的本地部署跑通了，能运行 Qwen3.6-

背景

前一阵在网上刷视频，都在说现在中等模型已经超过了能干活的那个基点了。代表就是 Qwen3.6 的 27B 和 35B-a3b 的模型。

于是没忍住，在网上淘了一套 V100 为基础的二手洋垃圾电脑，过过伪极客的瘾。

各种折腾

安装机器

因为我在国外，正好碰到海关严查，结果快递一个多月才到。

到了之后发现显卡得自己装，装上之后发现无法开机。

上网各种查教程，发现是跳线没插，于是折腾了一通，终于让它开机了。。。

安装 LLM 及框架

之前看的视频是「一猫之下」的，他们在 GitHub 上开源了一个项目 1Cat-vLLM，专门为 V100 适配的 vllm 版本。

说实话，虽然看了很多视频，但是对于很多概念都不清楚，反正按着他的文档装的，结果爆显存了。。。

然后再各种学习和在技术群里请教之后，知道了一些常识，比如：

vllm 官方在 0.20 以后就不支持 SM70（V100）的架构了，所以得用 1Cat 的那个库；
除了 vllm，还有 llama.cpp、Ollama、LM Deploy 等框架，特点各不相同；
不同框架支持的大模型格式也不同，什么 AWQ、GGUF、GPTQ 等等；
大模型下载的渠道有国内的魔塔社区和国外的 Hugging Face，它们都有自己的 cli 可以下载，也可以用 Aria2 下载；
一个模型差不多 20G+，下载要很久，下错了或者爆显存了，要重下（别问我怎么知道的）；
……

最后折腾的我没辙了，也不求什么性能，并发了，只要跑起来就行。

终于！我用 llama.cpp + Qwen3.6-35B-A3B-Q5_K_M.gguf 终于成功跑起来了本地的大模型。

启动参数

还没完，之前看视频了解到，还有什么张量优化、MTP、KV 压缩……

在启动的时候需要各种配置，有的功能还需要下载对应的模型……

最关键，不同的框架的启动参数还不一样……

最后，实在是学不过来了，返璞归真，先跑起来再说，用了下面的命令：

llama-server \
  -c 262144 -ngl 99 -np 2 \
  --reasoning off --jinja \
  --cache-type-k q5_0 \
  --cache-type-v q4_0 \
  --tensor-split 10,12 \
  --host 0.0.0.0 \
  --port 8080 \
  -m ~/models/Qwen3.6-35B-A3B-Q4_K_M.gguf

我就直接把 AI 给的说明贴到下面了，省的大家再问了，为全人类省点电。

-c 262144
- 设置 上下文长度（Context Size） 为 262144 Token（256K） 。
- 模型一次能够保留的历史上下文上限。
- 数值越大，占用的 KV Cache 显存/内存越多。
-ngl 99
- --n-gpu-layers
- 将模型层尽可能卸载到 GPU。
- 99 一般表示层数远大于模型实际层数，因此效果就是：所有可以放到 GPU 的层都放到 GPU。
- 如果显存不足，会自动有部分层放回 CPU。
-np 2
- --parallel
- 允许同时处理 2 个并行请求（Slot） 。
- 每个 Slot 都拥有独立 KV Cache。
- 显存占用几乎会随着 Slot 数量线性增加。
--reasoning off
- 关闭推理（Reasoning）模式。
- 对支持 Thinking/Reasoning 的模型（例如部分 Qwen3）来说：
  - 不生成 <think> 内容；
  - 直接输出最终答案；
  - 响应更快，也更省 Token。
--jinja
- 使用 Jinja Chat Template。
- 自动根据 GGUF 中保存的聊天模板，把：
  - system
  - user
  - assistant
- 转换成模型需要的 Prompt 格式。
- 一般推荐开启。
--cache-type-k q5_0
- 指定 Key Cache(KV Cache 中 K 部分) 使用 Q5_0 量化。
- 相比 FP16：
  - 显存占用更低；
  - 精度损失较小；
  - 长上下文更加省显存。
--cache-type-v q4_0
- 指定 Value Cache 使用 Q4_0 量化。
- 比 K Cache 更进一步压缩。
- 常见搭配就是：
  - K：Q5_0
  - V：Q4_0
- 能显著降低 KV Cache 显存。
--tensor-split 10,12
- 多 GPU 权重划分比例。
- 表示把模型权重按 10:12 分配到两张 GPU。
- 大约就是：
  - GPU0：45%
  - GPU1：55%
- 常用于两张显存容量不同的显卡。

安装 bge-m3

因为我想要跑通「本地大模型处理知识库」的场景，所以我需要一个向量化的模型。也是经过学习之后，发现了 baai/bge-m3 这个国产 Embedding 模型，于是尝试跑一下它。当然也少不了一番学习和折腾，我直接说最后的成功结果吧。

用 vllm 0.18 成功起了 bge-m3，命令如下：

conda activate bge

vllm serve ~/models/bge-m3 \
    --served-model-name baai/bge-m3 \
    --trust-remote-code \
    --host 0.0.0.0 \
    --port 8101

是的，这里又出来了一个 conda，跟她相关的我还知道了 uv。反正就是 python 的虚拟环境，这里我就不展开了，要不我都要吐了了。

到这里就完事了？

No~~

Too Young~~~

Too Simple~~~

还记得上面说的最新版的 vllm 已经不支持 V100 了嘛，于是我干脆一步到位，降级到 0.18.0 了。结果启动服务碰到了 '_IncludedRouter' object has no attribute 'path'……

问了 AI，说是 fastapi 版本太新了，尝试一番后，用下面的命令终于可以了。

pip install "fastapi<0.137"

成果

目前最终的成果是，我的双 16G V100 + 64G 内存的二手洋垃圾机器，能够同时启动 bge-m3 和 Qwen3.6-35B-A3B-q4 的服务。

是的，是同时，同时跑！

细心的朋友肯定注意到，我 qwen 模型启动参数里的 --tensor-split 10,12，意思是给第一个卡少分点，第二个卡多分点。

为什么？

就是为了在第一张卡上留出跑 bge-m3 的空间。是的，它非常小，跑起来只占 2G 左右的显存。

这样我跑起来两个服务，qwen 的上下文开到 256K，每张卡的显存高峰期大概会飙到 14G 多。

刚好够用

而且我已经用它们跑通了本地大模型 + LightRAG 的知识库管理系统。qwen 高峰能跑 100 t/s，平均也能达到 70+ t/s，效果还是不错的。

关于 LightRAG 的内容，会另起一篇介绍。

后续计划

目前跑通了本地知识库的这个场景，其实已经攒了一波体感和认知了。最近会进一步加深使用，拿更多的认知。

然后就是怎么让 qwen 能支持高并发，比如跑通 1cat 的框架，或者试一下 LM Deploy。

为什么要研究高并发？

当然是想自建 AI Token 站赚钱了，不过眼看这 DeepSeek-V4-Flash 的价格都低到跟电费差不多了，感觉好像也不一定有啥搞头。

但是好歹做一做拿个认知吧，没准有什么新想法呢。

行了，今天就到这了，等我后续关于 LightRAG 的文章吧。