Unity Vector 的 FlashVector：
agent 怎么优化整个 serving stack？

英文问法Walk me through FlashVector. How does the agent optimize the whole serving stack? · How does it know a change is correct and really faster? · How do the agent's changes reach production?

考过Unity Vector 自己的论文（arXiv 2609.17391，2026-09，Unity Vector AI Team 与 Stanford；据 LinkedIn 转发，一作是 2026 年暑期实习生）· 面试官提示会考 "agentic 优化 kernel / CUDA"（2026-10，你转述），很可能指这篇，这是推断 · 没有 Unity 自己的面经原题 · 面试前必读

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

Serving stack: 一次广告请求要穿过的四层，从 feature processing 到 GPU kernel。瓶颈分散在各层。
Layer agent: 每层一个 agent，四步的接口相同，工具和知识不同。
Verifier: 决定改动留不留的固定代码，agent 改不了它。
Noise floor: baseline 一行不改重复跑时指标自己的波动，端到端是 ±6%。
Shadow-traffic canary: 把真实请求复制一份给新版本，结果不返回用户。

看图：四层 stack 和四步循环

图 1：被抽中的层跑四步，再过 full-stack load test。蓝线表示 Diagnose 读 knowledge base，Refine 在 run 结束后写回一次。

30 秒回答

FlashVector applies the kernel-optimization agent to the whole serving stack of Unity's ads models: GPU kernels, the PyTorch graph, the Triton model server and feature processing. Each layer has its own agent running the same four steps: profile, diagnose, optimize, verify. Correctness is tiered by change type, from bit-exact outputs for a deterministic rewrite to a shadow-traffic canary for a config change. Every change is load-tested end to end on replayed production traffic at the latency SLO, and kept only if the gain beats the noise, about six percent. Changes ship as reviewed pull requests. Across six production models, throughput rose 1.1 to 2 times.

四步循环加 Refine

步骤	做什么	要点
Profile	GPU kernel 用 Nsight，model server 用 eBPF	GPU kernel 在 local simulated environment 测，model server 和 feature processing 在 production-like load test 测
Diagnose	对照 knowledge base 提假设，按“时间占比 × 预期收益”排序	预期收益低于 noise floor 的直接跳过
Optimize	改代码或配置	一轮只做一个改动
Verify	先过本层的正确性四档，再过 full-stack load test	提升超过 noise floor 才留
Refine	run 结束后 in-place 写回 knowledge base	接受和拒绝的改动都记

要记的规则

正确性四档：按改动类型，分别要求逐元素相等、dtype 的容差、business metrics 和 shadow-traffic canary
Noise floor：2–6% 的提升加样本重测，最多 8 倍，按 \(1/\sqrt{k}\) 收紧到 2.1%
Knowledge base：人写的六类文档，加 agent 写回的 per-model card
进生产：agent 开 PR，人 review。配置改动的 canary 稳住才采纳
自动触发：新 release 进 fleet，或在线模型太久没被分析时
Offline：循环搬到 data 和 training pipeline 是推断

四个 case 的数字

Case	改了什么	数字
1 model server	Triton Python backend 的 string 反序列化改写成 C++，已合入 Triton 上游	函数级 microbenchmark 最高 30×
2 GPU kernel	attention 的 6 个 kernel 融成 1 个，结果 bit-identical	attention 996.5 µs → 279.8 µs；连同 embedding bag 的改动，forward latency −30.1%
3 feature processing	Cython kernel 加 zero-copy	每个 pod 的 RPS 从 940 到约 1.5k
4 配置	搜 instance count 和 dynamic batch size，以 PR 交付	用 shadow-traffic canary 验

6 个生产模型的 latency speedup 是 1.30–1.98×，throughput 提升 1.10–2.00×。

论文没写什么，适合当反问

用哪个 LLM 和 agent 框架
sandbox 用什么技术（见 sandbox）
一次 run 的 token、耗时和并行度

读论文要小心的两处

Case 1 的时间：论文引用的 Triton issue #8348 开于 2025-08，早于 2026 年暑期项目。不要说成 agent 在暑期发现的
Table 4 的 Model B：p99 是 271 ms，超过 250 ms 的 SLO，论文没有解释

必答点

四层：GPU kernel、PyTorch graph、model server、feature processing
每层同样四步：Profile → Diagnose → Optimize → Verify，run 结束后 Refine
每轮随机抽一层，一轮一个改动
Optimize locally, verify globally：本层通过后还要过 full-stack load test
提升超过 noise floor（±6%）才留
agent 开 PR，人 review；新 release 进 fleet 时自动触发

追问

为什么不让 LLM 一次生成优化方案？

论文说 LLM 会看错自己的 profile，所以要 harness 逐步检查。它还需要精确的 kernel trace（nsys、ncu）和准确的 tensor shape，roofline 分析时才少 hallucinate。

它用了什么 search，每轮怎么选层？

单链循环，没有 beam、evolution 或 MCTS（对比见 search 方法）。Algorithm 1 每轮随机选一层，没有按时间占比加权，论文没解释，适合当反问。自己设计时可以按时间占比加权抽样，这是我的想法，不是论文的做法。

Case 1 的 30× 能说成线上快了 30 倍吗？

不能。30× 是 deserialize_bytes_tensor 这个函数的 microbenchmark，结果表里 retrieval model 的 latency speedup 是 1.67×。

来源FlashVector（HTML 全文：§1、§4.1、§4.2、Algorithm 1、§5 的四个 case、Table 1、Table 4、Figure 2）· ml-八股 08 第 0 题 · 调研笔记 Unity 的证据和同类对照第 0、1 节

Unity Vector 的 FlashVector：agent 怎么优化整个 serving stack？