Optimization progress report
当前最好部署、有效优化与精度风险复盘
2026.08.09 · Mid-project Review
Current best result
同一长输出口径：单并发、prompt 约 84 token、输出 2048 token、streaming 首 token 不计、temperature=0、thinking=false。
三轮为 76.08 / 71.58 / 70.60 tok/s
TTFT 约 290 ms；尚未稳定常驻到 80
B186 固定负载；GPU 周期中位约 64.17 ms
3轮中位 / 最好单次；MTP6 配置
按 SGLang 中位数计算，需要再省约 6.7 ms
512-token stream；不同输出长度，仅用于看演进
说明：fixed effective tok/s 会被 MTP 接受率波动影响；分析 kernel 收益时优先看 verify latency。各页增益不可直接相加。
Machine & benchmark
gx10-2ebe · SSH :43333
NVIDIA GB10 · 20-core ARM
121 GiB 统一内存 · 273 GB/s 理论带宽
TP 地址 192.168.100.11
服务入口 :30000 · earlyoom active
gx10-74a7 · SSH :43322
NVIDIA GB10 · 20-core ARM
121 GiB 统一内存 · 128 GB LPDDR5X
TP 地址 192.168.100.10
双 RoCE 数据口 Up · earlyoom active
服务 CTX=8192；长输出测试实际约 84 + 2048 token。MEMFRAC=0.758，不能用 0.85；压测不使用 ignore_eos。
Best deployment stacks
71.58 median · 76.08 best
72.19 median · 74.77 best
“无额外精度损失”是相对当前原生 FP8/NVFP4 checkpoint 而言，并不表示模型等同于全 BF16。FP8 KV cache 的风险另有专页。
Optimization 01 · speculative decoding
动机：大模型逐 token 解码很慢。如果小型 draft 能提前猜中多个 token，就能把一次大模型计算摊到多个输出 token 上。
平均 committed 约 4.23 → 4.73；verify 成本约 +7.3%，但每轮交付更多 token。gamma=7 的 fixed 反而 −4.6%。
exact verification 保证最终 token 仍由 target 决定。网上“MTP 开大质量下降”主要针对直接采用 draft 输出，不适用于本部署。
数字置信度：高 · B67/B68 同口径 A/B
Optimization 02 · attention path
动机：通用 attention 为很多模型准备了转换、检查和临时张量；DeepSeek-V4 的形状固定，这些通用步骤在短解码里会显得很贵。
这是“修正执行路径 + 去掉框架开销”的合并效果，不应理解成单个 attention kernel 独自提升 3.8×。当前 trace 中 attention 只剩约 0.98 ms/verify。
计算的仍是同一 DSV4 attention；只改变调用路径。可能存在普通浮点末位差异。
数字置信度：中 · 历史阶段结果，非当前逐项 A/B
Optimization 03 · draft projection fusion
动机：draft 模型很小，真正计算时间不长，反而容易被“启动两个 kernel、写回中间结果、再读回来”的固定开销拖慢。
B50 → B58：stream 58.32 → 67.03；fixed 56.93 → 60.68。这是目前最清晰的单项端到端收益。
融合可能改变 draft 的浮点舍入与接受率，但最终结果仍经过 target exact verification。
数字置信度：高 · 端到端 A/B
Optimization 04 · FlashMLA shape
动机：同一个 attention kernel 并非所有 head 数都高效。GB10 上的短序列、小批次，需要较小的工作分块，避免很多线程空等。
B58 → B59：stream 67.03 → 67.37；fixed 60.68 → 61.75。单项不大，但方向稳定，已常驻。
只更换执行形状；数学操作不变。仍可能有浮点规约顺序造成的末位差异。
数字置信度：高 · 同口径 A/B
Optimization 05 · native NVFP4 MoE
动机：MoE 专家权重占模型主体。若先完整反量化再计算，统一内存容量和带宽都会吃不消；默认后端对这个 DeepSeek-V4 NVFP4 形状也不够理想。
它解决的是“能否在两台 128 GB Spark 上高效跑原生 NVFP4 MoE”。当前每个 verify 的 W4 累计约 30.9 ms，也是后续最大瓶颈。
没有再次量化；相对当前 NVFP4 checkpoint 无额外损失。相对全精度模型，量化损失已由 checkpoint 本身引入。
效果量级：决定性；精确 tok/s 无干净 A/B
Optimization 06 · W4 small-M kernel
动机：每次 target 验证只有 7 个 token。通用 GEMM 按 16 行或更大分块，会让大量线程计算填充行，并浪费 shared memory。
代表性演进：72.86 → 71.73 ms；最后 stage 2 调整约 67.91 → 67.74 ms（约 0.25%）。单个子改动易受并行重叠影响。
仍使用相同权重、scale 和输出定义；变化在 tile、加载与流水调度。
数字置信度：中 · 多项累积，非完全正交 A/B
Optimization 07 · MHC/residual fusion
动机：归一化、残差相加和 MHC 统计本身计算不多，但若每一步各起一个 kernel，启动和读写成本会超过计算本身。
当前 trace 中 MHC 累计约 1.90 ms/verify，几乎都在关键路径；说明仍值得继续压，但已不是第一大项。
数学公式不变；融合可能改变浮点求和顺序，理论上会有末位误差，但没有模型级算法损失。
数字置信度：低到中 · 依据 trace 与历史组合版本估计
Optimization 08 · FP8 projections
动机：LM head 和若干 projection 每轮都要读很大的权重。使用 checkpoint 自带的 FP8 权重，可降低读取量，并针对固定 shape 选择更合适的 GEMM。
这是 draft LM-head FP8 专用路径的代表性前后差异。当前 FP8 blockwise GEMM 累计约 18.4 ms，但大部分已与其他工作重叠。
相对当前 FP8 checkpoint 无新增量化；相对 BF16 全精度仍存在 checkpoint 固有误差。
数字置信度：中 · B133 → B142，相邻版本接受率有波动
Optimization 09 · Markov head GEMM
动机：DSpark draft 每轮都要通过 Markov head 为候选 token 打分。它比主模型小，但调用频繁，通用实现仍会积少成多。
B142 → B143 的代表性改善约 0.80 ms/verify。真实 stream 收益会随候选接受长度变化。
draft 分数可能因 FP8 舍入改变候选或接受率；最终 token 仍由 exact target verification 决定。
数字置信度：中 · 相邻 fixed 版本
Optimization 10 · native page 256
动机：KV cache 像一本按页存放的书。页太小会频繁查目录，页布局不匹配则需要拆分和重排；DSV4 对 256-token 页有专用路径。
B143 → B145 包含 page split/native page-256 路径的组合收敛，是后半程最大的 verify latency 改善。
只改变 KV cache 的分页与访问方式，不改变保存的数值；精度风险来自下一页所述 FP8 KV dtype。
数字置信度：中 · 两个相邻页面相关版本的组合效果
Optimization 11 · FP8 KV cache
动机：上下文越长，KV cache 越大。把 BF16 的 key/value 压成 FP8，理论上可将这部分容量和读取量减半。
当前日志提示没有提供专用 KV scaling factors，默认 scale=1.0。exact speculative verification 无法修复 target KV 量化误差。
这是当前栈中最需要单独做质量回归的优化；建议补长上下文 perplexity/任务集 A/B。
性能数字置信度：低 · 风险判断置信度：高（运行时明确告警）
Optimization 12 · cross-node NCCL
动机：TP2 每层都要把两台机器的部分结果合并。如果 collective 慢，GPU 即使算完也只能等另一台。
大 payload all-reduce 约 0.400 → 0.220 ms。当前 trace 中 NCCL 仍约 5.0 ms/verify，且几乎完全暴露在关键路径上。
collective 数学不变；不同规约树/协议可能改变浮点末位，但不是模型级近似。
CTA=4 数字置信度：高；双 HCA 端到端增益仅有量级估计
Optimization 13 · CUDA Graph
动机：一次 verify 包含上千个小 kernel。逐个由 CPU 下达命令会产生空档；CUDA Graph 将固定流程预先录制，运行时一次提交。
CG6 在 C6 为 184.30 tok/s。CG16 在 C16 仅 +1.64%，却让 C6 从 184.30 降到 169.33（−8.1%），故保留 max BS=6。
只是重放相同 kernel；temperature=0 下 local argmax 与原 greedy 选择一致。
并发 A/B 置信度：高；C1 单独收益无当前 eager 对照
Optimization 14 · direct route preplan
动机：draft 每轮只有 6 个 token。先把 token 按 expert 打包再启动 MoE，准备工作可能和真正计算一样显眼；固定 graph shape 可以提前计划。
B185 → B186 改善约 0.39 ms/verify。当前 route/epilogue 累计约 0.77 ms，但几乎全部被其他计算隐藏。
token-to-expert 映射不变，只把准备步骤提前并选择专用 launch。
数字置信度：中到高 · 相邻 fixed A/B
Current bottleneck & next move
B186 每个 verify 的“未被其他 kernel 隐藏”时间；这是比简单累计 kernel 时间更接近关键路径的口径。
已否决：W4 blocks/SM=2/3、direct scale load、FP8 Stream-K、锁高 GPU 时钟。它们不是“方向错误”，而是当前具体实现均在完整图中负收益。