当前位置：首页 > news >正文

从450亿美元算力大单看大模型训练与推理基础设施

news 2026/8/30 4:16:18

AI 算力军备竞赛又出现了标志性事件。Anthropic 被曝出将斥资约 450 亿美元租用 Nscale 的算力基础设施，用于支撑旗下大模型的训练与推理。消息一出，很多人第一反应是“值得吗”，第二反应是“什么是 Nscale”，第三反应是“450 亿美元到底能买到多少算力”。

这篇文章不打算做商业八卦，而是把这件事拆成技术问题：算力在大模型全生命周期里扮演什么角色，为什么头部 AI 公司宁可租用算力也不全部自建数据中心，450 亿美元对应的算力规模大概是什么量级，以及作为普通开发者，我们应该如何理解算力、token、GPU 集群、分布式训练和推理 API 这些概念。

如果你正在做大模型应用开发，或者准备进入 AI 基础设施领域，这篇文章可以帮你建立一张比较完整的算力认知地图。

1. 事件背景：Anthropic 与 Nscale 的算力大单

1.1 事件本身

Anthropic 是目前全球最受关注的 AI 公司之一，旗下核心产品是 Claude 系列大模型，长期聚焦 AI 安全与对齐研究。Nscale 则是一家面向 AI 算力提供基础设施服务的公司，主营业务包括 GPU 算力租赁、AI 数据中心建设和算力集群运维。

根据公开报道，Anthropic 与 Nscale 签署了一份长期算力租用协议，合同金额约为 450 亿美元。这笔交易的核心不是购买 GPU 硬件，而是租用由 Nscale 建设、运营和维护的大规模 AI 算力集群，用于 Claude 系列模型的训练、微调和推理。

换句话说，Anthropic 用长期租约锁定了未来数年的大规模 GPU 计算资源，而不需要自己建造和运维超大规模数据中心。

1.2 为什么这件事值得关注

很多人觉得 450 亿美元离普通开发者太远，其实不然。这笔交易背后透露出几个重要信号：

算力已经成为大模型公司的核心竞争力之一。模型算法再厉害，没有大规模算力支撑，训练和迭代速度就会受限。
算力租赁正在成为主流模式。自建数据中心周期长、投入大、运维复杂，长期租用专业算力基础设施的性价比越来越高。
AI 基础设施产业链正在走向专业化分工。模型公司专注算法和应用，算力公司专注 GPU 集群的建设和运营，双方通过长期合约绑定。

对于开发者来说，理解这笔交易的技术含义，其实就是理解 AI 应用背后“算力从哪来、怎么用、怎么计费”的基础逻辑。

2. 算力在 AI 大模型中的角色

2.1 算力是什么

算力，简单理解就是“计算能力”。在大模型领域，算力特指 GPU 等加速芯片执行矩阵运算、张量运算的能力。

大模型的训练和推理，本质上都是大量的矩阵乘法和非线性变换。以 Transformer 架构为例，每个 token 在每一层都会与权重矩阵做乘法运算，模型参数越多、训练数据越多，需要的计算量就越大。

算力的常用单位包括：

TFLOPS：每秒万亿次浮点运算。
PFLOPS：每秒千万亿次浮点运算。
EFLOPS：每秒百亿亿次浮点运算。

如果细看 GPU 参数，还会看到 FP32、FP16、BF16、FP8 等精度指标。不同精度的算力差异很大，例如同一块 GPU 的 FP8 算力通常是 FP32 的数倍到数十倍，因此训练大模型时通常会采用混合精度策略。

单位	含义	典型场景
TFLOPS	每秒万亿次浮点运算	单卡性能参考
PFLOPS	每秒千万亿次浮点运算	小型训练集群
EFLOPS	每秒百亿亿次浮点运算	超大规模训练集群

2.2 算力在模型训练中的分配

大模型的完整生命周期包括数据清洗、预训练、监督微调、人类反馈强化学习、评测、部署推理等环节。每个环节对算力的需求不同：

预训练：算力消耗最大，通常占总算力成本的 60% 到 80%。百亿到千亿参数模型需要数千张 GPU 连续训练数周甚至数月。
监督微调（SFT）：在预训练基础上使用高质量标注数据进行调整，显存和计算量相对较小。
人类反馈强化学习（RLHF）：需要多次前向和反向传播，并且需要为奖励模型准备额外算力。
推理：用户每次调用 API，模型都要执行一次前向计算。推理算力需求随用户量增长而持续增加。

也就是说，这笔 450 亿美元的算力租赁大单，既覆盖了 Anthropic 训练新一代模型所需的大规模训练集群，也覆盖了 Claude API 全球用户访问所需的推理集群。

2.3 token 与算力的关系

在大模型世界里，token 是模型处理文本的基本单位。一个中文汉字通常对应 1 到 2 个 token，一个英文单词通常对应 1 到 3 个 token。

token 与算力的关系非常直接：每生成一个 token，模型都要执行一次完整的前向推理。因此，推理成本通常用“每百万 token 的价格”来计量，而训练成本通常用“每万亿 token 的数据量需要多少算力”来估算。

这也是为什么 API 定价里非常看重 token 数量。Anthropic、Nscale 这类交易从宏观层面锁定了算力成本，最终这些成本都会通过 token 定价传导给开发者和企业用户。

3. 为什么 Anthropic 选择“租用”而不是“自建”

3.1 自建数据中心的挑战

很多人会问：既然 Anthropic 融了这么多钱，为什么不自己买 GPU、自己建数据中心？真实原因是自建超大规模 AI 数据中心的门槛极高，远不只是“买显卡插上”那么简单。

首先是建设周期问题。一个万卡级 GPU 集群从选址、设计、土建、机电安装、网络布线、设备调试到稳定运行，往往需要 12 到 24 个月。而 AI 模型迭代速度是按季度计算的，等不起这么长的周期。

其次是电力与散热。单张高性能 GPU 的功耗通常在 300W 到 700W 之间，一个万卡集群的 IT 负载轻松超过 30MW，如果加上空调、电源转换损耗，总功耗可能接近 50MW。这需要配套的变电站、冷却塔、液冷系统，涉及大量的基础设施工程。

再次是运维复杂度。GPU 集群不是“买来就能一直跑”的，硬件故障、网络拥塞、驱动兼容、任务调度、断电保护，每一个环节都需要专业团队。Anthropic 的核心团队更专注于模型研究和应用，而不是机房运维。

3.2 租赁模式的优势

与自建相比，长期租用算力基础设施有以下优势：

快速上线：Nscale 已经建好或正在建设的数据中心可以直接交付，Anthropic 的模型训练可以快速启动。
资本开支转运营开支：450 亿美元虽然金额巨大，但分摊到数年的租金模式，比一次性投入几百亿美元自建数据中心更灵活。
弹性扩缩容：训练任务有峰谷，推理需求随用户量波动，租赁模式可以在一定程度上获得规模弹性。
专业技术团队运维：GPU 集群的硬件维护、网络优化、故障处理由 Nscale 负责，Anthropic 可以把精力集中在模型本身。

当然，租赁模式也有风险，比如长期合约的锁定期较长、算力供应商的经营风险、以及未来硬件更新换代导致的老旧设备问题。这也是头部 AI 公司通常采用“自建 + 租用”混合策略的原因。

4. 450 亿美元背后的技术规模估算

4.1 估算思路

虽然我们无法拿到合约的具体条款，但可以通过公开信息和行业惯例做粗略推算。

首先需要明确一个前提：450 亿美元对应的是算力租赁服务的长期收入，不是单批硬件的采购成本。Nscale 需要承担硬件采购、数据中心建设、电力成本、运维人力等所有费用，并通过租金回收成本和获取利润。

假设一块主流 AI 训练 GPU 的月租价格在数百到上千美元区间，具体取决于显存、互联带宽、集群规模和配套服务。一个万卡集群的年租金可能在数十亿到上百亿美元之间。

按这个量级粗算，450 亿美元的合约可能对应数万张 GPU 的多年期租用，也可能包含多个数据中心节点、光缆专线、以及与模型训练匹配的存储和网络服务。

4.2 训练集群规模推算示例

我们可以用公开的大模型训练数据做一个简化估算演示。以训练一个千亿参数模型为例，假设：

模型参数量：1000 亿
训练 token 数：2 万亿
单张 GPU 平均有效算力：约 400 TFLOPS（按混合精度估算）
算力利用率：40%

总计算量约为：

总FLOPs = 6 × 参数量 × 训练token数 = 6 × 1e11 × 2e12 = 1.2e24 FLOPs

单张 GPU 每秒有效计算量约为：

400 TFLOPS × 40% = 400e12 × 0.4 = 1.6e14 FLOPs/s

单卡每天可完成的计算量约为：

1.6e14 × 86400 ≈ 1.38e19 FLOPs/天

训练完成天数与显卡数量相关：

显卡数 = 总FLOPs ÷ （单卡每天计算量 × 目标天数）

如果目标 60 天完成训练，需要约：

1.2e24 ÷ （1.38e19 × 60）≈ 1449 张 GPU

如果目标 30 天完成训练，需要约 2899 张 GPU。这还只是单次预训练的估算，考虑到数据清洗、实验调参、微调、RLHF 等环节，实际需要的算力是上述数字的 2 到 5 倍。

下面用一段 Python 脚本把上面计算过程固化下来，方便大家调整参数自行估算。

# 文件路径：gpu_quantity_estimator.py """ 大模型训练算力估算脚本 通过模型参数量、训练token数、单卡算力和目标训练天数，估算所需GPU数量 """ def estimate_gpu_count( params_billion: float, tokens_trillion: float, single_gpu_tflops: float, utilization: float, target_days: int, ) -> float: """ 估算训练所需GPU数量 :param params_billion: 模型参数量，单位：十亿 :param tokens_trillion: 训练数据量，单位：万亿token :param single_gpu_tflops: 单卡FP16/BF16算力，单位：TFLOPS :param utilization: 算力利用率，例如0.4表示40% :param target_days: 目标训练天数 :return: 估算GPU数量 """ # 大模型标准估算公式：6 * 参数量 * token数 total_flops = 6 * (params_billion * 1e9) * (tokens_trillion * 1e12) # 单卡每秒有效浮点运算次数 single_card_flops = single_gpu_tflops * 1e12 * utilization # 单卡每天完成的浮点运算次数 single_card_daily = single_card_flops * 86400 # 在目标天数内完成训练所需GPU数 gpu_count = total_flops / (single_card_daily * target_days) return gpu_count if __name__ == "__main__": # 示例：千亿参数模型、2万亿token、单卡400 TFLOPS、利用率40%、30天完成 gpu_num = estimate_gpu_count( params_billion=100, tokens_trillion=2, single_gpu_tflops=400, utilization=0.4, target_days=30, ) print(f"估算所需GPU数量：{gpu_num:.0f} 张")

运行脚本：

python gpu_quantity_estimator.py

输出示例：

估算所需GPU数量：2894 张

需要强调的是，这只是一个教学层面的简化估算。实际训练中还需要考虑通信开销、故障恢复、评估任务、多实验并行等因素，真实 GPU 数量通常比估算值高很多。

4.3 FP8 与算力组网

在最新网络热词中，“pro6000算力fp8”和“dsh算力组网”值得展开说一下。

FP8 是一种比 FP16 更低精度的浮点格式。FP8 计算速度更快，显存占用更小，适合对精度要求不那么苛刻的阶段。相当一部分新模型训练流程在设计时就已经兼容 FP8，从而显著提升算力利用效率。

“算力组网”在 AI 基础设施中指用高速网络把大量 GPU 连接成一个可协同计算的集群。训练千亿、万亿参数模型时，单卡无法装下全部参数，必须把模型切分到多张卡上，通过集合通信库（如 NCCL）同步梯度信息。显卡之间的通信带宽直接决定训练效率。常见的组网方式包括：

InfiniBand：低延迟、高带宽，适合大规模同步训练。
RoCE：基于以太网的 RDMA 方案，成本比 InfiniBand 低，部署灵活。
NVLink + NVSwitch：同一服务器内多卡高速互联，常用于 8 卡节点内部通信。

Nscale 这类算力服务商的竞争力，很大程度上取决于网络组网能力和 GPU 集群的工程化水平。同样的 GPU 数量，组网优化得好，训练效率可能相差 20% 到 50%。

5. 从算力到 API：开发者接触到的 AI 服务链路

5.1 算力通过 API 对外输出

对于大多数开发者，我们不需要直接接触 GPU 集群，而是通过 API 使用模型能力。以 Anthropic 的 Claude API 为例，一个典型的请求链路是：

应用代码 -> API 网关 -> 推理集群调度 -> GPU 执行前向推理 -> 返回 token 流

在这个链路里，算力成本被封装在 API 价格中。你请求的 token 越多、生成的速度要求越高，背后消耗的算力就越多。

开发者常见的任务之一是处理 API 调用失败。这里有一个很现实的场景：模型服务负载高时，API 可能会返回超时或 529 状态码。下面给出一个带指数退避重试的 Claude API 调用示例。

# 文件路径：claude_api_demo.py """ Claude API 调用示例，包含带指数退避的重试逻辑 使用前需要安装依赖：pip install anthropic """ import time from anthropic import Anthropic # 请替换成你自己的 API Key client = Anthropic(api_key="your-api-key") def call_claude_with_retry(prompt: str, max_retries: int = 5) -> str: """ 调用 Claude API，并实现指数退避重试 :param prompt: 输入提示词 :param max_retries: 最大重试次数 :return: 模型生成的文本 """ attempt = 0 while attempt < max_retries: try: response = client.messages.create( model="claude-3-5-sonnet-latest", max_tokens=1024, messages=[ {"role": "user", "content": prompt} ] ) # 提取返回文本 return "".join(block.text for block in response.content) except Exception as e: attempt += 1 if attempt >= max_retries: raise RuntimeError(f"API 调用失败，已重试 {max_retries} 次：{e}") # 指数退避：第一次等2秒，第二次4秒，第三次8秒... sleep_seconds = 2 ** attempt print(f"第 {attempt} 次重试，等待 {sleep_seconds} 秒...") time.sleep(sleep_seconds) raise RuntimeError("未知错误") if __name__ == "__main__": result = call_claude_with_retry("请用一句话解释什么是算力。") print(result)

5.2 连接与鉴权问题

调用 API 时经常会遇到如下报错：

unable to connect to anthropic services failed to connect to api.anthropic.com

这类错误虽然表现相似，但原因可能完全不同。常见原因包括：

本地网络访问异常，或者防火墙拦截了对外请求。
API Key 无效、过期或权限不足。
请求并发过高，触发了服务端的限流策略。
Anthropic 服务端临时故障或者正在进行负载均衡调整。

排查思路如下：

检查 API Key 是否正确配置，优先使用环境变量注入。
检查网络连通性，确认能正常访问 api.anthropic.com。
查看服务状态页，确认是否是官方故障。
加入重试和退避机制，避免集中的瞬时抖动打爆对端服务。

5.3 吞吐量、时延与成本

调用 LLM API 时，还有三个重要指标：吞吐量（Throughput）、时延（Latency）和成本（Cost）。

时延指从发出请求到收到第一个 token 的时间，主要取决于模型大小、输入长度和推理集群负载。
吞吐量指单位时间能处理的请求数或 token 数，依赖 GPU 算力和服务架构。
成本与 token 数直接挂钩，使用时可以开启流式输出，让用户更快看到内容，同时结合 max_tokens 控制输出长度。

在开发 AI 应用时，建议从一开始就做成本监控，统计每个用户、每个功能消耗的 token 数量，避免月底账单超标。

6. 算力规模估算实践：从需求到预算

6.1 需求建模

如果你所在的公司计划私有化部署一个大模型，或者团队准备微调一个开源模型，你通常需要从业务需求出发做算力规划。

我们以“微调开源 7B 模型”为例，做一个简化的需求分析：

选择基础模型后，确定训练方法（LoRA 还是全量微调）。
LoRA 微调显存需求较低，通常单张 24GB 到 48GB 显存的显卡即可运行。
全量微调 7B 模型，需要几十 GB 显存，可能需要多卡并行。

6.2 显存估算

下面给出一个结合模型参数和训练方式的显存估算脚本：

# 文件路径：memory_estimator.py """ 大模型微调显存估算脚本 以字节为单位估算显存占用，结果只作为参考，精确值取决于框架实现 """ def estimate_memory_gb( params_billion: float, use_lora: bool, batch_size: int, sequence_length: int, precision_bytes: int = 2, ) -> float: """ 估算训练所需显存 :param params_billion: 模型参数量（十亿） :param use_lora: 是否使用LoRA :param batch_size: 批大小 :param sequence_length: 序列长度 :param precision_bytes: 精度字节数，FP16/BF16为2，FP32为4 :return: 显存估算值（GB） """ # 模型参数显存 = 参数量 * 精度字节数 param_count = params_billion * 1e9 param_memory = param_count * precision_bytes # LoRA 只训练低秩矩阵，可减少约70%的优化器状态显存 if use_lora: optimizer_memory = param_memory * 0.3 gradient_memory = param_memory * 0.3 else: optimizer_memory = param_memory * 2 gradient_memory = param_memory * 1 # 激活值粗略估算：参数量的20%，再乘以batch_size和序列长度修正系数 activation_memory = param_memory * 0.2 * batch_size * (sequence_length / 2048) total_bytes = param_memory + optimizer_memory + gradient_memory + activation_memory total_gb = total_bytes / 1024 ** 3 return total_gb if __name__ == "__main__": memory_gb = estimate_memory_gb( params_billion=7, use_lora=True, batch_size=4, sequence_length=2048 ) print(f"LoRA 微调 7B 模型估算显存：{memory_gb:.1f} GB")

运行后可以得到一个显存估算值。在实际使用中，务必要给框架、CUDA 内核和临时缓冲留出额外空间，建议在估算结果上再增加 20% 到 30% 的余量。

6.3 容量规划最佳顺序

在做算力规划时，建议按以下顺序执行：

明确业务目标：是训练基础大模型，还是微调开源模型，还是只做推理服务。
确定模型规模：参数从 1B 到 100B 不等，对显存和算力的要求差异巨大。
选择训练策略：全量训练、LoRA、QLoRA 的选择决定显存和 GPU 数量。
估算推理负载：峰值 QPS、平均并发数、每个请求的输入输出 token 数。
结合预算选型：云上按需租用、包月租用、还是私有化部署。
先做小规模压测：用单机多卡或少量 GPU 先跑通流程，再向上扩展。

7. 常见问题与排查思路

问题现象	常见原因	解决思路
训练时 GPU 利用率低	数据加载瓶颈、网络通信瓶颈	检查 DataLoader 是否使用多进程，检查 NCCL 通信带宽
微调时显存溢出 OOM	模型过大、batch_size 过大	降低 batch_size，启用梯度累积，使用 LoRA/QLoRA
训练速度慢且不稳定	网络组网问题或故障节点未隔离	检查 InfiniBand/RoCE 健康状态，清理故障 GPU
API 返回 529	服务端过载	配置指数退避重试，降低并发
API 连接失败	本地网络异常、Key 错误、服务故障	逐项检查网络、Key、服务状态页
推理延迟高	模型过大、并发过高、未开启流式输出	使用流式输出，配置更大推理集群，优化 Prompt 长度
成本超预算	未限制 max_tokens，未做 token 统计	在代码中统计 token 消耗，设置调用上限

8. 最佳实践与工程建议

8.1 算力成本治理

不管是大模型公司还是普通业务团队，算力成本治理都应该提上日程。建议从以下维度入手：

预算先行：每个项目启动前明确算力预算上限，按周或按月监控实际消耗。
分层设计：把高频低难度任务路由到小模型或快速模型，把复杂任务交给大模型，避免所有请求都走最贵链路。
Token 压缩：优化 Prompt 长度，使用缓存机制减少重复请求，控制输出长度上限。
离线任务错峰：训练、离线批处理任务安排到低峰时段，降低推理集群峰值压力。

8.2 分布式训练注意事项

如果团队需要自建或租用多卡训练环境，以下事项需要特别关注：

使用标准分布式训练框架：PyTorch DDP 适合中小规模，DeepSpeed ZeRO、Fully Sharded Data Parallel 适合超大模型。
开启混合精度：FP16/BF16 可以显著降低显存和算力开销。
设置检查点：每隔一定步数保存模型状态，防止节点故障导致训练中断。
监控训练指标：观察 loss 曲线、GPU 利用率、通信耗时，及时发现问题。
故障自动恢复：多节点训练时一定要考虑单节点故障的恢复策略。