提升大模型智效比，从缩短一次数据验证的等待开始

OmniTable：面向 PB 级大模型数据治理与探索的统一宽表系统

01 智效比的另一面

为真实世界而生的智能，需要回答一个具体问题：如何用更合理的时间、算力和工程投入，持续改进模型解决实际问题的能力？

追求智效比，不只要看模型运行得多快，也要看一次数据策略验证需要付出多少时间和工程成本。

前者，百灵不久前给出了一次回答：原生混合推理模型 Ling-3.0-flash , 124B 总参数、5.1B 激活参数，不一味堆砌参数规模，而是追求单位算力所能转化的智能。

后者则隐藏在研发过程中那些不容易被看见的投入里：准备一批数据需要多久，调整一项质量标准需要多少人工操作，一次实验的数据来源和处理过程能否被清楚追溯。

让研究人员少一些等待和重复操作，多一些验证问题的机会，是数据工程可以贡献的价值。

围绕这一目标，百灵建设了 OmniTable —— 面向 PB 级大模型数据治理与探索的统一宽表系统。相关论文获得了 VLDB 2026 最佳工业论文奖（Best Industry Paper）。

02 一次数据策略验证，为什么需要这么久？

研究人员想要验证一种数据策略，往往只是从一个具体问题开始：提高某类高质量样本的占比，能否改善模型在特定任务中的表现？

但在开始后续训练之前，团队需要汇集不同来源的数据，完成清洗、去重、质量打分和安全检查，再按照实验要求进行筛选、组合与导出。

论文记录了百灵一项真实的 SFT 数据治理任务：汇集 8 个数据源，完成 12 项数据特征的生产——其中既有规则处理，也有需要调用模型完成的质量评估。

按照原有方式，数据接入约需 2 天，12 项特征的计算约需 9.5 天，筛选与导出约需 2.5 天，总计约 14 天。

使用 OmniTable 后，同一项任务的端到端处理周期缩短至约 2.5 天，数据处理周期缩短约 82.1%。流程中的人工操作步骤也从约 45 个减少至约 12 个，减少约 73.3%——这一指标反映的是操作流程的简化，并不等同于人力成本的同比例下降。

需要特别说明的是，从 14 天到 2.5 天，缩短的是这项特定数据治理任务的处理周期，而不是完整的模型训练周期。它带来的价值，是减少后续训练开始前的数据等待和重复操作，让研究人员能更快把一种数据策略推进到可训练、可验证的阶段。至于这种策略是否有效，仍要由后续的训练与评测来回答。

OmniTable 将一项真实 SFT 数据治理任务从约 14 天缩短至约 2.5 天

03 14 天的等待，花在了哪里？

这 14 天不仅包含特征计算耗时，也包含数据接入、任务编排以及筛选导出等环节的开销。

在传统数据系统中，不同来源、不同阶段的数据和特征，通常分散在大量物理表中。每增加一项质量分或安全标签，团队都可能需要新建表、补写脚本、重新编排任务；当原始数据或处理规则发生变化，相关特征还要沿着流水线逐层更新。

在前述任务中，原有流程涉及 35 张物理表、24 条数据流水线或脚本，以及约 45 个操作步骤。另一个真实案例更直观：为了给网页数据增加一项特征，工程师需要在任务编排画布上逐一连接 106 张表。

数据生产就这样变成一座不断扩建的”流水线迷宫”：表越来越多，依赖越来越复杂。研究人员不仅要等待计算结果，还要投入精力维护流程、排查故障、确认数据来源——有时夜里还要盯着流水线，一旦失败就要排查重试。

数据工程的复杂度，最终会转化为数据策略验证的等待时间。这是智效比中容易被忽视的损耗。

PB 级大模型数据生产中的”流水线迷宫”

04 OmniTable：把复杂留给系统，把时间还给研究

OmniTable 的核心思路可以概括为一句话：逻辑上一张宽表，物理上持续自适应。

对研究人员来说，不同来源的数据及其特征，可以像一张持续生长的表一样使用：需要增加一项质量分，就像在表中增加一列；需要调整筛选标准，也不必重新搭建一套流水线。研究人员只需说明需要哪些数据和特征，具体的计算、更新和存储由系统完成。

改变主要体现在三个方面：

• 减少重复编排。 特征的依赖关系由系统自动梳理，新增或调整一项特征时，不必再逐表搭建流水线；需要模型打分的任务会被自动调度到 GPU 资源，系统会自动隔离并记录处理失败的数据，减少个别数据异常导致整批任务失败的情况。
• 沉淀专家经验。 计算参数不再依赖个人经验反复试错——系统会根据数据规模和历史任务自动配置，新同学首次提交任务的成功率从约 60% 提升到 90% 以上。
• 保持过程可追溯。 数据来自哪里、经过哪些处理、形成了哪个版本，都可以被记录和查询，实验数据的来源和处理过程不再是一笔”糊涂账”。

OmniTable 不替代模型训练，也不直接判断一种数据策略是否有效。它要解决的是：让数据策略以更少的等待和重复操作，进入后续训练与评测环节。

OmniTable 系统架构：上层提供统一宽表视图，底层保留可持续调整的存储和计算系统

05 在 35 PB 数据上持续运行

效率的提升，只有在大规模生产环境中长期成立，才真正有意义。

目前，OmniTable 管理的数据规模已超过 35 PB，覆盖超过 3050 亿条记录，涵盖网页、代码、PDF 和 SFT 数据等多种类型。

这些数据并非处理一次就不再变化。随着研究目标和质量标准的调整，团队需要持续增加新的数据源和特征，重新计算部分结果，并按照新的实验要求组合数据。数据规模越大、变化越频繁，一次策略调整所牵动的工程链路就越复杂——工程效率每提升一分，研发投入的节约就被放大一分。

真正的考验在于：规模不断增长，效率能不能不塌陷。论文中的两组测试给出了回答——在网页宽表上，一次导出任务覆盖的数据量从 1 TB 增加到 25 PB，系统的导出吞吐基本稳定在 18–23 TB/小时；宽表的逻辑列从 200 列增长到 2500 列，已超过底层存储引擎约 1200 列的物理上限，查询延迟仅上升约一半。这背后是系统后台持续进行的数据整理与布局优化；如果将其关闭，同等规模下的吞吐会下降数倍。

数据量增长约四个数量级、特征列突破存储引擎物理上限，OmniTable 的导出吞吐与查询延迟保持基本平稳

OmniTable 在这样的生产环境中持续运行，支撑百灵日常的数据治理与探索。

06 数据工程如何提升智效比？

在 Ling-3.0-flash 上，智效比有一个直观的度量：单位计算成本所能提供的智能水平——用 5.1B 激活参数，提供超越同参数量级别旗舰模型的能力。

在模型研发过程中，智效比还有另一面：从提出一个问题，到获得一个可验证的结果，需要投入多少时间和工程资源。

数据生产周期的缩短，并不意味着模型效果必然提升。但它可以让研究团队：

• 更快判断一种数据选择是否值得继续；
• 更方便地比较不同质量标准和数据配比；
• 更清楚地追溯实验数据的来源与处理过程；
• 减少在建表、编排任务和维护脚本上的重复投入。

在相同的时间和工程条件下，研究人员因此能获得更多验证问题的机会，更早发现无效方向，也让有效的数据策略更快进入后续训练和评测。

这正是数据工程对智效比的贡献：不是替模型得出结论，而是降低获得可靠结论所需的等待和工程成本。

07 让每一次数据探索，都更接近答案

VLDB 是国际数据管理领域的重要会议，目前已召开 52 届，其工业赛道关注能够在真实生产环境中解决大规模数据问题的系统与实践。

OmniTable 获得 VLDB 2026 最佳工业论文奖，是对这项大规模数据工程实践的认可。对百灵而言，更重要的是它所解决的实际问题：如何让研究人员减少等待与重复操作，如何让数据处理过程更容易追溯和复现，以及如何为经过筛选、处理和验证的数据进入后续训练提供稳定支撑。

从 Ling-3.0-flash 到 OmniTable，百灵从模型运行与研发工程两个维度持续提升智效比：既提高单位算力所能承载的模型能力，也提升单位工程投入所能支持的有效验证效率。

面向真实世界的智能，需要模型、数据与系统共同发挥作用。百灵也将继续从这些具体的工程问题出发，在模型能力、运行效率与研发投入之间，探索更高的智效比。

相关论文已公开：https://arxiv.org/abs/2609.11148v1 

《OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration》

点击文末「阅读原文」，查看论文全文。