The Window Before AWS Wakes Up: Nebius CTO on Racing the Hyperscalers

Nebius 的 CTO Dima 透露：他们 2024 年硬件团队仅 40-50 人，软件团队已扩张到 200 人，AI 云市场未来 3-5 年需求或再增长 10-100 倍。

AWS醒来前，AI云拼的不是GPU

嘉宾是 Nebius CTO Dima。他在公司还未命名为 Nebius 时便加入，核心硬件团队则来自 Yandex：这群人运营过横跨多个设施、数十万乃至数百万服务器规模的基础设施。Dima 主导了 Nebius 从头重写云平台，也亲历了 AI 云从“谁抢到 GPU”变成“谁能把 GPU 变成可靠服务”的全过程。这场对话最有意思的地方在于，他没有把 AI 基建讲成芯片采购故事，而是讲成一场供应链、软件、调度和责任体系同时失控又必须同时收住的战争。

这期回答了 8 个问题：

1. AWS、Google Cloud 和 Azure 为何没有在 AI 云市场一开始就通吃？
2. 当所有人都在抢 GPU 时，为什么 Nebius 认为软件才是护城河？
3. AI 基础设施真正的瓶颈，为什么不是电力、芯片或机房？
4. 企业部署开源模型，为什么不该执着于“原版最大模型”？
5. 低延迟推理到底该靠重造硬件集群，还是靠软件编排？
6. AI 编程普及后，工程师的责任边界应该如何重设？
7. 为什么一个 30MW 数据中心，如今可能都不够服务单一客户？
8. 未来 AI 基础设施卖的会是模型调用，还是“结果达成率”？

被问到为什么 hyperscalers，也就是 AWS、Google Cloud、Azure 这类超大规模云厂商，没有更早、更彻底地拿下 AI 云市场时，Dima 先泼了盆冷水：这不是它们不知道怎么做，也不是它们卖不动，而是可分配的芯片容量太少，外部 AI 云在它们的总盘子里仍显得不够大。微软、Google 一边要把 GPU 留给内部训练、推理和研发，一边又要卖给外部客户；芯片不够时，两边必然抢同一批资源。Dima 的判断很直接：如果 Nvidia 能生产十倍芯片，市场格局可能早已不同。"Because there is not enough capacity for their scale, this is a relatively small business for them."（因为对它们那个规模而言，容量根本不够，这还是一门相对小的生意。）

更难的部分在后面。巨头原有基础设施是为传统云工作负载建的，AI 要的却是更高的网络吞吐、存储性能和集群互联能力。若要把这些能力铺进整套云栈，账单会非常大，而一门只有数十亿美元级别的新增业务，未必足以推动一家年收入规模极高的云厂商立刻重构底座。这意味着独立 AI 云的机会，不在于永远比巨头技术更强，而在于芯片稀缺时，巨头无法同时满足自己和市场。边界也很清楚：Dima 预计两到五年内短缺缓解后，巨头会重组内部系统，并带着销售体系重新进场。窗口期不是护城河，窗口期里做出的规模才可能是。

被问到 AI 数据中心扩张里到底哪个最卡脖子——电力、散热、网络、HBM 高带宽内存，还是 GPU——Dima 的回答没有选任何一个。他说，CPU 缺、NVMe 缺、合格劳动力缺、网络收发器也缺；更上游的大型电力变压设备，交付周期已经按“年”计算。换句话说，建 AI 数据中心不像缺一颗螺丝钉的装配线，更像所有零件都可能迟到的施工现场。"There is one single bottleneck and that's your ability to execute."（只有一个真正的瓶颈：你的执行能力。）

Nebius 的应对不是坐等某一种供给恢复，而是在设施之间不断挪动资源：这个项目先延，那个项目必须按时交；这批设备先从 A 机房调到 B，条件具备后再移回去。Dima 甚至认为，经验丰富的项目经理可能是他职业生涯里最紧缺的人才之一。这里的“执行力”不是抽象的管理口号，而是同时掌握采购、交付、机房排期、设备迁移、客户承诺和优先级取舍的能力。

这意味着，AI 基建公司未来比的不只是融资额和拿卡量。资本可以买设备，却不能自动解决“哪台设备现在该去哪、哪个客户不能延、哪个项目值得牺牲”的连续判断。反面也要看清：执行力不能让变压器明天到货，也不能凭空制造 GPU；它只能决定在多种短缺叠加时，谁还能继续往前走，谁会被一个延误拖垮全部计划。

被问到 AI 云的差异化是否只是“谁能拿到 GPU”时，Dima 把 Nebius 的起点讲得很具体：同一套平台，既要服务一个由数万张 GPU 互联而成的大集群，也要服务一个只租一张 GPU、只用半小时的自助客户。前者像把整座发电厂卖给一家工厂，后者像让普通用户扫码充电；底层资源相同，产品形态却完全不同。

Nebius 的人员配置能说明它押注在哪里。2024 年，负责 GPU 采购、服务器和机箱、固件、网络建设的硬件团队约 40 至 50 人；软件组织已经约 200 人。公司没有选择托管裸金属，也没有拿第三方服务拼成一个界面，而是从头重写平台，并在 2024 年底上线新版本。原因在于，客户买的不是一块插在机架里的 GPU，而是可被隔离、调度、计费、连接存储和网络，并能稳定交付的算力。

这意味着 GPU 采购能力会逐渐变成必要条件，而不是充分条件。真正难的是把万卡级集群的虚拟化、存储、网络和工作负载隔离，做成普通客户也能自助购买的“零售商品”。云的本质，正是把批发级复杂性藏到用户看不见的地方。代价也不小：软件优先意味着平台重写风险、招聘压力和交付压力同时上升。硬件到了不等于产品能卖，产品上线也不等于在大规模下还能保持稳定。

被问到推理侧还有什么比 prefill/decode 解耦更值得优先优化时，Dima 把焦点拉回企业的真实任务。他说，Nebius 的客户里，95% 不会原封不动运行开源模型。"95% of our customers do not run vanilla open-source models."（我们 95% 的客户都不运行原封不动的开源模型。）它们会修改、微调模型，因为企业要解决的通常不是无边界问题，而是限定领域里的具体流程：某类文档审核、某种客服判断、某个内部操作链路。

这就带来一个不那么直觉的结论：若只需要模型在一个任务子集上保留前沿推理能力，就没必要为所有不相关能力继续背负最大模型的成本。Nebius 因此投入内核优化、模型压缩等专门团队，还通过一次收购补齐了模型优化、压缩和 speculative decoding 人才。所谓 speculative decoding，可以简单理解为让较小模型先“打草稿”，再由主模型验证，从而减少等待。

这意味着企业评估模型时，通用榜单分数会变得没那么重要。更关键的是结果是否稳定、完成一件事要多少真实秒数或分钟，而不是模型理论上会多少种能力。但这条路有明确边界。开放式深度研究、宽泛编程任务的边界不断变化，今天删掉的能力可能明天就需要；模型一旦被选择性压缩，离开原定场景就可能明显失灵。删能力不是降级，而是以任务边界换取效率；前提是你真的知道边界在哪里。

被问到面对不同延迟需求的客户，Nebius 会不会为每类客户搭一套专属硬件集群时，Dima 的回答是连续四个“No”。Nebius 的前提是先建一套通用云平台，把基础性能基线抬到足够高，让绝大多数工作负载都能跑进去。对于托管推理客户，再围绕 SLA，也就是服务等级承诺，去测首个 token 出现的时间、整个请求完成的延迟，以及特定流量模式下能否达标。

但优化的位置不在硬件。"This is never done on the hardware level, because hardware is good enough."（这从来不是在硬件层面完成的，因为硬件已经足够好了。）Dima 说，底层基础设施也很少需要改动，工作会一路向上移到编排层、模型层，以及请求从客户 endpoint 抵达推理服务器的整条路径。比如该怎么路由、怎样排队、如何批处理、哪些请求可以共用资源，往往比再换一批机器更影响用户感知。

这意味着低延迟竞争会越来越像交通调度，而不是修更多高速公路。硬件是路面，足够好之后，堵不堵车取决于谁先放行、车辆怎么分流、是否把不同目的地的车硬塞进同一条道。通用硬件并不代表无需定制，客户的 SLA 和流量形态仍不同；只是定制应尽量放在更高的软件层，而不是每接一个客户就重造一座机房。这样才能既保留规模效应，又把差异化放在可复制的软件里。

被问到模型编码能力快速提升后，技术组织该如何调整时，Dima 的态度是“开放使用，收紧责任”。Nebius 不限制个人或部门的 token 使用量，给 AI 工具的预算也相当可观。公司并不把 token 当成需要层层审批的办公耗材，而是默认工程师应当用 AI 降低重复劳动、释放认知负担。但放开额度，不等于把工程判断外包出去。

团队会审查工具具体如何被使用，尤其留意低效使用方式；更重要的是，公司制定了明确政策：由 agent 参与完成的代码，责任仍归提交者本人。那份 pull request 是你的，线上出故障时半夜被叫醒的人也是你。完全由自主 agent 生成的内容会被标记，而且这类 agent 在一段时间内不会接触核心服务。Dima 担心的是“slop”——表面顺滑、看起来像那么回事，但实际不可维护、不可验证的机器产物。

这意味着 AI 编程没有把工程师从责任链上移走，反而迫使角色变化。过去，工程师主要对自己亲手写下的逻辑负责；现在，他还要对模型建议、自动生成补丁和工具调用路径负责，工作更像审查员、系统所有者和故障响应人。边界也很现实：生成速度越快，混入核心系统的垃圾代码可能越多。一个流畅的 agent 界面，很容易让人误把“能跑”当成“可信”。因此，自动化可以扩张，核心权限却不能无条件下放。

被问到建设 Nebius 至今最大的失误是什么时，Dima 没有说选错芯片路线，也没有说融资不够快。他说，自己低估了单一客户如今的运行规模。"I underestimated the scale that a single client operates at nowadays."（我低估了如今单一客户的运行规模。）五年前，一座 30MW，也就是 30 兆瓦的数据中心，已经是能容纳数十万服务器的大型设施；现在，它有时甚至不够服务一个客户。

存储的数据更能让人感到尺度变化。过去讨论网络附加存储吞吐，单位还是每秒数百 MB，或者数 GB；如今，Nebius 的部分客户会从单一共享文件系统持续读取每秒数百 GB。Dima 提到的极端数字是，一组连接大量 GPU 服务器的共享存储卷，可以被客户打到每秒 500、600、700 GB 的吞吐。这里不是多加几张显卡那么简单，网络、存储、文件系统和调度都必须一起扛住。

这意味着容量规划的最小单位变了。以前的问题是“一座数据中心能服务多少客户”；现在更常见的问题是“一个头部客户会吞掉多少座数据中心的资源”。销售合同、资源预留、建造节奏都要按极端客户重新计算，否则卖出一个大单，反而可能把整个资源池挤爆。Dima 也承认，即便自己长期做基础设施，面对这些末尾多出几个零的新常态，仍在适应。规模不是线性放大，它会迫使原本合理的设计假设全部重写。

被问到哪些未解趋势最可能改变 Nebius 的整体战略时，Dima 说自己已经不太关注模型会不会更大、更聪明了。他把这当作既定趋势，真正盯住的是 agent 如何更可靠地完成任务。Nebius 内部为此设了一个小型研究组，研究怎样提升 agent 抵达结果的概率，而不只是替换成更大的模型。"I think like a lot of future AI adoption lies in how reliable your agentic scenarios are and how reliably you reach those outcomes."（我认为，未来很大一部分 AI 普及取决于你的 agent 场景有多可靠，以及你能多可靠地达成结果。）

这里的变化是从“请求”转向“结果”。过去，人们计量的是一次模型调用花多少 token、速度多快、价格多低；长时运行的 agent 则要经过质量门、调用复杂工具、使用不断演化的 harness。harness 可以理解为包在模型外面的任务执行框架：它给模型工具、规则、检查和重试机制。有时 agent 能运行数分钟，却一次都不向 LLM 发后端请求，因为它正在执行代码、校验结果或操作工具；这会产生显著的 CPU 消耗。

这意味着未来 AI 基础设施不能只卖 GPU 时间和模型调用次数。客户更可能关心：这个 agent 是否稳定完成任务，失败后能否检测和恢复，完成一次任务到底消耗了哪些算力。GPU 仍重要，但 CPU、工具链、沙箱、质量门和 agent 编排会一起进入产品核心。真正被定价的，也许不再是“调用了多少次”，而是“这件事到底有没有办成”。

“GPU只是入场券，把万卡集群零售化才是护城河”和“下一代AI基础设施，卖的不是调用量而是结果达成率”，其实在说同一件事：AI 基础设施正在从卖设备能力，转向交付可验证的业务结果。GPU 是原材料，不是终点；模型调用是过程，不是终点。用户真正付钱，是为了让一个训练任务跑完、一套推理服务满足 SLA，或一个 agent 稳定完成工作。

这也是 Nebius 的核心赌注。“巨头没赢AI云，不是技术不行，而是生意还不够大”说明，它并不假设 GPU 会永久稀缺；“AI基建没有单一瓶颈，真正稀缺的是穿越混乱的执行力”则说明，在巨头全面适配 AI 工作负载以前，胜负取决于谁能把采购、设施、软件和客户需求先拧成一条线。

对读者而言，这套判断也适用于自己的 AI 项目。别只问模型够不够大、GPU 够不够多。更该问的是：任务边界是否清楚，延迟究竟卡在哪一层，模型生成的东西谁负责，系统能否稳定走到结果。答案若只是一张更贵的 GPU 账单，问题多半还没有被真正解决。