gahow/obsidian
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit: obsidian to gitea

Browse Source
This commit is contained in:
Gahow Wang
2026-05-07 15:04:41 +08:00
commit a57afa86b4
323 changed files with 42569 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

732
projects/auto-tuner/Untitled 1.md Normal file
View File

@@ -0,0 +1,732 @@
你这个批评是对的。
上一个版本把问题讲成了“单请求 service time + 泛泛 queueing”，但对 vLLM 这类 **continuous batching / bulk-service** 系统来说，这样建模不够锋利。
## 先把问题修正：正确的服务对象不是 request，而是 batch
对 TTFT 来说，真正被执行的是 **prefill batch**，不是单个请求。
因此更准确的建模方式是：
* 先定义 **batch runtime** $T_b(t)$
* 再定义 request 的 TTFT 是“排队等到自己所在 batch 被执行”加上“自己所在 batch 的执行时间”
而不是先写一个模糊的 $S_{\text{comp}} + S_{\text{comm}} + S_{\text{sched}}$。
---
## 一、最小而精确的建模框架
设：
* 总 GPU 数固定为 $G$
* TP 为 $t$
* 则可部署 replica 数为
$$
m_t = \frac{G}{t}
$$
对某个 replica，上面的第 $b$ 个 prefill batch 记为 $\mathcal{B}_b$。
对 batch 中每个请求 $i$：
* prompt length 为 $x_i$
* 该 batch 的总 prefill token 数为
$$
Z_b = \sum_{i \in \mathcal{B}_b} x_i
$$
---
## 二、batch runtime $T_b(t)$ 应该怎么写
### 2.1 总式子
更准确地，应该写成：
$$
T_b(t) = T_b^{\text{comp}}(t) + T_b^{\text{comm}}(t) + T_b^{\text{rt}}(t)
$$
其中：
* $T_b^{\text{comp}}(t)$：真正算子计算时间
* $T_b^{\text{comm}}(t)$：TP collective 通信时间
* $T_b^{\text{rt}}(t)$：runtime 固定开销，例如 launch gap、executor 调度、图切换、kernel 边界等
这里我故意不用模糊的 $S_{\text{sched}}$，而把它收敛为 **runtime overhead residual**。
因为对这类系统，“调度”大量体现为 **batch 之间的时间缝隙和执行边界成本**，而不是某个独立的物理项。
---
## 三、$T_b^{\text{comp}}(t)$ 到底怎么算
### 3.1 prefill 的计算量不是只和 $\sum x_i$ 成正比
对 decoder-only Transformer，一个 prompt length 为 $x$ 的请求，其 prefill 计算量可以抽象成：
$$
F(x) = a x d^2 + b x^2 d
$$
其中：
* $d$ 是 hidden size
* $a x d^2$ 对应 dense 部分：QKV 投影、O 投影、MLP 等
* $b x^2 d$ 对应 self-attention 部分
* $a,b$ 吸收了层数 $L$、MLP expansion ratio、head 结构等常数
因此，一个 batch 的总 FLOPs 是：
$$
F_b = \sum_{i \in \mathcal{B}*b} F(x_i)
= a d^2 \sum*{i \in \mathcal{B}*b} x_i + b d \sum*{i \in \mathcal{B}_b} x_i^2
$$
如果把层数 $L$ 显式写出来，则是：
$$
F_b = L \left( a' d^2 \sum_{i \in \mathcal{B}*b} x_i + b' d \sum*{i \in \mathcal{B}_b} x_i^2 \right)
$$
这比“$S_{\text{comp}}$ 是计算项”要具体得多，因为这里直接告诉你：
> **prefill batch 的成本对长度分布是凸的，关键不是只有总 token 数 $Z_b$，而是还取决于 $\sum x_i^2$。**
---
### 3.2 一个非常关键的结论：length variance 直接进入 batch cost
因为：
$$
\sum_{i \in \mathcal{B}_b} x_i^2
= n_b \left( \bar{x}_b^2 + \operatorname{Var}_b(x) \right)
$$
其中：
* $n_b = |\mathcal{B}_b|$
* $\bar{x}_b$ 是 batch 内平均 prompt length
* $\operatorname{Var}_b(x)$ 是 batch 内长度方差
所以在固定 $n_b$ 和固定平均长度 $\bar{x}_b$ 下：
* 方差越大
* $\sum x_i^2$ 越大
* prefill compute cost 越高
这就是一个很强的、可计算的 insight：
> **heterogeneity 不只是“调度难”，而是直接提高了 attention 的物理计算量。**
这也解释了为什么 coder window 往往更敏感：
它通常不是只有更高平均长度，而是更高的 $\operatorname{Var}(x)$ 和更高的长尾。
---
### 3.3 把 FLOPs 映射成计算时间：roofline 形式
给定 batch $b$ 和 TP=$t$，其计算时间可以写成：
$$
T_b^{\text{comp}}(t) = \max\{\frac{F_b}{\Pi_t}, \frac{Q_b}{B_t}\}
$$
其中：
* $\Pi_t$ 是 TP=$t$ 时该 instance 的有效算力
* $Q_b$ 是这个 batch 的总 memory traffic
* $B_t$ 是 TP=$t$ 时该 instance 的有效 HBM 带宽
再进一步写：
$$
\Pi_t = t \Pi_1 \eta_t^{\text{comp}}
$$
$$
B_t = t B_1 \eta_t^{\text{mem}}
$$
其中：
* $\eta_t^{\text{comp}} \le 1$ 是 TP 扩大后由于 GEMM shape 变化、kernel utilization 降低带来的效率损失
* $\eta_t^{\text{mem}} \le 1$ 是内存系统扩展效率
于是：
$$
T_b^{\text{comp}}(t)
=
\max
\{
\frac{F_b}{t \Pi_1 \eta_t^{\text{comp}}},
\frac{Q_b}{t B_1 \eta_t^{\text{mem}}}
\}
$$
这已经比“$S_{\text{comp}}$ 会随 TP 降低”精确很多了。
它明确说明：
* 理想情况下，compute/memory 时间会按 $1/t$ 降
* 但实际只能按 $1/(t \eta_t)$ 降
* 而 $\eta_t$ 通常随 $t$ 变大而下降，所以是 **次线性加速**
---
## 四、$T_b^{\text{comm}}(t)$ 到底怎么算
### 4.1 TP 的通信本质是 activation collective
对标准 tensor parallel，每层通常会有若干个 activation 同步。
如果用 ring all-reduce 近似，大小为 $n$ bytes 的一次 collective 时间是：
$$
T_{\text{AR}}(n,t)
=
2 (t-1) \alpha
+
2 \frac{t-1}{t} \frac{n}{\beta}
$$
其中：
* $\alpha$ 是每 hop latency
* $\beta$ 是链路带宽
如果每层平均有 $k$ 次这样的 collective，且每次 payload 与 batch activation 大小成正比：
$$
n_b \approx q d Z_b
$$
其中 $q$ 是 dtype bytes，那么：
$$
T_b^{\text{comm}}(t)
\approx
L k
\left(
2 (t-1)\alpha
+
2 \frac{t-1}{t} \frac{q d Z_b}{\beta}
\right)
$$
这就是你要的更具体形式。
---
### 4.2 这个式子带来的核心含义
它说明 TP 通信开销有两个部分：
#### 固定项
$$
2 (t-1)\alpha
$$
这是 latency-driven 的，batch 小时特别痛。
#### 线性 payload 项
$$
2 \frac{t-1}{t} \frac{q d Z_b}{\beta}
$$
这是 batch token 数越大越重。
所以：
* 低负载、小 batch 时，通信固定项不一定主导，但也不会消失
* 高负载、大 batch 时，payload-driven 通信会上升
* 更重要的是：**即使 compute 时间下降，communication 不会按 $1/t$ 同步下降**
这也是 TP 速度提升无法线性的根本原因。
---
## 五、把三项合起来：一个真正可用的 $T_b(t)$
综合起来，一个 batch 的执行时间可以写成：
$$
T_b(t)
======
\max
\{
\frac{
L ( a' d^2 \sum_i x_i + b' d \sum_i x_i^2 )
}{
t \Pi_1 \eta_t^{\text{comp}}
},
\frac{Q_b}{t B_1 \eta_t^{\text{mem}}}
\}
+
L k
(
2 (t-1)\alpha
+
2 \frac{t-1}{t} \frac{q d Z_b}{\beta}
)
+
T_b^{\text{rt}}(t)
$$
这已经是一个相当具体的 mechanistic model 了。
---
## 六、TTFT 应该怎么精确定义，而不是模糊说 $W_q + E[S_t]$
### 6.1 request 级别的精确定义
对请求 $i$，设它被分配到某个 replica，并最终进入 prefill batch $b(i)$。
它的 TTFT 精确写成：
$$
\mathrm{TTFT}_i(t)
==================
W_{q,i}(t) + T_{b(i)}(t)
$$
其中：
* $W_{q,i}(t)$ 是它在自己 batch 真正开始执行前等待的时间
* $T_{b(i)}(t)$ 是它所在 batch 的执行时间
而 $W_{q,i}(t)$ 又可以精确分解为：
$$
W_{q,i}(t)
==========
R_i(t) + \sum_{u \in \mathcal{H}_i} T_u(t)
$$
其中：
* $R_i(t)$ 是请求到达时当前正在跑的那个 batch 的 residual runtime
* $\mathcal{H}_i$ 是它前面还排着的 prefill batches 集合
这个式子是对的，而且比“queueing delay”四个字更有结构。
---
### 6.2 为什么上次写的 $E[S_t]$ 不够准确
因为对 continuous batching 系统，**“request 的 service time”不是一个天然的一维随机变量**。
更自然的随机变量其实是 batch runtime $T_b(t)$。
request 的 TTFT 是：
* 一个 residual batch
* 加上若干个完整 batch
* 再加上自己的 batch
所以更对的期望写法是围绕 $T_b(t)$，而不是围绕某个抽象的 $S_t$。
---
### 6.3 如果一定要写平均 queueing term，应该怎么写
在稳态下，如果把 batch 看成 renewal process，那么 residual life 的精确均值是：
$$
\mathbb{E}[R_t]
===============
\frac{\mathbb{E}[T_b(t)^2]}{2 \mathbb{E}[T_b(t)]}
$$
这比“queueing increases with variance”更具体，因为它明确告诉你：
> **batch runtime 的二阶矩直接进入等待时间。**
如果再做一个独立性近似，则：
$$
\mathbb{E}[W_q(t)]
\approx
\frac{\mathbb{E}[T_b(t)^2]}{2 \mathbb{E}[T_b(t)]}
+
\mathbb{E}[|\mathcal{H}|] , \mathbb{E}[T_b(t)]
$$
其中 $|\mathcal{H}|$ 是到达时前方排着的 batch 数。
这就已经比之前的 $E[S_t]$、$W_q(t,w)$ 精确得多了。
---
## 七、真正关键的量不是 $E[S_t]$，而是 cluster capacity
如果你想分析“为什么高负载时小 TP 更好”，最关键的不是某个 request 的平均 service time，而是：
> **固定总 GPU 数下，cluster 能提供的总服务能力到底是多少。**
---
### 7.1 单 instance 的 batch token throughput
对 workload window $w$，定义 TP=$t$ 时单 instance 的平均 prefill token throughput 为：
$$
\mu_{t,w}
=========
\mathbb{E}
\left[
\frac{Z_b}{T_b(t)}
\middle| w
\right]
$$
这里：
* $Z_b$ 是 batch token 数
* $T_b(t)$ 是 batch runtime
这是一个比 “$E[S_t]$” 更自然的核心量。
---
### 7.2 cluster 总 capacity
因为总 replica 数是 $m_t = G/t$，所以 cluster 级别的总 prefill capacity 是：
$$
\Lambda_{t,w}
=============
\frac{G}{t} , \mu_{t,w}
$$
这个式子非常关键。
它说明：TP 的 tradeoff 不是抽象的，而是直接落在
* 单 instance throughput：$\mu_{t,w}$
* replica 数：$G/t$
两者的乘积上。
---
## 八、为什么高负载下大 TP 很难赢：一个几乎是定理级别的结论
比较 TP=$t$ 和 TP=1 的 cluster capacity：
$$
\frac{\Lambda_{t,w}}{\Lambda_{1,w}}
===================================
\frac{\mu_{t,w}}{t \mu_{1,w}}
$$
因此，大 TP 只有在下面这个条件成立时，才能在固定总 GPU 数下提升 cluster capacity：
$$
\mu_{t,w} > t \mu_{1,w}
$$
也就是说，**单 instance throughput 必须超过线性扩展**。
但这是非常苛刻的，因为：
* compute 只能理想到线性
* 实际有 $\eta_t^{\text{comp}} < 1$
* 还有额外的 $T_b^{\text{comm}}(t)$
* 还有 runtime overhead
所以在稳态下，通常只能有：
$$
\mu_{t,w} < t \mu_{1,w}
$$
从而：
$$
\Lambda_{t,w} \le \Lambda_{1,w}
$$
这就是为什么在**固定总 GPU 数**下：
> **大 TP 几乎不可能提升饱和状态下的 cluster total capacity。**
它能提升的是：
* 单请求 latency
* 单 instance 的 service time
但它通常不能提升**总集群容量**。
这就是你图里最核心的 principle。
---
## 九、为什么低负载时 TP4 更好，但高负载时 TP1/TP2 更好
### 9.1 低负载：系统是 arrival-limited
观测到的 goodput 近似为：
$$
g_{t,w}^{\text{obs}}
\approx
\frac{1}{G}
\min
\left{
\lambda_w^{\text{good}},
\Lambda_{t,w}
\right}
$$
其中：
* $\lambda_w^{\text{good}}$ 是外部 offered good-token arrival rate
* $\Lambda_{t,w}$ 是系统 capacity
当低负载时：
$$
\lambda_w^{\text{good}} \ll \Lambda_{t,w}
$$
对所有 TP 都成立，所以：
$$
g_{t,w}^{\text{obs}}
\approx
\frac{\lambda_w^{\text{good}}}{G}
$$
因此不同 TP 的 observed goodput/GPU 看起来几乎一样。
这就解释了你在 $time_scale=0.5$ 看到的现象：
* goodput/GPU 差异很小
* 但 TP4 latency 更好
因为这时真正显现出来的是：
$$
T_b(4) < T_b(1)
$$
而 capacity 差异被 arrival-limited 掩盖了。
---
### 9.2 高负载：系统开始 capacity-limited
当：
$$
\lambda_w^{\text{good}} \approx \Lambda_{t,w}
$$
或者超过它时，系统进入高利用率区。
此时：
* observed goodput 开始接近 capacity
* queueing term 开始爆炸
因为利用率可以写成：
$$
\rho_{t,w}
==========
\frac{\lambda_w^{\text{good}}}{\Lambda_{t,w}}
$$
而大 TP 通常让 $\Lambda_{t,w}$ 下降，所以会让 $\rho_{t,w}$ 上升。
一旦 $\rho_{t,w}$ 接近 $1$，你就会看到：
* queueing delay 急剧上升
* p95 TTFT 急剧恶化
* SLO pass 数下降
* goodput/GPU 反而输给小 TP
这就解释了为什么高负载下 TP1/TP2 更优。
---
## 十、为什么 coder 比 chat 更容易出现这个现象
这可以从两个层面解释。
### 10.1 batch cost 的凸性更强地惩罚高方差长度分布
前面已经有：
$$
F_b
===
a d^2 \sum_i x_i + b d \sum_i x_i^2
$$
而：
$$
\sum_i x_i^2
============
n_b \left( \bar{x}_b^2 + \operatorname{Var}_b(x) \right)
$$
所以 coder 如果具有更高的：
* long tail
* length variance
* long fraction
那么 batch runtime 就会更高，而且不是线性地更高。
---
### 10.2 queueing tail 还会额外放大 runtime variance
你真正关心的是 p95 TTFT。
而 p95 受的不仅是 $\mathbb{E}[T_b]$，还受 $\mathbb{E}[T_b^2]$ 甚至更高阶尾部分布影响。
如果 coder 的 batch runtime 分布更 heavy-tail，那么：
$$
\mathbb{E}[R_t]
===============
\frac{\mathbb{E}[T_b(t)^2]}{2 \mathbb{E}[T_b(t)]}
$$
也会更大。
所以 coder 更早进入：
* residual time 大
* queue 深
* p95 爆掉
的 regime。
---
## 十一、因此你应该怎么总结这条 principle
你现在最该写的不是：
> 负载越大，TP 越小越好。
而应该写成下面这个更强、更准确的形式：
---
### Principle
在固定总 GPU 数下，TP 同时影响两个不同层面的量：
1. **单 instance 的 batch runtime $T_b(t)$**
更大的 TP 往往降低 compute time，因此改善低负载下的 TTFT。
2. **集群总 capacity $\Lambda_{t,w} = \frac{G}{t}\mu_{t,w}$**
由于 TP 扩展通常只有次线性速度提升，且引入额外 collective 开销，因此 $\mu_{t,w}$ 很难超过线性增长，导致 cluster capacity 通常随 TP 增大而不升反降。
因此：
* 在低负载区，系统是 arrival-limited，capacity 差异被隐藏，TTFT 主要由 $T_b(t)$ 决定，所以较大 TP 更优。
* 在高负载区，系统是 capacity- / queueing-limited，$\Lambda_{t,w}$ 和 $\rho_{t,w}$ 主导表现，因此较小或中等 TP 更优。
---
## 十二、把你图里的 observation 严格落到这个模型上
你现在的图，其实支持的是下面这句话：
### 低载区
在 sampled low-load windows 上，
$$
\lambda_w^{\text{good}} \ll \Lambda_{t,w}, \quad \forall t \in {1,2,4}
$$
因此 observed goodput/GPU 相近；同时
$$
T_b(4) < T_b(1)
$$
所以 TP4 的 p95 TTFT 更好。
---
### 高载区
随着 $time_scale$ 增大，$\lambda_w^{\text{good}}$ 被放大，系统开始逼近：
$$
\lambda_w^{\text{good}} \approx \Lambda_{t,w}
$$
而由于通常有：
$$
\Lambda_{4,w} < \Lambda_{2,w} \lesssim \Lambda_{1,w}
$$
或者至少：
$$
\Lambda_{4,w} < \Lambda_{2,w}
$$
所以 TP4 更早进入高利用率区，queueing tail 更早爆炸，于是：
* goodput/GPU 开始输给小 TP
* p95 TTFT 恶化更明显
这就是你观察到的 phase change。
---
## 十三、如果你要把这个模型真正用于预测，下一步该怎么做
你现在可以不再泛泛地说“workload affects TP”，而是直接拟合下面这些量。
### 需要拟合的量
| 量 | 含义 | 如何估计 |
| ---------------------- | --------------------------------- | ----------------------------------------------------------------------- |
| $a,b$ | prefill FLOP 模型常数 | 用 isolation microbench 拟合 batch runtime 对 $\sum x_i$ 和 $\sum x_i^2$ 的系数 |
| $\eta_t^{\text{comp}}$ | TP 计算扩展效率 | 对固定 batch 组合测 $T_b^{\text{comp}}$ 反推 |
| $\alpha,\beta$ | collective latency / bandwidth 参数 | 用 NCCL microbench 或 server log 中 collective 时间拟合 |
| $T_b^{\text{rt}}(t)$ | runtime residual | 用实测 $T_b - T_b^{\text{comp}} - T_b^{\text{comm}}$ 得到 |
| $\mu_{t,w}$ | 单 instance token throughput | 直接从 trace replay 实测 batch token / runtime 统计 |
| $\Lambda_{t,w}$ | cluster capacity | 用 $\frac{G}{t}\mu_{t,w}$ 计算 |
---
## 十四、最本质的一句话
这条 principle 的本质其实可以压缩成一句话：
> **大 TP 优化的是“单个 batch 跑多快”，小 TP 优化的是“固定 GPU 预算下整个 cluster 同时能接多少活”。**
在低负载时，前者主导。
在高负载时，后者主导。
---
如果你愿意，我下一条可以继续直接把这个模型再往前推一步，给你一版**可写进论文的小节**，包括：
* 精确定义
* Proposition
* 证明思路
* 为什么会出现 TP4 $\rightarrow$ TP2 $\rightarrow$ TP1 的 regime shift。