跑分榜：Ollama 开 16 槽，5090D 比只开 1 槽还慢
结论先行：峰值在 4 槽，180.92 tok/s。开到 16 槽，只剩 55.71 —— 比单槽的 61.25 还低 9%
环境、命令、量出来的数都在下面，可以直接照着重跑。
这周的跑分榜只有一个主角：Ollama 的 OLLAMA_NUM_PARALLEL。
我拿同一个模型（qwen2.5:14b，Q4_K_M，ctx 8192），在 5090D 上把槽位从 1 一路开到 16，每档都重启一次 serve 再发满并发请求，三轮取中位。
结果不是「越大越好」，是一条先涨后塌的曲线：
61.25 → 97.33 → 180.92 → 158.82 → 55.71 (tok/s)
1 槽 2 槽 4 槽 8 槽 16 槽
峰值在 4 槽，180.92 tok/s。开到 16 槽，只剩 55.71 —— 比单槽的 61.25 还低 9%。
我给这张图起了个名字：花钱买回来的负收益。
同一轮我在 5060Ti 16GB 上跑了同一套流程，峰值出现在 2 槽（16.63 tok/s），开 4 槽变成 16.22，也是往下掉。
两张卡的吞吐峰值差了 10.9 倍（180.92 ÷ 16.63），但峰值出现的位置也不一样。这一篇就把这条曲线摊开，讲清楚它为什么长这样，以及你手上那张卡该配几槽。
① 本周跑分榜：一栏槽位，先涨后塌
先上表。同一个模型、同一个上下文长度、同一套发请求逻辑，每档独立重启一次 serve（OLLAMA_NUM_PARALLEL 只在进程启动时读一次，进程内切档不生效——这条我上一轮踩过），每档丢弃首轮预热，三轮取中位。
RTX 5090D 32GB（qwen2.5:14b Q4_K_M / ctx 8192 / 每请求 128 token / Ollama 0.40.4）：
| 槽位 | 聚合吞吐 | 相对单槽 | 总显存 | KV 落 CPU 的部分 |
|---|---|---|---|---|
| 1 | 61.25 tok/s | 1.00× | 13502 MiB | 0 |
| 2 | 97.33 tok/s | 1.59× | 15042 MiB | 0 |
| 4 | 180.92 tok/s | 2.95× | 18119 MiB | 0 |
| 8 | 158.82 tok/s | 2.59× | 24962 MiB | 0 |
| 16 | 55.71 tok/s | 0.91× | 31887 MiB | 2560 MiB |
RTX 5060Ti 16GB（同模型同上下文 / Ollama 0.40.3 / 桌面环境已占约 9.2 GiB）：
| 槽位 | 聚合吞吐 | 相对单槽 | 总显存 |
|---|---|---|---|
| 1 | 11.43 tok/s | 1.00× | 15945 MiB |
| 2 | 16.63 tok/s | 1.45× | — |
| 4 | 16.22 tok/s | 0.98× | 15919 MiB |
两件事同时成立：32G 卡巅峰在 4 槽，16G 卡巅峰在 2 槽。 换句话说，「Ollama 建议开几个槽」这件事没有通用答案，它随显存容量移动。
顺便放本期最扎眼的一组：两张卡的并发峰值差 10.9 倍（180.92 ÷ 16.63）。这是本周跑分库里唯一一个两位数倍差。
② 数字背后：两段曲线，两个不同的机制
这条曲线不能用一个原因解释完。我把 5 个档的显存和 KV 逐档拆开后，发现它是两段拼接的。
4 槽之前：真收益，而且效率高得合理。
四个槽换来 2.95 倍吞吐，效率 73.8%。此时总显存 18119 MiB，全程没有任何卸载——这是「完全不溢出」的最后一档，也正好是吞吐最高的一档。这一段没什么可挑的。
4 槽到 8 槽：没有任何溢出，还是掉了 12%。
这一档我特意核了：NP=8 时总显存 24962 MiB，构成是模型 8148.38 + KV 12288 + CUDA_Host 417.66 + 计算缓冲，KV 一分钱都没落到内存里，占了 32G 卡的 76.6%。
它掉到 158.82，纯粹是单张卡上同时跑 8 路 decode，抢同一份 SM。并发越多，每路分到的算力越薄，调度的固定开销却一分不少地摊在每一次 token 上。这一段不是容量问题，是并行度本身开始亏。
8 槽到 16 槽：这里才轮到溢写，而且不报错。
NP=16 时启动日志出现两行，这是本轮最该记的东西：
CPU KV buffer size = 2560.00 MiB
CUDA0 KV buffer size = 22016.00 MiB
KV 总量 24576 MiB（8192 cells / 48 层 / 16 路，正好等于单槽 1536 MiB 乘以 16），其中 2560 MiB 被搬到了内存。
更隐蔽的是权重：NP=1 和 NP=8 时 GPU 上的模型段都是 8148.38 MiB，到 NP=16 变成 GPU 7316.31 + Host 1249.73，也就是 832.07 MiB 模型权重也被挪出了显存。
请求照样返回 200，推理照样完成。你从外面看一切正常，只有吞吐塌了。
这也解释了那个看起来矛盾的现象：NP=16 的总显存 31887 MiB 低于「模型 8148 + KV 24576 = 32724」的直觉值——因为有一部分根本不在卡上。
总显存占 32607 MiB 的 97.8%，余 720 MiB。 到这一步它已经在 OOM 边缘，只是没掉下去。
而 decode 阶段每生成一个 token 都要把全部 KV 读一遍，落在 CPU 的那 2560 MiB 每次都要过 PCIe。这就是为什么单请求延迟从 1.47 秒涨到 22.69 秒——慢了 15.4 倍，用户体感就是「点了没反应」。
卸载有边界，而且边界很近。 同一台机器把 ctx 开到 32768 再试 NP=16，KV 需求量按公式算就是 98304 MiB，远超物理上限，Ollama 直接返回 502 Bad Gateway，错误体是 upstream connect failed。
判据：卸载机制能兜住「超出一点点」，兜不住「超出三倍」。要判能不能开 N 个槽位，不能只看总 KV 是否小于显存，还要看超出部分有没有在可卸载范围内。
③ 对你意味着什么：三张卡，三个数
我不给通用结论，只给按显存分档的判据。全部基于今天这两张卡的实测，换模型、换上下文长度都要重测。
| 你的卡 | ctx 8192 跑 14B 该开几槽 | 依据 |
|---|---|---|
| 16GB（5060Ti） | 2 槽 | 单槽已用 15945 / 16311 MiB，4 槽只剩 392 MiB，吞吐反降 2% |
| 32GB（5090D） | 4 槽 | 4 槽 18119 MiB 全程无溢出，2.95× 吞吐 |
| 24GB（4090） | 没有实测，不给数 | 按 2 槽与 4 槽之间的容量推断，但推断不是实测 |
这套数落在钱上是这样的：
如果你有一台 24 小时跑的本地服务，按 4 槽配置，一天理论上是 180.92 × 86400 ≈ 15.6M token；按 16 槽只有 4.8M。同一张卡、同一份电，开错槽位等于白扔掉三分之二的产出。 这台机器满载按 575W 估、0.55 元一度，一天电费不到 5 块——省电从来不是重点，白扔吞吐才是。
如果你在纠结 5090D 还是 5060Ti：并发峰值差 10.9 倍（180.92 对 16.63）。按公开报价粗估整卡价格（三万上下 vs 一万上下，均为估价不是实付），摊到每 1 tok/s：5090D 约 166 元，5060Ti 约 601 元。要跑并发服务，5090D 大约便宜 3.6 倍；只跑单路对话，这个价差一分都不值。
如果你正在给 16G 卡加槽位「榨性能」：别加。单槽 15945 MiB 已经把 16311 塞满，余 366 MiB。第二槽是真的并行（延迟只涨 3%），第三第四槽是假的（延迟从 8.12 秒涨到 13.80 秒，吞吐还掉）。16G 卡跑 14B 这件事本身是「能跑」级别，不是「能服务」级别。
④ 一个副作用：别用 tok/s 判断「能不能开」
上面那张表里有个细节容易漏：NP=8 全程没有卸载，NP=16 只卸载了 2560 MiB（占 KV 的 10.4%），但吞吐从 158.82 掉到 55.71，掉了 65%。
卸载量只占一成，性能赔掉三分之二。这说明在 decode 这种「每 token 读全 KV」的负载下，哪怕一小段 KV 落在 PCIe 后面，代价也是非线性的。
所以判据不能是「显存够不够」。要看的是 llama_kv_cache 那两行日志是不是出现了 CPU KV buffer。 一旦出现，不管 tok/s 当时还好看不好看，你已经在付 PCIe 的账了。
⑤ 下周预告
下周我打算把这件事往深一层做：同一个 5090D，把 ctx 从 8192 拉到 32768，看 4 槽的峰值会不会前移。
按公式算，ctx 拉到 32K 之后单槽 KV 就是 6144 MiB，4 槽 24576 MiB——已经超过 4 槽今天用掉的 12288 的两倍。如果峰值真的往前移到 2 槽，那就等于说：「该开几槽」这件事不只看卡，还看你的上下文长度。 到点来看。
验证等级：L1 ｜ 五档槽位各独立重启 serve 三轮取中位，轮间极差 0.4%–10.9%；KV 与总显存读数与 llama_kv_cache 日志逐 MiB 对齐，5 次采样极差 0 MiB
参考来源
- 槽位扫描：2026-11-03 本机 RTX 5090D 32GB + Ollama 0.40.4 实测（qwen2.5:14b Q4_K_M / ctx 8192 / 每请求 128 token / 五档 1-2-4-8-16，每档独立重启 serve、丢弃首轮、三轮取中位）
- 16G 卡对照：同轮 RTX 5060Ti 16GB（Windows 11 桌面机，桌面环境占约 9.2 GiB）+ Ollama 0.40.3，三档 1-2-4
- KV 与卸载：
llama_kv_cache/CPU KV buffer size/CUDA0 KV buffer size启动日志原文；显存读数为nvidia-smi memory.used，每档 5 次采样 - 失败形态：NP=16 × ctx 32768 返回
502 Bad Gateway，错误体upstream connect failed - 10.9 倍、73.8%、97.8%、65%、15.4 倍、15.6M 与 4.8M token、166 元与 601 元 均为按上表实测值换算，非独立计时；电价、整卡功耗、整卡价格均为假设或公开报价，不是实付
声明
本文所有吞吐、延迟、显存、KV 数值均来自本机真机实测，模型版本、量化格式、上下文长度、Ollama 版本已在文中标明。未测到的部分（24GB 卡不参与、其他模型与其他上下文长度不外推、双卡与多机并发未测、桌面环境占用的显存未扣除归因）已在文中写为未测或明确标为推断。另：跑分库里 NP=8 的总显存存在 24267 MiB 的一条旧读数，与同轮启动日志（KV 12288 MiB、无 CPU KV buffer 行、模型段 8148.38 MiB 未变）算不平，本文采用与日志对齐的 24962 MiB，该条旧读数保留在库中待复核。文中电价按 0.55 元/度、满载功耗按 575W 估算，属假设值不是实测。不同模型、不同上下文长度、不同量化下这条曲线的位置都会移动，判断方法不变。
本文所有数字均为本机实测，非引用。环境与脚本版本见文末参考来源。 作者：丘山录 · 记录本地部署与算力实测
