5.3 KiB
五、怎么从理论上建模这个 principle
这个现象很适合用一个“固定 GPU 预算下的排队模型”来解释。
1. 固定总 GPU 数
设总 GPU 数固定为 $G$，选择的 tensor parallel size 为 $t$。
那么可部署的实例数是：
m_t = \frac{G}{t}
这是整个问题最核心的约束。 因为 TP 变大，带来的不是“免费加速”，而是“用更多 GPU 服务一个 instance”，因此 instance 数会减少。
2. 单请求 service time
对某个 workload window $w$，在 TP 为 t 时，一个请求的 service time 可以写成：
S_t(w) = S_{\text{comp}}(w,t) + S_{\text{comm}}(t) + S_{\text{sched}}(w,t)
其中：
计算项
S_{\text{comp}}(w,t) \approx \frac{A(w)}{\eta_t}
A(w)表示该窗口请求的纯计算量\eta_t表示 TP 带来的 speedup，通常是次线性的，即\eta_t < t
通信项
S_{\text{comm}}(t)
这个项通常随 TP 增大而上升，包括：
- all-reduce
- synchronization
- cross-GPU launch / coordination
- pipeline / collective overhead
调度与干扰项
S_{\text{sched}}(w,t)
这个项反映的是：
- batch 内请求相互干扰
- 长请求阻塞短请求
- 调度器等待
- cache / memory / token budget 竞争
3. 为什么低负载下大 TP latency 更好
低负载时，排队几乎可以忽略，因此：
\text{TTFT}_{p95}(t,w) \approx S_t(w)
此时系统 tail latency 基本由 service time 决定。
如果 workload 比较 prefill-heavy，或者单请求计算量较大，那么：
- 计算项占主导
- TP 的并行收益大于通信损失
于是会出现：
S_{TP4}(w) < S_{TP1}(w)
这正对应你在低负载图里看到的现象：
TP4 的 p95_{ttft} 明显优于 $TP1$。
4. 为什么低负载时 good\_token/s/GPU 差异很小
定义 TP 为 t 时，单实例可提供的最大处理能力为 $R_t(w)$。
那么整个集群总能力是：
m_t R_t(w) = \frac{G}{t} R_t(w)
按 GPU 数归一化后，单位 GPU 能力为：
C_t(w) = \frac{1}{G} \cdot \frac{G}{t} R_t(w) = \frac{R_t(w)}{t}
如果 TP 加速接近线性，即：
R_t(w) \approx t R_1(w)
那么：
C_t(w) \approx R_1(w)
也就是说单位 GPU 吞吐几乎不变。
但更关键的是，在低负载下，真实 goodput 不是被 capacity 限制，而是被外部到达流量限制。于是：
\text{goodput}_t(w) \approx \text{offered load}
因此不同 TP 的 good\_token/s/GPU 看起来会非常接近。
这正是你在 time\_scale=0.5 里看到的现象。
5. 为什么高负载时更小 TP 更占优
一旦负载升高，问题就不再只是单请求 service time，而变成“每个 instance 会不会排队”。
假设整个集群的总到达率是 $\lambda$，那么在 TP 为 t 时，每个 instance 平均承担的到达率是：
\lambda_t = \frac{\lambda}{m_t} = \frac{\lambda t}{G}
这非常关键，因为它说明：
- TP 越大
- instance 数越少
- 每个 instance 的流量越重
于是实例利用率约为：
\rho_t = \lambda_t \cdot \mathbb{E}[S_t]
= \frac{\lambda t}{G} \mathbb{E}[S_t]
当 \rho_t 接近 1 时，排队延迟会急剧放大。
因此 tail latency 可以近似理解为：
\text{TTFT}_{p95}(t,w)
\approx S_t(w) + W_q(t,w)
其中 W_q 是 queueing delay。
而 W_q 会随着以下因素快速上升：
\rho_t上升- service time variance 上升
- instance 数
m_t减少 - workload burstiness 增加
这就是为什么高负载下，虽然大 TP 可能让单请求更快，但整体上却不一定更优： 因为它牺牲了多实例并发能力，把更多流量压到更少的 instance 上，最终 tail latency 和 SLO-goodput 反而变差。
6. 为什么 coder 比 chat 更敏感
你的图里最明显的区别就是：
- chat 对 TP 更“温和”
- coder 更早进入“小 TP / 中 TP 更优”的 regime
这通常意味着 coder workload 有更高的异质性，比如：
- request length variance 更大
- long-request fraction 更高
- burstiness 更强
- prefill / decode mix 更复杂
从排队论角度，一个很重要的量是 service time 的二阶矩。
如果服务时间随机变量为 $S$，那么 queueing delay 对 \mathbb{E}[S^2] 很敏感。
当 length variance 变大时，\mathbb{E}[S^2] 会明显上升，因此 tail latency 会更容易爆掉。
所以 coder 更早出现：
TP4goodput 不占优- 最优 TP 向
TP2或TP1漂移
这是很合理的。
八、还差什么实验，才能把这个变成更强的 paper claim
现在这组图已经足够支持“趋势”，但如果你想把它上升到更强的 principle，最好再补一个 regime boundary 实验。
不要只用 time\_scale 当横轴，而是用更本质的 offered-load 指标，比如：
- offered prefill tokens/s per GPU
- offered requests/s per instance
- 或者更 general 的 normalized utilization proxy
然后画：
- 横轴：offered load
- 纵轴：best TP
- 或者纵轴：相对
TP4的 SLO-goodput gain
这样你就能真正得到一个“转折点”：
当 load 低于某阈值时，大 TP 更优；超过阈值后，最优 TP 向中等或更小 TP 漂移。
这个图会非常强，因为它把现在的“观察”变成了“phase transition / regime transition”。