qqtang/sskj
1
3
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
sskj/experiments/pro6000/glm53_nvfp4_128k_capacity_topology/README.md
yy-fighting 92517e87f0 128k low-cc capacity topology: TP2PP4-nomtp winner (60.8 serving, 60.5 v2 delivered, 09-09) 
诊断 60.5 排队根因：KV 池 276,864 token 纯容量算术（MLA KV 按 PP 分层切分，
池≈PP 度数倍增；TP8 调参无解，fp8 断言封顶 314,944 < c3 需求 394,752）。
四臂对拍（i128k/o512 冷缓存 cc1-4，PG19 真实语料同窗口映射）：
- A-mirror(60.5 现状)：c3 起容量排队，cc4 TTFT p50 119.6s，痛点复现
- r37(TP4PP2+MTP)：池 384,960，c3 起排队
- B'(TP4PP2 nomtp)：池 589,696，c4 零排队
- TP2PP4 nomtp 池 909,632 优胜：cc4 in 5907 / out 23.1 tok/s，
  TTFT p50 全场最优（cc1 15.5s），e2e 88.8s
优胜者验证全过：质量门 7/7；512k 单条 TTFT 88.4s；900k 单条可完成
（单条上限 ~909k 实证）；并发上限 c6（cc7 第 7 条起排队）；hit90 cc4
输入吞吐 17,625 tok/s、TTFT 7.3s。
60.8 末态：TP2PP4 容器在役（restart=unless-stopped）。
60.5 交付：deploy_glm53_605_v2.sh（一键部署+前置检查，原脚本=回滚路径）。
资产：arm_runner.sh / val_runner.sh / all_summaries.json(26 点全量) /
profile glm53_nvfp4_pro6000_sglang_tp2pp4_hicache.env / CURRENT.md 两行更新。
2026-09-09 12:43:11 +08:00

11 KiB
Raw Blame History

GLM-5.3-NVFP4 128k 低并发容量扩容与拓扑选型实验报告 — 2026-09-09 @ 174.1.60.8

一、结论速览

优胜配置 = TP2PP4 nomtp（radix/hicache 保持开启、--context-length 1048576、cu13 栈 9 挂载、memfrac 0.85、chunk 8192）。

维度 60.5 现役（TP8+EAGLE） 优胜配置（TP2PP4 nomtp） 提升
KV 池（token） 276,864 909,632 3.29×
i128k 并发上限 c2（c3 起排队） c6（c7 起排队，实测） 3×
单条请求上限 264k（ctx 270,336 参数所限） ~909k（900k 实跑通过） 3.4×
c4 输入吞吐 3,228 tok/s 5,907 tok/s 1.83×
c4 输出吞吐 12.6 tok/s 23.1 tok/s 1.83×
c4 TTFT p50 119.6s 43.4s −64%
c4 e2e p50 161.3s 88.8s −45%
90% 命中真实流量形态（c4） — 输入 17,625 tok/s、TTFT 7.3s —
  • 质量门 7/7 通过（GSM8K×5 + 中文推理 + tool call，PP4+radix+hicache+parser 新组合无 correctness 问题）。
  • 60.8 已按用户决定部署优胜配置留役（restart=unless-stopped，替代 r37）。
  • 60.5 交付 deploy_glm53_605_v2.sh（只交未执行），原 deploy_glm53_605.sh 原样留盘即回滚路径。

二、问题诊断（60.5 生产日志实证）

现役容器 glm53-nvfp4（TP8 + EAGLE 4/1/5，memfrac 0.90，fp8 KV，hicache-ratio 3，--context-length 270336）：

  1. "单条最高 256k" 不是模型限制：模型原生 max_position_embeddings = 1,048,576（1M）。上限来自部署参数 --context-length 270336，且 KV 池 276,864 也刚好只装得下一条 26.4 万请求。
  2. 排队是纯容量算术：单条 1622 万 token 请求占池 0.580.90；近期一万行日志 ~13% 的 decode 步有 #queue-req>0，09-08 有一次池满 retract。日志实例：一条 173k（95% 命中）请求在 160k 请求 decode 期间排队无法准入。
  3. 命中不省并发容量：radix/hicache 只加速重复前缀的 prefill；不同文档的并发请求各自全额驻留 KV，照样排队。60.5 真实流量 12万~22万 token、命中率 90%+，仍然撞容量墙。
  4. TP8 调参无解（结构性）：每 token KV 57.3KB（MLA 44.9 + DSA indexer ~10），fp8_e4m3 已是断言封死的硬顶（FP4 启动即 AssertionError）；TP8 全系调参上限 314,944（60.6 实测 0.89+hicache4）< c3×128k 需求 394,752。

三、机理：为什么只有 PP 拓扑能解

GLM-5.3 是 MLA/DSA 家族，KV 在 TP 组内每卡全量复制、只按 PP 分层切：TP8 每卡存全部 78 层 KV（15.85GB→276,864 token）；PP2 每卡存半数层（池×2）；PP4 每卡存 1/4 层（池×4，实际因 hicache/图开销打折）。KV 池容量 ≈ PP 度数倍增，与 TP 度数无关。这就是 TP4PP2≈2.37×、TP2PP4≈3.29×（实测）的来源。另：MTP/EAGLE 的 draft KV + verify 图额外吃池（r37 同 memfrac 下 589,696→384,960，−35%）。

四、实验方法

  • 平台：60.8（8×RTX 6000D 85.6GB，与 60.5 同型）；四配置臂各部署后跑同窗口。
  • 场景：i131072 / o512 / cc∈{1,2,3,4}，nreq=8/点，PG19 真实语料（bench_corpus.py，input_ids 直发 /generate，temp 0，ignore_eos，stream）。
  • 公平性协议：每点独立语料窗口（cc1→base 10M，cc2→11,048,576，cc3→12,097,152，cc4→13,145,728），所有臂用同一映射=同文本；每点前 POST /flush_cache（实测连 host 层一起清，复跑命中率 0.0）；每臂先做一次不计分的 131k 形状预热（吸收内核首触成本，实测不做会污染首点：16k 首跑 1653 vs 复跑 4526 tok/s）。
  • 指标口径（沿用 rev20 双场景协议）：输入吞吐 = 总输入 token/墙钟；输出吞吐 = 服务端 completion_tokens 总和/墙钟；TTFT = 发出→首个流式响应（含排队）；命中率从 TP0 Prefill 日志核算。queue-req 日志用于排队取证。
  • 配置臂：
    • arm0 r37：60.8 在役原样（TP4PP2+EAGLE 3/1/4+verify 图，memfrac 0.88，池 384,960）
    • arm1 A-mirror：60.5 现役逐参数复刻（旧镜像 20260828，池 276,864，ctx 270,336）
    • arm2 B'：TP4PP2 nomtp，memfrac 0.88，ctx 524,288（池 589,696）
    • arm3 TP2PP4：TP2PP4 nomtp，memfrac 0.85，ctx 1048576，radix/hicache 开，含 glm45/glm47 parser（池 909,632）

五、主扫数据（i128k/o512，冷缓存）

输入吞吐（tok/s）

cc A-mirror（池276,864） r37（池384,960） B'（池589,696） TP2PP4（池909,632）
1 3,026 4,110 3,737 3,262
2 3,142 4,754 4,619 4,635
3 3,214 5,016 4,843 5,017
4 3,228 5,061 5,256 5,907

输出吞吐（tok/s）

cc A-mirror r37 B' TP2PP4
1 11.8 16.1 14.6 12.7
2 12.3 18.6 18.0 18.1
3 12.6 19.6 18.9 19.6
4 12.6 19.8 20.5 23.1

TTFT p50 / max（秒）（排队签名 = p50 跳升整请求时长倍数）

cc A-mirror r37 B' TP2PP4
1 37.8 21.1 21.0 15.5
2 37.8 / 76.9 21.1 / 41.7 41.3 29.0
3 77.2 / 120.3 43.6 / 73.8 41.3 / 61.6 29.6 / 43.4
4 119.6 / 156.4 72.2 / 93.9 61.6 / 81.9 43.4 / 57.3

e2e p50 / max（秒）

cc A-mirror r37 B' TP2PP4
1 43.8 31.7 35.0 40.2
2 83.7 / 121.6 55.3 / 76.6 56.8 56.5
3 121.7 / 163.3 75.2 / 105.1 80.0 75.8
4 161.3 / 201.8 103.3 / 125.2 99.7 88.8

排队证据与机理注解：

  • A-mirror：池只容 2 条并发，c3/c4 排队（TTFT p50 77→120s）；c4 输入吞吐被排队锁死在 3,228（prefill 带宽根本没用满）。
  • r37：池 384,960 同样只容 2 条 + 1 条错峰补位，c3/c4 排队（TTFT p50 43.6→72.2s；日志 518 行 queue-req>0）。60.8 原在役配置在本场景也不合格。
  • B'：c3/c4 全并发准入、零容量排队（稳态 usage 精确停在 0.22/0.45/0.67/0.89；e2e p50≈max 波内同步）。日志中的 queue-req 行是 chunk 调度/波间 radix 逐出瞬态（秒级），非容量排队——判据：TTFT 缩放=纯 prefill 带宽分摊（cc2 p50=max=41.3≈2×21.0）。
  • TP2PP4：同上零容量排队，且 TTFT 全场最优（4 级流水 prefill 重叠最深：cc1 TTFT 15.5s、串行 prefill 等效 ~8.5k tok/s）；代价是 TPOT 最慢（cc1 48.4ms vs B' 27.3 vs r37 20.7 vs A 12.0），c1 短输出场景 e2e 吃亏（40.2s），c2 起被并发摊平、c3/c4 反超。
  • MTP/EAGLE 观察：accept 随并发上升（r37 2.91→3.64，A-mirror 3.31→4.26，verify batch 越大接受越高）；但 MTP 的 35% 池代价在本容量场景不划算——r37 全程吞吐被 B'/TP2PP4 压制或打平。

六、优胜者（TP2PP4）附加验证

验证项 结果
质量门 7/7（GSM8K 72/3/60/63/10 + 鸡兔同笼 23 + tool call get_weather北京）
512k 单条（523,776+512 真实语料） ✅ TTFT 88.4s，e2e 114.4s，TPOT 50.9ms（旧配置直接拒绝）
900k 单条（900,000+512） ✅ TTFT 210.6s，e2e 237.8s —— 单条上限 ~909k 实证（池减 512 后的余量）
cc5 ✅ in 5,747 / out 22.5，e2e p50≈max 107s，零容量排队
cc6 ✅ in 5,849 / out 22.9，e2e p50≈max 122.7s，零容量排队 —— 并发上限 = c6
cc7 ⚠️ 第 7 条排队（TTFT max 138.7s、e2e max 179.7s）—— 边界与池算术吻合（7×131,584=921,088 > 909,632）
90% 命中 c4（60.5 真实流量形态，实测命中 0.8999） in 17,625 / out 68.9 tok/s，TTFT p50 7.3s，e2e 29.9s —— radix 去重+hicache 对重复查询流量再放大 ~3×

七、方案对比与推荐

方案 池 c4 in/out 容量定位 判定
A（TP8+EAGLE，60.5 现役） 276,864 3,228/12.6 c2、单条 264k 本场景被全面支配，淘汰
r37（TP4PP2+MTP，60.8 昨日在役） 384,960 5,061/19.8 c2、单条 ~380k c3 起排队，容量不合格；仅 c1 最优
B'（TP4PP2 nomtp） 589,696 5,256/20.5 c4、单条 ~588k（512k 单条会占 89% 池、堵死并发） 强力备选：16k 短文本场景历史成绩好
TP2PP4 nomtp（优胜） 909,632 5,907/23.1 c6、单条 ~909k、512k 单条+2 并发共存 用户需求（512k 单条+长上下文为主）下的正解

推荐：60.5 采用 TP2PP4 nomtp（deploy_glm53_605_v2.sh，参数与 60.8 现役完全一致）。决策依据：c3/c4/c5/c6 吞吐全场第一 + 唯一满足"512k 单条与并发共存" + 质量门 7/7 + TTFT 全档最优。若 60.5 未来 16k 短文本流量占比显著上升，再评估切 B'（其 s1 短文本历史成绩比 TP2PP4 好 27~48%）。

留观旋钮（未验证，报告只记录不推荐）：memfrac 0.85→0.88 或可再抬池（PP0 空闲 22GB 最大的 stage 不均匀提示有空间）；TP2PP4+MTP 可修 c1 短输出短板（池约降至 ~59 万，恰为 B' 水平）；hicache-ratio 3→4 扩 host 前缀池（60.6 在 TP8 验证过）。

r37 角色变化说明：r37 的 MTP 优势区间是 i16k/cc≤16（09-09 判决 +6%@cc16），本次让位给容量优先的 TP2PP4 是按用户明确选择执行；若 60.8 未来主要服务短文本低并发，可用 deploy_ppmtp_r37.sh mtp 模式一键切回。

八、已证伪 / 排除项（本轮+引用前判）

  • TP8 任何调参：fp8 KV 断言封顶 + 上限 314,944 < c3 需求 394,752（60.6 数据）。
  • r37 现役直接顶上：池 384,960，c3 差 1 万 token 仍排队（本轮实测）。
  • MTP/EAGLE 换 KV 池：draft+verify 图 −35% 池，本场景不划算。
  • HiSparse 超池驻留：本 nightly 自旋不可用（60.6 前判）。
  • TP1PP8：池 2M 但吞吐 −12~33%（60.2 前判），仅当需要 >c6 且能接受慢时再议。
  • PD 分离/DP/EP：前判劣化或不可用，与本问题正交。

九、资产与复现

  • 60.8：容器 glm53-nvfp4:30000 = 优胜配置，restart=unless-stopped。启动命令 = bash /root/deploy_ppmtp_r37.sh '--tp 2 --pp-size 4 --disable-overlap-schedule --max-prefill-tokens 16384 --disable-custom-all-reduce --context-length 1048576' nomtp 8192 0.85。实验日志全量：/root/bench_logs/128kexp/（26 点 SUMMARY 已提取为 all_summaries.json）。
  • 60.5：交付 deploy_glm53_605_v2.sh（内嵌完整 docker run+前置检查+显存归零等待+健康门+回滚提示）；回滚 = bash /root/deploy_glm53_605.sh。执行前置检查会列出缺失的补丁/镜像清单（60.8 /root 均有）。
  • 压测复现：bash /root/arm_runner.sh <arm>（c1-4 四点+形状预热）、bash /root/val_runner.sh <arm>（512k/900k/cc5-7/hit90）；语料窗口映射与 flush 协议见第四节；质量门 bash /root/quality_gate_605.sh。
  • 仓库归档：experiments/pro6000/glm53_nvfp4_128k_capacity_topology/（README=本报告、scripts、results/20260909）；profile deploy/profiles/pro6000/glm53_nvfp4_pro6000_sglang_tp2pp4_hicache.env；CURRENT.md 已更新 60.8 行。

报告与数据：ZCode 实验 2026-09-09；压测窗口 run-id 9501-9507/9601-9604/9990-9991；全部冷缓存口径。