同一项任务从 14 天到 2.5 天：蚂蚁量的是数据策略进训练前的等待

同一项任务从 14 天到 2.5 天：蚂蚁量的是数据策略进训练前的等待

蚂蚁百灵在 2026 年 9 月 17 日公开 OmniTable。它是面向 PB 级大模型数据治理的统一宽表，相关论文拿到 VLDB 2026 最佳工业论文奖。这篇只整理他们怎么量「数据策略还没进训练」这段等待，不把缩短天数写成模型涨分。

对照的是同一项 SFT 治理任务

SFT 是监督微调，用整理好的问答样本继续训练模型。论文里的一项真实任务要汇集 8 个数据源，并生产 12 项数据特征。特征里既有规则处理，也有要调用模型才能完成的质量评估。

原流程拆成三段：数据接入约 2 天，12 项特征计算约 9.5 天，筛选与导出约 2.5 天，合计约 14 天。换成 OmniTable 后，同一项任务端到端约 2.5 天，数据处理周期缩短约 82.1%。人工操作步骤从约 45 个减到约 12 个，减少约 73.3%。作者写明，73.3% 只表示操作步骤变少，不等于人力成本同比例下降。14 天到 2.5 天也只是这项治理任务的处理周期，不是完整训练周期。策略有没有用，仍要等后续训练和评测。

旧流程同时记着 35 张物理表、24 条流水线或脚本。另一个网页数据案例里，只为增加一项特征，工程师要在编排画布上连接 106 张表。这些是等待从哪来的分项，不是另一套基准的分数。

系统改的是编排、配置和追溯

逻辑上，不同来源的数据和特征被当成一张继续生长的宽表：加一项质量分就是加一列，改筛选不必重搭整条流水线。计算、更新和存储由系统做。

三处改动对应三件可核对的事：

• 依赖由系统梳理。需要模型打分的任务自动调度到 GPU，失败样本被隔离并记录，避免一条坏数据拖垮整批。
• 计算参数按数据规模和历史任务自动配置。新同学首次提交任务的成功率从约 60% 提到 90% 以上。
• 来源、处理和版本可以查询。实验数据不再只靠人回忆。

OmniTable 不代替训练，也不直接判定一种数据配比是否有效。它只把策略推进到「可以训练、可以评测」。

规模测试只证明吞吐没塌

生产环境已经超过 35 PB、3050 亿条记录，覆盖网页、代码、PDF 和 SFT 数据。论文里的两组规模测试是：网页宽表一次导出从 1 TB 增到 25 PB，导出吞吐基本停在 18–23 TB/小时；逻辑列从 200 增到 2500，超过底层存储引擎约 1200 列的物理上限，查询延迟只上升约一半。关掉后台整理和布局优化后，同等规模吞吐会下降数倍。文中没有给出下降倍数，也没有给出查询延迟的绝对毫秒。

作者把智效比分成两面。一面是 Ling-3.0-flash 用 5.1B 激活参数去比更大的模型，具体分不在这篇正文里。另一面是从提出问题到拿到可验证结果，要花多少时间和工程。数据周期变短不等于效果变好，只是让团队更快丢掉无效配比，并把有效配比送进训练和评测。论文是《OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration》，https://arxiv.org/abs/2609.11148v1 。复现以论文为准，不能把 82.1% 挪到模型榜上。

出处：蚂蚁，蚂蚁百灵（页面未署个人作者），提升大模型智效比，从缩短一次数据验证的等待开始，2026-09-17，https://developer.ant-ling.com/zh-CN/blogs/omnitable