2025 年 AI 行业最值得关注的变化可能不是某个新模型的发布而是 Anthropic 与 Nscale 签下的这笔 45 亿美元算力订单。很多人第一反应是“又是一笔大额融资”但仔细看会发现这笔交易的核心不是股权不是并购而是算力锁定——一家顶尖 AI 实验室愿意一次性拿出几十亿美元换取未来数年的稳定计算资源。这件事值得所有做 AI 应用、做大模型训练、甚至只是用 API 调模型的开发者认真看一遍。因为它揭示了一个正在发生的产业变化AI 竞赛已经从“拼模型”转向“拼算力供应链”。谁能在全球范围内找到足够的 GPU 集群、数据中心和能源配套谁才有资格参加下一轮比赛。这篇文章不打算复述新闻而是想从技术角度拆清楚几个问题这笔交易背后发生了什么算力为什么值得一家公司花 45 亿美元提前锁定如果你是开发者这件事对你的成本、选型和架构有什么影响以及最重要的——在大厂疯狂囤算力的时代普通团队应该如何规划自己的算力策略。全文会包含算力基础概念的通俗解释、行业供需结构的分析、适用的工具和命令示例以及一套可以落地的算力评估和优化思路。建议先收藏再慢慢看。1. 这笔交易为什么值得关注先给一个明确判断Anthropic 花 45 亿美元锁定 Nscale 算力本质上是把“算力”从采购项变成了战略资产。过去几年AI 公司的典型资源结构是“模型团队 数据 GPU”。模型团队负责算法创新数据负责训练素材GPU 负责把想法变成现实。这个结构看似自洽但有一个致命问题GPU 的供应周期远远跟不上模型的发布节奏。如果你负责过 GPU 采购就会知道一台高性能服务器的交货周期可能长达几个月更不用说大规模集群的机房改造、网络组网、制冷和电力配套。而 Anthropic 的产品节奏是半年左右更新一代模型训练集群的需求在模型规模扩大时呈现指数级增长。这种供需错配意味着等到模型团队说“需要更多算力”再开始采购已经来不及了。所以头部 AI 公司开始改变策略提前锁量、长期签约、绑定基础设施供应商。这和航空公司锁定油价、制造企业锁定钢材是一个逻辑——把未来的不确定通过合约变成确定。这笔 45 亿美元的订单也释放了三个信号Anthropic 对未来的模型训练有明确且庞大的算力规划不是小规模扩容。算力供应链正在被头部玩家瓜分中小团队可获取的高端 GPU 资源会进一步紧张。AI 基础设施正在成为比模型本身更稀缺的资源资本正在大量涌入这一层。对于普通开发者你可能觉得自己和大规模算力交易没有直接关系。但事实是算力成本最终会体现在 API 价格、模型开源策略和云服务商的定价上。理解这笔交易就是理解未来几年 AI 应用的成本结构。2. 算力是什么从名词到工程概念很多人在各种文章里看到“算力”这个词但真正能说清楚它指什么的人不多。我们先把概念拆开。2.1 算力的工程定义算力在 AI 语境下通常指的是单位时间内能完成的浮点运算次数常见单位是 FLOPSFloating Point Operations Per Second。用在数据中心场景常用 PFLOPS每秒千万亿次衡量。用在单张 GPU 或专用 AI 芯片场景常用 TFLOPS每秒万亿次衡量。用在端侧设备或边缘场景常用 TOPS每秒万亿次整数运算衡量。注意FLOPS 和 TOPS 不是一回事。FLOPS 针对浮点运算TOPS 通常针对整数运算。很多 NPU、端侧芯片标称的 TOPS 很高但不能直接和 GPU 的 TFLOPS 对比因为精度的定义和运算类型不一样。2.2 精度与算力的关系AI 训练中数据的数值精度直接影响结果质量和计算速度。目前业界常用的精度包括精度类型术语特点常见用途FP32单精度数值范围大精度高但速度慢显存占用大传统训练基线、精度要求高的场景FP16 / BF16半精度 / BF16速度较快显存占用减半BF16 动态范围更稳大规模分布式训练主力精度FP88 位浮点速度最快显存占用最低但对量化算法和误差控制要求高新一代 GPU 的推理和部分训练场景FP8 是当下算力讨论中最常被提到的词也和热搜词里的“pro6000 算力 fp8”直接相关。FP8 的核心价值在于它能让同一块 GPU 在单位时间内完成更多运算同时减少显存和带宽压力。但代价是精度下降需要在算法层面做补偿比如混合精度训练、损失缩放、经验性的量化校准等。2.3 算力不等于单卡性能一个容易被忽视的事实是单卡的算力再高如果集群组网能力跟不上实际可用算力会大打折扣。大模型训练是分布式任务模型会被切分到几十上百张 GPU 上通过高速网络频繁同步梯度。如果网络带宽不足、延迟过高GPU 就会持续等待数据利用率大幅下降。这也是为什么“算力中心”不只等于“显卡堆在一起”还包括高速互联、并行文件系统、对象存储和任务调度系统。热搜词里的“dsh 算力组网”本质就是解决大规模 GPU 集群的网络互联问题。所以评估一个算力平台的能力不能只看 GPU 型号还要看节点之间的互联带宽比如 InfiniBand 还是 RoCE。存储系统的吞吐和延迟。调度系统能否支撑多租户、多任务并发。能源和散热能否支撑长期满载运行。3. 为什么大模型公司要“锁定”算力回到 Anthropic 这笔交易本身。45 亿美元不是小数目Anthropic 为什么不用这笔钱自己建数据中心或者直接向芯片厂商下单3.1 供给周期错配训练新一代大模型需要的不是几十张 GPU而是几万张。这个规模的集群建设至少需要三个周期并行推进硬件交付周期GPU 服务器从下单到交付需要数月。机房建设周期电力扩容、制冷改造、机柜部署以季度为单位计算。集群调试周期几万张卡的集群跑通中间必然经历网络调优、故障更换、存储压测。如果完全依赖自建Anthropic 的业务速度会被基础设施拖垮。而和 Nscale 这类专业基础设施提供商签约相当于把这三项周期的风险转移给更擅长的一方。3.2 需求预测比采购更重要大模型公司的算力需求不是线性的。训练一个新模型时需求会在某个时间点突然暴增模型发布后推理需求又会持续爬坡。如果按峰值需求自建集群大部分时间资源都会闲置如果按平均需求采购高峰期又会排队。长期锁定模式的核心价值是把“突发需求”转变成“计划性需求”。双方都能基于合约做容量规划基础设施商可以提前备货模型公司可以稳定推进训练计划。3.3 算力已经成为模型能力的直接约束OpenAI 的 GPT-4 等了很久才推出多模态能力Anthropic 的 Claude 系列每一代模型的上下文长度都在增加。表面看是算法进步底层看是算力在支撑。更准确地说模型的参数量、训练数据量、上下文长度、推理质量每一项的进步都对应着算力投入的增加。在没有算法革命的前提下算力就是模型能力的上限。谁锁定的算力多谁就有更多的试错空间和进化速度。4. Nscale 是谁它的稀缺价值在哪从公开材料看Nscale 是一家专注大规模 AI 基础设施的提供商业务覆盖 GPU 集群、数据中心资源和高性能网络服务。它的定位和传统公有云厂商并不完全相同——更侧重提供“可专用、可定制、可规模化”的算力资源。之所以 Anthropic 会选择合作而不是直接扩容现有云资源可能有几个原因4.1 供应能力与地域分布通用云厂商的 GPU 资源需要兼顾所有租户头部客户的超大规模需求很难随时满足。而 Nscale 这类专业算力提供商可以把全部资源按少数几个大客户的规格定制选址也可以更接近能源便宜、气候适合散热的地区对用能效率和资源利用率更友好。4.2 架构适配度大模型训练对集群的互联拓扑、存储读写模式、容错切换机制都有特殊要求。专业算力供应商可以围绕训练框架做定向优化而不是让客户去适配通用云的虚拟化层。对于动辄上亿美元训练成本的模型来说哪怕算力利用率提升 5%都是巨大的成本节省。4.3 可用性与弹性长期合约还意味着弹性保障。Anthropic 可以在训练高峰期使用扩展部分资源在训练间歇期收缩。这种“规模可调整但容量有保底”的模式比自建数据中心更灵活比按调用付费的公有云更可控。从产业链位置来看Nscale 踩中的正是当前 AI 行业最稀缺的环节——具备大规模交付能力的算力产能。芯片再好如果变不成可用的集群就无法创造价值。专业算力提供商的价值就在于把芯片变成训推可用的计算服务。5. 这笔交易改变了什么市场结构层面的影响5.1 对云厂商和算力供应商以前云厂商的基本盘是多租户、按量计费。现在头部 AI 公司开始签长期大单这会导致算力供应商的业务模式分层面向头部客户超大单、定制化、长期合约。面向中小客户标准化、弹性、按量计费。这意味着中小开发者在公共云上的算力供给可能不会因为大客户的大量采购而被“挤爆”但高端资源的价格可能会被推高因为供应商会把头部订单的利润压力分摊到标准化产品上。5.2 对芯片厂商芯片厂商的竞争逻辑也在变化。过去拼单卡峰值算力现在拼的是集群吞吐、网络兼容性、能效比和供应链稳定性。FP8 这类新精度方案的普及也需要芯片厂商和算力提供商深度联调否则很难发挥真实性能。5.3 对开源社区和中小团队大模型公司锁定大量算力后可能带来两个影响开源模型的训练成本被头部公司承担的越来越多对中小团队是好事。中小团队想自己从头训练大模型的难度进一步提高因为资源竞争加剧。这正是为什么我们在后面要专门讨论“算力规划”和“推理优化”。对绝大多数团队来说在算力受限的前提下把效果做出来比盲目堆规模更现实。6. 开发者如何核算自己的算力需求你不需要参与 45 亿美元级别的交易但也应该对自己的算力需求有一个理性评估否则很容易在云账单和自建成本之间反复踩坑。6.1 训练场景的算力估算大模型训练成本的核心公式是训练所需算力 ≈ 模型参数量 × 训练 token 数 × 计算系数通常取 6这个“6”来自 Transformer 架构的前向传播和反向传播次数。6 倍系数估算出来的总 FLOPS再除以单卡有效算力考虑 MFU 模型利用率通常取 30% 到 50%就可以大致估算训练所需的 GPU 卡数和时长。下面的 Python 脚本可以帮你快速估算# 文件路径estimate_training_flops.py def estimate_training_gpus( params_billion: float, tokens_billion: float, gpu_tflops: float, mfu: float 0.4, hours_per_day: float 24, ): 估算训练一个大模型所需的 GPU 卡数和天数。 参数: params_billion: 模型参数量单位十亿 tokens_billion: 训练数据量单位十亿 token gpu_tflops: 单卡算力单位TFLOPSFP16/BF16 mfu: 模型利用率一般取 0.3-0.5 hours_per_day: 每天运行小时数 返回: (卡数, 天数) # 计算总计算量6 * 参数量 * token 数 total_flops 6 * (params_billion * 1e9) * (tokens_billion * 1e9) # 单卡每天实际可用算力 daily_flops_per_gpu gpu_tflops * 1e12 * mfu * 3600 * hours_per_day # 假如目标 30 天完成训练反推需要的卡数 target_days 30 gpus_needed total_flops / (daily_flops_per_gpu * target_days) return gpus_needed, target_days if __name__ __main__: # 示例70B 模型训练 200B token单卡 1000 TFLOPSMFU 0.4 gpus, days estimate_training_gpus( params_billion70, tokens_billion200, gpu_tflops1000, mfu0.4, ) print(f训练 70B 模型30 天内完成约需要 {gpus:.0f} 张 GPU)运行python estimate_training_flops.py输出示例训练 70B 模型30 天内完成约需要 716 张 GPU注意这是简化估算没有考虑优化器状态、激活值显存、通信开销和故障恢复。实际工程中显存可能先于算力成为瓶颈。6.2 推理场景的成本核算推理场景的成本不像训练那么线性。影响要素包括输入和输出的 token 数量。并发请求数。模型参数量和量化精度。推理框架的批处理效率。比较实用的做法是先压测再算账单。用vLLM这类推理框架部署模型后可以用下面的命令做简单压测# 使用 vLLM 自带的 benchmark 工具 python -m vllm.entrypoints.benchmark.benchmark_latency \ --model /path/to/model \ --tensor-parallel-size 4 \ --dtype float16 \ --input-len 512 \ --output-len 256 \ --num-prompts 50这个命令会输出 P50、P90、P99 延迟和吞吐数据。得到这些数据后你可以结合 API 单价算出单次请求的算力成本。6.3 什么情况下自建什么情况下用云一个相对稳妥的判断标准训练需求长期稳定、规模大可以考虑自建或长期合约锁定。训练需求波动大、周期短优先用云的弹性资源。推理量持续增长但峰值不确定优先用 Serverless 或按量付费配合弹性伸缩。数据敏感、合规要求高私有化部署或专属集群更合适。7. 算力受限环境下的实用优化建议对于大多数开发者和中小团队短期内很难买到无限算力。更现实的路径是在有限的算力预算内把模型的训练、微调、推理效率做到极致。7.1 训练侧混合精度与序列长度控制能用 BF16 就不用 FP32。能用梯度检查点gradient checkpointing就用减少显存峰值。大序列训练时要考虑 attention 计算的二次方复杂度尽量先用短序列训练再在后期用长序列继续训练。开启 flash attention可以大幅降低显存占用并提升速度。7.2 推理侧量化与批处理推理侧最直接的优化是模型量化。从 FP16/BF16 降到 FP8理论上能减少一半显存占用同一块卡上的吞吐也能明显提升。但量化各有风险FP8 尤其需要注意激活值的溢出问题。更稳妥的方式是先用工具评估量化误差再决定上线。例如对量化后的模型做一些输出对比观察是否有关键任务掉点。7.3 架构侧缓存与混合部署如果你的应用是高频调用同一个模型可以考虑把通用推理放在高吞吐的离线批处理中。用语义缓存减少重复计算。把轻量任务分给更小、更快的模型只有复杂任务才调用大模型。# 一个简单的语义缓存思路 import hashlib import json import redis r redis.Redis(hostlocalhost, port6379, decode_responsesTrue) def get_cache_key(prompt: str, model: str, temperature: float): raw f{model}|{temperature}|{prompt} return hashlib.sha256(raw.encode(utf-8)).hexdigest() def cached_generate(prompt: str, llm_func, model: str claude-3-5-sonnet, temperature: float 0.7, ttl3600): key get_cache_key(prompt, model, temperature) cached r.get(key) if cached: return json.loads(cached) result llm_func(prompt, temperaturetemperature) r.setex(key, ttl, json.dumps(result)) return result这个示例虽然简单但它体现了算力优化的核心思路减少无效计算把有限的算力花在最重要的事情上。8. 算力采购与使用的常见问题问题现象可能原因排查方式解决方案训练时 GPU 利用率低数据加载慢、网络通信瓶颈查看nvidia-smi利用率波动检查 CPU 和网络带宽使用高性能并行文件系统、DataLoader 多进程、提前做数据预处理训练时显存不足模型规模超过单卡显存查看nvidia-smi显存使用情况使用梯度检查点、ZeRO 或张量并行降低批次大小多卡训练速度不随卡数线性提升并行策略不合适或网络互联带宽不足对比 1 卡和 4 卡的训练吞吐调整并行策略检查 InfiniBand 或 RoCE 配置减少跨节点通信推理延迟高但 GPU 没跑满推理框架批处理调度不足压测并观察单请求延迟和 GPU 利用率使用 vLLM、TGI 等框架开启 continuous batching启动任务时报连接超时算力平台的网络策略或服务连接受限确认 API 地址、端口和网络策略检查实例安全组、代理配置和可访问性设置量化后效果明显下降量化校准数据处理不当对比量化前后在典型任务上的输出用训练集或代表性数据做校准尝试 FP8 与混合量化方案这里尤其想提醒一点算力平台的选择不只是选 GPU 型号还要看平台自身的网络、存储和调度能力。一个组网不合理的集群即使用最新显卡训练效率也可能被拖得很低。9. 在没有“钞能力”的情况下如何保持竞争力如果你不是 Anthropic没有 45 亿美元可以锁定算力那么你的竞争力来自哪里9.1 选择适合自己的模型接入方式中小团队应该优先使用成熟的大模型 API而不是自己从头训练模型。API 调用的成本看起来在增长但相比自建集群的沉没成本仍然是小得多。9.2 深耕垂直场景积累数据资产算力是通用资源数据是差异化资产。与其把预算全部投入算力不如思考你手头有什么独有的数据能不能转成可持续优化的提示词模板、微调数据集或评测集这些才是别人抢不走的优势。9.3 建立评测体系避免盲目换模型很多团队在做模型选型时只看基准分。更稳妥的做法是建立自己的评测集覆盖应用的真实场景。每次切换模型、调整参数、做量化前后都跑同一套评测集看关键指标的变化。下面是构建评测集的一个最小示例# 文件路径eval_pipeline.py EVAL_CASES [ {prompt: 请将下面的句子翻译成英文今天天气很好。, expect_keywords: [today, weather]}, {prompt: 总结这段客服对话中用户的核心诉求。, expect_keywords: [退款, 发票]}, ] def run_eval(model_func): pass_count 0 for case in EVAL_CASES: output model_func(case[prompt]) hit all(kw in output for kw in case[expect_keywords]) if hit: pass_count 1 print(fPrompt: {case[prompt]}) print(fOutput: {output}) print(fPass: {hit}) print(- * 50) print(f评测通过率: {pass_count}/{len(EVAL_CASES)})这套方法不高级但非常适合在团队内部统一模型选型标准。9.4 监控成本建立预算告警在云环境里算力成本容易失控。建议从第一天就建立标签体系按项目、环境、负责人拆分成本并设置预算告警。这比事后看账单冷静得多。10. 总结与后续学习方向Anthropic 与 Nscale 的这次合作是 AI 行业进入“算力供应链时代”的又一个标志性事件。它说明在模型能力提升的曲线上基础设施的约束越来越重要。无论是大公司还是小团队都不能再把算力看作一个可随时购买的通用品而应该把它纳入技术规划和成本模型。对普通开发者来说最值得做的三件事是建立算力成本意识。无论是 API 调用还是自建集群都要能算出每一块钱花在了哪里。掌握推理和训练的基础优化方法。量化、批处理、缓存、混合精度这些技巧在算力紧张时能救你一命。时刻关注算力行业的动态。基础设施供应商的格局变化会直接影响你未来能买到什么样的服务以及花多少钱。如果你对这个话题感兴趣下一步可以重点研究这些方向GPU 集群的组网架构、FP8 量化在推理中的实际效果、分布式训练框架如 DeepSpeed、Megatron-LM、Ray的适用场景以及不同精度策略对成本和延迟的影响。这些内容会随着算力行业的发展变得越来越重要。建议收藏本文后续在实际项目中遇到算力规划问题时可以回来对照检查。 算力供应链时代：FP8、GPU集群与大模型训练的架构优化
2025 年 AI 行业最值得关注的变化可能不是某个新模型的发布而是 Anthropic 与 Nscale 签下的这笔 45 亿美元算力订单。很多人第一反应是“又是一笔大额融资”但仔细看会发现这笔交易的核心不是股权不是并购而是算力锁定——一家顶尖 AI 实验室愿意一次性拿出几十亿美元换取未来数年的稳定计算资源。这件事值得所有做 AI 应用、做大模型训练、甚至只是用 API 调模型的开发者认真看一遍。因为它揭示了一个正在发生的产业变化AI 竞赛已经从“拼模型”转向“拼算力供应链”。谁能在全球范围内找到足够的 GPU 集群、数据中心和能源配套谁才有资格参加下一轮比赛。这篇文章不打算复述新闻而是想从技术角度拆清楚几个问题这笔交易背后发生了什么算力为什么值得一家公司花 45 亿美元提前锁定如果你是开发者这件事对你的成本、选型和架构有什么影响以及最重要的——在大厂疯狂囤算力的时代普通团队应该如何规划自己的算力策略。全文会包含算力基础概念的通俗解释、行业供需结构的分析、适用的工具和命令示例以及一套可以落地的算力评估和优化思路。建议先收藏再慢慢看。1. 这笔交易为什么值得关注先给一个明确判断Anthropic 花 45 亿美元锁定 Nscale 算力本质上是把“算力”从采购项变成了战略资产。过去几年AI 公司的典型资源结构是“模型团队 数据 GPU”。模型团队负责算法创新数据负责训练素材GPU 负责把想法变成现实。这个结构看似自洽但有一个致命问题GPU 的供应周期远远跟不上模型的发布节奏。如果你负责过 GPU 采购就会知道一台高性能服务器的交货周期可能长达几个月更不用说大规模集群的机房改造、网络组网、制冷和电力配套。而 Anthropic 的产品节奏是半年左右更新一代模型训练集群的需求在模型规模扩大时呈现指数级增长。这种供需错配意味着等到模型团队说“需要更多算力”再开始采购已经来不及了。所以头部 AI 公司开始改变策略提前锁量、长期签约、绑定基础设施供应商。这和航空公司锁定油价、制造企业锁定钢材是一个逻辑——把未来的不确定通过合约变成确定。这笔 45 亿美元的订单也释放了三个信号Anthropic 对未来的模型训练有明确且庞大的算力规划不是小规模扩容。算力供应链正在被头部玩家瓜分中小团队可获取的高端 GPU 资源会进一步紧张。AI 基础设施正在成为比模型本身更稀缺的资源资本正在大量涌入这一层。对于普通开发者你可能觉得自己和大规模算力交易没有直接关系。但事实是算力成本最终会体现在 API 价格、模型开源策略和云服务商的定价上。理解这笔交易就是理解未来几年 AI 应用的成本结构。2. 算力是什么从名词到工程概念很多人在各种文章里看到“算力”这个词但真正能说清楚它指什么的人不多。我们先把概念拆开。2.1 算力的工程定义算力在 AI 语境下通常指的是单位时间内能完成的浮点运算次数常见单位是 FLOPSFloating Point Operations Per Second。用在数据中心场景常用 PFLOPS每秒千万亿次衡量。用在单张 GPU 或专用 AI 芯片场景常用 TFLOPS每秒万亿次衡量。用在端侧设备或边缘场景常用 TOPS每秒万亿次整数运算衡量。注意FLOPS 和 TOPS 不是一回事。FLOPS 针对浮点运算TOPS 通常针对整数运算。很多 NPU、端侧芯片标称的 TOPS 很高但不能直接和 GPU 的 TFLOPS 对比因为精度的定义和运算类型不一样。2.2 精度与算力的关系AI 训练中数据的数值精度直接影响结果质量和计算速度。目前业界常用的精度包括精度类型术语特点常见用途FP32单精度数值范围大精度高但速度慢显存占用大传统训练基线、精度要求高的场景FP16 / BF16半精度 / BF16速度较快显存占用减半BF16 动态范围更稳大规模分布式训练主力精度FP88 位浮点速度最快显存占用最低但对量化算法和误差控制要求高新一代 GPU 的推理和部分训练场景FP8 是当下算力讨论中最常被提到的词也和热搜词里的“pro6000 算力 fp8”直接相关。FP8 的核心价值在于它能让同一块 GPU 在单位时间内完成更多运算同时减少显存和带宽压力。但代价是精度下降需要在算法层面做补偿比如混合精度训练、损失缩放、经验性的量化校准等。2.3 算力不等于单卡性能一个容易被忽视的事实是单卡的算力再高如果集群组网能力跟不上实际可用算力会大打折扣。大模型训练是分布式任务模型会被切分到几十上百张 GPU 上通过高速网络频繁同步梯度。如果网络带宽不足、延迟过高GPU 就会持续等待数据利用率大幅下降。这也是为什么“算力中心”不只等于“显卡堆在一起”还包括高速互联、并行文件系统、对象存储和任务调度系统。热搜词里的“dsh 算力组网”本质就是解决大规模 GPU 集群的网络互联问题。所以评估一个算力平台的能力不能只看 GPU 型号还要看节点之间的互联带宽比如 InfiniBand 还是 RoCE。存储系统的吞吐和延迟。调度系统能否支撑多租户、多任务并发。能源和散热能否支撑长期满载运行。3. 为什么大模型公司要“锁定”算力回到 Anthropic 这笔交易本身。45 亿美元不是小数目Anthropic 为什么不用这笔钱自己建数据中心或者直接向芯片厂商下单3.1 供给周期错配训练新一代大模型需要的不是几十张 GPU而是几万张。这个规模的集群建设至少需要三个周期并行推进硬件交付周期GPU 服务器从下单到交付需要数月。机房建设周期电力扩容、制冷改造、机柜部署以季度为单位计算。集群调试周期几万张卡的集群跑通中间必然经历网络调优、故障更换、存储压测。如果完全依赖自建Anthropic 的业务速度会被基础设施拖垮。而和 Nscale 这类专业基础设施提供商签约相当于把这三项周期的风险转移给更擅长的一方。3.2 需求预测比采购更重要大模型公司的算力需求不是线性的。训练一个新模型时需求会在某个时间点突然暴增模型发布后推理需求又会持续爬坡。如果按峰值需求自建集群大部分时间资源都会闲置如果按平均需求采购高峰期又会排队。长期锁定模式的核心价值是把“突发需求”转变成“计划性需求”。双方都能基于合约做容量规划基础设施商可以提前备货模型公司可以稳定推进训练计划。3.3 算力已经成为模型能力的直接约束OpenAI 的 GPT-4 等了很久才推出多模态能力Anthropic 的 Claude 系列每一代模型的上下文长度都在增加。表面看是算法进步底层看是算力在支撑。更准确地说模型的参数量、训练数据量、上下文长度、推理质量每一项的进步都对应着算力投入的增加。在没有算法革命的前提下算力就是模型能力的上限。谁锁定的算力多谁就有更多的试错空间和进化速度。4. Nscale 是谁它的稀缺价值在哪从公开材料看Nscale 是一家专注大规模 AI 基础设施的提供商业务覆盖 GPU 集群、数据中心资源和高性能网络服务。它的定位和传统公有云厂商并不完全相同——更侧重提供“可专用、可定制、可规模化”的算力资源。之所以 Anthropic 会选择合作而不是直接扩容现有云资源可能有几个原因4.1 供应能力与地域分布通用云厂商的 GPU 资源需要兼顾所有租户头部客户的超大规模需求很难随时满足。而 Nscale 这类专业算力提供商可以把全部资源按少数几个大客户的规格定制选址也可以更接近能源便宜、气候适合散热的地区对用能效率和资源利用率更友好。4.2 架构适配度大模型训练对集群的互联拓扑、存储读写模式、容错切换机制都有特殊要求。专业算力供应商可以围绕训练框架做定向优化而不是让客户去适配通用云的虚拟化层。对于动辄上亿美元训练成本的模型来说哪怕算力利用率提升 5%都是巨大的成本节省。4.3 可用性与弹性长期合约还意味着弹性保障。Anthropic 可以在训练高峰期使用扩展部分资源在训练间歇期收缩。这种“规模可调整但容量有保底”的模式比自建数据中心更灵活比按调用付费的公有云更可控。从产业链位置来看Nscale 踩中的正是当前 AI 行业最稀缺的环节——具备大规模交付能力的算力产能。芯片再好如果变不成可用的集群就无法创造价值。专业算力提供商的价值就在于把芯片变成训推可用的计算服务。5. 这笔交易改变了什么市场结构层面的影响5.1 对云厂商和算力供应商以前云厂商的基本盘是多租户、按量计费。现在头部 AI 公司开始签长期大单这会导致算力供应商的业务模式分层面向头部客户超大单、定制化、长期合约。面向中小客户标准化、弹性、按量计费。这意味着中小开发者在公共云上的算力供给可能不会因为大客户的大量采购而被“挤爆”但高端资源的价格可能会被推高因为供应商会把头部订单的利润压力分摊到标准化产品上。5.2 对芯片厂商芯片厂商的竞争逻辑也在变化。过去拼单卡峰值算力现在拼的是集群吞吐、网络兼容性、能效比和供应链稳定性。FP8 这类新精度方案的普及也需要芯片厂商和算力提供商深度联调否则很难发挥真实性能。5.3 对开源社区和中小团队大模型公司锁定大量算力后可能带来两个影响开源模型的训练成本被头部公司承担的越来越多对中小团队是好事。中小团队想自己从头训练大模型的难度进一步提高因为资源竞争加剧。这正是为什么我们在后面要专门讨论“算力规划”和“推理优化”。对绝大多数团队来说在算力受限的前提下把效果做出来比盲目堆规模更现实。6. 开发者如何核算自己的算力需求你不需要参与 45 亿美元级别的交易但也应该对自己的算力需求有一个理性评估否则很容易在云账单和自建成本之间反复踩坑。6.1 训练场景的算力估算大模型训练成本的核心公式是训练所需算力 ≈ 模型参数量 × 训练 token 数 × 计算系数通常取 6这个“6”来自 Transformer 架构的前向传播和反向传播次数。6 倍系数估算出来的总 FLOPS再除以单卡有效算力考虑 MFU 模型利用率通常取 30% 到 50%就可以大致估算训练所需的 GPU 卡数和时长。下面的 Python 脚本可以帮你快速估算# 文件路径estimate_training_flops.py def estimate_training_gpus( params_billion: float, tokens_billion: float, gpu_tflops: float, mfu: float 0.4, hours_per_day: float 24, ): 估算训练一个大模型所需的 GPU 卡数和天数。 参数: params_billion: 模型参数量单位十亿 tokens_billion: 训练数据量单位十亿 token gpu_tflops: 单卡算力单位TFLOPSFP16/BF16 mfu: 模型利用率一般取 0.3-0.5 hours_per_day: 每天运行小时数 返回: (卡数, 天数) # 计算总计算量6 * 参数量 * token 数 total_flops 6 * (params_billion * 1e9) * (tokens_billion * 1e9) # 单卡每天实际可用算力 daily_flops_per_gpu gpu_tflops * 1e12 * mfu * 3600 * hours_per_day # 假如目标 30 天完成训练反推需要的卡数 target_days 30 gpus_needed total_flops / (daily_flops_per_gpu * target_days) return gpus_needed, target_days if __name__ __main__: # 示例70B 模型训练 200B token单卡 1000 TFLOPSMFU 0.4 gpus, days estimate_training_gpus( params_billion70, tokens_billion200, gpu_tflops1000, mfu0.4, ) print(f训练 70B 模型30 天内完成约需要 {gpus:.0f} 张 GPU)运行python estimate_training_flops.py输出示例训练 70B 模型30 天内完成约需要 716 张 GPU注意这是简化估算没有考虑优化器状态、激活值显存、通信开销和故障恢复。实际工程中显存可能先于算力成为瓶颈。6.2 推理场景的成本核算推理场景的成本不像训练那么线性。影响要素包括输入和输出的 token 数量。并发请求数。模型参数量和量化精度。推理框架的批处理效率。比较实用的做法是先压测再算账单。用vLLM这类推理框架部署模型后可以用下面的命令做简单压测# 使用 vLLM 自带的 benchmark 工具 python -m vllm.entrypoints.benchmark.benchmark_latency \ --model /path/to/model \ --tensor-parallel-size 4 \ --dtype float16 \ --input-len 512 \ --output-len 256 \ --num-prompts 50这个命令会输出 P50、P90、P99 延迟和吞吐数据。得到这些数据后你可以结合 API 单价算出单次请求的算力成本。6.3 什么情况下自建什么情况下用云一个相对稳妥的判断标准训练需求长期稳定、规模大可以考虑自建或长期合约锁定。训练需求波动大、周期短优先用云的弹性资源。推理量持续增长但峰值不确定优先用 Serverless 或按量付费配合弹性伸缩。数据敏感、合规要求高私有化部署或专属集群更合适。7. 算力受限环境下的实用优化建议对于大多数开发者和中小团队短期内很难买到无限算力。更现实的路径是在有限的算力预算内把模型的训练、微调、推理效率做到极致。7.1 训练侧混合精度与序列长度控制能用 BF16 就不用 FP32。能用梯度检查点gradient checkpointing就用减少显存峰值。大序列训练时要考虑 attention 计算的二次方复杂度尽量先用短序列训练再在后期用长序列继续训练。开启 flash attention可以大幅降低显存占用并提升速度。7.2 推理侧量化与批处理推理侧最直接的优化是模型量化。从 FP16/BF16 降到 FP8理论上能减少一半显存占用同一块卡上的吞吐也能明显提升。但量化各有风险FP8 尤其需要注意激活值的溢出问题。更稳妥的方式是先用工具评估量化误差再决定上线。例如对量化后的模型做一些输出对比观察是否有关键任务掉点。7.3 架构侧缓存与混合部署如果你的应用是高频调用同一个模型可以考虑把通用推理放在高吞吐的离线批处理中。用语义缓存减少重复计算。把轻量任务分给更小、更快的模型只有复杂任务才调用大模型。# 一个简单的语义缓存思路 import hashlib import json import redis r redis.Redis(hostlocalhost, port6379, decode_responsesTrue) def get_cache_key(prompt: str, model: str, temperature: float): raw f{model}|{temperature}|{prompt} return hashlib.sha256(raw.encode(utf-8)).hexdigest() def cached_generate(prompt: str, llm_func, model: str claude-3-5-sonnet, temperature: float 0.7, ttl3600): key get_cache_key(prompt, model, temperature) cached r.get(key) if cached: return json.loads(cached) result llm_func(prompt, temperaturetemperature) r.setex(key, ttl, json.dumps(result)) return result这个示例虽然简单但它体现了算力优化的核心思路减少无效计算把有限的算力花在最重要的事情上。8. 算力采购与使用的常见问题问题现象可能原因排查方式解决方案训练时 GPU 利用率低数据加载慢、网络通信瓶颈查看nvidia-smi利用率波动检查 CPU 和网络带宽使用高性能并行文件系统、DataLoader 多进程、提前做数据预处理训练时显存不足模型规模超过单卡显存查看nvidia-smi显存使用情况使用梯度检查点、ZeRO 或张量并行降低批次大小多卡训练速度不随卡数线性提升并行策略不合适或网络互联带宽不足对比 1 卡和 4 卡的训练吞吐调整并行策略检查 InfiniBand 或 RoCE 配置减少跨节点通信推理延迟高但 GPU 没跑满推理框架批处理调度不足压测并观察单请求延迟和 GPU 利用率使用 vLLM、TGI 等框架开启 continuous batching启动任务时报连接超时算力平台的网络策略或服务连接受限确认 API 地址、端口和网络策略检查实例安全组、代理配置和可访问性设置量化后效果明显下降量化校准数据处理不当对比量化前后在典型任务上的输出用训练集或代表性数据做校准尝试 FP8 与混合量化方案这里尤其想提醒一点算力平台的选择不只是选 GPU 型号还要看平台自身的网络、存储和调度能力。一个组网不合理的集群即使用最新显卡训练效率也可能被拖得很低。9. 在没有“钞能力”的情况下如何保持竞争力如果你不是 Anthropic没有 45 亿美元可以锁定算力那么你的竞争力来自哪里9.1 选择适合自己的模型接入方式中小团队应该优先使用成熟的大模型 API而不是自己从头训练模型。API 调用的成本看起来在增长但相比自建集群的沉没成本仍然是小得多。9.2 深耕垂直场景积累数据资产算力是通用资源数据是差异化资产。与其把预算全部投入算力不如思考你手头有什么独有的数据能不能转成可持续优化的提示词模板、微调数据集或评测集这些才是别人抢不走的优势。9.3 建立评测体系避免盲目换模型很多团队在做模型选型时只看基准分。更稳妥的做法是建立自己的评测集覆盖应用的真实场景。每次切换模型、调整参数、做量化前后都跑同一套评测集看关键指标的变化。下面是构建评测集的一个最小示例# 文件路径eval_pipeline.py EVAL_CASES [ {prompt: 请将下面的句子翻译成英文今天天气很好。, expect_keywords: [today, weather]}, {prompt: 总结这段客服对话中用户的核心诉求。, expect_keywords: [退款, 发票]}, ] def run_eval(model_func): pass_count 0 for case in EVAL_CASES: output model_func(case[prompt]) hit all(kw in output for kw in case[expect_keywords]) if hit: pass_count 1 print(fPrompt: {case[prompt]}) print(fOutput: {output}) print(fPass: {hit}) print(- * 50) print(f评测通过率: {pass_count}/{len(EVAL_CASES)})这套方法不高级但非常适合在团队内部统一模型选型标准。9.4 监控成本建立预算告警在云环境里算力成本容易失控。建议从第一天就建立标签体系按项目、环境、负责人拆分成本并设置预算告警。这比事后看账单冷静得多。10. 总结与后续学习方向Anthropic 与 Nscale 的这次合作是 AI 行业进入“算力供应链时代”的又一个标志性事件。它说明在模型能力提升的曲线上基础设施的约束越来越重要。无论是大公司还是小团队都不能再把算力看作一个可随时购买的通用品而应该把它纳入技术规划和成本模型。对普通开发者来说最值得做的三件事是建立算力成本意识。无论是 API 调用还是自建集群都要能算出每一块钱花在了哪里。掌握推理和训练的基础优化方法。量化、批处理、缓存、混合精度这些技巧在算力紧张时能救你一命。时刻关注算力行业的动态。基础设施供应商的格局变化会直接影响你未来能买到什么样的服务以及花多少钱。如果你对这个话题感兴趣下一步可以重点研究这些方向GPU 集群的组网架构、FP8 量化在推理中的实际效果、分布式训练框架如 DeepSpeed、Megatron-LM、Ray的适用场景以及不同精度策略对成本和延迟的影响。这些内容会随着算力行业的发展变得越来越重要。建议收藏本文后续在实际项目中遇到算力规划问题时可以回来对照检查。