Anthropic 用 45B 美元锁定 Nscale 算力。这条消息刚出来时不少人把它当成普通的云服务采购其实它是 AI 算力供应链里一次典型的长期锁单头部模型公司把巨额预算提前押给算力服务商换取未来一段时间内稳定的 GPU 供应和可预期的成本。对做模型训练、推理部署、AI 基础设施选型和云成本控制的人来说这件事值得拆开看。它真正指向的不是某一笔订单而是大模型竞争已经从模型参数卷到了算力采购、资源调度和供应商管理。开头先给结论这笔交易最值得关注的不是“Anthropic 很有钱”或“Nscale 拿到了大单”而是头部 AI 公司开始把算力当成一种需要提前规划、长期锁定的战略资源。如果你所在团队也在做大模型训练或推理业务那么这类签约背后的逻辑和你日常做资源规划、采购 GPU 实例、控制训练成本时遇到的问题是同一个。1. 45B 美元锁算力锁的到底是什么1.1 为什么 AI 公司愿意提前把钱押给算力供应商最直接的原因是算力供给的节奏和需求不匹配。大模型训练的特点是前期不确定要跑多少轮中期一旦开始就不能频繁中断后期又有大量在线推理请求。而算力资源的特点是从下单到真正可用往往隔着数据中心建设、GPU 交付、电力扩容、网络调试好几个环节。等业务真的需要算力时再临时去买大概率要排队。所以头部 AI 公司会选择提前锁定。锁定的不是几张显卡而是一段时间内的可用容量和价格。45B 美元这个量级放在 AI 算力市场里属于顶级订单。至于这些钱到底覆盖多少年、包含多少卡、是否包含扩容选项最终要看合同细节。但从动作本身看它至少说明几个信号Anthropic 对后续训练和推理任务有较长周期的稳定预期Anthropic 不希望把核心训练任务押在随时波动的按需市场上算力服务商作为独立供应商已经进入了 AI 公司核心供应链。这类提前锁定对成本测算也有帮助。GPU 价格不是一成不变的市场供需、新一代硬件发布、电力价格都会影响最终报价。如果按需购买遇到行情波动预算很难控制。提前锁定价格等于把算力成本从浮动变成相对固定。对于要连续训练多个版本的模型团队来说成本可预期本身就是一种竞争力。1.2 算力、Token、数据、模型、场景五个词要串起来理解很多人在讨论大模型时候会听到“算力、Token、数据、模型、场景”但不知道它们怎么串。我一般把它们理解成一条链路算力是底层资源可以看成水电。模型是消耗算力的设备训练和推理都会消耗 GPU。Token 是计费单位也是实际消耗量输入一段文本、生成一段内容都按 Token 数计算。数据决定模型要学什么影响训练次数和微调频率。场景决定你需要的算力类型训练任务偏重长时间、高吞吐和大显存在线推理任务偏重低延迟、高并发和稳定的服务链路。只看算力数字没有意义。同样的 GPU 数量训练一个大模型和跑几百个在线推理实例资源配置完全不同。同样买一百张卡有人拿来做密集训练有人拿来做批量推理有人拿来做多模态视频理解最后对网络、存储、显存的要求都不一样。所以签算力合同之前先想清楚自己要解决的是训练、推理、微调还是混合负载。2. 评估算力供应商不能只看 GPU 型号2.1 纸面参数和真实可用性之间隔着四件事一张卡能不能真正发挥性能不只是看型号。我评估一个算力供应商时会先看四个容易被忽略的点交付周期、供电能力、散热条件和机房位置。交付周期很好理解合同签了什么时候能拿到卡有些供应商给出的时间很乐观但实际 GPU 到货和上架时间会受到供应链影响。如果业务正在等算力训练模型晚一个月交付就意味着模型迭代慢一个月。供电能力更隐蔽。很多机房从外部看容量很大但现代 GPU 卡的功耗很高机柜功率密度直接决定能塞进去多少计算设备。如果供电不足就算有卡也只能降频跑性能打折。散热同理高密度机柜如果散热设计跟不上长期跑训练任务会出现温度墙性能不稳定。机房位置影响的是延迟和数据合规。如果团队主要客户在国内模型部署在海外机房业务接口延迟就会明显增加。如果客户有数据出境要求机房位置更是不能拍的脑袋。具体选哪里需要结合业务场景和数据要求来判断。2.2 网络、存储、调度平台才是隐性门槛GPU 型号只是第一步。真正影响大模型训练效率的是卡和卡之间的互联、存储读写速度以及调度系统的稳定性。大模型训练通常需要多卡并行。卡与卡之间如果走的是普通以太网通信延迟会非常明显训练效率上不去。好的算力服务商会提供高速互联网络版本、带宽和拓扑直接决定多卡扩展性。存储也很关键。模型的权重、训练数据、日志都会频繁读写如果存储性能不够GPU 会经常处于等待数据的状态看起来利用率不高实际是存储拖了后腿。调度平台是另一个容易低估的部分。训练任务、推理服务、调试任务混在一起时需要用调度系统排队和分配资源。常见的方案包括 Slurm、Kubernetes 等。供应商是否支持你熟悉的调度方式是否提供完善的监控日志和权限管理会直接影响团队日常使用效率。我遇到过的情况是算力纸面配置不错但提交任务后只能通过基础 SSH 操作没有队列管理、没有资源监控所有人都挤在一起乱跑最后谁也说不清自己用了多少资源。2.3 算力供应商评估维度参考表评估维度具体要看什么判断方法交付周期合同签署到可用算力的天数拿样例任务跑通为准不要看口头承诺硬件配置GPU 型号、显存、内存、CPU、本地磁盘用 nvidia-smi 等工具验证真实配置网络拓扑卡间互联、对外带宽、延迟跑多卡通信测试观察吞吐和波动供电和散热可用机柜功率密度、PUE、温度曲线长时间测试任务观察是否存在降频调度平台是否支持队列、弹性扩缩容、持久化存储提交多个任务验证排队和隔离监控和日志资源使用率、告警、任务日志可读性确认监控面板能按项目、用户拆分API 兼容性是否提供标准 API是否支持常用工具链跑一段推理脚本验证兼容性成本模型计费单位、包时段价格、流量费、存储费按实际任务估算平均单卡成本3. 算力合同里的关键条款怎么判断3.1 价格锁定、计费单位和成本口径算力合同最需要抠清楚的一点是价格到底包含什么。有些合同看着单价很低签完才发现网络流量、存储容量、技术支持都要额外收费。GPU 按卡收费、按实例收费、按节点收费最终折算出每小时成本完全不同。签之前最好把一条真实任务跑下来算一遍最终账单包括训练时长、数据读取、日志存储和偶尔调试的碎片时间。还要注意价格锁定不等于所有成本都锁定。能源价格、新一代硬件上线后的定价策略、超量使用后的计费方式都可能影响最终支出。如果合同中只有基础单价没有超量部分的封顶或折扣条款高峰期费用会很难控制。3.2 预留容量、扩容条件和取消机制第二个关键点是容量保证。合同里说“有多少张卡”和“你随时能拿到这些卡”是两回事。要看条款里是否包含预留容量承诺。AI 业务经常有突发需求比如临时发起一次大规模微调、或者新版本模型上线前要做多轮评测这些都需要短期拿到更多算力。如果合同没有扩容通道业务就容易卡在资源上。取消和降配机制同样重要。大模型技术迭代快可能出现的情况是上一个方案还需要大量训练下一个方案通过数据筛选和模型压缩把算力需求降下来了。这时候如果合同锁死了长期订单又不能转租或降配就会造成资源浪费。我建议在签合同前确认三点能否提前终止终止需要提前多久能否降配或转成按需资源如果供应商未能提供承诺容量有什么补偿机制。3.3 数据位置、合规边界和供应链稳定性数据位置不是小事。训练数据、用户请求、模型权重都可能属于敏感资产。合同里要明确数据存放在哪些节点运维人员有哪些访问权限是否支持私有网络和加密存储。如果业务涉及多个地区还要确认数据是否可以在不同区域之间迁移。供应链稳定性也值得关注。算力服务商的芯片来源是否稳定、后续扩容是否受上游交付影响都会影响你的长期使用。供应商自己的运维能力同样关键。故障响应时间、SLA 赔付标准、维护窗口通知方式这些都是实操中会踩到的细节。我不是说大合同就一定要把所有条款都写到极致而是说越大的合同越要把不确定的事情提前划清楚。4. 算力上线后的验收与实测流程4.1 先跑三类测试连通性、基准、业务算力交付不是跑一条nvidia-smi就算验收。我更建议把验收拆成三层第一层连通性测试。确认 SSH 能登录GPU 能被系统识别内存、磁盘、网络接口都正常。这一步通常很快但要记录下驱动版本、CUDA 版本和基础环境。第二层基准测试。跑一些通用的计算任务比如矩阵运算、单卡推理、多卡通信测试。这一步能反映出卡和网络是否达到标称性能。第三层业务测试。拿一个真实业务场景的样例跑一遍比如对一个小的数据集做微调或者用真实输入测推理延迟。只有业务样例跑通才算真正可用。不要跳过第二层直接跑业务。如果卡本身有问题或者网络配置不对业务测试会花很长时间而且报错往往不直接指向硬件问题。先跑基准能快速暴露基础设施的明显异常。4.2 验收时重点盯的指标验收不是只看“能跑”还要看“跑得稳不稳”。重点指标包括单卡算力利用率和显存占用多卡训练时的通信吞吐任务队列的排队时间长任务运行过程中有没有温度墙或者网络抖动以及最终输出结果是否可重复。我在实测时一般会先跑一个短任务观察资源使用曲线。如果 GPU 利用率经常掉到很低的水平先别急着调业务代码优先检查网络存储和调度配置。很多情况下问题不是卡不行而是数据读取太慢GPU 一直在空等。对于推理服务还要额外关注批处理能力和单次请求延迟的波动。如果一个接口在低并发时延迟很低但并发一高就出现大量超时可能是资源配额不够也可能是供应商的实例规格和网络带宽有瓶颈。4.3 资源利用率和任务队列要提前设计算力到位后最容易被忽视的是任务队列和资源分配规则。团队里如果有多条业务线每个人都会觉得自己需要最多的资源。如果没有队列优先级、没有资源配额、没有成本归属就会出现有人长时间占着 GPU 跑低优先级任务真正重要的训练却排队等不到资源。我建议从第一天就定好两件事一是按项目和任务拆分资源标签二是给不同项目设定优先级。队列管理用 Slurm 或 Kubernetes 都可以关键是要有统一入口。另外空闲资源检测也很重要。很多团队算力成本高不是因为任务真的那么重而是大量 GPU 处于闲置状态没人回收。定期扫描空闲节点把不用的资源释放掉能省下不少预算。5. 锁定大额算力不等于一劳永逸5.1 硬件代际更新和合同期限的错配风险算力合同锁定的是“当前一代的硬件资源”但技术迭代速度很快。新一代 GPU 发布后旧卡在算力、显存、能效上都会落后。如果合同周期很长可能出现一种尴尬钱已经花出去了绑定的还是前几年的硬件新模型在旧卡上跑不动需要额外再买新算力。这并不意味着长期锁单完全不可取。关键是要在合同里留好灵活性。比如在特定时间点允许对部分资源做技术升级或者在合同中保留一定比例按需资源。头部公司可以靠巨额订单拿到定制方案普通团队要学的是同一个思路不要把全部预算都锁死在同一家、同一个硬件代际上。5.2 厂商故障、容量不足和迁移成本算力供应商也会出问题。机房故障、网络波动、容量超卖都可能导致训练中断或推理服务不可用。如果所有算力都押在一家供应商身上那这家供应商的稳定性就直接决定了你的业务连续性。容量不足是另一个常见风险。合同里写了可用容量但到了高峰期供应商可能因为其他客户也在用资源而无法把你的任务排到前面。这时候你的选择要么是等待要么是去别的供应商临时采买。迁移成本也要提前评估训练脚本、数据存储、容器镜像、监控体系如果和供应商深度绑定迁移到新环境的成本会很高。所以早期就算只用一家供应商也应该保证容器镜像、模型权重和数据都是可迁移的。5.3 多供应商策略和统一调度大型 AI 公司往往会有多个算力供应商目的不是为了比价而是为了分散风险。不同供应商的硬件配置、计费方式、区域覆盖不同可以按任务类型分派。比如把核心训练任务放在主供应商把推理和批量任务放到另一个平台同时保留一部分按需资源应对突发流量。多供应商的关键是统一调度和统一观测。如果你的团队需要同时对接多个 GPU 云平台建议用统一的资源抽象层管理集群比如 Kubernetes 多集群或算力调度平台。否则每个平台一套账号、一套监控、一套计费逻辑管理成本会很高。统一调度之后任务可以根据资源价格、队列长度、硬件要求自动路由到合适的集群上。6. 给普通技术团队的落地建议6.1 从按需实例开始小规模验证后再决定是否长期锁定不是每个团队都需要一次锁定 45B 美元级别的算力。大多数团队的资源策略应该更渐进先按需购买少量实例跑通业务记录真实的资源消耗和成本确定稳定需求后再考虑包月、预留实例或长期订单。如果一开始就签大合同很容易出现两种情况一是业务没有想象中消耗那么多算力造成浪费二是业务对硬件版本有特殊要求签完发现现有方案不匹配。按需起步的成本可能单看单价更贵但它给了你验证和调整的空间。这种灵活价值在早期比单价折扣更重要。6.2 把算力成本做成台账按项目拆开看算力成本不能只看总账单。同一个团队不同项目的资源消耗差异可能非常大。建议按项目、按任务、按调用方拆分明细记录 GPU 使用时长、Token 消耗量、占用的存储空间和网络流量。有了台账之后才能回答几个关键问题哪个项目最烧钱哪个任务单位成本最高哪些资源可以降配或回收后续预算应该往哪里倾斜。成本台账不需要做得很复杂可以先用表格记录再逐步接入监控系统。关键是口径统一比如所有任务都按 GPU 小时、Token 数量、存储 GB 月三个维度统计。这样无论是内部复盘还是供应商对账都能快速对齐。6.3 用模型优化和批处理把单位成本降下来算力预算再充足也经不起无谓消耗。最直接的降本方式是让单位任务消耗更少的算力。模型侧可以做的包括量化、蒸馏、减少上下文长度、使用更小的模型做前置路由。推理侧可以做的包括批量请求、结果缓存、动态调整并发数、把过多空闲实例缩容。批处理特别值得重视。很多推理请求有峰谷波动如果峰值时开大量实例闲时又空转成本会很高。更合理的做法是把非实时任务放进队列在资源闲时统一处理让 GPU 的使用曲线更平滑。结果缓存同样有效完全相同或高度相似的请求命中缓存后就不需要再消耗一次模型推理。回到最开始的话题。Anthropic 锁定 Nscale 算力是头部公司在算力供应链上的一次长期布局。它不一定适合所有团队照抄但背后的思路是通用的先想清楚需求周期再评估供应商真实能力最后用合同、验收、监控和优化把资源管好。很多算力项目最后出问题不是卡不够而是从采购到使用的整条链路没有理顺。