一句話：prefill 是串行的，context 上限是算出來的——C=3 + 131,072 + nvfp4 450K pool 是這顆卡上「3 路滿載並發 + 活的 agent session」全在 device 的最大窗口。

1. 跟上一篇的分別

上一篇（lcz.me/topic/1228，13.7 小時真實編程負荷，int8 KV）的結論是「agent 負載 98.6% 是 prefill，最佳 C=2」。這篇換三個變量：

1. KV 換 nvfp4——NInfer 近期新增的 feature（--kv-dtype nvfp4，上一篇的路線還是 int8 KV）；pool 從 262,144 提到 450,560 tokens（reservation 省約 1 GiB，token 容量反而多 73%）；
2. 把 context 窗口鎖在 DSH 實際會觸發 compact 的上限（floor(0.8 × contextWindow)，thresholdRatio 0.8）去壓力測試，而不是拍一個整數；
3. 拿官方 docs/performance.md 的完整方法學（MTP0 長 prompt profile + MTP3 corpus × C=1/2/4/8）跑一遍，跟發布參考值逐項對。

2. 環境與測法

3. 壓力測試：s1–s4 + C4

3-1. TTFT ladder（各路同時提交，engine-measured）

每條線都恰好是 solo prefill 時間 × 1/×2/×3——prefill 嚴格 FIFO 串行，每路都在用 solo 速度跑。所以 TTFT 的規劃公式非常簡單：TTFT(第 k 條) ≈ k × (prompt_tokens / solo_prefill_tps)。

3-2. Solo prefill 隨 context 遞減

3-3. Decode

256-token 短 output 下，每路 95–146 tok/s（MTP3）。output 太短 batching 收益未完全展開；長 output 的數字見第 5 節 doc campaign（155–419 tok/s）。

3-4. Pool 從不 OOM、從不排隊阻塞

所有壓力窗口 materializing=0、無 pool-queue 等待、零 request 失敗。s3 / s4（pool 被 3×157k / 3×143k 占滿）的實際代價是：閒置的 parent session（就是這篇所在的 DSH 對話）被 dematerialize 到 host 冷層（host_active_ms 小幅抬升），它後續的請求照常完成。s1（3×105k + session ≈ 419k ≤ 450,560）則完全沒有 offload——全部狀態留 device。

4. C=3 vs C=4（同一 104k workload）

C4 的 prefill 略快（≈4,358 vs ≈4,090 tok/s）是因為那是全新、無 resident session 的 server，不是並發度帶來的——斜率（每路的 solo 時間）兩邊一樣。C=4 的真實成本：4 路占滿 pool 後 parent session 被擠到 host 層。結論：維持 C=3。

5. docs/performance.md 對照官方發布值

方法學完全照搬（INT8 KV / 131,072 / kv-capacity auto / stochastic / fixed shuffle / 75 requests per point）。

5-1. MTP0 context-length profile（Long NIAH，n=5）

5-2. MTP3 corpus makespan（75 requests/point）

發布參考值裡 C=8 被 memory pressure 壓到 avg batch 2.36（比 C=4 慢 31%）；本 build 的 C=8 avg batch 3.32，已追平 C=4（1,780 vs 1,766 s）。C=4 仍是 makespan 最優點；C=3 是 450K pool + live session 的線上的操作點。 makespan Δ 混雜 stochastic 抽樣長度（decode tokens 690k–746k 各異），decode tok/s 較乾淨。

5-3. MTP3 per-fixture（C=1 point，n=5/fixture）

最大偏差 −7.6%（aime 30，stochastic 高變異 fixture，在參考值自身 1σ 內），其餘均在 ±3.1%。判定：零回歸。 300/300 requests 完成，無 request / CUDA / OOM 失敗。

6. 為什麼 131,072 是 C=3 的最佳 context

DSH 的自動 compact 在上限 = floor(0.8 × contextWindow)（thresholdRatio 0.8）觸發；policy 只讀 settings.yaml 的 contextWindow，從不參考 server 的 model discovery。pool 規劃 = 3 路在上限 + 1 條活的 session 在上限 ≤ 450,560：

contextWindow	compact 上限	3 路 + session	Pool 450,560
131,072	104,857	3×104,857 + 104,857 = 419,428	容納，margin 31,132
196,608	157,286	3×157,286 = 471,858	超 21,298（只能 C=2）
262,144	209,715	3×209,715 = 629,145	超 178,585（只能 C=2）

實測佐證：s1（3×105k，131k line）materializing=0、session 全程留 device；s4（3×143k）3 路照跑，session 轉 host 冷層繼續工作。131,072 是「3 路滿載並發 + 活 session 全在 device」的最大窗口。 配置：server 保持 --max-context 262144（只作 backstop），DSH settings.yaml 改 contextWindow: 131072，host restart 後生效。

7. 新發現 / 坑

1. --max-concurrency 不加速 prefill。 NInfer 的 prefill 是 FIFO 串行：每路用 solo 速度跑，TTFT 就是隊位 × solo 時間。並發度只決定「同時能 decode 幾條」。
2. 改 server --max-context 防不了 compact。 DSH compact policy 只讀 settings.yaml 的 contextWindow；只把 server 調大，session 照樣在 0.8× 老窗口觸發 compact；走錯方向（server 比 DSH 窗口小）反而會觸發 CONTEXT_WINDOW_EXCEEDED → forced max balanced head reduction + 1 retry 的錯誤路徑。
3. Pool overflow 不 OOM、不排隊。 超限時 engine 把最低優先的 resident（閒置 session）dematerialize 到 host 冷層，不是拒絕請求。體感代價 = 那個 session 自己的請求多一點 host 往返。
4. 輸入 tokenization 校準：0.47 tok/byte。 隨機字/十六進制/數字是 tokenizer 最壞情況；100 KB ≈ 47.7k tok；600 KB 直接超 262,144 tok（server error）。做 calibration 記得用 ≤100 KB 的切片。
5. nvfp4 pool 比 int8 大（nvfp4 KV 是 NInfer 近期新增的 feature，--kv-dtype nvfp4）。int8 262,144 pool reservation ≈11.20 GiB；nvfp4 450,560 = 9.89–10.21 GiB——省下的 ~1 GiB 直接變成多 73% 的 token 容量。
6. C=8 在本 build 不再 memory-throttled（doc campaign：avg batch 3.32 vs 參考 2.36），makespan 比發布值快 17.8%；但 C=4 仍是 makespan 最優。

8. 最終配置

9. 限制與未測

• 壓力輸入是最壞 tokenization 的隨機文本：真實 prompt 每 byte 更快，但真實 agent 負荷吃 prefix cache（上一篇 97–99% hit）——兩種 workload 的 prefill 數字不要直接互比。
• 壓力段 output 只有 256 tok：batching 的 decode 收益未完全展開；doc campaign 的 4,096+ output 更代表實戰（155–419 tok/s）。
• stochastic 抽樣：per-fixture decode 有 ±5% 級別抽樣噪聲（參考值 aime 30 自身 σ=23.7 tok/s）。
• doc campaign 用 INT8 KV（方法學固定），跟壓力段的 nvfp4 數字不同 pool、不同 dtype，不可直接互比。
• C4 ladder 跑在全新 server（無 resident session），solo baseline 比 s1 快 ~7%（23.9 vs 26.4 s），C3/C4 對照不是嚴格同條件——但結論（斜率不變、成本在 host offload）不受影響。
• WSL2；全部數字可從 serve log 的 status=done 行與結果目錄逐項核對。

數據與複現：全部結果目錄在本機 WSL home 下：壓力 ~/ninfer_stress_032756/（s1–s3）、~/ninfer_stress_s4_033927/（s4）、~/ninfer_c4_test_083409/（C4）；doc campaign ~/ninfer_doc_test_20260902_035140/（mtp0_corpus/summary.csv、mtp3_makespan/points/*.json、每 request server jsonl），pointer ~/ninfer_doc_test_latest；engine build 21a0e85f，docs 參考 docs/performance.md。

本篇由本地全棧生成：NInfer（自寫引擎）驅動 DeepSeek Harness（agent 框架）跑完全部測試與數據整理，圖表由本地 Python 生成，全部數字可從上述結果目錄與 ninfer_serve.log 逐項核對。歡迎複現或打臉。