时延少 77.5%，卡时少 63.9%：字节 FastCI 用运行时证据选 GPU 测试

时延少 77.5%，卡时少 63.9%：字节 FastCI 用运行时证据选 GPU 测试

字节跳动 Seed 与北京大学的预印本 FastCI: Efficient GPU-Intensive CI for LLM Training Frameworks。arXiv 提交日期是 2026 年 10 月 1 日（2610.01967v1）。作者包括 Tianshuo Qiao、Naiqian Zheng、Xiaopeng Liu、Shuguang Wang、Diandian Gu、Xuanzhe Liu、Xin Jin，单位是北京大学和 ByteDance Seed。FastCI 是给大模型训练框架的持续集成做测试选择、剪枝、调度和减载的一套流程。这篇要看的是它相对现在线上那套管线少了多少，以及「受影响测试召回」和「改动行覆盖保留」为什么不是同一个数。

文件级映射会多测，先进先出又晚报错

持续集成在这里指合并请求提交或更新时持续构建和测试。训练框架和普通软件不一样：很多行为要跑完训练或评测才能看，例如训练能不能跑完、数值是否对齐。所以测试是吃 GPU 的端到端，而不是一堆毫秒级单元测试。

生产侧的量级写在引言里。主干每周收到 200 个以上合并请求，一次请求会随着后续提交多次触发。编码 Agent 把改动频率又抬高了一截。他们维持一个上千张 GPU 的专用池，池子仍然打满，一次持续集成平均超过 4 小时。

现在线上用的是路径映射：手工维护「文件对应哪些测试」。改一个函数，整份文件挂上的测试都会被选中。图 1 的例子是 parallelize_vision。路径映射把依赖该文件的测试都算进去，运行时痕迹却显示只有多模态训练测试真正执行了这个函数。映射还会漏：代码库变得快，手工表不完整，就会出现该测没测的假阴性。

选完之后还有两处浪费。测试按先进先出跑，失败要等很久才露出来，开发者停掉再重跑，卡时已经花掉。单条测试还沿用生产负载里和验证目标无关的维度，例如模型规模、序列长度、日志和指标采集。并行度和批大小会按持续集成改过，其余常常原样留下。

四步：证据选测、等价剪枝、风险排序、减掉无关负载

FastCI 用轻量采样收集 GPU 测试的运行时调用，收成一张图：每个测试实际执行过哪些函数、怎么调用。选择时只留执行了改动函数的测试。

剪枝看的是等价上下文。改动函数如果在几个测试里的执行上下文相同，就留下一个，其余当冗余剪掉。这一步是故意少测，不是漏测没发现。

调度不用先进先出。每条测试的风险是两项的加权：

R(t) = α_t × R_code(t) + (1 − α_t) × R_instability(t)

R_code 看历史上「这类改动」和失败的关联，对全新模块证据少。R_instability 看这条测试最近是否不稳，覆盖环境、依赖和偶发失败，但和本次 diff 不那么贴。α_t 随该类改动的历史观测变多而升高。测试按风险从高到低派发。附录 A 给了分项算法，正文实验不单列 α 的取值。

减载只动「能明确判断与验证目标无关」的维度。分布式测试仍保留并行度，长序列测试仍保留序列长度。判断来自测试元数据和历史执行路径。判断不了的维度不减。

影子流水线两天：相对全量，也相对路径映射

端到端评测从生产合并请求里抽样，送进自建的影子流水线，跑了两天，不碰生产。对照四套：全量；路径映射（现在的生产做法）；NameRTS，一种把静态分析扩到大代码库的回归测试选择；FastCI-select，只做证据选择和上下文剪枝，不做风险调度和减载。

图 5 的平均数都相对全量。路径映射选出 50.6% 的测试，GPU 用量、时延、排队时间分别降到全量的 51.5%、26.9%、21.1%。NameRTS 选出 55.1%，四项都不如路径映射。作者的解释是：它只能把改动映射到测试入口，而端到端测试常常共用入口，于是多选。FastCI 把 GPU、时延、排队降到全量的 18.6%、6.1%、1.8%。

摘要里的 77.5% 和 63.9% 对的是现在部署的路径映射，不是对全量。时延从全量的 26.9% 收到 6.1%，GPU 从 51.5% 收到 18.6%，按这个相对差，和摘要对得上。覆盖保留提高 3.2%，也是相对路径映射，依据在表 1：路径映射 96.0%，FastCI-select 99.2%，差 3.2 个百分点。端到端图和选择表不是同一次计数，不能把图 5 的 50.6% 和表 1 的 62.6% 当成同一格。

图 6 给分布，横轴画到 360 分钟。相对路径映射，中位数时延少 79.2%，排队少 97.3%；第 90 百分位是 78.3% 和 89.0%。有些请求在路径映射、NameRTS 和 FastCI 下时延是 0：新功能或新模块还没有任何测试执行过新增代码。

表 1 是回放生产负载做选择，分母是全量套件的离线行覆盖（Coverage.py）。五行：

LLM 基线是 GPT-5.5，读 diff 和候选测试后返回它认为受影响的测试。它比路径映射省，但召回只有 54.6%，覆盖保留 83.1%。不剪枝的证据选择把召回从 76.1% 抬到 84.5%，覆盖保留到 99.8%。加上剪枝，召回掉到 66.2%，覆盖保留只少 0.6 个百分点，到 99.2%。召回下降是剪掉了作者认为冗余的受影响测试，不是覆盖跟着掉了同样幅度。NameRTS 召回 94.0%，GPU 成本也到 80.8%，高召回里有大量多选。

调度看的是第一次失败的名次和失败前的卡时，不看总时延，因为池子容量和并发会搅进反馈时间。相对生产的先进先出，FastCI 把第一次失败名次的中位数降 63.6%，失败前 GPU 的中位数降 89.2%。相对 COLEMAN（FRRMAB + TimeRank，十个固定随机种子取平均），第一次失败的中位名次从 9 到 4，失败前 GPU 从 12.6 卡时到 2.3 卡时。P90 和 P99 也更好。不稳定性指标在中位数和 P90 更有用；改动关联指标在 P99 更好，因为那一批选出的测试更多。两项合在一起优于只用一项。

减载：单条测试平均执行时间少 11.8%，GPU 少 19.3%。相对只做选择的 FastCI-select，完整 FastCI 再把 GPU 少 18.3%，平均时延少 28.6%，排队少 46.6%。这些是图 5 上两条 FastCI 的差，不是相对路径映射的 77.5%。

采样率在表 2，Hz 是每秒栈采样次数，三行都开了剪枝。10 Hz 开销 0.3%，召回 57.7%，覆盖保留 97.5%。50 Hz 开销 4.1%，召回 66.2%，覆盖保留 99.2%。100 Hz 开销 17.0%，召回 68.4%，覆盖保留 99.6%。线上取 50 Hz。从 50 到 100，覆盖只多 0.4 个百分点，开销从 4.1% 到 17.0%。

上线是四段放开，58.4% 不是影子实验的 77.5%

影子环境先跑通，再和开发团队看过失败模式，才进生产。四段：先给一小部分测试做运行时追踪；再用合并请求标题里的关键词把部分请求送进完整流程；然后扩大插桩范围；最后去掉关键词，对符合条件的生产请求默认打开。

纯配置改动，例如只改 YAML，选择阶段仍走原有规则，不用证据图。回滚是一个配置字段两档：不再接新请求，或整个关掉。都不用改代码。

运行中踩过两个坑。痕迹堆多之后，每个请求都预先处理全部历史，选择步骤超时。改成按需物化：每个请求只处理当前需要的那个版本的痕迹，单请求开销相对痕迹总量是 O(1)。测试配置原来集中存在远端，并发读写很重。改成用环境变量在本地推导，远端配置开销基本去掉。

引言写，接上生产负载后，平均时延少了 58.4%。这是上线后的运行数。77.5% 是两天影子流水线里相对路径映射的时延。两个场景、两个分母。

这些数不能被读成什么

77.5%、63.9%、3.2% 对的是路径映射，不是全量，也不是 NameRTS。相对全量的时延是降到 6.1%，不能说成「少了 93.9% 的同时再少 77.5%」。图 5 和表 1 的选出比例不一致，因为一个是两天影子端到端，一个是回放选择。NameRTS 在图里是 55.1%，在表里是 77.2%，不能取平均。

剪枝后受影响测试召回 66.2%，低于路径映射的 76.1%。覆盖保留仍有 99.2%，是因为剪掉的测试多半覆盖已被留下的测试执行过的改动行。不能把 99.2% 读成「该跑的测试还剩 99.2%」。新增代码没有历史执行，相关请求时延可以是 0，这是没测到，不是测完了很快。

失败前 89.2% 是中位数，不是每条请求。COLEMAN 的 12.6 到 2.3 卡时也是中位数。十个种子的方差没有写进正文句子。减载的 11.8% 和 19.3% 是单测平均，和端到端的 28.6% 不是同一层。

50 Hz 的 4.1% 开销是追踪自身，已经含在选择实验里。端到端仍显示时延和 GPU 下降，但不能把开销从 77.5% 里再减一次。抽样只有两天，请求条数正文没有给。上千张 GPU、每周 200 个以上合并请求、平均超过 4 小时，是问题规模，不是 FastCI 之后的规模。58.4% 没有给出上线窗口和是否仍含关键词灰度。YAML 类改动不走这套选择。许可证是 arXiv 非排他分发许可。

出处：字节跳动 Seed、北京大学，Tianshuo Qiao、Naiqian Zheng、Xiaopeng Liu、Shuguang Wang、Diandian Gu、Xuanzhe Liu、Xin Jin，FastCI: Efficient GPU-Intensive CI for LLM Training Frameworks，2026-10-01，https://arxiv.org/abs/2610.01967