30 秒看懂
Nebius 首席技术官 Danila Shtan 与投资人 Jacob Effron 讨论公司的软件驱动云平台。他介绍 Nebius 的起源、新芯片上线、客户需求、推理优化、供应约束和竞争格局,最后解释自己对 AI 辅助工程持谨慎态度的原因。
- 1软件是差异化因素Shtan 说,Nebius 希望用同一平台同时服务超大规模集群和短时间的单 GPU 任务。
- 2存储达到新的规模他介绍了客户需要从共享存储中每秒读取数百 GB 的工作负载。
- 3分离部署很难部分高需求客户已部署分离的预填充和解码,但他认为这不是通用的默认方案。
- 4推理尚未充分优化Shtan 认为服务配置、内核和模型压缩都有改进空间;他说多数 Nebius 客户使用经过修改的模型。
- 5超大规模云厂商全面回应前的窗口他将市场机会归因于芯片短缺、内部需求和改造既有基础设施的成本。
- 6对生成代码负责Nebius 观察 AI 使用情况,同时要求工程师对工作负责,并将完全自主的 agent 排除在核心服务之外。
要点建议
- AI 云既需要加速器,也需要能够服务不同规模客户的软件平台。
- 存储吞吐和企业合规可能与获取 GPU 同样重要。
- 推理仍有大量优化空间,但分离预填充和解码难以普遍运营。
- 芯片短缺、内部需求与改造基础设施的成本给了专业云厂商成长时间。
- 工程师仍须对 agent 生成的代码负责,完全自主的 agent 不得接触核心服务。
按章节阅读整理后的全文
AI 云的机会
Jacob Effron 介绍 Danila Shtan。后者解释 Nebius 以软件为核心的做法,以及对独立 AI 基础设施的押注。
Nebius 首席技术官 Danila Shtan 认为,如果 NVIDIA 能生产十倍数量的芯片,AI 云市场的格局将有所不同。超大规模云厂商面临供应有限、内部需求竞争,以及改造原为其他工作负载构建的基础设施所需的成本。
Jacob Effron 介绍 Shtan,并追问专业 AI 云市场为何会出现。两人将讨论 Nebius 的起源、新芯片上线、推理、数据中心的约束,以及来自大型云厂商的竞争。
Effron 从一种常见假设问起:AI 云是否只需要拿到 GPU?自称偏爱软件的 Shtan 说,平台本身很重要,因为客户所需的算力规模差别很大。
Nebius 一开始就希望既能支持在互联集群中使用数万块 GPU 的客户,也能服务只需租用半小时单块 GPU 的自助用户。Shtan 认为,大规模建设并按较小份额提供服务的能力是其产品核心。
Shtan 不喜欢“新云”这个称呼。他说,这个词原先指少数公司,如今却被扩展到数百家。Nebius 把自己视为 AI 云,在他看来,下一步的竞争对手不仅是其他专业厂商,还有 AWS 和 Google Cloud。
他承认 Nebius 的规模远小于 AWS,但表示公司押注的是一个迅速扩张的市场。尽管基础设施投资巨大,他预计未来几年需求仍会大幅增长。
一些大型 AI 集群服务于所有者自己的产品,而非整个市场。Shtan 还说,Google、Microsoft 和 Meta 必须在对外租赁与自身大量研究和生产需求之间取得平衡。
Nebius 的押注是:没有同等内部消耗压力的独立供应商,可以为成长中的客户提供所需算力。随后 Effron 询问公司如何走到这一步。
起源与新芯片
Shtan 介绍公司从 Yandex 分离的过程,以及集成新 NVIDIA 系统所需的工作。
Shtan 说,他在公司更名为 Nebius 之前就已加入。公司与 Yandex 的分离于 2024 年完成;据他说,新公司此后与俄罗斯资产没有关联。
Effron 问,Yandex 的哪些经验能迁移到 GPU 云。Shtan 首先提到基础设施团队:他们曾在多个设施中运营数十万乃至数百万台服务器,这种经验帮助公司完成早期建设和扩张。
软件方面则没那么直接。Nebius 必须从头重写平台,同时迅速招聘;因此到 2024 年底,软件团队中已有相当一部分成员来自 Yandex 之外。
尽管如此,公司仍坚持构建统一云平台,而不是仅提供托管裸机,或拼接第三方服务。Shtan 认为,有经验的基础设施团队和扩张期间招聘的工程师都发挥了作用。
他将公司的重点与一些先采购 GPU、再寻找买家的企业作比较。他说,2024 年公司硬件团队约有 40 到 50 人,而软件团队已有约 200 人。
Effron 问,从了解新一代 NVIDIA 芯片到向客户提供服务,中间要做什么。Shtan 说,NVIDIA 很早就会分享原型和设计方案,但团队在紧迫的时间里发现问题、不断迭代,设计也可能反复变化。
消费产品的最终设计可能在发布前很久就确定,而 AI 硬件市场变化迅速,发布时的信息往往只是初步方向,并非完整的最终规格。NVIDIA 的决定还会影响整个市场的供应链。
当样品接近量产系统后,Nebius 会进行测试,把新硬件的能力和限制纳入平台。由于公司提供的是云服务,而非简单的裸机主机,团队必须确保负载隔离、虚拟化、存储和网络能协同工作。
有时公司的集群规模足够大,会遇到其他人尚未见过的软件问题。工程师将问题反馈给 NVIDIA,提出或接收修复方案,测试后再将硬件整合进更广泛的平台。
新架构也会改变运维边界。Shtan 对比 B300 类部署与 GB300 系统:后者的隔离与维护可能涉及整个机架,而不只是关闭单台服务器并转移其工作负载。
客户需求与存储
训练和推理对基础设施有共同要求,但不同客户的合规需求各不相同。
Effron 询问不同客户的需求。Shtan 说,每位客户都有特点,但底层负载通常属于训练或推理等熟悉的类别。公司最初低估了一项许多客户共同需要的能力:存储。
存储不只是总容量的问题,吞吐和延迟也很重要。Shtan 说,一些客户经常从连接 GPU 服务器的共享存储卷中每秒读取 500 到 700 GB;几年前他还没预料到这种规模。
在他看来,为高需求场景设计平台——例如将数 PB 的共享文件系统连接到数千台服务器——可以提高平台的基本能力,从而服务更广泛的客户。
Shtan 说,更重要的差别可能来自客户的成熟度和义务。新成立的 AI 实验室可能在算力上花费巨大,却主要关心 GPU 和存储性能、可用性及连接情况,而不那么在意设备的具体地点。
企业客户的合同可能较小,却有现成客户、运营程序和跨司法辖区的义务。他们会询问认证、合规、安全状况、源代码审查以及如何防范具体攻击。
推理中的取舍
Shtan 讨论延迟、分离式服务,以及优化模型和软件的机会。
Effron 问,延迟和成本要求不同,是否会导致 Nebius 建造不同的集群。Shtan 说,底层平台旨在保持通用,并提供足够高的基础能力来支持多种负载。
在托管推理中,客户会提出流量模式和服务水平目标,例如首个 token 的生成时间或请求总延迟。Nebius 随后针对这些要求进行基准测试和优化。
Shtan 说,这类调优通常发生在软件栈的更高层:编排、模型服务,以及从客户端点到推理工作节点的请求路径。他通常不会因此重新设计底层硬件。
谈到将推理的预填充与解码分开,Shtan 说很多人都在讨论,但要把它运营好仍然困难。其他更简单的改进往往就能满足客户目标,因此他不认为分离是所有负载的默认选择。
Nebius 已有一些有前景的原型,也为需求特别高的客户提供了部分生产部署,但这些部署需要更细致的人工处理。他说,更新的机架级系统通过更快的互联,可以减轻此前的一些挑战。
哪些负载适合放在一个机架中,需要具体分析。一个机架可以处理大量流量,供应商也能将多个托管推理负载放在一起。关键是负载是否受益于刻意设置的预填充与解码资源比例,以及如何有效装箱。
谈到更容易实现的推理改进,Shtan 说开权重模型的服务远未成为已解决的问题。如果仅使用服务引擎对新模型的初始支持,未经进一步优化就运行,速度和成本可能令人失望。
他指出,请求处理、服务器配置和内核调优都有机会改进。优化尤其可以针对实际流量模式,而不是假设所有客户的工作负载都相同。
除了推测解码等技术,Shtan 还认为模型剪枝和压缩的潜力尚未充分挖掘。他说,约 95% 的 Nebius 客户使用经过修改或微调的模型,而非未经调整的版本。
较窄的应用场景可能只需要模型在一个领域保留强推理能力,而不必在其他方面保持同样广度。因此,选择性压缩也许可以得到更适合特定任务的模型;但 Shtan 说,这种方式不太适合开放式研究或广泛的编程任务。
对于专业化的企业 agent,他认为结果的可预测性,以及达成结果实际需要的时间,会成为重要指标。他预计这些领域还会进一步改进。
产品与数据中心
对话转向产品选择、收购 Tavily,以及标准化的数据中心建设。
Effron 问,哪些优化应成为 Nebius 的产品,哪些可以直接受益于更广泛的生态。Shtan 说,公司希望在多个层面投资,因为这些收益可能相加,甚至相乘。
他介绍了一次旨在增加模型优化、压缩和推测解码人才的收购。Nebius 将这些人才与现有团队结合,分别研究内核和模型压缩问题。
Effron 问起收购网络搜索公司 Tavily。Shtan 说,Nebius 对它的产品和市场推进速度印象深刻,也相信自己在大规模基础设施和网页索引方面的经验能够帮助团队加速。
他说,搜索目前尚未完全融入 Nebius 的所有产品。公司正在探索将托管推理与包括沙盒在内的 agent 工具结合,同时还有其他处于早期开发阶段的产品。
谈到数据中心,Shtan 说建筑物可能不同,但 Nebius 控制内部建设。租用设施时,公司可能租用建筑和电力,而内部网络与硬件仍遵循自己的标准。
他说,即使采取第三方为设施和 GPU 提供资金的轻资产模式,也遵循同样原则。标准化硬件和内部建设有助于 Nebius 保持技术栈的一致性,并满足服务水平承诺。
瓶颈与竞争
Shtan 分析执行上的约束,解释专业云厂商为何能在超大规模厂商旁边立足。
Effron 问,电力、劳动力、冷却、网络、内存和 GPU 的短缺中,哪项最制约 AI 建设?Shtan 回答说,瓶颈是同时解决所有这些问题的执行能力。
他列举了 GPU、CPU、NVMe 组件、设施、电力、合格工人和网络收发器等方面的短缺。大型电力变压器的交货时间可能以年计算,使采购与排期相互牵制。
在他看来,优势在于采购组件、作出适当取舍,并随着优先级变化在设施之间调配资源。当众多约束需要同时跟踪时,有经验的项目经理尤其宝贵。
Effron 问,长时间运行的 agent 和后训练等负载变化,是否要求以不同方式建设集群。Shtan 说,底层平台只要能力足够,便可支持大多数场景;更大的挑战是高效组合和拆分负载。
新硬件架构可能增加一些专门选项和限制,但他预计最低层基础设施的根本变化会比人们想象的少。平台需要提供合适的基本能力,并在不需要完整节点时支持负载共置。
为什么超大规模云厂商没有更有决定性地赢得市场?Shtan 不认同他们没有尝试:他们已经获得大额合同;据他说,即使公开标价看起来昂贵,实际商议的价格也可能很有竞争力。
一个约束是,超大规模厂商必须在内部需求和外部客户之间分配稀缺芯片。Shtan 认为,如果 NVIDIA 芯片供应充足得多,市场结构可能会截然不同。
与成熟超大规模云厂商的庞大收入相比,这项业务目前所占比例也相对较小。这会影响它获得的关注和资本,尤其是服务 AI 负载需要改造网络和存储。
Shtan 预计,随着市场扩大、芯片短缺缓解,大型云厂商将增加投资。他们的销售能力会发挥作用,因此 Nebius 押注自己能足够快地成长,等他们更加关注这个市场时,以相近规模参与竞争。
市场的长尾
他预计市场将出现整合,大型厂商会继续扩张,但独立公司仍有空间。
Effron 问,五到十年后还会剩下多少专业供应商。Shtan 预计会有整合和失败,但独立供应商的长尾仍将存在,正如今天较小的托管公司依然与 AWS 并存。
他认为,增长自然会推动大型云厂商进入相邻产品领域,但这不意味着独立供应商都会消失。他举出专业存储、算力和数据库公司的例子,说明它们仍能与综合云平台并存并找到客户。
大型供应商将受益于捆绑销售和销售网络,但 Shtan 说,在一个非常大的市场里,细分领域也能支撑规模可观的公司。专业企业不必因为不提供所有服务就注定规模很小。
谈到 OpenAI 与 Baseten 的合作,Shtan 推测,提供开放模型可能让客户获得成本较低的选择,同时保留使用前沿模型的能力。他认为这一合作体现了灵活性,同时也指出把用户留在同一生态中的价值。
工程、规模与 agent 结果
Shtan 反思 AI 生成的代码、被低估的客户规模,以及 agent 达成结果的可靠性。
被问到过去一年改变了什么看法时,Shtan 提到 AI 编程。在他看来,模型及其周边工具进步明显,使编程助手从不可靠的新奇工具变成日常工作的一部分。
他个人也开始使用本地 agent 及其 harness 来分担部分认知工作。Effron 问,这些进步如何影响大型工程组织的管理。
Shtan 说,他对此持谨慎态度。好用的界面可能使低质量内容轻易扩散到对话和拉取请求中,因此他希望组织观察这些工具的实际使用方式。
他说,Nebius 不对个人或部门设定 token 限额,但会分析使用情况,寻找低效做法。公司的政策强调,工程师仍须对最终结果负责,包括拉取请求、代码及其运维后果。
完全由自主 agent 创建的工作会被标记出来。Shtan 说,在一段时间内这些 agent 不会接触核心服务;尽管他身处 AI 基础设施行业,对技术的了解反而让他对关键系统更加保守。
他认为自己最大的错误是低估了单个客户的规模。一个 30 兆瓦的数据中心过去已是大型设施;但他说,现在这样的容量可能还不够一个客户使用。
存储需求也发生了同样剧烈的变化。Shtan 回忆说,过去网络附加存储的吞吐以每秒数百 MB 或几个 GB 计,而现在客户能从共享系统中每秒读取数百 GB。
被问到哪些未解决的问题可能改变 Nebius 的战略时,他说自己假定模型会持续进步,同时也会关注真正的新架构。他尤其关注如何优化 agent 的最终结果,而不只是模型大小。
面对长时间运行、多轮交互的 agent,客户可能更关心能否达成期望结果,而不是单次请求。Shtan 说,公司内部一个小型研究组正在研究如何通过工具和 harness 提高成功概率。
其中一部分工作使人重新关注 CPU 消耗、质量关卡和形式化工具。Agent 可能花费数分钟执行代码和检查,而不再发出模型请求。Shtan 认为,模型之外的可靠性与优化将是更广泛采用的关键。
Effron 感谢 Shtan 参与对话。讨论最后回到一个实际挑战:如何将强大的模型和基础设施转化为用户可以信赖的结果。
同频道的其他文章
59:27EN → 简体中文
56:31EN → 简体中文
58:17EN → 简体中文
1:04:14EN → 简体中文
1:13:48EN → 简体中文
50:57EN → 简体中文