今融道从很早开始，我就保持一个习惯：每年 GTC 之后，把黄仁勋主题演讲里那些被 PPT 一笔带过的词单独拉出来，对照产品发布清单和合作生态的变动，重新读一遍。今年（GTC 2026）这场读完，我最大的感受不是又发布了哪块新 GPU，而是他用了大量篇幅去讲“数据”这件事，从数据工厂、数据飞轮到企业数据管道的生态合作，几乎是把数据底座摆到了和算力底座同等重要的位置上。
如果你只盯着芯片参数，会觉得这届 GTC 还是老配方；但如果你做的是数据工程、AI Infra 或者企业数字化架构，就会发现风向已经明显变了——算力军备竞赛的上半场拼的是能用多少张卡训练多大模型，下半场拼的是能不能稳定地、高质量地、低损耗地把数据喂给模型。这篇文章我想从我的视角拆一拆这个变化：黄仁勋为什么在这个时间点反复强调数据，传统数据架构到底卡在哪，AI 时代的数据底座重新定义之后，企业应该按什么顺序去重构、哪些坑我建议你绕开。
内容会偏向实际工程判断和架构层面的推演，适合正在做 AI 应用落地、数据平台建设，或者准备把企业数据资产真正用起来的团队参考。
1. GTC 2026 的风向标：从“卖算力”到“铺管道”，NVIDIA 的叙事重心变了
1.1 过去的 GTC 讲芯片，这届 GTC 讲“数据供应链”
如果你往前翻几届 GTC 的主题演讲，核心脉络非常清晰：新一代 GPU 架构、互联带宽、CUDA 生态更新、推理成本优化。整个叙事围绕一个逻辑——“模型效果和算力规模强相关，想变大就买更多算力”。这个逻辑在最吃算力的预训练阶段完全成立，也确实是过去几年英伟达增长的基本盘。
但今年能明显感觉到一个转折：黄仁勋在演讲里花了不少时间讲“AI 工厂”的完整链条，而不是只讲工厂里的“机床”。他把人工智能的落地拆成了三个环节——计算（Compute）、基础设施（Infrastructure）、数据（Data），并明确提到模型的智能水平同时取决于三者，而不是只取决于前者。这个表述如果放在五年前，可能只是泛泛而谈，但今年配合着发布的数据处理工具链、检索框架升级、以及与多家数据基础设施厂商的深度合作来看，它其实是在给市场传递一个信号：GPU 性能再强，如果企业的数据进不来、洗不净、供不上，AI 项目照样跑不起来，而英伟达的商业护城河也不能只靠芯片。
我关注到一个很有意思的细节：他在演讲中专门放了一张“token 消耗量”的对比曲线，展示企业级 AI 应用上线之后数据调用量如何呈指数增长，并借此引出“数据工厂”这个概念——模型训练是炼油，但在此之前的采集、清洗、标注、增强、版本管理，是整条炼化链路上最容易被低估、却又决定成品率的环节。把话说到这个份上，已经不是在推荐某个具体产品了，而是在重新定义整个产业的价值链分配。
1.2 黄仁勋点名的几个关键指标，背后藏着数据底座的转向
如果你仔细听，会发现他这届反复出现的数据相关指标和以前的“浮点算力”“显存带宽”完全不同。他不再只强调每秒能算多少次，而是强调几个和数据处理效率直接挂钩的数字：
- 数据吞吐的“有效利用率”。过去我们看一个存储集群，习惯看 IOPS 和带宽，但 AI 场景下真正要命的是数据从存储到 GPU 显存的“有效供给率”——数据格式不对、文件碎片多、元数据查询慢，都会让 GPU 在那里空转等数据，算力再高也是浪费。
- 样本级别的成本核算。他在多个案例里提到，企业真正应该关心的是“一个有效训练样本的成本”，而不是“一 TB 存储的成本”。这句话冲击力很大，因为传统数据平台的计费模型几乎全是按容量和计算资源算的，没有人按“样本质量”来算账。
- “数据飞轮”的闭环速度。他反复讲数据回流、模型在真实使用中产生的反馈数据如何被清洗后继续进入训练集，这个概念并不新鲜，但他公开点出“很多企业跑不起来飞轮，卡点不在模型，而在数据回流管道”，算是把锅从算法团队那边挪到了数据工程这边。
这些指标的变化说明一个事实：数据底座的核心评价体系正在从“存得下、读得出”转向“供得上、供得准”。这也是我这篇文章反复要说的主线——架构可以慢慢演进，但评价标准必须先变过来，否则你做的所有优化都可能打在错误的目标上。
1.3 为什么是现在：模型能力的天花板开始由数据质量决定
我很反感那种“某某时代来了”的空洞论断，但“数据质量决定模型效果上限”这句话，在过去一年里被反复验证。给你举个直白的例子：同样的开源模型基座、同样的算力预算，一家公司用爬虫堆出来的噪声数据做微调，另一家用经过清洗和领域标注的高质量数据集做微调，最后在业务指标上的差距可以达到 20% 甚至更高。这个差距不是模型结构带来的，就是数据带来的。
为什么是这个时间点爆发？因为模型架构本身的边际收益在放缓。各家基础模型的底子拉不开代差之后，比拼的焦点自然前移到“谁的数据更能代表真实业务分布”。再加上合成数据和领域数据的结合玩法越来越成熟，数据的生产、加工和供给方式已经变成了新的竞争阵地。黄仁勋这一届把数据放到和算力并列的位置，本质上是顺着产业必然走向做的叙事调整，只是他的嗓门足够大，把这个趋势一下子推到了公众视野中心。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 传统数据栈的“三堵墙”：为什么你的数据仓库和数据湖喂不动大模型
2.1 第一堵墙：数据仓库装不下非结构化数据
先说一个我天天听到的抱怨：“我们数仓里有十年的经营数据，怎么 AI 项目还是没数据可用？”问题恰恰出在这个“数仓里”。
传统数据仓库是为结构化表格设计的，它有严格的模式（Schema）、强一致的事务、成熟的 SQL 生态。这套东西处理订单表、财务表、用户表非常好用，但它几乎没有能力承载 AI 真正需要的大头——文本、图片、音视频、日志、代码、对话记录。业内有个粗略的估算：企业数据里非结构化数据占比通常超过 80%，而传统数仓能管理的只有那不到 20% 的结构化部分。你可能守着几 TB 的报表数据，但模型需要的客户对话记录、售后工单、设备运行日志，全散落在各个业务系统的对象存储里，没有统一的访问入口，更谈不上清洗和标注。
这不是换个工具能解决的，而是一个“入口”问题。AI 时代的数据底座第一层要做的事，就是把非结构化数据纳入统一管理，让数据工程师能像查表一样检索文档、图片和日志，而不是每次都要翻服务器目录。
2.2 第二堵墙：数据湖变成了“数据沼泽”
数据湖的理论初衷很好：所有数据先往里面放，便宜、灵活、不分格式，等要用的时候再定义结构。但落地几年之后，大量企业得到的是一个“数据沼泽”——把数据扔进去很容易，扔进去之后想找到能用、敢用的数据却难如登天。
我在多个项目里见过同样的场景：湖里有十几个团队各自上传的同一类业务日志，字段命名各不相同，数据质量层次不齐，有的区还缺少权限标记。到了训练大模型的时候，数据科学家根本不敢直接用湖里的原始数据，只能拉人重新做一轮清洗，一拉就是几周。
说到底，数据湖缺失的是“治理”这个基因。模型训练对数据质量的要求远比传统 BI 分析苛刻——BI 报表里缺几个字段还能看趋势，训练集里混入大量重复和错误样本，模型学到的东西会直接跑偏。湖里的脏数据如果不经过系统化的校验、去重、血缘追踪和质量打分，就喂给模型，那不是在训练模型，是在给模型下毒。
2.3 第三堵墙：ETL 管道的批处理基因与 AI 的实时需求相悖
传统 ETL 管道是按“天”甚至按“小时”来设计的：凌晨跑批、早上出数、分析师再来查。这个节奏做经营分析没问题，但 AI 应用对数据时效性的要求是完全不同的——尤其是检索增强生成（RAG）和智能体类应用，它们需要的是最新的事实数据、最新的用户会话状态、最新的库存和价格信息。等你今天凌晨跑完批，昨天的风控规则已经过时了。
而且传统 ETL 的“清洗-转换-装载”顺序也存在问题。ETL 的思路是先搞清楚数据结构再装载入库，但 AI 场景里很多清洗和转换发生在数据使用过程中——比如向量化的过程、预训练分词的过程、按语义切片的过程，这些工作不是一次性入库就能完成的，而是需要在“数据供给链路”上反复执行。这就是为什么大家都在谈从 ETL 走向 ELT 或 EtLT，本质就是把转换推迟到消费端，让数据先流动起来，再在需要的地方加工。
所以传统数据栈的问题不是一个点坏了，而是三个环节同时老化：存储结构不匹配、治理能力缺失、时效机制落后。这三堵墙不拆，就算买再多的 GPU，数据到不了模型嘴里，一切都是白搭。
3. AI 原生数据底座的三个支点：语义理解、数据工程自动化、治理前置
3.1 支点一：从“表结构”到“语义层”，向量检索与传统检索的融合
AI 时代的数据底座，第一个明显变化是数据访问方式从“按字段精确匹配”向“按语义相似度检索”延伸。这不是说 SQL 要消失，而是 SQL 变成了一个子集——你需要既能精确回答“上个月华东区销售额是多少”，也能回答“哪些客户投诉内容和库存短缺相关”。后者没有明确字段，只能靠语义检索。
所以现在主流的架构是“混合检索”：传统倒排索引负责关键词精确命中，向量数据库负责语义相似度召回，再由重排序模型把两路结果合并打分。这个架构看起来只是加了一个组件，实际影响的是整个数据建模方式。以前你要为某个查询需求专门建宽表、建索引，现在你只需要把文档切好片、把向量算好、把元数据挂对，就能覆盖大量未知的未来查询。
我建议团队做选型时不要迷信“纯向量数据库”，而要优先考虑那些同时支持标量过滤、全文检索和向量检索的引擎，因为真实业务查询里，“语义相关性 + 结构化条件过滤”的组合几乎是无处不在的。只靠向量相似度，你会发现召回结果漂亮但精确率惨不忍睹；只靠关键词，语义匹配又完全做不了。两者融合不仅是技术选型问题，更是数据建模思路的升级。
3.2 支点二：数据清洗和标注的自动化，合成数据成为重要补充
数据工程的自动化以前指的是“定时调度任务”，但 AI 时代的数据工程需要把“数据质量修复”本身变成自动化流水线。比如用大模型来做数据清洗规则的学习、用嵌入模型自动发现近乎重复的样本、用主动学习算法来选择最值得人工标注的样本——这些以前需要数据工程师一行行写规则的事情，现在正在被大模型和机器学习算法自身接管。
这听起来像“用魔法打败魔法”，实际效果却很好。我见过一个知识库项目，几千份产品文档里大量重复和过期内容，人工清理需要两周，用嵌入向量做去重和聚类，再结合 LLM 辅助判断过期段落，两天就完成了初筛，人工只要做最后确认。标注环节也一样，CLIP 类模型可以先给图像打粗标签，人工只需要修正置信度低的部分，标注成本直接降一个数量级。
合成数据在这轮重构里的角色也不容低估。真实数据总有长尾覆盖不足的时候——罕见的故障模式、冷门的说法习惯、新产品的早期使用反馈，靠真实采样可能等半年都凑不齐。现在通行的做法是用生成式模型针对短板分布做定向补全，再把合成数据和真实数据按比例混合。我特别想提醒的是：合成数据不是拿来“替代”真实数据，而是拿来“补充”边缘场景，如果反着用，模型能力会虚胖，一到真实环境就现原形。这个分寸，决定成败。
3.3 支点三：治理不再是事后清算，而是训练流程的组成部分
传统数据治理给人的印象是“合规压头才做项目”，一堆 Excel 和流程图，和业务跑得有多快毫不相干。但在 AI 原生数据底座里，治理必须变成内嵌在数据流水线里的关卡——每一个数据集在进入训练或推理链路之前，都要自动完成权限校验、合规审计、质量评分、来源血缘记录的检查，就像产品上线必须跑自动化测试一样。
我建议数据团队把治理规则做成标准化的“关卡”（Gate），而不是依靠人工审批。比如：数据进入训练集之前，自动检查是否包含敏感个人信息、是否超过授权用途范围、是否达到最低质量分；不过关的数据必须走人工申诉流程，而不是绕过关卡强行灌给模型。这样做的价值不止是合规，更是让数据工程师在训练事故（比如模型输出泄露隐私）发生时，能够通过血缘系统快速定位是哪一批数据、哪一步处理出的问题。
另一个被很多人忽略的点是：模型的版本管理必须和数据集的版本管理绑定。训练记录里光有“用了什么模型结构、什么超参”是不够的，必须能追溯“吃的是哪一个版本的数据集、清洗规则是什么、合成数据占比多少”。一个 AI 原生的数据底座，底层应该像代码管理一样管理数据集——有 commit、有分支、有回滚。
4. 重构数据底座的实操路线图：哪些先动、哪些缓动、哪些别动
4.1 先做“数据盘点与质量体检”，再谈架构升级
很多团队一听到“重构数据底座”，第一反应就是引入最新的湖仓一体平台、上向量数据库、搭实时计算框架。方向没错，但顺序大错特错。我在项目里见过太多“平台先行、数据一团乱麻”的案例：花了几个季度把新平台搭起来，结果数据迁移进去之后，质量问题被原封不动带了过来，新平台只是把旧沼泽装修成了新沼泽。
正确的第一步是数据资产的全面盘点和质量体检。盘点不需要追求自动化全覆盖，先把核心业务域的数据找出来，明确四个问题：这个数据是谁产生的？它现在存在哪？它的质量分是多少？它能否被合法地用于 AI 训练或推理？这一步的输出不是架构图，而是一张“现状登记表”——按业务域、数据源、格式、质量等级、敏感级别、可用性来打分。有了这张表，后面所有架构决策才有依据。
质量体检还有一个隐藏收益：它能帮你快速找出“快赢项目”。比如某组客服对话记录虽然散，但字段完整、质量尚可，只要做个管道接到大模型就能做知识库问答，这个项目两到三周就能见效。先打一个胜仗，团队信心和数据治理话语权都会大幅提升，后面推进大改造的阻力会小得多。
4.2 增量改造优于“推倒重来”：湖仓一体和可插拔计算层
数据底座的迁移改造，最忌讳的是“推倒重来”。原因很简单：企业数据资产是二十年积累出来的，里面牵涉无数历史包袱和隐性问题，一步到位的“大爆炸”式迁移，失败概率极高。我倾向的路线是增量演进：保留现有数据仓库继续跑核心报表，同时引入湖仓一体的架构把流批链路统一起来，让离线数据湖和在线数仓共享同一份元数据，但物理存储可以分阶段合并。
具体落地上，先把 IoT 日志、对话记录、文档内容这些非结构化数据接入新平台，因为它们对旧数仓本来就是负担，迁走之后两边都变轻。等新平台的稳定性验证通过，再把核心数仓的读流量一点点切过去——先读后写，先副本后主库，一旦出问题随时回退。这个策略看起来慢，但每一步都是可逆的，风险被摊薄在周期里，而“活儿活着、老系统还能兜底”本身就是最大的降险。
可插拔的计算层也非常关键。不要把数据处理逻辑绑死在某一个引擎上，尽量用开放的表格式（比如 Iceberg 这类开源方案）和统一的 Catalog，让 Spark、Flink、Presto、向量检索框架都能直接读写同一份数据。这样做的好处是：将来某个引擎落伍了、某个新框架出现了，你只需要加一个适配器，不需要再做一次数据搬家。
4.3 团队技能结构的调整：数据工程师要补的 AI 功课
重构数据底座，最容易被低估的是团队技能的升级。很多人以为招几个算法工程师就够了，但实际瓶颈往往在“懂数据工程又懂模型数据需求”的中间层人才。
传统数据工程师需要补的功课大概有三块：一是理解训练集和评估集构造的基本逻辑，知道什么叫数据泄漏、什么叫标注偏差，否则洗出来的数据模型直接学歪；二是掌握和向量化、嵌入模型相关的操作技能，至少要知道什么时候该用哪种切片策略、选择多大向量维度、如何做混合检索的调参；三是建立“数据即产品”的意识，把数据集当作有版本、有文档、有服务等级协议的产品来运营，而不只是跑批任务。
团队里最好能设置一个“数据与模型接口人”的角色，专门负责翻译两边的话：把算法团队对数据分布、质量、时效的要求转译成数据工程的任务，把数据清洗和供给的成本与限制反馈给算法团队。这个角色不用太多，一个就够，但必须有。很多 AI 项目死在“算法怪数据不行，数据怪算法不讲需求”的互相拉扯上，一个合格的接口人能省掉一半内耗。
5. 未来一年，我对数据底座的几个技术判断与建议
5.1 数据编排会成为比模型微调更稀缺的能力
过去一年，我越来越明显地感觉到：模型微调的门槛在快速下降，开源基座加上成熟的微调框架，一个合格的算法工程师几周就能跑通；但数据编排——也就是把零散的内部数据、外部数据、反馈数据组织成高质量训练供给链路的整套能力——仍然极度稀缺，因为它是高度依赖业务理解和工程经验的脏活累活。
未来的竞争高地，一定是“谁的数据管道更顺、样本成本更低、飞轮转得更快”。所以我的建议很直接：如果你所在的团队资源有限，别把宝全押在自研模型和复杂微调上，把资金和人力优先投到数据管道的自动化上，投到“让高质量数据以最低成本进入模型”这件事上。这个判断未来一年大概率依然成立。
5.2 成本核算单位将从“存储/计算”变为“Token/样本质量”
财务模型的变化值得单独拿出来说。以前数据平台的成本中心很清晰：存储买多少 TB、计算跑多少 CU，按资源量核算。但 AI 场景下，存储和计算成本只占模型总成本的一小部分，真正的大头是数据准备的人力成本和算力在无效数据上的浪费。
我建议企业从现在就引入一个新的成本指标：有效训练样本的单位成本。它的计算方式是（全链路数据工程成本 + 所消耗算力成本）÷ 最终通过质量关卡、进入训练集的有效样本数。第一次算这个指标，很多团队会被吓一跳——因为清洗环节的返工成本、无效样本消耗的 GPU 时数，会彻底暴露传统数据栈的低效。把这个指标纳入月度复盘，你会发现团队的优化重点会自动转到数据质量的前置治理上，而不是事后救火。
5.3 给从业者的三个建议：小步快跑、双轨验证、留好回退
最后说几句掏心窝的建议，完全是基于我自己踩过坑之后总结出来的。
第一，小步快跑。不要试图一次性建完“完美底座”，选一个业务痛最明确的场景（客户支持、知识管理、风控辅助都可以），两周内做出端到端的管线，让数据从源头流到模型输出结果。这个 Demo 不需要完善，但必须全链路打通，因为它会把所有隐藏的坑暴露出来——权限、格式、质量、时效，哪个环节断了马上就能看到。
第二，双轨验证。任何数据改造，都让新旧两套并行跑一段时间，用同一个业务指标去对比。旧管道结果作为基准线，新管道只有证明“不低于基准且越跑越好”时才算成功。这个过程中你会积累大量关于数据质量和管道的真实认知，远比你读一百篇架构文章有用。双轨并行会带来暂时的双倍成本，但相比出事故的代价，这点成本完全值得。
第三，留好回退。我给团队定的规矩是：“任何一步改造，上线前必须有能力在四个小时内回到上一个稳定状态。”也就是说，数据表的变更要有版本，管道的调度要有开关，模型的提示词和知识库要能一键切换。听起来保守，但真实的业务环境里，你永远不知道哪份数据会在哪个环节出问题，可回退性是底线。
重构数据底座这件事，它不是某一个季度能完成的项目，而是一种持续演进的能力。方向已经很清楚——算力底座决定你能跑多大的模型，数据底座决定你能把模型用到多好。早一点把评价标准切换过来，早一点让数据管道变成一种工程能力，你后面的路会越走越顺。