本次数据分两类：受控基准（copy 任务 / 固定长度提示）与真实负载统计（正常服务状态下 273 个请求的引擎聚合）。受控基准不挑"最好看的一次"，只取能重复的那一档；个别只有单次采样的值会在表里标出来。

2026-10-23 晚在双卡上补测了一组纯复述（3 次，草稿接受率 88–94%），读数并入第 2 节。单卡沿用一条历史 copy 记录（98.4 tok/s），两者的调优状态不同，怎么对比见第 3 节。

一、硬件规格与运行前提

【核心硬件】

【软件与引擎栈】

【关键运行参数】

加卡前提：BIOS 必须开 Above 4G Decoding（否则第二张卡 BAR1 = 0M，nvidia-smi -L 只看到一张），顺手开 Re-Size BAR、关 CSM。

二、核心实测数据汇总

测试规范：decode 一律取引擎底层 timing，不用客户端壁钟；decode 主指标用 copy 任务（逐字复述，草稿接受率 88–100%），排除"这段文本好不好猜"的干扰；冷提示与热缓存分开记；关键项 2–4 次取值，单次数据在表中标 n=1。

【1. 单卡四阶段：8 GB → 16 GB → IQ3_S】

★ 8 GB → 16 GB：槽位 ×9.0，8K Prefill ×4.4，解码 ×2.2。 全程收益最大的一次硬件改动，比后来加第二张卡明显得多。

★ IQ3_XXS → IQ3_S：槽位 −19%，copy 解码 −12%，Prefill −3%。 用 12% 的速度换质量；长链 agent 任务里工具参数写错、重复发请求的次数明显下降（体感，无跑分）。

【2. 双卡 vs 单卡】

★ 加卡没有让解码翻倍，也不该期待它翻倍。 层拆分是逐 token 串行过两张卡，第二张卡不缩短关键路径；它买到的是槽位和命中率：4,351 → 9,183 槽，75–80% → 94–98%。

★ 同任务整体 +55%：单卡 98.4 → 双卡中位 152.5。但这 55% 里混着加卡与两项调优，不能记在卡头上——详见第三节。

★ Prefill 短降长升：2.3K 从 900–1,100 掉到 793，30.5K 却能到 2,516——层拆分的交接开销在短提示上摊不平，长提示反而被流水填满。

【3. 上下文档位权衡】

★ 64K 试验说明：槽位不是被上下文上限卡住的。减掉一半 KV 只多 63 个槽，代价却是一个能读 67K 文档的窗口——因为会话缓存的 6 GiB 并不全在显存里，减 KV 释放不了多少 VRAM。

【4. 参数逐项 A/B】

有效的：

改动	实测	代价	判定
--pipeline-windows 2	利用率 45/49% → 70/79%；2.3K 83.6 → 91.6/119.1	272 MiB、−206 槽
学习型 expert profile	命中率 82.6–85.6% → 92.6–96.4%；2.3K 91.6 → 105.6	下次启动才生效
presence_penalty: 0	默认 1.5 时 overlap 退化为串行	采样风格变化
会话缓存 6 GiB / 4 槽	复用 2.5K token，首字 8.3 s → 1.0 s	6 GiB 内存
--vram-reserve-mib 1024	空闲 652 MiB，#2065 显存告警消失	约 100 槽（2–3%）
--kv-grow	112.6 / 1,597（KV 流式 110.6 / 1,579）	无
--adapt-async 1（单卡）	52.15 → 55.0（+5.5%，4/4 一致）	双卡层拆分下被引擎关闭	/ —

负优化（都回滚了）：

#	改动	实测	结论
1	--kv k8v4	Prefill −38%（561 → 347），解码不变
2	--ple-io ram	启动 +45 s；解码 55.75 vs 55.0；ulimit -l 仅 8 MB，mlock 全失败
3	--adapt-swaps 160 --adapt-every 2	54.95 vs 55.0，另出现一次 108 s 异常
4	STRATA_MTP_STAGE0=1	7.7K 86.4/87.7 → 75.6/77.1（−12%）
5	--max-context 65536 省显存	4,351 → 4,414（+63），67,409 token 请求被拒
6	--max-context 262144 日常用	槽位 −11%、解码 −6%	️ 分场景
7	--kv-grow + --kv-resident 同开	语义冲突，只能二选一
8	期待 --adapt-async 在双卡生效	层拆分下引擎直接关闭（日志有说明）
9	pkill -f strata	模式匹配到执行它的 shell，SSH 一起断

【5. 真实负载统计（273 个请求）】

★ 平均 59K 的上下文还能跑 89 tok/s，靠的是 97.8% 前缀复用——真正需要 prefill 的只有 35 万 token。没有会话缓存，这台机器会被 prefill 拖死。

三、横向对比与差异分析

【与论坛 （2× V100 16G / IQ3_S）的横向参照】

口径不同：本机是热缓存、对方未注明；引擎差 4 个小版本；对方测到 200K，本机没测 100K 冷 Prefill。只能当量级参照，不能当胜负。

【+55% 里，有多少是卡的功劳】

单卡留有一条历史 copy 记录：98.4 tok/s（4,351 槽、未开 pipeline / profile、提示长度未记录）。今天双卡同任务中位 152.5，相差 +55%。

这 55% 混着三样东西：第二张卡、--pipeline-windows 2、学习型 profile。后两项在 2.3K 真实提示上分别测到 10–40% 和约 15%，但那是另一组提示，不能直接搬来做减法。

所以正文只写「同任务整体 +55%」，不写「加卡 +55%」——这不是谦虚，是口径。

【为什么加卡换不来翻倍：一个 token 要过两张卡】

1. decode 是逐 token 串行的：token 依次过卡 0 的层、交接、卡 1 的层，加卡不缩短关键路径，只多一次 hand-off。
2. 真正的瓶颈是"专家在不在显存里"。8 GB 常驻 629 个（约 2.6%），16 GB 5,659 个（23%），双卡 9,183 个（37%）；命中率从个位数级别爬到 75–80%，再到 95%。
3. 卡内带宽 448 GB/s，PCIe 4.0 x8 只有 15.75 GB/s，差 28 倍——"少走一次 PCIe"比"多一张卡算"值钱。
4. 所以加卡真正兑现的地方是长上下文：30.5K 冷 Prefill 2,516 tok/s，50–60K 上下文仍能跑 89–105 tok/s。

【为什么短提示 Prefill 反而下降】

层拆分下，每个 8K chunk 都要跨卡交接一次；单卡时那个 +5.5% 的 --adapt-async 在层拆分下被引擎直接关掉。prefill_stages=2 是流水不是并行——短提示只有一两个 chunk，流水填不满，交接成本全暴露；30K 以上的 prompt chunk 多，流水跑起来，反而能到 2,516 tok/s。

【为什么 256K 只掉 6% 解码，却不建议日常开】

256K 的 KV 从 1.68 GB 涨到 3.35 GB，槽位 9,183 → 8,138（−11%），解码 89.3 → 83.6（−6%）。单看数字不亏，但 6 GiB 会话缓存只放得下 1 个长会话，日常切对话会频繁重建前缀。除非你确实要读 128K 以上的文档，否则 128K 是更划算的档位。

四、结论与心得

1. 双卡的真实价值不是速度，是"上下文不塌"

同任务整体是 98.4 → 152.5（+55%，含两项调优），但可以确定：加卡本身没有翻倍，也不该期待翻倍。真正的变化是槽位 4,351 → 8,957、命中率 75–80% → 93–97%——50–60K 上下文下仍能稳定 89–105 tok/s，这是单卡 4,351 个槽做不到的。如果你只跑短提示问答，第二张卡是性价比最差的升级；如果你的负载是 agent（平均 59K prompt），它才是从"能用"到"好用"的那一步。

2. 参数符号会翻转，任何百分比先看条件

--kv k8v4 在论坛双卡 16G 的环境里是 +8～13%，在本机 sm_120 + 消费卡上是 Prefill −38%。同一个参数，换架构、换引擎小版本，符号能反过来。抄参数之前先看对方的卡型、量化、上下文长度。

3. "省显存换槽位"多半是负收益

64K 试验只多 63 个槽（+1.4%），代价是一个 67K 文档读不了；--vram-reserve-mib 1024 掉 100 个槽，但换来显存不被打满——前者是亏，后者是买保险，别把两者混为一谈。

4. 适用与不适用

• 适合：单机跑 125B 级 MoE、要 100K+ 上下文、要给 agent 当后端（前缀复用率高）、电费敏感（2.6 J/token）。
• ️ 勉强：想要 256K（能开，但会话缓存吃紧）、想要视觉（16 GB 下图像编码器走 CPU，每张几秒）。
• 不适合：只追求短提示峰值、指望加卡翻倍、显存 <24 GB 还想上 125B、想上 NVFP4（92 GB 内存太紧，约需 80 GB 权重常驻）。

数据说明：受控基准为单次或 2–4 次采样，decode 对草稿接受率极其敏感（同一配置 28～65 tok/s 都出现过），所以正文只用 copy 任务和标注过热缓存的数字；「—」表示未测，不是 0。真实负载数据来自 2026-10-23 的 /metrics 聚合。单卡只有一条历史 copy 记录（提示长度未记录），双卡为今日补测，调优状态不同，所以凡涉及"加卡快多少"的地方只给整体口径，不拆到卡上。

另附一张实际跑一个小项目的实况截图以供参考。真实体感是双卡比单卡爽太多了，跑任务速度肉眼提升！