← 2026-11-03 期
Unsupervised Learning01:01:08 节目 · 24 分钟阅读

买到 GPU 只是起点:Nebius 如何把算力变成可交付的 AI 云

Ep 96: Nebius CTO on Racing the Hyperscalers Before AWS Wakes Up

Jacob Effron(主持);Danila Shtan(Nebius CTO)

节目日期(北京时间) 2026-11-02来源标注:完整音频转写
THE BRIEF

三句话速览

  1. 01

    Nebius CTO Danila Shtan 用从半小时租一张卡到数万卡互联集群的例子说明:AI 云的交付物不是库存,而是能把不同规模的硬件变成可操作、可维护服务的软件平台。

  2. 02

    在推理上,他主张先按客户实际流量优化服务、内核和模型,只给部分适合的生产负载做预填充与解码拆分;在建设上,他把多个供应瓶颈同时出现时的执行能力看得比单一资源更重要。

  3. 03

    他认为芯片稀缺与既有基础设施重构成本为独立 AI 云争取了时间,但并不预期超大云厂商缺席;更长远的考验,是能否在可控成本与责任边界内稳定交付完整的智能体结果。

核心判断

访谈最可检验的判断是:AI 云的竞争单位不是 GPU 小时本身,而是带条件的交付——能否按时间上架、以真实流量满足延迟和可靠性要求、在故障时可恢复、并在代理链条终点交出合格结果。它解释了为什么同一套标准化底座可以向上做差异化优化,也解释了为什么 GPU 紧缺带来的窗口与长期竞争力是两回事。Shtan 是供应商 CTO,他的市场判断与规模数字应视为访谈口径,不是第三方能力认证或经营预测。

THE ARGUMENTS

10 条核心观点

01

软件平台把整座集群和一张卡变成同一类云服务

英文观点句 · 基于完整节目忠实转述

Nebius bets that a single software platform can serve both an interconnected cluster of tens of thousands of GPUs and a self-service customer renting one GPU for half an hour.

中文直译

Nebius 的押注是,同一个软件平台既能服务由数万张 GPU 互联而成的集群,也能服务自助租用一张 GPU 半小时的客户。

难词注译
  • software platform:承载资源申请、分配和管理的软件平台,不只是设备出租页面
  • interconnected cluster:由高速网络联结、可供一个工作负载协作使用的大规模计算集群
  • self-service customer:无需逐单联系销售或运维、可自行申请资源的客户

原文语境

01:25–02:46,主转写 26–40:主持人以‘哪里有 GPU 就去哪’作为待反驳假设,Shtan 以大客户数万卡和小客户半小时租单卡来阐述统一平台的价值。06:16–10:15,86–155:按嘉宾回忆,公司在 2024 年完成与 Yandex 的分离;一批有跨设施硬件运营经验的人继续做建设,新软件平台要从头写,且扩招后软件团队不再只由原班人马组成。其所举 2024 年硬件团队约 40–50 人、软件团队约 200 人,是当时团队规模自述。

观点解读

‘软件优先’不是硬件可有可无,而是统一平台让硬件能力可重复消费。自助客户需要分钟级开通、清晰状态和简单退出,大客户需要容量成组、互联与故障管理;如果两者共享身份、调度和运维原语,新增硬件和开通新客户就不必各重做一遍。反过来,裸金属租赁可能适合已有编排能力的团队,不能以统一体验推断人人都应买托管。节目给的是设计理念和例子,不是任意规模、地区和型号都可按同一条件即时开通的承诺。

02

芯片上线是设计迭代、隔离和维护边界的重做

英文观点句 · 基于完整节目忠实转述

Bringing a new GPU generation online involves testing evolving hardware samples, adapting virtualization and networking, and sometimes redesigning maintenance around an entire rack.

中文直译

让新一代 GPU 上线涉及测试不断变化的硬件样品、调整虚拟化和网络,有时还要围绕整机柜重新设计维护方式。

难词注译
  • evolving hardware samples:从原型到实验室样品、设计仍可能变化的实物,不是已定型的交付批次
  • virtualization:把实际计算资源以虚拟化形式分给不同工作负载并维持隔离
  • entire rack:将整个机柜而非单台服务器当作部署或维护的基本边界

原文语境

10:15–14:55,主转写 156–236:NVIDIA 先展示原型与接口布局,后来的实验样品可能又变;接近量产后,Nebius 要测试并适配虚拟化、存储、网络和隔离。有些集群规模先撞到软件问题,需要反馈供应商、提补丁并验证修复。嘉宾以 Blackwell B300 向 GB300 架构变化为例,说明工作可能从迁走一台服务器的负载,变成设计机柜级维护。

观点解读

能点亮样品与能对外开售相隔许多步骤。上线清单应明确谁负责固件和驱动版本、流量隔离、故障演练,以及哪个层级的维护会同时影响几组作业。机柜级维护是故障域与运营边界变化,不是说任何机柜故障必然使整柜不可用。采购对比不妨把出货、集群验收、可迁移维护、实际承诺开始时间分列;发布会时间和到货数量都不能单独代表可用容量。

03

同一底座,按流量和客户责任验收不同服务

英文观点句 · 基于完整节目忠实转述

Nebius aims for a common infrastructure baseline, then tunes managed inference to each customer's traffic pattern and latency targets rather than building a different cluster for every workload.

中文直译

Nebius 力求采用共同的基础设施基线,再根据每个客户的流量模式和延迟目标调优托管推理,而不是为每一种工作负载建造不同的集群。

难词注译
  • common infrastructure baseline:多数负载可共享的硬件、网络、存储和底层服务能力基线
  • traffic pattern:请求到达方式、并发和输入输出长度等构成的实际流量形态
  • latency targets:例如首个 token 时间和完整响应时长等需要达标的延迟要求

原文语境

15:39–21:53,主转写 245–336:训练不仅要 GPU,还可能需要极高共享存储吞吐,嘉宾举约 700 GB/s、3 PB 共享文件存储、约千台服务器或八千 GPU 的组合。新实验室可能更在意 GPU、存储性能和可用,已有下游客户的企业则可能要求认证、安全核查和跨地区约束,即使采购额更小。主持人追问交互任务和后台代理是否要分别建集群;Shtan 回答通常共用够高的底座,在模型、编排和请求传递层调优,按流量验证首 token 或整个请求的 SLA。

观点解读

训练中的共享读取和推理中的响应等待不是同一个瓶颈,单张卡算力高也未必能救慢存储。线上交互要给出可接受等待的目标,后台任务则要看完成窗口和成本。评测还要注明约束:同一个引擎在长输入、短输出和短输入、长输出下会遇到不同问题,平均时延更无法说明峰值是否过关。嘉宾讲的是自家平台架构和客户例子,不保证每个客户都可复现数值,也不能把较小合同额等同于较低的工程交付要求。

04

预填充与解码拆分有生产用例,但不是默认配置

英文观点句 · 基于完整节目忠实转述

Nebius uses prefill and decode disaggregation in some demanding production setups, but it does not make it the default because operating it and meeting service-level agreements remain difficult.

中文直译

Nebius 在一些要求很高的生产配置中使用预填充与解码拆分,但不把它设为默认方案,因为运营这种配置和满足服务级协议仍然困难。

难词注译
  • prefill and decode disaggregation:把先处理输入上下文、后逐步生成输出的两个阶段分到不同资源池或节点
  • production setups:已经服务实际客户工作负载的特定部署,而不是实验原型
  • service-level agreements:服务应达到的延迟、可用性等事先约定目标

原文语境

21:53–24:58,主转写 337–375:嘉宾先批评讨论热度超过成熟度,再明确已有少数最苛刻客户的定制生产部署、另有原型,不能摘录前句当作‘没人上线’。当工作负载能放到带高速互联的同一机柜,拆分带来的互联难题可有所缓解;此时重点变成按请求模式配两类节点,以及如何把一个或多个工作负载放入有限资源。他还区分了例子中的云产品整柜分配与托管推理可能做的内部共置。

观点解读

拆分能让阶段各自调度,但同时引入阶段之间的状态传递、排队和故障恢复;在负载稀疏或波动时,两个池子可能同时出现某边空闲、另一边排队。能在高并发、快互联环境里找到收益,不等于拆分天然便宜。工程验收要与未拆分基线比较,并在真实长短输入组合下同时看首 token、完整请求时间、有效吞吐、故障恢复和运营人力。节目说过‘千级请求每秒’等量级,但没有给某个可复现的门槛或统一部署公式。

05

开放模型能运行,不等于按业务目标优化过

英文观点句 · 基于完整节目忠实转述

Shtan argues that open-model inference can be improved through request handling, kernel optimization, and selective compression of model weights for narrowly scoped tasks.

中文直译

Shtan 认为,可以通过改进请求处理、优化计算内核,以及为范围有限的任务选择性压缩模型权重,来改善开放模型的推理。

难词注译
  • request handling:服务接到流量后怎样排队、调度并将请求送到推理实例
  • kernel optimization:针对硬件和负载改进底层计算算子的执行方式,不是泛指操作系统优化
  • selective compression:按任务选择要压缩的权重或部分,并保留该任务所需的质量

原文语境

24:59–30:10,主转写 376–433:嘉宾说新模型只用推理服务初始支持的默认配置,速度和成本可能都不理想;他列出请求处理、推理服务器配置、内核以及权重剪枝或压缩,还谈到推测解码。按他对 Nebius 自家客户的说法,约 95% 不跑未经改动的原版开放模型;他列举修改、微调等做法,但没有拆分占比,也没披露分母和测量期。窄域任务能有意牺牲域外表现,开放研究和宽泛代码任务不一定适合。他另称有一项收购补充模型优化人才,并分设内核与压缩小组。

观点解读

可以把优化分成服务调度、算子实现与模型参数三层,先找证据再动一层。吞吐下降可能是队列与批处理、内核未适配或模型本身过大;压缩未必解决请求分配,也可能牺牲低频任务质量。量化或剪枝前先定义任务边界和失效回退,保留真实业务样本与域外反例。95% 是自家客户的访谈说法,不代表全市场、不说明多少客户做了全量微调,更不说明修改后的质量或成本一定优于闭源 API。

06

搜索和沙箱有平台协同,但尚不是一站式整合

英文观点句 · 基于完整节目忠实转述

Nebius sees Tavily's web search and its own sandboxes as building blocks for agents while exploring how to combine agent tools with managed inference.

中文直译

Nebius 把 Tavily 的网页搜索和自家的沙箱视为构建智能体的基础组件,同时探索如何将智能体工具与托管推理结合。

难词注译
  • web search:让智能体获取外部网页信息的搜索能力,并不等于已核验事实
  • sandboxes:隔离智能体执行代码或工具动作的运行环境
  • building blocks:可与推理或其他工具组合的独立基础组件,而非已经组合完毕的产品

原文语境

30:10–32:13,主转写 434–468:主持人以 Tavily 收购追问平台意图。Shtan 说看重产品及市场推进,认为自己的底层技术、基础设施和大规模索引经验可补上团队能力;但搜索还没有明确嵌入其余现有产品,托管推理与智能体工具的组合仍在探索。他还提到正在开发沙箱,主持方则指出长期运行的智能体会用搜索持续拉取信息。收购名称 Tavily 采用官方节目章节拼写,不沿用机器转写的 Tavoli。

观点解读

组合的价值在于同一代理能从拉资料、推理、执行走到结果,但每步都增加独立的成本、权限和失败条件。使用者应分别验收检索覆盖与来源、沙箱隔离和停止机制、推理失败回退,以及跨组件日志能否拼回一次任务。把几项产品收在同一家名下不是集成验收;反过来,即使统一入口最终出现,也仍可以保留自有工具与数据路径的替换能力。节目不支持把收购动机或未发功能写成交易效果或上线保证。

07

谁出资本可以不同,数据中心仍要按可运维标准搭建

英文观点句 · 基于完整节目忠实转述

Nebius says it can use different facility ownership and financing arrangements while keeping internal build-outs aligned with its own specifications so the software platform remains consistent.

中文直译

Nebius 表示,它可以采用不同的设施所有权和融资安排,同时让内部建设符合自家规格,以保持软件平台的一致性。

难词注译
  • facility ownership:设施是自有还是由其他方持有,不等于谁管理里面的技术栈
  • financing arrangements:由谁提供建站和设备资本的安排,包括访谈举的第三方出资
  • internal build-outs:把网络、服务器和其他内部设备装配成可运营设施的建设工作

原文语境

32:21–34:28,主转写 472–506:嘉宾区分自建、租用楼宇和电力、以及第三方出资建设和配 GPU 的轻资产安排。虽然资本路径不同,他强调内部仍按 Nebius 规格部署,使用团队熟悉的硬件并运行其软件栈;他不愿把别人配置好的硬件直接包装成自己的云,理由是未知硬件更难接管并兑现 SLA。37:03–39:17,549–575:长任务等负载变化,通常先通过编排、拆分和共置适配,专用新硬件可作为局部补充。

观点解读

‘轻资产’和‘技术控制’是两条轴。出资人改变不必自动改变运营标准,但一致的软件接口也不证明两个地点的电力、网络路径或恢复时间完全一致。要看设施里谁决定网络与固件、谁接收告警、坏件谁换、维护窗口谁承诺;一旦同一平台跨多个设施扩容,还要验证容量和故障转移,而不仅仅是同一个管理界面可见。这是嘉宾描述的运营原则,不代表对每个站点完成了独立审计。

08

短缺不止一项,项目执行决定何时能交付

英文观点句 · 基于完整节目忠实转述

Shtan sees execution across simultaneous shortages as the central build-out bottleneck, because teams must source components, resequence projects, and move equipment between facilities when priorities change.

中文直译

Shtan 将同时应对多种短缺的执行能力视为建设的核心瓶颈,因为优先级变化时,团队必须采购部件、重排项目顺序,并在设施间调配设备。

难词注译
  • simultaneous shortages:芯片、供电设备、部件和人员等多类短缺同时约束交付
  • build-out bottleneck:阻止规划产能按期建设并投入使用的制约因素
  • resequence projects:在物料和窗口变化时调整项目先后顺序,而不只是加派人手

原文语境

34:29–37:03,主转写 507–549:主持人请给电力、散热、网络、HBM 等排优先级,嘉宾不选单一物料,强调同时应对 GPU、CPU、NVMe、场地、电力、施工人手、收发器和变压器。变压器要等‘年’是他对所见供期的口头说法。嘉宾举设备先从一处调去保更重要工期、再调回来的例子,把稀缺能力落在能维护全局上下文的项目经理;末段他也承认低估的是单客户规模,30 MW 有时都不够,不是每家客户都需此功率。

观点解读

一个站点缺电,单买更多 GPU 不会让机架上线;另一个站点已经通电但缺网络,则可能适合先调设备或重排批次。应把关键依赖、替代方案、最晚到货时间与回迁风险放进同一张进度表,明确何时可以调整、何时不能牺牲安全或可靠性。访谈强调的是在瓶颈移动时仍能交付,并不否定某个项目的电力或硬件可以成为硬约束,也不提供市场通用采购周期。

09

超大云厂商没有缺席,稀缺和改造成本只创造了时间窗口

英文观点句 · 基于完整节目忠实转述

Shtan argues that chip scarcity and the cost of redesigning existing infrastructure gave independent AI clouds an opening, even though hyperscalers already compete for major deals and may invest more as the market grows.

中文直译

Shtan 认为,芯片稀缺与重构既有基础设施的成本给独立 AI 云创造了机会,尽管超大规模云厂商已经在争夺大单,并可能随市场增长加大投入。

难词注译
  • chip scarcity:芯片供给不足以同时满足内部用量和面向市场的租赁需求
  • redesigning existing infrastructure:重做面向既有负载建立的网络、吞吐和存储等底层能力
  • hyperscalers:拥有大规模基础设施和销售能力的超大云厂商,文中举 AWS、Google 等

原文语境

03:36–06:15、39:17–45:42,主转写 53–85、576–674:Shtan 说大型厂商在重大交易上已经有竞争力,公开标价不等于合同报价;稀缺下还要在内部训练、产品与外部租赁间分配,既有网络和存储的大改需要业务规模证明。他举‘如果芯片可多十倍’的反事实,并预期未来大厂更重视该市场;他以 Hetzner、DigitalOcean、Linode 类比规模不同的长期共存,也承认当前进入者不一定都存活。

观点解读

短期机会来自容量配置和决策速度,不是永久的成本护城河。供给缓和后,独立云要靠同类流量下更可预测的服务、区域容量、可迁移性或具体应用的工具与运维能力来留客。嘉宾提到的新云数量、AWS 收入量级和未来需求倍数是个人估计或假设,没有可比时间窗口和核算口径,不应变成市场规模或交易建议。‘大厂没赢’也不等于没竞争,标题的 AWS ‘醒来’应作为节目问题理解。

10

代理时代要按结果衡量,模型外的工程同样决定交付

英文观点句 · 基于完整节目忠实转述

For long-running agents, Shtan is interested in improving outcome reliability through tools, harnesses, and quality gates rather than relying only on a bigger or different model.

中文直译

对于长时间运行的智能体,Shtan 感兴趣的是通过工具、执行框架和质量关卡提高结果的可靠性,而不是只依赖更大或不同的模型。

难词注译
  • outcome reliability:多步骤代理反复达到可接受业务结果的能力,不只是单次回复正确
  • harnesses:控制模型、工具和任务状态如何协作的执行框架
  • quality gates:通过测试、校验或人工核准才能进入下一步的质量检查关卡

原文语境

52:07–55:48、57:33–01:00:28,主转写 780–841、874–931:嘉宾说公司不按个人或部门设 token 配额,但观察用途和低效用法;人仍对代码、PR 和值班负责,全自主产物标注、暂不碰核心服务。末段他更关心多轮长任务能否到达结果,提到内部小组研究工具和执行框架怎样提高成功机会,并以代理数分钟只跑代码、没有调用 LLM 为例说明 CPU 与质量关卡的重要性。

观点解读

以结果为单位会改变成本和容量规划:同样多的 token,工具出错重试、重复等待或没有产出都可能令交付失败;更少的 token 也可能靠严谨校验和正确工具交付。应同时看任务完成率、每个合格结果的总时间和总成本、重试与人工接手率。内部不设个人配额是嘉宾自述的管理选择,并不等于无限预算、无需审核或建议照搬。按结果计费在这里是他观察的讨论方向,节目没有交代可验证的合同模式。

A CLOSER LOOK

深度分析

一、把容量分成能点亮、能运行、能交付三种状态

一批设备离开工厂,不等于云上有同等的可售容量。第一步只是硬件能运行;第二步要配好网络、存储、虚拟化与监控,验证大规模联动;第三步才是服务达到客户承诺,包括需求突增时调度、计划维护、故障转移、权限隔离和合格的下线路径。芯片代际变化可能在三个层次同时发生:型号换了,机柜互联和维护边界也变了,云产品还要把这些差异转成用户可以正确申请的资源。节目里先看图、再看样品、最后提补丁的顺序提醒我们,交付不是一个上架按钮。

这也解释了为何嘉宾强调统一平台,又不说原来的软件直接搬过去。老团队带来跨设施运营经验,能提前想起维修、追踪、供货和规模问题;新平台必须为新的资源粒度和客户条件重新设计。在应对来自前沿芯片的新问题时,‘供应商有修复’与‘本方确认修复并可服务’同样不同。对项目管理而言,把芯片已到、集群经测试、服务可承诺分别列为验收门,比只追踪采购到账日期更接近真实的客户体验。

统一不意味着所有入口照着一种客户设计。大型客户会关心集群同时就绪并满足拓扑要求,小客户只想拿到一张卡、用完即停;尽可能共享开通和运维原语,才能让大集群也支持许多不同规模的请求。一个反向测试是:同一套身份、权限与观测能不能在资源规模变化后延续;如果从一张卡升级到一组节点就需重建账号、监控和故障流程,产品一致性的收益就没有兑现。

二、把性能预算写到从请求到完成的每一段

访谈把训练侧的共享存储和推理侧的延迟区分开了。若一组训练任务在等共享文件系统,增加 GPU 可能让等待增加;若面向用户的请求首 token 延迟太高,增加批量有时反而使等待更明显。工程上应先拆总时间:请求在入口等多久、引擎处理输入多久、首 token 后输出多久,客户端是否会重试,队列能否承受峰值。只有在实际输入、输出和并发分布下,才知道钱花在硬件、网络还是服务调度更有效。

拆分预填充与解码,就是把优化目标不完全一样的两个阶段分开配置,但它多了一处跨阶段协调和状态搬运。机柜内互联快时,这些成本可能下降,才能把注意力放在两边节点数量和多工作负载的放置问题;在其他环境,同样的方案可能把问题从一台实例转移到网络和运营。嘉宾提到最难服务的客户已有人工深度参与的部署,同时说尚不普遍。工程团队可以保留一个未拆分的稳定版本作为对照,在流量峰值、连接异常与节点损失时检查新路径,而不是拿满载时一个平均值替代生产 SLA。

模型优化也应这样拆解。请求处理和服务端调度针对的是排队与处理策略,算子优化针对的是机器执行具体计算,剪枝和压缩则改变模型本身。它们可以叠加,也可能令问题更难归因。先验证请求模式和默认基线,再做单因素试验,最后检查叠加;业务质量和回退条件与成本一起看。对相对标准的专业任务,有时不需要通用能力都保留;但一旦域外请求变多,应能回退,而不是把窄域优化当作任何模型都应做的统一改造。

三、供应链关键路径与资本结构是两件事

如果只问限制行业的是电力还是芯片,就默认了每家设施处在同一阶段。实际一个站点等变压器、另一个站点等交换机或施工队伍,第三个站点已经通电却受熟悉硬件和验收能力限制。把资源从甲站调到乙站有时能保住更关键项目,却会增加二次运输、安装和原计划延期。访谈说能组织这些动作的人难得,重点不是把某种短缺讲轻,而是让每项短缺都进入能重新计算的交付路径。

设施可自有、可租楼宇与电力,也可让第三方投入资本,但在访谈的运营逻辑里,谁融资和谁控制标准不能混在一起。拥有资产不自动带来熟悉的网络、可用的固件和可靠的故障响应;只租场地也不表示不能运行自家的完整技术栈。最实用的交付检验是把站点清单与控制责任一项项对应:哪方提供电、哪方能重启或换件、谁能打补丁、谁对维护窗口负责。否则‘轻资产’很容易被错误理解成随时可以借任何现成机房。

嘉宾说曾低估单客户需要的资源,30 MW 有时不够的例子与共享文件系统上数百 GB/s 的口述都指向同一点:平均客户的规格不能代替最耗资源的业务部署,也不能用最耗资源的那个客户设定所有人必须购买的门槛。设计通用基线时,可单独定义保底能力、峰值可买能力与定制代价;建设运营用真实大客户峰值作压力场景,小客户体验另行验收。

四、把短缺窗口和长期差异化分开看

Shtan 对大厂迟来的解释有两条:当分配到的 GPU 不够多,训练与面向用户的模型业务先占一部分,租给外部的容量就有限;即使需求显著,要在已有网络与存储上做系统级改造也需经过投资决策。这解释了一种阶段性空隙,并不是证明大厂没有服务能力。大厂已有竞标能力和客户渠道,公开价格又和大单报价不同。若未来供应变化,规模、渠道和产品捆绑可能反过来强化它们。

独立服务能否留在市场,取决于是否有一些服务需求不是大厂的一般配置就能填满。嘉宾以托管、数据库和对象存储历史类比:大厂可以覆盖多数类目,独立厂商仍可能在特定开发体验、部署条件或专业功能上提供更好选择。类比不是定律;应看标准产品覆盖、迁移成本、服务差异能否被客户确认,并分清客户留下究竟是因为暂时拿不到其他容量,还是因为可验证的交付表现。

同样,OpenAI 与 Baseten 的谈话只能告诉我们嘉宾怎样看待平台动机:开放模型给成本敏感用户一个选项,平台还可保留回到前沿模型的入口。但把多模型选项留在同一生态不意味着迁移无摩擦,工具、权限、日志和计费仍可能改变。对买方更值得问的是同一任务能否导出输入、运行证据和结果,以及在模型、云和工具之间切换时会牺牲什么。

五、以结果计量的智能体,要求模型外工程和责任都能看见

Tavily 和沙箱的讨论与尾段的结果优化其实连在一起。一个长代理可能查网页、跑代码、校验数据、等待任务,然后才调用下一次模型;GPU 推理并不是所有时间和成本。搜索能找到资料但不能自动证明引用正确,沙箱能隔离执行但仍要对许可动作和资源限额作定义,最终输出还要通过测试或人工关卡。把这些组件放在一起的价值,是提高多步骤工作成功率,而不是给模型调用的 token 数再加一个表。

按合格结果而不是请求量看系统,至少要定义三个东西:什么才算完成、什么失败可以重试、什么环节必须由人确认。例子可以是生成一份可复现的集群故障报告:它不仅要写出文本,还要抓到合法范围内的日志、把测试结果附上、核对时间线,并在无证据时停止。未完成任务同样消耗 CPU、网络和模型费用。把全部投入按完成结果分摊,就能看见一个单价较低却经常重试的方案未必更省,且从访谈不能推出实际结果计费条款。

嘉宾自己的工程团队政策与这种度量相互呼应:给人使用模型的空间,同时留下人对代码、合并和故障负责的边界。标注自主生成不是质量保证,拒绝让完全自主代理碰核心服务,也不等于永远拒绝自动化。一个渐进方案是先让代理产生可复核草案,遇到异常停止和交接,只有在长期同类结果稳定且有明确回滚方式后才提高授权。这样评价的是可靠性与责任,而不是谁用掉更多或更少 token。

LISTEN AGAIN

值得回听的时间点

00:00

冷开场和主持导入

芯片产量反事实与大厂重构成本是先导,不是新闻公告。

01:25

AI 云差异化、统一平台与独立容量

用一张卡到数万卡的例子说明,不把商业壁垒等同于能拿卡。

06:16

Nebius 起源、硬件经验与软件重写

延续人员经验和沿用旧平台不是同一回事。

10:15

NVIDIA 样品迭代和新芯片上线

隔离、网络、存储以及维护粒度需一起验收。

14:55

客户需求、订阅插播与共享存储

约 15:18–15:35 的节目订阅宣传不是嘉宾内容;访谈随后回到不同客户。

19:58

延迟与成本、统一硬件与软件调优

区分首 token、整个请求和客户具体流量。

21:53

预填充和解码拆分

区分原型、少量定制生产与默认托管服务。

24:59

开放模型推理的调优空间

讨论服务配置、算子和权重三个不同层级。

28:31

推理优化产品化与团队布局

收购优化人才与专门小组均是嘉宾自述。

30:11

Tavily、搜索索引与智能体工具

业务互补不等于产品已完全集成。

32:21

自有、租赁和轻资产数据中心

资本安排变化与内部建设标准分开。

34:29

多类资源短缺与项目执行

关键路径会在芯片、供电、场地和人力之间变化。

37:03

长代理、新负载和集群通用性

先看编排、共置和局部新硬件,不默认每类负载重建底座。

39:17

大厂为何没更早拿下市场

既有竞争、内部用量和改造成本要一起解释。

43:39

独立 AI 云长期格局

用传统托管商类比长尾,但不预测特定公司生存。

45:42

一站式捆绑与独立工具供应商

云产品线扩张与独立供应商生存可能并存。

49:43

OpenAI 与 Baseten 的讨论

把开放模型的成本选择和平台留存动机当嘉宾解读,不当合作条款。

52:07

快问快答:编程代理、团队政策、单客户规模

不设个人 token 上限与人对合并请求负责并存;低估的是单客户。

57:33

关注结果优化与节目告别

从模型大小回到长代理结果、CPU 和质量关卡;约 01:00:36 起为主持方片尾。

人物、工具与数字

Danila Shtan/Jacob Effron:以官方节目介绍校正自动转写中变形的人名;主持人的投资者身份与嘉宾的厂商身份均应保留。Nebius/Yandex:嘉宾谈公司分离、平台重写和硬件运维传承;此处不据访谈为公司历史或资产权属作法律认证。NVIDIA Blackwell、B300、GB300:用于说明样品迭代及机柜维护差异的节目例子,不作为型号采购或规格表。约 700 GB/s、3 PB、约 1,000 台服务器或 8,000 张 GPU:嘉宾用于说明共享存储需求的组合举例,不是每个设施或客户的性能保证。约 95%:嘉宾指 Nebius 自家客户不跑原版开放模型的口述比重;没有独立样本、区间或修改类型占比。Tavily/Baseten:官方节目章节采用的拼法;两者分别出现在 Nebius 收购与主持人问 OpenAI 合作的讨论,不混同为同一交易。AWS/Google Cloud/Azure,Hetzner/DigitalOcean/Linode,以及 Snowflake/MongoDB/ClickHouse:分别是竞争背景、云长尾和独立服务的类比,不是经横向验证的排名。
PERSPECTIVES

立场与分歧

共同立场

  • 主持人和嘉宾都承认,客户流量与延迟要求不一,且 AI 基础设施需适应不同模型与长期运行的代理;他们讨论的是这些变化要落在底座还是软件层。
  • 双方都讨论平台扩大功能的趋势,并认可工具调用与其他计算会影响长代理交付;没有据此达成所有产品将归并为单一供应商的结论。

主要分歧

  • 主持人以拿到卡即有竞争力作反例,并问为何大厂早期没有更强势;Shtan 强调统一软件和内部外部分配,同时指出大厂已经拿到大单并能给竞争性报价。
  • 主持人问哪些推理优化应该由 Nebius 产品化,哪些只需借力开源;嘉宾倾向在多层都投入,认为组合优化能改善效果,但没有宣称每项技术都应在所有客户中开启。
  • 主持人请对电力、器件等瓶颈排序,嘉宾认为同时处理多项短缺的执行能力更能解释结果;这是运营视角,不是对电力等物理约束的否定。
  • 主持人问 OpenAI 与 Baseten 是否为进入更通用多模型平台;嘉宾解读为让用户在生态内有开放模型的成本选项并可切回前沿模型,未确认合作商业条款。
INTO PRACTICE

工作启发与行动

  • 采购 GPU 云应一起考察可交付日期、共享存储、租户隔离、维护故障域与合同服务目标;标称卡数不能替代工作负载验收。
  • 推理优化先量化真实流量和服务目标,再从编排、引擎、内核或权重中选择最合适的改动;重架构不是必答题。
  • 建设侧要区分资本来源、物理责任与平台标准;每个节点都能显示在同一控制台,不等于各站点具有同样的恢复能力。
  • 代理基础设施不只消耗 GPU。工具运行、检索、验证与沙箱会占用 CPU、网络和人力,按合格结果计量才能看到真正成本。

可以从这里开始

  1. 拟一页工作负载基线:分开训练与交互、批量推理,写明真实输入输出长度、峰谷并发、首 token 和全请求延迟目标,再用相同样本跑候选服务。
  2. 建立 GPU 上线清单:原型、样品、量产交付、虚拟化隔离、网络和存储、维护演练分别签验;拉通整机柜维护和退出预案后再承诺容量。
  3. 为开放模型保留未经调优的对照组,每次只变更服务参数、算子或权重中的一层。除成本与速度外,加测失败回退、域外输入和结果正确率。
  4. 只在现有推理基线已清楚、互联与负载足以测出差异时,挑一条流量试行预填充/解码拆分;用整条响应链、故障切换和运营工时决定是否推广。
  5. 让设备、电力、设施和施工依赖进入同一个交付计划,给每个替代路径写审批人和最晚决策点;不要用赶工换取未经验证的安全或可用性。
  6. 定义长代理的一次合格交付,将推理、检索、沙箱、校验、人工接手分别计时计费;高风险写入设质量关卡,研发端保持具名责任与可回滚。
EVIDENCE & LIMITS

事实、观点与不确定项

本期基于完整节目内容整理。节目中的二手引用、嘉宾自述和编辑推断分别标注,不将其等同于独立事实调查。

已核对的来源与节目内容

  • 官方 RSS 的节目 GUID 为 4248d1df-1156-4e68-b67a-5f3cfd063aea;官方发布时间为北京时间 2026-11-02 21:54:35,处于 11 月 3 日刊监测窗口。
  • 完整官方音轨覆盖约 61 分 08 秒;主文来自完整音频转写,官方说明用于人名、题名和章节,不当作逐字稿。节目中间有订阅插播,结尾有主持方介绍与订阅提示。
  • 节目中嘉宾报告有少量定制拆分生产部署、正探索托管推理与代理工具结合,以及公司不设个人或部门 token 上限但观察用途;这些是明确可定位的嘉宾陈述,不是对现有系统的外部验收。

观点与判断

  • Shtan 认为开放模型直接采用初版推理配置通常不够优化,窄域任务可从权重和内核定向优化受益;不等于每个开放模型都比闭源服务差。
  • 他预期大厂会投入更多,独立供应商仍可找到长尾位置;对需求增长与新云存活数量的说法均是他的判断和类比。
  • 他个人更关注结果可靠性和模型外工具,不再把模型越来越大或聪明当成最有信息量的变化;这不是关于研究界没有新架构的独立调查。

仍需留意

  • 访谈未披露 95% 的计量时段、客户分母及改动分布,也未公布共享存储案例的可复现测试环境;不能推导市场渗透率或服务保证。
  • 自动转写中的某些模型名称、代际代号和说话人变体不够可靠;优先使用官方元数据可核对的人名与章节名称,不用相似发音补写未核实的型号或公司交易。
  • 节目未提供并购条款、OpenAI 合作产品覆盖、设施合同、收益口径或市场份额证据;相关内容保留为节目中的讨论、自述或判断,不构成投资或合规意见。
  • 没有单一阈值可决定何时适合拆分预填充与解码;实际流量、互联、部署形态与 SLA 的联合条件仍需同场对照。
LANGUAGE & CONCEPTS

金句与关键词

BACK TO THE SOURCE

回到原始内容

本期根据完整节目整理,英文观点句为非逐字忠实转述,中文按对应句子直译。来源方法与未确认事项见上文。了解编辑说明

处理方式:本篇使用 Redpoint 发布的 Simplecast 官方 RSS 完整音频。官方节目页可访问但本次未获得可用的完整文字,RSS章节仅作元数据和导航校对,不是逐字稿;未用第三方摘要替代。完整媒体58,692,055字节、物理时长3668.167596秒,逐段核验206字节范围、ETag、文件总长度,独立复取首中尾样本后一致。本地 large-v3 完整处理七个物理区间,生成948条带时码发言,明确告别语至3667.1秒;另用 medium 模型独立解码24段实际物理音频,含开头、实际中点、近尾以及成本/延迟、拆分、模型优化、搜索、数据中心及云市场各章。两个模型是机器核对,不是人工听音;近尾抽检印证结论与告别,不声称独立识别物理终点每字。用官方元数据校正 Danila Shtan、Jacob Effron 与 Nebius,不擅自修复两路都含混的模型版本、带宽和公司专名。95%是嘉宾对自家客户的描述,不等于行业份额,也不把所有非原版模型都说成全量微调;拆分仅用于部分严苛负载的生产案例,芯片十倍供给是反事实假设而非出货统计。收购、公司客户与成本和市场预测保留节目归属,不作投资建议。十句英文忠实非逐字重述、逐句直译,附同句语境词汇,不用未核实的逐字金句。

官方 RSS 与单集发布时间 ↗

报告生成时间:2026/11/3 13:57:49(北京时间)

收录于 2026-11-03