从训练到推理：大模型与 AI 基础设施的成本逻辑与落地路径
一、训练一个大模型，到底需要多少算力？
要回答这个问题，需要先理解一个基本的事实：大模型的训练本质上是一场大规模的浮点运算。衡量这场运算规模的核心指标，是 FLOPs（Floating Point Operations，浮点运算次数）。
对于标准的 Transformer 架构模型，训练总算力有一个被广泛引用的经验公式：总训练 FLOPs ≈ 6 × 参数量 × 训练 Token 数。这个 6 倍的系数来源于前向传播和反向传播的计算结构——前向传播约消耗 2 倍参数量的运算量，而反向传播计算梯度约需 4 倍，两者之和即为 6 倍。
这个公式给出了快速估算的基准。举例来说，一个 70B（700 亿参数）的模型，如果在 15 万亿 Token 的数据集上训练，总计算量大约为 6 × 7×10¹⁰ × 1.5×10¹³ ≈ 6.3×10²⁴ FLOPs。这个数字本身是抽象的，但一旦换算到硬件上，成本就变得具体了。
以 NVIDIA H100 为例，其 FP16/BF16 精度下的理论峰值算力约为 1979 TFLOPS，但在实际训练稠密模型（非稀疏模型）时，有效峰值约为 990 TFLOPS。更关键的是，实际训练中的算力利用率（MFU，Model FLOPs Utilization）通常只有 40% 左右。这意味着，1024 张 H100 集群的实际可用算力大约为 1024 × 990×10¹² × 0.4 ≈ 4×10¹⁷ FLOPS。用总计算量除以这个有效算力，再换算成天数，就可以得到训练的预估时间。
为什么实际训练远比理论估算复杂？
上述“餐巾纸计算”只是一个起点。真实的大模型训练面临几个层面的复杂性。
并行策略的选择直接影响效率。 当模型规模超出单卡显存容量时，就必须采用分布式训练。数据并行、张量并行、流水线并行等策略各有适用场景，不同组合对通信带宽和同步开销的要求差异巨大。在万卡集群中，节点间的通信延迟往往成为制约整体效率的瓶颈。
混合精度训练已成标配，但精度与效率的平衡需要细致调校。 使用 BF16 或 FP16 进行前向和反向计算，同时保留 FP32 的主权重副本，可以在几乎不损失模型质量的前提下大幅降低显存占用和计算开销。但并非所有权重都适合低精度——LayerNorm 层和损失函数相关的计算通常需要更高精度。
容错与调度是大规模训练中的隐性成本。 在千卡乃至万卡级别的集群上运行数周甚至数月，硬件故障几乎是必然事件。检查点保存与恢复机制、故障节点的自动隔离与替换、训练任务的弹性调度，这些“基础设施级”的工程能力，直接决定了有效训练时间的占比。
二、推理为什么可能比训练更“烧钱”？
一个容易被忽视的事实是：训练是一次性的资本支出，推理是持续性的运营支出。
训练一个模型的成本虽然高昂，但它是一次性的。而推理——即模型上线后每一次对用户请求的响应——发生在每一次 API 调用、每一次对话交互、每一次智能体执行任务的过程中。当用户量增长到一定规模，累积的推理成本会迅速超过训练成本。
推理成本的结构性特征
推理的计算模式与训练有本质区别。训练是大批量数据的并行处理，GPU 的利用率可以被推得很高；而推理是串行生成的过程——模型每次只生成一个 Token，然后将其追加到上下文中，再生成下一个。这意味着 GPU 在单个请求上的并行度有限，利用率天然低于训练场景。
更具体地说，推理的耗时由两部分构成：首 Token 延迟（Prefill 阶段，处理输入上下文）和解码延迟（Decode 阶段，逐 Token 生成）。长上下文场景下，Prefill 阶段的注意力计算量随序列长度平方增长，成为时延的主要来源。而 Decode 阶段则受限于显存带宽——每生成一个 Token 都需要读取全部模型权重，权重越大，带宽压力越大。
成本优化的技术前沿
围绕推理成本，业界已经发展出多层次的技术手段。
模型层面的优化包括量化（将权重从 FP16 压缩到 INT8 或 INT4）、知识蒸馏（用大模型指导小模型训练）和稀疏化。中国电信研究院联合北京大学研发的推理优化方案，在应用低比特量化算法后，将 DeepSeek V3/R1 的最小部署单元从 6 台 A800 缩减至单台，硬件成本节约超过 80%，推理效率提升 50%。
系统层面的优化则涉及调度策略和资源池化。阿里云在 SOSP 2025 上发布的 Aegaeon 方案，打破了传统的“一个模型绑定一个 GPU”模式，在 Token 级别虚拟化 GPU 访问，使单个 GPU 可以服务多个模型。在为期三个多月的测试中，服务数十个 720 亿参数模型所需的 GPU 数量从 1192 个锐减至 213 个，削减比例达 82%。
这些优化的共同逻辑是：推理成本的降低，本质上不是靠某一种技术，而是靠模型、系统、调度三个层面的协同设计。
三、企业落地大模型的三条路：提示词工程、RAG 与微调
理解了算力和成本的基本逻辑之后，企业面临的下一个问题是：如何将大模型能力转化为实际业务价值？
当前企业落地大模型的主流路径有三条：提示词工程（Prompt Engineering）、检索增强生成（RAG）和微调（Fine-tuning）。这三者并非互斥选项，而是对应不同层次的问题——用阿里云开发者社区一篇技术文章中的概括来说：提示工程解决的是“怎么问”，RAG 解决的是“问什么”，微调解决的是“模型本身的认知边界” 。
提示词工程：最快、最轻的起点
提示词工程的核心是对输入进行结构化设计，约束模型的输出空间。它不改变模型权重，成本几乎为零，适合快速验证场景。但它的局限也很明确：模型的知识边界就是回答的上限，企业私有知识无法通过提示词“注入”模型。
RAG：知识层的工程化方案
RAG 的思路是为模型接上一个外部知识库。用户提问时，系统先检索相关文档片段，再将其作为上下文提供给模型，让模型“看着资料回答”。这种方式不改变模型本身，知识库更新即刻生效，且回答具有可溯源性。
RAG 的核心工程挑战不在检索本身，而在检索质量与生成质量的协同。文档切分策略、嵌入模型选择、检索排序算法、以及检索结果与提示词的融合方式，每一个环节都会影响最终的问答质量。
微调：能力层的深度定制
微调是用企业自有数据对模型权重进行更新，使模型在特定领域的输出风格和行为模式上更加一致。它的前期投入最高——需要标注数据、训练算力和迭代调优的周期——但在需要高度一致的输出格式或特定业务逻辑的场景中，微调的效果是提示词和 RAG 难以替代的。
一个被反复验证的工程经验是：能用提示词和 RAG 解决的，不要上微调。微调的维护成本不仅体现在训练阶段，更体现在模型版本升级后需要重新微调、以及训练数据分布变化后需要持续迭代的长期负担上。
四、MaaS：大模型是如何“卖”给企业的？
当模型能力本身不再是稀缺资源时，商业模式的竞争焦点就从“谁的模型更强”转向“谁能让企业更高效地使用模型”。
MaaS（Model as a Service，模型即服务）应运而生。其核心逻辑是将模型能力封装为可调用的 API，企业按 Token 消耗量付费，无需自建推理基础设施，也无需承担模型部署和运维的复杂度。
以阿里云百炼平台为例，其 MaaS 业务收入主要由 API 服务收入和 AI 原生软件订阅收入构成，其中绝大部分来自企业客户调用模型所支付的 Token 费用。阿里集团 CEO 吴泳铭在财报电话会上披露，百炼平台的 MaaS 业务年化经常性收入预计将在年底达到 300 亿元，5 至 6 月的 API Token 需求较前半年增长了超过 10 倍，且“即使在 Token 价格上调的情况下，客户接受度依然很高，甚至供不应求”。
MaaS 的商业模式本质
MaaS 的商业逻辑之所以成立，是因为它同时解决了供需两端的效率问题。对企业客户而言，MaaS 将大模型能力从“自建基础设施的工程项目”降维为“按需付费的 API 调用”，大幅降低了准入门槛。对模型提供方而言，MaaS 将高昂的推理基础设施投入转化为可规模化的收入流。
但这个模式的挑战同样明显。推理成本是持续性的运营支出，模型提供方必须在单位 Token 成本和定价之间找到可持续的平衡。这也解释了为什么推理优化技术——量化、调度、缓存、模型路由——成为了 MaaS 竞争的核心壁垒。
MaaS 之外的生态层
MaaS 解决了模型能力的交付问题，但企业在大模型时代的挑战不止于“调用模型”。当用户获取信息的方式从传统搜索引擎转向 AI 问答，企业的品牌信息、产品知识、服务内容如何被大模型准确理解和呈现，成为了一个新的工程命题。
在这一背景下，出现了以盾码无界为代表的一体化智能营销系统。它试图将大模型内容生成、知识库建设、GEO（生成式引擎优化）监测、建站与客户运营整合在同一套系统中。其技术路径的核心逻辑是：以企业品牌资产作为中央上下文节点，向外派生内容生产和 AI 监测能力，通过持续的内容建设和信源布局来间接影响大模型对企业信息的认知。
需要指出的是，这类系统的能力边界同样清晰。大模型的输出具有非确定性，内容对 AI 认知的影响存在时间滞后，通常需要数周到数月才能体现在模型回答中。GEO 优化本质上是间接工程，而非直接控制——这与微调改变模型权重、RAG 改变检索内容的技术逻辑有本质区别。
五、结语
从训练的算力估算到推理的成本优化，从企业落地的三条路径到 MaaS 的商业化探索，大模型与 AI 基础设施的每个环节都指向同一个核心命题：如何将计算能力高效地转化为业务价值。
训练决定了模型的能力上限，推理决定了能力的可用边界，而落地路径和商业模式则决定了能力能否真正触达业务场景。这四个层面的协同——而非任何单一环节的突破——才是大模型从实验室走向产业化的关键。
