225 lines
5.3 KiB
Markdown
225 lines
5.3 KiB
Markdown
## 五、怎么从理论上建模这个 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 更早出现：
|
||
|
||
* $TP4$ goodput 不占优
|
||
* 最优 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”。
|