如果你手头只有一张 V100，又想跑 Qwen3.8-27B 这个量级的模型，大概率已经看了一堆“换 GPU”的建议。但现实就是设备就在那儿，预算也就这么点，任务卡在这里，必须想办法把它跑起来、跑得稳、跑得快。我前后折腾了三个周末，总算把单卡生成速度从基线 28 tok/s 拉到了 38.6 tok/s，中间还处理了好几轮 OOM、API 报错、系统资源告警，甚至显卡掉驱动。这篇实录会把完整的排查过程和最终可复现的配置清单放出来，适合正在 V100 16GB 单卡上部署 Qwen3.8-27B、又不想折腾到崩溃的人参考。
先说结论：这 10.6 个 tok/s 的提升，不是靠某一个“神奇参数”瞬间榨出来的，而是把环境、显存布局、KV Cache、批处理配置、编译选项这些环节里的坑一个个填平之后的结果。整个过程用到的核心工具就是 llama.cpp 的 llama-server，下面按实际调优顺序来讲。
1. 算清这笔账：V100 单卡跑 27B，先别急着开骂
1.1 这张卡的真正瓶颈不是算力，是显存带宽
V100 是 Volta 架构，16GB HBM2，显存带宽约 900GB/s。放到今天看确实不够看，但它的 FP16 算力依然有 112 TFLOPS 左右。真正的问题出在：Qwen3.8-27B 如果以 FP16 精度加载，权重就要占 54GB 左右，16GB 显存根本装不下，所以必须量化。量化到 Q4_K_M 之后，模型文件大概降到 15~16GB，才能勉强放进 V100。
这里有个特别容易忽略的物理限制：大模型在生成阶段，每生成一个 token，都要把整份模型权重从显存里读一遍。也就是说，生成速度的上限不是“算力多强”，而是“显存带宽多大”。假设量化后权重是 16GB，V100 的 900GB/s 带宽，理论上每秒钟最多从头到尾读完权重约 56 次，也就是 56 tok/s 左右。这还没算 KV Cache 读取、激活值读写、内存碎片和 kernel 启动开销。所以 V100 单卡跑 27B 量化模型，能稳定跑到 35~40 tok/s，已经算是非常健康的水平了。
1.2 为什么基线只有 28 tok/s
我最初用的是 llama.cpp 的官方预编译版本，参数也按“大上下文、多并发”的习惯配置：ctx-size 开到 32768，parallel 设为 4，batch-size 设为 1024。结果显存被 KV Cache 和并发槽位吃掉一大块，模型权重和 KV 数据挤在一起，内存碎片化严重，生成速度只有 28 tok/s，而且每隔几十次请求就会出现 CUDA OOM，API 直接报错。
更重要的是，这种配置下 V100 的显存带宽利用率只有一半左右。很多显存带宽都被“无意义的开销”浪费了，比如过大的上下文预分配、多路并发槽位、fp16 缓存数据，以及处理器架构不匹配导致的低效 kernel 选择。这才是调优的切入点，而不是去盲目追求更高精度的量化或更花哨的推理框架。
2. 环境底子：llama-server 版本、CUDA 架构和显存布局
2.1 V100 该选哪一代 llama-server，以及要不要自己编译
V100 的计算能力是 7.0，这一点直接影响 prebuilt 版本的兼容性。llama.cpp 的预编译包通常为了方便会往新架构偏移，虽然也保留了旧架构的通用 kernel，但在 V100 上经常选不到最优 kernel。我自己实测下来，老版本预编译包在 V100 上生成的效率偏低，而最新 master 又容易出现依赖太新、兼容性反而不稳的问题。
我的建议是：选择一个稳定 release 分支，自己编译，显式指定 CUDA 架构为 70。编译参数如下：
cmake -B build -DGGML_CUDA=ON \ -DCMAKE_CUDA_ARCHITECTURES=70 \ -DLLAMA_CUDA_FORCE_MMQ=ON \ -DCMAKE_BUILD_TYPE=Release cmake --build build --config Release -j$(nproc)其中-DLLAMA_CUDA_FORCE_MMQ=ON是我在 V100 上发现的“关键开关”之一。MMQ 是 llama.cpp 里的矩阵乘法 kernel，强制使用 MMQ 后，在很多旧显卡上反而能跑出比默认 kernel 更好的带宽利用率。配合CMAKE_CUDA_ARCHITECTURES=70，可以让编译器只针对 V100 生成机器码，避免包体膨胀和运行时 kernel 选择的不确定性。
2.2 显存布局：全层下放，但上下文和 KV Cache 必须做减法
很多人以为“把 GPU 层数拉满”就够了，结果模型放到 GPU 后剩下几个层在 CPU 上，通信开销巨大，生成速度直接腰斩。所以我用--n-gpu-layers 99，把能下放到 GPU 的层全部下放。
但全层下放之后，显存就不是你想怎么用就怎么用了。KV Cache 才是吃掉显存的大头。我最初用 32K 上下文、fp16 KV Cache，KV 占掉的显存比想象中多得多。后来把上下文降到 8192，并把 KV Cache 类型切到 q8_0，显存瞬间腾出好几个 GB。
启动命令里，我最终稳定使用的核心参数是：
./build/bin/llama-server \ -m /models/qwen3.8-27b-instruct-q4_k_m.gguf \ --port 8000 \ --host 0.0.0.0 \ --n-gpu-layers 99 \ --ctx-size 8192 \ --parallel 1 \ --batch-size 512 \ --ubatch-size 256 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --threads 8 \ --threads-batch 8 \ --no-flash-attn这里--no-flash-attn可能很多人会觉得奇怪，后面专门解释。
2.3 驱动和系统层：优先 Linux，不要头铁上 Windows
V100 在 Windows 11 下不是不能跑，但我实际遇到的坑比 Linux 多太多：驱动容易在高负载后进入异常状态，资源句柄释放不干净，长时间运行后服务开始报“系统资源不够”。如果你的目标是 7x24 小时对外提供服务，强烈建议直接用 Linux，最好用 Ubuntu 20.04 或 22.04。驱动版本选支持 CUDA 12 的稳定版即可，不要追求最新 beta 驱动。
另外，llama-server 对显存的要求比较“刚性”，一旦显存不够，不会像普通软件那样慢慢变慢，而是直接 OOM。所以部署前先通过nvidia-smi确认显存只有模型服务在占用，其他进程的显存占用全部清掉。
3. 提速的主战场：KV Cache、上下文长度和批处理参数
3.1 一版参数对比表：从 28 到 38.6
下面这张表是同一台机器、同一个模型文件、从基线到最终配置的对比。看起来每一处都是“小调整”，合在一起效果就非常明显。
| 配置项 | 基线值 | 调优后 | 主要作用 |
|---|---|---|---|
| llama-server 编译方式 | 官方预编译包 | 自编译，指定 sm_70 | 让 kernel 更匹配 V100 |
| LLAMA_CUDA_FORCE_MMQ | 未开启 | 开启 | 提升矩阵乘法带宽利用率 |
| ctx-size | 32768 | 8192 | 大幅减少 KV Cache 显存占用 |
| parallel | 4 | 1 | 减少多路请求预留的 KV 槽位 |
| batch-size | 1024 | 512 | 降低 prefill 阶段显存峰值 |
| KV Cache 精度 | fp16 | q8_0 | 降低 KV 读带宽和显存占用 |
| flash-attn | 开启 | 关闭 | 避免 V100 上 kernel 选择异常 |
| 实测生成速度 | 28 tok/s | 38.6 tok/s | 约提升 38% |
3.2 上下文长度不是越大越好，KV Cache 才是显存黑洞
Qwen3.8-27B 这类模型的上下文能力很强，但对于 V100 16GB 单卡，上下文长度就是显存换速度的博弈。KV Cache 占用的显存和上下文长度基本成正比，上下文从 8K 拉到 32K，KV Cache 占用可能增加数 GB。生成时每次还要读取对应 layer 的 KV 数据，KV 越小，内存带宽压力越小。
所以我把 ctx-size 从 32768 降到 8192。如果你的实际业务场景根本用不到 8K 上下文，甚至可以降到 4096，理论上显存更宽裕，速度还能再提升一点，只是稳定性和长对话能力会受影响。对于单卡 27B 部署，我建议 8K 是一个比较平衡的默认值。
3.3 parallel=1：先用单路服务模式把速度跑满
--parallel是 llama-server 同时处理的请求槽位数量。parallel=4 时，服务会为每个槽位预留 KV Cache 空间，四路并发虽然能同时接请求，但单路生成的显存带宽被分走，单用户延迟和吞吐都会下降。如果你只是内部 API 使用、单并发场景居多，parallel=1 是更优选择。
这也回答了为什么我基线用 parallel=4 时只有 28 tok/s：显存留给生成的带宽和空间都被摊薄了。调成 1 之后，资源全部集中给当前请求，生成速度直接上了一个台阶。
3.4 batch-size 和 ubatch-size：prefill 阶段的安全性设置
--batch-size控制 prompt 批量预填充时一次性处理的最大 token 数，--ubatch-size是内部微批量大小。V100 的处理能力有限，batch 设得太大，prefill 阶段会出现显存峰值，容易在长 prompt 请求进来时直接 OOM。设在 512 和 256，一方面显存峰值更可控，另一方面对 V100 来说已经足够把 prefill 速度跑起来。
很多人看到这些参数会觉得“批次越大肯定越快”，但这个逻辑只适用于算力余量很大的新卡。V100 上更重要的指标是“每个 token 处理时能不能稳定不爆显存”。实测下来 512/256 这组值在速度和稳定性之间最平衡。
3.5 为什么我最后关掉了 flash-attn
按理说 Flash Attention 能减少显存读写，应该对 V100 有好处。但 llama.cpp 在新版本里的 Flash Attention 优化默认针对 Hopper、Ampere 等新架构做 kernel 特化，在 V100 这种架构上，部分版本反而会选到不合适的分块策略，导致速度下降。我在对比测试中开启 flash-attn 的版本比关闭时低约 2~3 tok/s，而且长时间跑偶发卡顿。
所以这里的经验是：不要照抄教程里的--flash-attn，一定要自己在 V100 上做一次开启和关闭的 A/B 测试。如果你用的 llama.cpp 版本在 V100 上支持得很好，开起来有提升，那保留也无妨。我的最终生产配置是关闭，因为实测更稳。
4. 报错现场还原：OOM、系统资源不够、掉驱动分别怎么处理
4.1 CUDA OOM 不是只有“显存不够”一个原因
我在调优过程中遇到最多的报错就是 CUDA OOM，但排查完之后发现真正的原因并不一样：
- 第一种确实是因为模型加 KV Cache 超出 16GB。这种情况优先缩上下文，或者把 KV Cache 从 q8_0 换到 q4_0。不过 q4_0 KV 会让输出质量有一定下降，不能盲用。
- 第二种是 prefill 瞬间显存峰值超限。长 prompt 进来时，batch-size 过大容易触发，把 batch-size 降到 256~512 就能缓解。
- 第三种是显存碎片。多次频繁请求后，旧的 KV 块没有完全回收，导致剩余显存虽多但都是碎片。重启 llama-server 最有效，同时把 parallel 降到 1 能显著减少碎片产生。
排查时不要只看 V100 当前显存使用量，还要看一眼进程的 CUDA context 数量。如果同时加载了多个推理环境，比如 Python、vLLM、llama-server 一起跑，显存会被拆得非常碎。尽量保证同一时间只有一个大显存进程在运行。
4.2 API 报“系统资源不够”的排查链路
这个报错相当有迷惑性，因为它并不是说你没有显存，也不是说 API 写错了。大多数情况下，这是操作系统层面的资源限制或进程内部线程创建失败。
我的排查顺序是这样的：
- 先看系统句柄限制：执行
ulimit -n，如果当前 nofile 比较小，而服务长时间运行产生大量连接后无法创建新 socket，就会报资源不足。可以改成ulimit -n 1048576再重启服务。 - 再确认内存锁限制：llama-server 如果配置了 mlock 或者在特定环境下加载权重时锁定内存，
ulimit -l过小也会报资源不够。把这个限制调大，或者去掉--mlock相关参数。 - 最后看线程数：V100 上 GPU 核数有限，
--threads设置过大反而会因为线程调度和内存锁竞争导致资源不够。我在最终配置里用--threads 8 --threads-batch 8，简单可靠。
如果你部署时把 llama-server 放在 systemd 或 Docker 里，还要注意容器内部的 ulimit 继承问题。Docker 默认的进程和文件上限不一定和宿主机一致，这也是“系统资源不够”的高发原因之一。
4.3 V100 掉驱动：先查温度和电源，再谈稳定性
V100 掉驱动这个问题在长时间高负载运行下确实会出现。我排查后发现，多数情况下不是驱动本身不行，而是电源状态或温度触发了保护机制。掉驱动的一般表现是nvidia-smi突然看不到卡，或者内核日志里出现 GPU 相关的 reset 记录。
处理思路是：
- 用
nvidia-smi -q -d TEMPERATURE,POWER查看温度和功耗。V100 长期超过 85 度就要特别注意机箱散热，不能只依赖风扇自动策略。 - 检查电源管理模式，设置成持久模式：
nvidia-smi -pm 1。 - 驱动版本不要追新。对 V100 来说，稳定版驱动比新功能更重要，我最后固定在 535 系列，跑了很久没再掉过驱动。
- 如果掉驱动已经发生，先
nvidia-smi --gpu-reset或重启服务，不要直接在异常状态下继续发请求，否则后续请求全都超时。
5. 最终参数清单和一次可信的验证方法
5.1 完整启动命令
这是我最终在生产环境里用的启动方式：
export CUDA_VISIBLE_DEVICES=0 export OMP_NUM_THREADS=8 ./build/bin/llama-server \ -m /models/qwen3.8-27b-instruct-q4_k_m.gguf \ --port 8000 \ --host 0.0.0.0 \ --n-gpu-layers 99 \ --ctx-size 8192 \ --parallel 1 \ --batch-size 512 \ --ubatch-size 256 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --threads 8 \ --threads-batch 8 \ --no-flash-attn \ --log-file /var/log/llama-server.log启动后，llama-server 会在日志里输出模型加载阶段和每次请求的耗时详情，包括prompt tokens/s和eval tokens/s。我们要看的生成速度，严格来说是eval tokens/s，而不是 “从发请求到拿到完整响应” 的整体速度。整体速度还会受到 prompt 长度、TTFT 和网络开销影响，不适合用来比较模型部署优化效果。
5.2 怎么测 tok/s 才可信
我在调优时不是直接看终端输出，而是写了一个简单脚本循环请求，记录每次耗时和输出 token 数，然后取中位数。单次请求很容易受系统调度干扰，至少连续跑 10 次，每次输出 256 个 token，然后取中位数。
可以这样模拟一次请求：
curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen3.8-27b", "messages": [{"role": "user", "content": "写一段关于显存优化的技术文章提纲"}], "max_tokens": 256, "stream": false }'然后去/var/log/llama-server.log里面看eval_tokens/s。我最终配置跑出来的稳定值是 38.6 tok/s，持续几十次请求基本都在 37.5~39.2 之间波动，说明已经压到了一个比较稳的平台期。
5.3 还能不能继续往上压
如果你追求极限，可以再把上下文降到 4096、KV Cache 换成 q4_0、batch-size降到 256，这样速度确实还能再快一点，但我测出来输出质量有可感知的下降，尤其在需要精确复述或推理的场景里，偶尔会出现上下文衔接变差的情况。
我最终没有选择极限压榨，而是停在“模型质量不牺牲、显存稳定、速度 38.6”这一档。对于 V100 单卡跑 Qwen3.8-27B，我觉得这已经是一个很值得参考的健康配置了。最后再说一个实操细节：如果服务会长期运行，建议每天凌晨自动重启一次 llama-server，把显存碎片和内部状态清干净，这个操作比任何调优参数都更管用。我踩过几次坑之后，已经把重启脚本写进 crontab，稳定运行下来再没出现越跑越慢的情况。
