Profile、diagnose、optimize、verify：
怎么用到 offline 的 data 和 training pipeline？

英文问法How would you apply this agent loop to offline data processing and training pipelines? · How do you tell whether the GPU is waiting on the data pipeline? · How do you verify an optimization to a data pipeline?

考过推断，没有面经 · 依据一：本岗 JD（JOBREQ-2615965）写了 "Help optimize performance and efficiency across data processing and training systems"（Workday）· 依据二：一个已关闭的旧版 Offline 岗在要求里列了 "Torch Compilation, Quantization, CUDA, GPU kernel optimization"（hitmarker）· 类比用的是 FlashVector 的 Case 3 · 公开材料没写 Offline 组用什么工具，也没写它负责 agentic infra

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

Offline pipeline: 不直接回应用户请求的那一段，把原始数据处理成训练样本，再拿去训练模型。
Stage: pipeline 里的一段，比如解码和 feature transform。
GPU 等 CPU: GPU 算完一个 batch，下一个 batch 还没准备好，只能空等。
Zero-copy: 不把数据再复制一份，直接在原来那块内存上读。
Samples/s 和 GPU-hour: samples/s 是每秒处理多少样本，GPU-hour 是用了几张卡乘以多少小时。

看图：GPU 在哪里等 CPU

图 1：上面是四个 stage，粗框是这个例子里的瓶颈。下面两条时间线的数字是示意。

30 秒回答

It's the same loop with different targets. I'd profile the pipeline stage by stage to see whether the GPU is waiting on the CPU. Then I find the dominant stage, often decoding and feature transforms, and change one thing, like vectorizing it. To verify, the output data must be identical row by row, training loss must stay within tolerance, and the throughput gain has to beat the noise. The end-to-end metric is samples per second and GPU-hours per run, not request latency. FlashVector's feature-processing case is the closest analogy: Cython kernels and zero-copy took a pod from 940 to about 1,500 requests per second.

同一个循环，两个场景

	Serving（FlashVector 论文）	Offline（推断）
Profile	Nsight 和 eBPF	GPU utilization、DataLoader 等待时间、每个 stage 的耗时
Diagnose	对照 knowledge base 找瓶颈	先分清是 GPU 等 CPU 还是 GPU 本身慢，再看解码和 feature transform、序列化、IO、GPU kernel
Optimize	kernel fusion、改写成 C++ 或 Cython、zero-copy、调 config	向量化或 Cython、zero-copy、调 worker 数；训练侧 torch.compile
Verify	输出逐元素相等或在 dtype 容差内；replay 生产流量	输出数据逐行相同；训练侧 loss 在容差内；数据版本固定
端到端目标	固定 latency SLO 下的 throughput	samples/s 和 GPU-hour，没有 latency SLO

最接近的类比是 FlashVector 的 Case 3，瓶颈在 CPU 上的 feature processing。它的第二轮 profile 的是改过的服务，冒出来的是新的瓶颈。

手算：瓶颈会转移

数字是示意。CPU 每 500 ms 才准备好一个 batch，GPU 300 ms 就算完，每步空等 200 ms，GPU 有 40% 的时间闲着。把 feature transform 做快到 250 ms 一个 batch 之后，瓶颈换成 GPU，一步变成 300 ms，throughput 是原来的 500 ÷ 300 ≈ 1.67 倍。这时再优化 CPU 没有收益，下一轮要 profile GPU 一侧。

GPU utilization 低的一般排查见训练慢与 hang。

必答点

循环不变，换的是 profile 工具、verify 标准和端到端目标
先分清是 GPU 等 CPU，还是 GPU 本身慢
一轮只改一处，改完重新 profile，因为瓶颈会转移
verify 看输出数据逐行相同、训练侧 loss 在容差内、提升超过 noise
目标是 samples/s 和 GPU-hour，没有 latency SLO
数据版本固定，前后才可比

追问

Offline 的 noise floor 还是 ±6% 吗？

不是。±6% 是 FlashVector 在 serving 端到端量出来的。offline 要把未改动的 pipeline 重复跑几遍，自己量（见 noise floor）。

训练侧的改动（比如 torch.compile）怎么 verify？

固定 seed 和数据顺序，比较若干步的 loss，差别在容差内才算过。浮点运算的顺序变了，就不能要求 bit-exact（见 kernel 正确性）。

这题适合反问面试官什么？

Offline 组现在用什么工具 profile，瓶颈在哪个 stage，FlashVector 的循环有没有搬到训练侧。公开材料里都没有。

来源FlashVector（arXiv 2609.17391，§4.2、§5.3 Case 3）· 本岗 JD · hitmarker：已关闭的旧版 Offline 岗 · 调研笔记 0 节第 13 点、2.4 节 · ml-八股 08 第 31 题

Profile、diagnose、optimize、verify：怎么用到 offline 的 data 和 training pipeline？