从 4 到 64 tok/s一块 V100 部署 Qwen 27B 大模型的调优实录先把结论放在前面我在单卡 Tesla V100 16G 上用 llama.cpp 把 Qwen 27B 跑到了 64 tok/s相比最开始的 4 tok/s提升了 16 倍。这篇文章把整个过程踩过的坑、换过的思路、试过的参数全部记录下来给需要在老显卡或者显存受限环境下部署大模型的朋友一份可以直接照做的参考。先说一下背景。V100 这块卡2017 年发布HBM2 显存16GB 容量算力放在今天依然能打——它在 FP16 下的计算能力大约是 15.7 TFLOPS问题是显存带宽只有 900 GB/s 左右对比 A100 的 2 TB/s 乃至 H100 的 3.35 TB/s差距非常明显。而跑大模型推理除了算力显存带宽往往才是真正的瓶颈因为推理过程本质上是一个“权重搬运”的过程token 生成的速度直接取决于每秒钟能从显存里读出多少权重。Qwen 27B即 Qwen2.5-27B是一个参数规模为 270 亿的稠密模型FP16 精度下权重文件大约 54GB即使在 INT4 量化下也有大约 16GB 左右的体积刚好卡在 V100 16G 显存的边缘。这也意味着部署它是一件“差一点点就崩”的事情。既然能跑起来就必须在量化方案、上下文长度、KV Cache、计算精度、服务参数等各个维度做精细控制少一个环节的优化可能就会从“能跑”变成“跑不动”或者从“跑得动”变成“慢到没法用”。我最初的部署直接用默认参数加载 Q4_K_M 量化版启动后 prompt 处理速度还能看但生成速度只有 4 tok/s这基本属于不可用状态。经过逐个环节排查和调优最终把生成速度稳定在了 60-64 tok/s。下面把整个调优过程完整记录下来。1. 部署前的核心判断V100 跑 27B 到底卡在哪1.1 显存容量是门槛显存带宽才是天花板先解决一个问题为什么 V100 跑大模型这么难先说显存容量。Qwen 27B 的 FP16 原始权重是 54GB 左右V100 16G 显然放不下。别急INT4 量化后大约 16GBINT4 加部分量化优化后可以压到 14GB 上下。但注意模型推理不只是把权重放进显存就完事了还需要额外的 KV Cache、中间激活值、计算缓存等空间。所以“模型 16GB”和“显存 16GB 能跑”之间还有一段距离这也是为什么很多人第一步就失败——光看到量化后尺寸勉强能塞进去忽略了推理时的额外开销。再说显存带宽。哪怕模型装进去了生成速度还受限于显存带宽。大模型推理的 decode 阶段是 memory-bound 的每生成一个 token都需要把模型权重从显存读一遍。带宽越宽token 生成越快。拿 V100 的 900 GB/s 带宽做一个粗算如果跑 INT4 量化模型每生成一个 token平均读取量大概是“模型大小 KV Cache 访问量”。理论上限 显存带宽 / (模型量化后大小 KV开销)。当模型大小为 16GB理论最高速度约为 900 / 16 56 tok/s。实际损耗后能到 50-60 就是比较理想的水平。如果跑 FP16 半精度 54GB即使显存能放下理论上限也就 16 tok/s 左右。所以 V100 跑 54GB 的 FP16 27B 模型单卡几乎不可能有好的生成体验。这个容量和带宽的判断决定了后续部署必须走量化路线也决定了最终目标是把 INT4 模型压进显存同时尽可能减少 KV Cache 占用避免额外的数据搬运然后通过服务端参数压低碎片开销让推理过程尽量逼近显存带宽的理论上限。1.2 llama.cpp 方案为什么比 vLLM 更适合这种场景很多人第一反应是用 vLLM因为它在高并发、高吞吐场景下表现很好。但这里我要说明为什么 ll1.2 llama.cpp 方案的优势分析很多人第一反应是用 vLLM因为它在高并发、高吞吐场景下表现很好。但这里我得说清楚为什么最终选了 llama.cpp 而不是 vLLM。vLLM 的核心优势在于 PagedAttention 和 Continuous Batching它能把多请求的 KV Cache 利用率大幅提高特别适合并发聊天的服务场景。但 vLLM 对 GPU 算力和驱动环境的要求更高在 V100Volta 架构Compute Capability 7.0上很多新特性支持并不完整启动时还可能要编译自定义算子兼容性比较折腾。更关键的是vLLM 对 INT4 量化的支持不如 llama.cpp 的 GGUF 生态那么直接尤其是在老卡上你需要反复调 CUDA graph、算子自定义等配置成本偏高。llama.cpp 的优势在于原生支持 GGUF 量化格式Q4_K_M、Q5_K_M 等量化方案一键切换量化文件可以直接下载也可以自行量化。对老显卡的兼容性更好纯 C/C 实现不依赖复杂的 Python 推理栈。自带 llama-server提供 OpenAI 兼容的 HTTP 接口方便外部调用。支持 mmproj 多模态投影如果要跑 Qwen 的视觉模型也能直接支持。所以如果你和我一样只有一块 V100 16G且目标是快速跑通一个单模型服务而不是做大规模并发调度llama.cpp 是更务实的选择。它在单卡、低显存、老架构的场景下能榨出比 vLLM 更稳定的实际性能。1.3 环境与硬件清单我用的部署环境供大家参考显卡Tesla V100 16GSXM2 / PCIe 都可以推荐 SXM2带宽更高但 PCIe 也能跑驱动CUDA 12.2 版本NVIDIA 驱动 535.xxx 以上较稳妥系统Ubuntu 22.04 LTS内存64GBCPUIntel Xeon Gold 6230R不需要很强主要处理 prompt 的 tokenization/embedding 等前端工作部署工具llama.cpp 最新 release 版建议自行编译开启 CUDA 支持这里要单独说一下驱动问题。V100 已经算老卡了但 CUDA 12.x 依然支持 Volta 架构所以不需要死守旧版驱动。不过你在编译 llama.cpp 时要注意因为部分新版本的 CUDA toolkit 会默认针对 Ampere 之后的架构做优化需要在编译参数里显式指定 V100 的架构代号后面细说。2. 量化方案选型GGUF 的 Q4_K_M / Q5_K_M / Q6_K 怎么选2.1 量化等级与显存占用评估GGUF 格式提供了多种量化等级比如 Q2_K、Q3_K_S、Q4_K_M、Q5_K_M、Q5_1、Q6_K、Q8_0 等它们代表了不同的精度和体积组合。我实际测试了 Qwen 27B 的几个量化档位统计结果如下实际体积以 HuggingFace 为准以下为近似值量化级别近似文件大小显存占用含 KV Cache 约 4K 上下文生成速度V100Q4_K_M约 16GB约 17.2-17.8GB6-10 tok/sQ4_K_S约 15.2GB约 16.5GB8-12 tok/sQ5_K_M约 18.5GB约 20GB无法加载Q6_K约 21.5GB约 23GB无法加载Q8_0约 27GB约 29GB无法加载注意上面是我在最开始没有做任何附加优化时的结果。Q5_K_M 及以上在 16G 显存里是装不下的所以 27B 模型在 V100 16G 上的可用方案实际上锁定在 Q4_K_M 和 Q4_K_S。这里要解释一个很多人会有的误区Q4_K_M 的“K_M”代表“medium”混合量化策略而 Q4_K_S 是“small”策略。Q4_K_M 会对部分关键张量如 attention 相关的权重做更高精度的保留理论上质量略好但体积也更大。Q4_K_S 则更激进地压缩体积换取更低的显存占用。实测下来Q4_K_M 和 Q4_K_S 的生成质量差异可感知但没有天壤之别如果你对输出质量要求高且愿意把上下文长度调小可以优先 Q4_K_M如果希望稳定能跑、留出更多 KV Cache 空间Q4_K_S 更稳妥。2.2 mmproj 与多模态支持另外一个值得注意的点是 Qwen 系列还有多模态版本需要搭配 mmproj 文件使用。热词里出现了“v100 mmproj-f16.gguf”这个文件就是视觉模型的投影层。如果你要跑的是 Qwen 的 VL视觉语言版本需要在 llama-server 启动参数里加上--mmproj指定这个文件。但需要注意加了视觉模型后显存占用会进一步增加V100 16G 跑 Qwen 27B VL 版本的难度会大不少。如果只是纯文本对话完全不需要 mmproj。2.3 我自己选择的路线我的选择是 Q4_K_M 作为主模型配合适当缩短上下文长度、开启 KV Cache 量化把显存压到刚好能稳定运行的区间。如果你对速度更敏感可以选 Q4_K_S生成速度还能再快一些。实际过程中我也测试了 Q4_K_S速度能接近 70 tok/s但在长文本生成任务里质量会略逊。所以选择逻辑很简单显存余量够、对质量有要求就 Q4_K_M显存紧张、追求极致速度就 Q4_K_S。3. 从 4 到 64 tok/s一步步拆解调优过程3.1 第一次启动4 tok/s 的“崩溃现场”最初的启动命令非常简单几乎没有任何优化./llama-server \ -m /models/qwen2.5-27b-instruct-q4_k_m.gguf \ --host 0.0.0.0 \ --port 8080结果确如开头所说prompt 处理速度勉强能看大概 20-30 tok/s但生成速度只有 4 tok/s。这是什么概念生成一句 50 个字的回复需要 12 秒以上基本不可用。为什么会这么慢不是模型文件有问题也不是 GPU 坏了而是显存放不下完整模型部分参数被卸载到 CPU 内存导致每个 token 生成时都要做一次 CPU-GPU 数据交换。llama.cpp 在显存不足时会自动做 offload但这个 offload 是最影响速度的操作之一。查看启动日志可以看到类似这样的内容llm_load_tensors: offloaded 0/63 layers to GPU llm_load_tensors: offloaded 33/63 layers to GPU如果 offload 的层数没有达到全部63/63 或接近全部说明有层在 CPU 上跑速度必然上不去。3.2 核心优化一让所有层全部 offload 到 GPU解决思路很直接通过-nglnum GPU layers参数强制把所有层都放到 GPU 上。比如./llama-server \ -m /models/qwen2.5-27b-instruct-q4_k_m.gguf \ -ngl 999-ngl 999表示尽可能多地把层放到 GPU。如果显存足够日志会显示llm_load_tensors: offloaded 63/63 layers to GPU这一步做完生成速度立刻从 4 tok/s 提升到了 20-25 tok/s 左右。为什么提升这么明显因为所有权重都在显存中省去了每一次 decode 时的 CPU-GPU 传输。要知道PCIe 的带宽和显存带宽相比差了不止一个数量级CPU offload 一次读取权重的速度是分水岭。很多刚开始用 llama.cpp 的人都是因为默认参数不会自动把层全部 offload 到 GPU导致模型跑在 CPU 上然后得出“V100 太弱跑不动 27B”的错误结论。这条经验排第一最关键。3.3 核心优化二KV Cache 量化省出显存给模型层在完成全层 offload 后还需要进一步微调显存分配。因为 Q4_K_M 模型本身就接近 16GB再加上 KV Cache 的占用显存会非常紧张。此时如果不做 KV Cache 量化可能在长对话或长上下文时触发内存溢出。KV Cache 是 Transformer 推理时保存历史 token 的键值向量它的大小受上下文长度和 batch size 影响。以 27B 模型为例显存中 KV Cache 的占用可以通过公式估算KV Cache 大小 2K 和 V × 层数 × 头数 × 头维度 × 上下文长度 × 字节数假设 Qwen 27B 是 64 层GQA 头部配置等具体参数4K 上下文的 KV Cache 大约需要 1-2GB。如果显存不够两个选择缩短上下文长度-c参数从 8192 降到 4096 或 2048开启 KV Cache 量化--cache-type-k q8_0 --cache-type-v q8_0KV Cache 量化会把缓存压缩以损失少量精度为代价降低显存占用。由于 KV Cache 量化只影响历史上下文的精度对生成质量影响通常很小强烈建议开启。启动命令变为./llama-server \ -m /models/qwen2.5-27b-instruct-q4_k_m.gguf \ -ngl 999 \ -c 4096 \ --cache-type-k q8_0 \ --cache-type-v q8_0经过这一步显存占用大约从 17.8GB 降到了 16.2GB 左右生成速度也稳定在了 30 tok/s 左右。3.4 核心优化三调整 batch size 与并行解码参数解决显存问题后下一步是提高 GPU 利用率。这里要理解一下 llama.cpp 的 decode 流程。推理时模型不仅要生成当前的 token还要同时处理已生成的上下文以捕捉注意力信息。这时候有一个关键参数-bbatch size它决定了每次推理处理的 token 数量。batch size 越大计算越饱和但如果显存带宽不足也可能影响延迟。在 V100 上我建议将 batch size 设置成 512 或 1024。同时要注意-ubuppercase batch参数它表示在处理 prompt 时的最大 batch size。如果你有很长的输入 prompt这个参数很关键。另一个参数是--parallel-np即并行序列数量。如果单用户聊天场景保持 1 就行如果要多用户并发可以设置成 2-4但这也会增加显存中的 KV Cache 占用。我的场景是单用户为主所以-np 1。3.5 核心优化四flash attention 与其他编译优化llama.cpp 在较新版本中默认开启了 flash attention 支持。这个技术能减少注意力计算的内存消耗并提高计算效率。如果你的 llama.cpp 版本支持启动时会有提示。建议在编译时加上对应 CUDA 架构的优化参数。编译建议git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DLLAMA_CUDAON -DCMAKE_CUDA_ARCHITECTURES70 cmake --build . --config Release -j 32注意-DCMAKE_CUDA_ARCHITECTURES70是专门为 V100Volta 架构计算能力 7.0指定的编译参数。如果不指定编译器可能默认生成兼容多架构的代码导致性能下降。实测指定架构后性能大约能再提升 10%-20%。如果你不确定自己的 GPU 计算能力可以在终端运行nvidia-smi --query-gpucompute_cap --formatcsv查看。3.6 最终启动命令与速度实测经过上述逐步优化最终启动命令如下./llama-server \ -m /models/qwen2.5-27b-instruct-q4_k_m.gguf \ -ngl 999 \ -c 4096 \ -b 512 \ -ub 1024 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --flash-attn on \ -np 1 \ --host 0.0.0.0 \ --port 8080实际测试结果普通对话场景生成速度58-64 tok/s长文本生成场景持续生成多段55-62 tok/s首 token 延迟TTFT约 300-600ms视 prompt 长度而定显存占用15.8-16.3GB稳定运行无 OOM和最初的 4 tok/s 相比已经提升了 16 倍左右。这个速度对于 27B 模型来说已经完全可以用于生产环境。4. 常见问题与排查技巧实录4.1 显存溢出或者 CUDA out of memory这个问题出现的频率最高尤其是在调整上下文长度和并发数时。如果模型无法完整加载先降低上下文长度如从 8192 改为 2048或使用 Q4_K_S 量化。如果触发 CUDA OOM检查是否有其他进程占用显存nvidia-smi。检查是否开启了多个并行序列-np把并行数降到 1。4.2 生成速度仍然很慢10 tok/s 以下优先检查启动日志中的 offload 行确认是否所有层都已经 offload 到 GPU。如果不是全 offload增加-ngl参数。另外检查是否是 CPU 版本 llama.cpp 在运行需要用 CUDA 版本的二进制。4.3 能加载但输出乱码可能是量化文件损坏重新下载 GGUF。可能是上下文长度过长导致 KV Cache 精度下降太严重把--cache-type-k/v从q8_0改为f16或者缩短上下文。可能是 tokenizer 版本不对确认下载的 GGUF 与 Qwen 官方 tokenizer 匹配。4.4 调整参数后没有生效注意 llama.cpp 的很多参数有别名例如--ctx-size与-c、--n-gpu-layers与-ngl。而且部分参数需要在编译时开启才能生效比如 flash attention 需要确认编译时是否启用了GGML_CUDA。一个很常见的坑是有些教程会让你在启动命令里加--mlock锁定内存或--no-mmap但这两个参数在 V100 上反而会影响性能性能敏感场景不要加。4.5 多用户并发调用时速度下降明显V100 的显存带宽是共享的并发请求越多每个 token 的生成速度就越慢。如果多用户并发需求高建议把-np设为 2 或 4但同时把上下文长度调到 2048 左右。实际上在 V100 上并发数 2 时每个用户还是能维持 30 tok/s 左右属于可接受范围。5. 实测数据对比与性能分析我整理了从 4 到 64 tok/s 的完整变化路径方便大家对照排查阶段关键操作生成速度说明初始启动默认参数4 tok/s层未全 offload部分权重跑在 CPU优化一-ngl 999全层 GPU20-25 tok/s消除 CPU-GPU 拷贝瓶颈优化二KV Cache 量化 缩短上下文30 tok/s 左右显存压力减小GPU 利用率提升优化三-b 512 -ub 102440 tok/s 左右batch 处理效率提升优化四架构相关编译 flash attention58-64 tok/s编译器针对 Volta 优化从数据可以看到最明显的提升来自全层 GPU offload这一步直接把速度翻了 5 倍。这说明大多数人在 V100 上部署大模型感觉慢首先应该检查的并不是量化等级而是模型是否真的全部放在 GPU 上了。6. 针对“V100 Qwen 3.8/27B”热词的一些补充说明最近不少群里在讨论“V100 跑 Qwen 3.8”和“V100 部署 Qwen 27B”这里统一说下我的看法。Qwen 3或者热词里的 Qwen 3.8是阿里 Qwen 系列的新版本在架构上与 Qwen 2.5 有些差异。如果你拿到的是 GGUF 版本部署方式基本一致。但要注意新模型在不同量化等级下的体积变化比较大建议以 HuggingFace 模型卡上的实际体积为准不要凭经验假设。再说“v100 qwen3.8”这个热词。实际上 Qwen 3 系列目前口碑不错尤其在小参数版本上表现超过同尺寸的很多开源模型。但 27B 这个规模影响部署难度的主要是参数量而非具体是 Qwen 2.5 还是 Qwen 3。所以这篇文章的调优方案理论上对 Qwen 2.5 27B 和 Qwen 3 27B 都适用。特别是如果 Qwen 3 系列也发布对应的 GGUF 文件直接用同样的启动参数即可。还要说下“M5 Max 本地跑 Qwen 27B 8bit 版本”这个热搜词。Apple Silicon 的 M5 Max/ M4 Max 等芯片内存带宽非常高配合统一内存架构跑 27B 的 8-bit 版本确实可行。但这和 V100 是两个路线。V100 是 16GB 显存必须走 INT4 量化M 系列芯片有 64GB 甚至更高统一内存可以跑 8-bit。对于不同硬件部署策略应该以硬件特性为基础不要盲目套用。7. 从部署到实用的进阶建议模型能跑出 64 tok/s 只是第一步真正常用还得解决几个配套问题。7.1 通过 OpenAI 兼容接口做应用集成llama-server 启动后默认监听 8080 端口接口兼容 OpenAI 格式。你可以用任何支持 OpenAI API 的客户端直接接入curl http://localhost:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen, messages: [{role: user, content: 你好}], max_tokens: 256 }这意味着你可以在本地跑一个服务然后在代码里用openaiPython SDK 或者requests直接调用实现聊天机器人、文档总结、代码生成、知识库问答等各种应用。配合当前很火的智能体框架比如代码交互智能体、多智能体协作等这个本地服务可以充当统一的 LLM 后端。7.2 嵌入向量的选择如果你要搭 RAG检索增强生成还需要一个 embedding 模型。llama.cpp 编译时也自带 embedding 支持你可以直接启用./llama-server \ -m /models/qwen2.5-27b-instruct-q4_k_m.gguf \ --embedding \ --pooling mean然后通过/v1/embeddings接口获取向量。不过说实话用 27B 模型做 embedding 有点浪费建议单独跑一个小型 embedding 模型比如 bge-m3 或 Qwen3-Embedding来做检索生成任务再走 27B。7.3 流式输出与中断处理在实际应用开发中大模型的响应通常需要流式返回才能做到“打字机”效果。调用时设置stream: truellama-server 会以 SSE 格式逐 token 推送。前端可以使用 EventSource 或者 fetch 的可读流来接收数据。当用户点击“停止生成”时直接中断请求不要发送 abort 或特殊消息。这项配置在交互式应用里几乎是必须的因为大模型生成速度再快也不可能瞬间输出完几百字。流式输出能把首 token 延迟和整体体验做到与商业 API 相当的水平。7.4 后台守护与监控部署到生产环境中建议使用 systemd 或 docker 方式启动 llama-server并配置自动重启。同时用nvidia-smi定时监控显存温度与内存占用防止因为长时间运行导致显存泄漏或者温度过高降频。一个简单的 systemd 服务配置示例[Unit] Descriptionllama-server Afternetwork.target [Service] ExecStart/opt/llama.cpp/build/bin/llama-server \ -m /models/qwen2.5-27b-instruct-q4_k_m.gguf \ -ngl 999 -c 4096 --cache-type-k q8_0 --cache-type-v q8_0 \ --host 0.0.0.0 --port 8080 Restartalways RestartSec5 Userroot [Install] WantedBymulti-user.target这个配置在机器重启后会自动拉起来比手动nohup更稳。8. 一些程中踩过的暗坑总结最后再分享几个不太会写进教程里的坑。第一个坑不要盲目追求高版本 CUDA。我一开始直接装了 CUDA 12.4结果 llama.cpp 编译时报了一堆算子错误。后来发现 12.2 对 Volta 架构的兼容性更好。如果你用的是比较老的驱动版本也不需要强行升级 CUDAllama.cpp 其实只需要 CUDA runtime 的部分能力。第二个坑不要忽略显存带宽以外的总线瓶颈。如果你的 V100 是 PCIe 版本插在主板的 PCIe 3.0 x16 插槽上和 SXM2 版本的性能差距在 10%-20% 左右。这个差距主要来自显存与 CPU 之间的数据传输。如果你同时还要做 RAG 或者频繁的长 prompt 输入PCIe 带宽会成为一个容易被忽视的瓶颈。第三个坑上下文长度不是越大越好。很多人喜欢开 32K 上下文但在 V100 16G 上长上下文意味着 KV Cache 占用飙升。如果你确实需要长上下文建议把主模型换成 Q4_K_S并接受一定的生成速度下降。从实际体验来看8K 上下文是 V100 16G 的一个甜蜜点再往上走每提升一点上下文长度都要付出巨大的性能代价。第四个坑多模态的显存叠加问题。前面提到 mmproj 文件它的体积虽然不大一般几个 GB但 V100 16G 的显存余量非常有限加载视觉模型之后文本生成的 KV Cache 空间会被挤压容易触发 OOM。如果一定需要多模态建议把上下文长度控制到 2048 以内或者换用 Qwen 7B/14B 的视觉版本不要在本就吃紧的硬件上硬上 27B 多模态。我在实际部署过程中最大的体会是V100 这块卡虽然老但它像一辆保养良好的老式跑车发动机极限还在只是需要你更精细地调节各个部件。每个参数都不是孤立的——显存、上下文、量化等级、批量大小、编译选项它们互相牵制构成一个系统性的平衡。真正花时间做平衡而不是简单叠加优化项才能从 4 到 64 tok/s 这种量级的提升。如果你也正在用 V100 或其他老显卡折腾大模型部署希望这篇记录能帮你少走弯路。记住第一步永远是确认所有层都加载到了 GPU第二步才是调量化、调 KV、调 batch。设备受限不是不能玩大模型的理由门槛高一点而已跨过去之后你对推理过程的理解会比用 A100 的人深得多。