Initial commit: obsidian to gitea

projects/auto-tuner/principles model.md

@@ -0,0 +1,224 @@
+## 五、怎么从理论上建模这个 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”。