## 五、怎么从理论上建模这个 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”。