本文档说明实验内部使用的容量、吞吐、流平衡与 Split 子策略。用户入口和复现
命令见项目根目录的 README.md。
- 一台机器是固定的 8×H100 80GB、8-way tensor parallel 实体,总显存
C = 640 GB; - 模型权重容量为
C_w; - 忽略 P/D 传输 KV Cache 的延时与容量开销;
beam = 1,并忽略序列长度对 Decode 容量的额外影响;- Prefill、Decode 长度分别为
L_p、L_d; - Prefill batch 为
B_p = n_p L_p,Decode batch 为B_d = n_d。
用下列函数表示两阶段的 batch scaling:
容量函数对每个阶段的全部散点分别做二次最小二乘拟合:
吞吐函数可选择相同的二次拟合,或对 Figure 6 每个独立 label 使用端点截断的 分段线性插值。集群实验只调用 BLOOM-176B 的 Prefill、Decode 两条曲线。
每台机器同时承担 P/D,同机请求并发相同,即 n_p = n_d = n。容量边界为:
如果 α ∈ (0,1) 是机器分给 Prefill 的时间比例,请求流平衡要求:
X 台机器的实际阶段吞吐为:
对应的可持续请求率为:
设 x 台机器属于 Decode 池,X-x 台属于 Prefill 池。程序分别构造两类候选
策略,求出整数节点分配后选择可持续 RPS 较高者。
两侧先分别取容量允许的最大 batch:
再选择最接近并发平衡 (X-x)n_p ≈ xn_d 的整数节点分配。固定 batch 和节点
后,用时间利用率 α_p, α_d ∈ (0,1] 限制更快的一侧:
至少一侧时间利用率为 1。若 Prefill 侧达到 1,记为 CUF-P;若 Decode 侧达到 1,记为 CUF-D。阶段吞吐为:
两侧时间利用率都取 1,同时满足请求并发和 RPS 流平衡:
其中一侧 batch 达到容量允许的上限,另一侧 batch 相应缩小。Prefill batch 达到上限记为 TUF-P,Decode batch 达到上限记为 TUF-D。连续解映射到整数节点 后,程序重新计算可行 batch、并发残差和 RPS 残差。
Split 的可持续请求率为:
实验报告两个阶段的实际吞吐倍率:
由于 Baseline 和 Split 都强制请求流平衡:
因此两幅阶段热力图数值相同,但仍分别保留,明确表示两个阶段实际交付的 token 吞吐都按同一请求流获得提升或下降,而不是只比较某一侧的孤立峰值吞吐。
机器池必须使用整数节点。程序枚举可行的 x ∈ {1,…,X-1},分别生成 CUF 和
TUF 候选,并记录:
- Prefill/Decode 节点数与 batch;
- batch 容量利用率和时间利用率;
- 并发平衡残差与 RPS 平衡残差;
- 实际交付的 P/D token/s 与可持续 requests/s。
最终候选按可持续 RPS 最大化选择。策略分类中的 P/D 后缀采用以下定义:CUF 标记时间满载阶段,TUF 标记 batch 容量满载阶段。
普通二次容量拟合的逆函数可能没有在观测域内精确达到 C = 640 GB。程序在
指定可行域内采用最近的数值边界并在结果中记录是否为精确逆解。吞吐的
piecewise-linear 模式在观测域之外采用端点值,避免无限线性或二次外推,但
容量模型仍可能外推。相关状态保存在 results/model_parameters.json。