当 Anthropic 与 Nscale 之间一项规模高达 45B 美元的算力合作被外界讨论时我第一反应不是“又一个天价新闻”而是 AI 公司的竞争终于从模型效果卷到了基础资源供给。过去两年大模型公司比拼的是算法创新和模型评测分数从 2025 年开始真正决定一家公司能不能持续迭代的可能是它到底锁住了多少长期、稳定、成本可控的算力。Nscale 这类基础设施服务商也因此从幕后走到台前。对很多工程师和团队来说这种巨额合同看起来很遥远但它背后关于算力采购、成本估算、容量规划和交付运维的底层逻辑恰恰是每个打算认真使用 AI 的团队都要补的课。1. 这笔算力交易锁的到底是什么1.1 从“租服务器”到“锁定产能”过去我们理解云计算是“按需租用”今天需要 16 张卡开 16 张明天不用了释放掉。这种模式对中小团队非常友好因为弹性大、首期成本低。但当模型规模大到一定程度你面对的问题就不再是“想租的时候有没有”而是“我需要的时候市场上根本没有足够产能”。这其实是头部 AI 公司最恐惧的供给瓶颈。训练一个前沿大模型动辄需要数万张高端 GPU 连续运行数周。如果中途因为资源被其他客户抢占而中断损失的不只是几十万美元的电费还有几周的训练进度和团队排期。所以与其每次重新去市场上抢资源不如签署长期协议把未来几年的产能直接锁定下来。所谓 45B 美元锁定算力本质上是把一个不确定的、高波动的资源市场转化成一段可预测的供应链关系。它锁的不是某几台服务器而是一整套持续交付算力的能力。1.2 算力不只是一个“显卡数量”问题很多人对算力合同的理解停留在“多少钱买多少块 GPU”。但实际上GPU 只是算力链条中最容易被看到的一环。一块 GPU 要真正产生模型训练价值需要配套的电力、制冷、机柜、高速网络、存储、监控、调度系统和运维人员。数据中心的电力容量决定了你能同时点亮多少卡网络拓扑决定了多机分布式训练时的通信效率存储系统决定了数据能不能及时喂给模型运维质量决定了故障发生时能不能快速恢复。Nscale 这类服务商真正提供的其实是整套“算力产能”而不是一个裸的硬件列表。这一点对普通团队同样有参考意义当你评估一个云服务商时不能只看“单卡多少钱每小时”还要看机房间带宽、存储吞吐、故障响应速度、配额管理能力。很多性能问题看似模型写的不好实际是底层存储和网络拖了后腿。1.3 对 AI 公司来说这是资产负债表级别的选择巨额算力合同不只是一个采购决定它会直接影响 AI 公司的现金消耗、资本结构和估值逻辑。长期锁定算力意味着未来的训练和推理成本变得可预测但也意味着公司需要当下承担巨额承诺或者至少提前占用大量现金流。所以这类交易里面通常会包含非常细的商业条款交付时间、可用性 SLA、扩产预留、退款机制、价格调整上限。可以说算力采购已经从“IT 预算”变成了“公司战略”。如果你所在团队正在选择 GPU 资源哪怕体量没那么大也应该用这种思路来审视合同而不是简单比较单价。2. 为什么头部 AI 公司宁可先付钱也要把算力锁下来2.1 模型训练的“不可中断性”让资源可得性变得极其重要大模型训练的一个核心特征是任务周期长、状态重。训练到一半如果被中断即使有 checkpoint恢复后也可能要重新消耗一定算力才能回到之前的收敛状态。越是超大规模训练越不能接受频繁的“资源被回收”或“节点被抢占”。因此对头部 AI 公司而言算力资源的关键属性不是便宜而是“稳定可得”。他们宁可用长期合同锁定价格和数量也要避免在最关键的训练窗口期无卡可用。这笔 45B 美元级别的合作本质上是在为训练计划购买保险保险的标的是交付时间。2.2 Token 消耗正在让推理成本变成另一座大山不少人只关注训练需要多少算力却忽略了推理阶段的 token 消耗。一旦模型上线并开始高频调用每次对话、每次代码生成、每次文档分析都在消耗 GPU 资源。很多 AI 产品用户量增长很快但推理算力跟不上于是出现排队、超时、连接失败等问题。我们看到一些用户遇到 “unable to connect to anthropic services” 或 “failed to connect to api.anthropic.c” 之类的错误背后可能就是服务端容量不足、限流或者网络不稳定。头部公司锁定大额算力正是为了给推理侧留出弹性避免产品放量时被基础设施卡住。如果你自己的产品依赖第三方大模型 API并且控制不了上游算力那么一定要做几件事设计好超时重试、监控错误率、准备降级方案、必要时接入备用模型或私有化部署。否则算力一紧张最先暴露的一定是你的用户体验。2.3 算力即壁垒先锁产能的人先拿到迭代速度模型效果迭代需要不断重训、微调、评测。谁能先用更多算力完成实验谁就能更早发现有效的模型结构或数据配方。因此算力从来不只是成本也是研发速度的一部分。当头部公司通过长期合同锁定大量产能时后进团队再想去市场上抢临时算力不仅价格更贵还会面临更长的排队时间。这也是为什么“算力军备竞赛”并不完全是一句夸张描述它是模型迭代速度、产品上线时间、用户体验稳定性综合竞争的一部分。3. 从算力合同看基础设施选型的几个关键维度3.1 不要只看总算力要看有效算力很多团队选型时喜欢问“你有多少张 H 系列卡”这个指标有意义但不够。更重要的指标是有效算力也就是你实际能用来跑通任务的那部分资源。有效算力要考虑四个方面GPU 可用率实际可调度时间里有多少比例能被你的任务占用。网络带宽多卡分布式训练时通信占比越高模型跑得越慢。存储 IO数据读取和 checkpoint 写入会不会成为瓶颈。运维中断机房维护、实例迁移、故障重启会造成多少时间损失。所以在和算力平台谈合作时建议要求对方提供基准测试环境最好用自己的模型跑一轮真实的短任务看吞吐和数据。不要轻信纸面算力。3.2 电力、制冷和网络才是最容易踩坑的地方GPU 集群和普通 CPU 集群不同单机柜功耗往往远高于传统机柜。如果服务商的数据中心没有足够的电力余量或制冷能力就算采购合同里写了很多卡实际交付时也可能会缩水。对中小团队来说在云平台上租用实例时也要注意“资源拓扑”问题。比如某些厂商宣传“八卡实例”但如果同一台物理机上的八卡之间没有 NVLink 全互联使用体验可能远不如跨机分布式训练来得稳。网络拥塞、存储区域带宽不足都会造成实际利用率远低于显卡利用率监控数据。3.3 短期弹性与长期承诺如何平衡不是每个团队都要签五年长约。大公司锁定算力是一种战略选择但普通团队更适合“按需配额 少量预留”的组合。下表是不同团队的算力策略参考团队类型主要场景推荐策略注意点个人开发者模型微调、跑实验按需使用不预付优先选择按小时计费避免闲置中小创业团队产品原型、推理服务少量预留 弹性扩容设置配额告警控制成本中大型企业私有化部署、生产级服务长期合同 按量混合明确 SLA、交付时间、故障赔偿头部 AI 公司前沿模型训练、大规模推理锁定多年产能管理好现金和利用率避免空转4. 普通团队能从这笔交易中学到什么4.1 先定义任务类型再估算算力当我看到很多人讨论“算力多少钱”时第一反应都是“你的任务是什么”。训练和推理是完全不同的算力模型训练任务是持续的、高强度的目标是在尽可能短的时间内处理更多数据。推理任务是离散的、有峰谷的更看重吞吐、时延和弹性。如果你的任务主要是每天处理几千条文档那用 API 可能比自建 GPU 集群更划算。如果你想做私有化部署那就要先估一个峰值请求量再倒推需要的并发实例数。4.2 用“单卡基准测试”推算整体需求这里有一个很实用的方法先不要急着采购一堆卡而是选择一张样本卡跑一个和真实负载接近的小任务记录下来几个数据处理一个 batch 耗时多少。每秒钟能处理多少个 token或者多少条数据。显存峰值是多少。CPU、内存、磁盘 IO 有没有成为瓶颈。然后根据任务总量换算成需要的 GPU 时数。比如一项批处理任务需要 100 万条数据单卡每秒处理 10 条那就要 10 万秒约 27.8 小时。如果你希望 5 小时内跑完就需要约 6 张卡并行。这种估算方法不完美但比凭感觉采购靠谱得多。4.3 算力成本不是“显卡价格 × 数量”这么简单实际使用算力时总成本至少包括实例时长费存储费用网络流量费用停机调试时间监控与运维人力模型不收敛导致的重跑成本所以我一直建议团队做“算力预算”时预留至少 30% 到 50% 的冗余。不是因为服务商故意多收费而是因为真实使用过程中调参、试错、数据清洗、任务重试都会消耗额外资源。4.4 排查“模型服务连不上”的基础顺序当出现连接不上模型服务、API 请求超时这类问题时不建议一上来就找模型本身的原因。建议按下面的顺序排查先看客户端请求网络是否能连通目标域名API Key 是否正确。再看服务端状态上游服务是否有故障限流或扩容中。检查负载均衡和网关日志请求是否被丢弃超时阈值是否设置过短。检查算力侧GPU 实例是否健康、是否有任务占满资源。最后看模型服务上下文过长、请求格式异常、token 数量超限都会导致报错。这个链路看起来很简单但很多人会直接从第 1 步跳到第 5 步忽略了算力容量这个中间变量。5. 锁定算力不是终点真正的挑战在交付之后5.1 买了算力不代表算力会“自动变成效果”有些团队拿到很多 GPU 之后发现模型训练速度并没有想象中那么快。原因通常不是显存不够而是模型并行策略、数据加载、框架配置没有跟上。比如数据加载如果不做预取GPU 会频繁等待 CPU 返回数据利用率可能只有 30% 到 50%。再比如多机通信没有做优化每轮迭代都在等网络同步。这里需要做的事情是 profiling把每个 step 的时间拆开看数据加载、前向、反向、梯度同步各占比多少找到瓶颈。5.2 长期运营需要监控、调度和弹性伸缩算力交付不是简单的“开机就能跑”。你还要考虑实例故障时怎么自动重启任务训练中断后如何从 checkpoint 恢复推理流量上升时如何自动扩容深夜低峰时如何缩容省成本多项目之间如何排队调度这些工程能力和模型算法本身无关但往往决定了一个团队能不能把算力用好。很多头部公司愿意签长期算力合同不只是因为需要卡而是他们有成熟的调度和观测系统可以在大量资源上保持较高利用率。没有这套能力再多 GPU 也会被浪费。5.3 真正稀缺的资源是规划与工程能力回到开头那个判断Anthropic 与 Nscale 这样的合作表面上是钱和算力的交易实际上是两家公司把“未来若干年的 AI 产能”作为战略契约来管理。对一个普通开发者或技术负责人来说最值得借鉴的是一种态度把算力当成需要长期规划的工程资源而不是临时去云平台点几台机器。你可以从小处开始先训练一个完整的算力评估流程任务类型、数据量、单卡基准、并行策略、成本核算、监控指标。这个流程越早建立团队对 AI 项目的时间、成本、效果预期就越准确。等到未来真的需要大规模扩展资源时你至少不会因为“看不懂算力合同”而踩坑。这些工程细节听起来不如一个“45B 美元”的新闻震撼但正是它们决定了一笔巨额算力投资最后变成优秀的模型、稳定的产品和可观的收益还是变成一堆闲置 GPU 和电费账单。