Kernel 快了 2 倍，
端到端为什么不一定快？

英文问法You made a kernel 2x faster. Why didn't end-to-end latency improve? · How do you check that a kernel-level win translates to an end-to-end gain? · What does "optimize locally, verify globally" mean?

考过Unity Vector 自己的论文（FlashVector §1 "Optimize locally, verify globally"）· 别家 JD：CoreWeave GPU Kernel Authoring & Optimization（2026-10）"validate that kernel-level wins translate to end-to-end latency/throughput gains"（JD）· 推断会问，没有 Unity 自己的面经原题

先弄清楚：每个概念是什么

时间占比: 一次请求的总时间里，这个 kernel 占多少。它决定了 kernel 变快之后总时间最多能少多少。
瓶颈转移: 最慢的一段被修好，第二慢的一段就成了新的瓶颈。
Microbenchmark: 把一个 kernel 或一个函数单独拿出来计时。它便宜，适合在一层里筛候选，但量不到它在整条链路里的影响。
Full-stack load test: 把整条 serving stack 跑起来，replay 真实的生产请求，看固定 latency SLO 下能撑住多少 throughput。

看图：kernel 占 10%，快 2 倍

图 1：总时间记成 100，10% 的占比是示意。虚线框是优化前终点两侧 ±6% 的 noise floor，优化后的终点还在框里。

30 秒回答

A kernel win only counts in proportion to that kernel's share of the request. If it's ten percent of the time and I make it twice as fast, the request gets five percent faster, which is inside a six percent noise floor. The bottleneck also moves, so a faster GPU just waits on CPU feature processing. And changes that pass alone can regress once combined. So FlashVector optimizes locally and verifies globally: after a change passes its own layer's checks, it reruns a full-stack load test on replayed production traffic at a fixed latency SLO, and keeps it only if the end-to-end gain beats the noise.

三个原因

原因	发生了什么	怎么发现
占比小	kernel 只占请求的一小段，再快总时间也动不了多少	先 profile 看占比。FlashVector 的 Diagnose 按“时间占比 × 预期收益”给假设排序
瓶颈转移	GPU 快了，CPU 上的 feature processing 成了最慢的一段	改完重新 profile。FlashVector 的 Case 3 第二轮 profile 出来的是新的瓶颈
组合后回退	各层单独通过，合在一起可能变慢	full-stack load test

手算，再看 FlashVector 怎么验

总时间记成 100，kernel 占 10。快 2 倍后 kernel 剩 5，总时间是 95，只少 5%，落在 ±6% 的 noise floor 里。按 FlashVector 的规则，它要加样本重测才可能留下。公式和更多算例见 Amdahl's law。

本层 verify：正确性按改动类型分档（kernel 正确性）
Full-stack load test：记固定 latency SLO 下的 sustained throughput
判定：端到端提升超过 noise floor 才留，否则 revert

必答点

收益和时间占比成正比，占 10%、快 2 倍时总时间只少 5%
5% 低于 ±6% 的 noise floor，一次 full-stack load test 分不出来
瓶颈会转移，改完要重新 profile
各层单独通过，组合后可能回退
Optimize locally, verify globally：本层通过后再过 full-stack load test，用 replay 的生产流量，固定 latency SLO

追问

FlashVector 自己的数字里有这种差距吗？

有。Case 2 的 attention 快了约 3.6 倍，连同 embedding bag 的改动，forward latency 只降了 30.1%。Case 1 的函数级 microbenchmark 是 30×，retrieval model 的 latency speedup 是 1.67×（见 FlashVector）。

load test 有什么坑？

client 自己成了瓶颈，就看不出 server 的改进。一位论文作者的公开 fork 里，loadgen 预先把 payload 序列化好来避开这一点。

别的团队也这样验吗？

Baseten 分 microbenchmark、ablation test、端到端 latency 三层。KDA-Pilot 回到真实的 SGLang 路径复验。KernelBot 每晚对前 10 名的提交跑 application validation。

来源FlashVector §1、§4.2、§5.2、§5.3.3、§5.4.2（原话 "a locally verified change could still regress the system once combined with the rest of the stack"）· CoreWeave JD · ml-八股 08 第 28 题 · 调研笔记 Unity 的证据和同类对照第 0 节第 4 点、4.2 节

Kernel 快了 2 倍，端到端为什么不一定快？