商业化大模型的技术栈分层

这篇笔记怎么读

这篇解决“商业化模型服务到底由哪些层组成”。
建议按基础设施、数据、模型、训练、推理、编排、平台、应用八层阅读。
如果只关心应用落地，优先看推理服务层、编排层和平台层。

为什么先看技术栈分层

商业化大模型服务表面上是一个聊天窗口、一个 API、一个 Copilot 或一个 Agent，但底层实际上是一套高度复杂的技术系统。

如果只从产品层观察，很容易把 OpenAI、Anthropic、Google Gemini、豆包、通义千问、DeepSeek、百度文心、腾讯混元等都理解为“能聊天的大模型”。但从底层技术看，不同供应商的差异可能出现在完全不同的位置：

有的公司强在基础模型训练；
有的公司强在推理成本控制；
有的公司强在长上下文与文档处理；
有的公司强在工具调用和 Agent 编排；
有的公司强在企业平台、安全治理和云服务集成；
有的公司强在应用入口和高频用户反馈闭环。

因此，在进入具体供应商分析前，必须先建立一张完整的技术地图。

本篇笔记的核心问题是：

一个成熟的商业化大模型服务，从 GPU 集群到用户应用，中间到底包含哪些技术层？这些层之间如何依赖？近几年技术演进的主线是什么？

2. 总体结构：商业化大模型不是一个模型，而是一套系统

可以把商业化大模型系统拆成九层：

第 9 层：应用层
Chatbot / Copilot / AI Search / Code Assistant / AI Office / AI Customer Service / Industry Agent

第 8 层：平台层
API / SDK / Model Studio / Knowledge Base / Evaluation / Observability / Guardrails / Billing

第 7 层：编排层
Prompt / Function Calling / Structured Output / RAG / Agent / Memory / Workflow / MCP

第 6 层：推理服务层
Serving Engine / KV Cache / Dynamic Batching / Speculative Decoding / Quantization / Model Routing

第 5 层：训练与对齐层
Pretraining / Continued Pretraining / SFT / RLHF / RLAIF / DPO / Reasoning RL / Safety Alignment

第 4 层：模型层
Dense Transformer / MoE / Reasoning Model / Multimodal Model / Embedding / Reranker / Small Model

第 3 层：数据层
Pretraining Data / Instruction Data / Preference Data / Synthetic Data / Multimodal Data / Enterprise Data

第 2 层：基础设施层
GPU/TPU/NPU / Distributed Training / Storage / Networking / Inference Cluster / Scheduler

第 1 层：治理与安全横切层
Privacy / Permission / Compliance / Red Teaming / Monitoring / Content Safety / Agent Security

其中，治理与安全不是独立的一层，而是贯穿所有层的横切能力。商业化大模型不同于研究模型，它不仅要“能跑”，还要“能稳定运行、可计费、可审计、可治理、可集成、可规模化交付”。

3. 技术发展脉络：从 Transformer 到 Agent 基础设施

3.1 2017：Transformer 奠定大模型架构基础

2017 年的 Transformer 论文提出了完全基于注意力机制的序列建模架构，摆脱了 RNN/CNN 的顺序计算瓶颈，使大规模并行训练成为可能。现代大语言模型、视觉语言模型、代码模型和多模态模型基本都建立在 Transformer 或其变体之上。

这一阶段的关键变化是：

序列建模范式：RNN / CNN → Self-Attention
训练方式：任务特定模型 → 大规模预训练
能力来源：人工特征与任务结构 → 数据、参数与计算规模

Transformer 的商业化意义在于，它为“大规模通用模型”提供了可扩展架构。

3.2 2018–2020：预训练语言模型成为通用底座

BERT、GPT、T5 等模型证明了预训练范式的有效性。模型先在大规模文本上学习通用语言和知识，再通过微调或提示适配下游任务。

这一阶段形成了两个重要方向：

Encoder-only：BERT 类模型，适合理解、分类、检索、排序
Decoder-only：GPT 类模型，适合生成、对话、代码、推理
Encoder-decoder：T5 类模型，适合文本到文本转换任务

商业化大模型最终主要选择了 decoder-only GPT 路线，因为它更适合统一生成式接口：输入自然语言，输出自然语言、代码、JSON、工具调用参数或多模态结果。

3.3 2020：RAG 把参数记忆与外部知识结合

RAG 提出将参数化语言模型与非参数化检索记忆结合，用外部文档库补充模型内部知识。它解决了商业应用中的三个关键问题：

模型知识过期；
企业私有知识不能完全写入模型参数；
需要给回答提供来源、证据和可追溯性。

从商业化角度看，RAG 是大模型进入企业知识场景的基础技术。大多数企业 AI 问答、客服、内部知识助手、文档分析系统，本质上都是 RAG 或 RAG 的变体。

3.4 2021–2022：Scaling Law、Chinchilla 与 RLHF 推动 ChatGPT 式产品形成

这一阶段出现了两条关键线索。

第一条是 scaling law 和 compute-optimal training。Chinchilla 证明，在给定计算预算下，模型参数规模和训练 token 数量需要更平衡地增长。它改变了“大就是好”的粗糙理解，使业界更重视数据规模、数据质量和训练预算之间的平衡。

第二条是 RLHF。InstructGPT 证明，仅仅扩大模型并不能保证模型遵循用户意图；通过指令数据、人工偏好排序和强化学习，可以显著提升模型的有用性、诚实性和安全性。这直接奠定了 ChatGPT 类产品的技术基础。

这一阶段的关键变化是：

预训练模型 → 指令模型
语言建模能力 → 用户意图对齐能力
离线 benchmark → 真实用户偏好
模型参数规模 → 参数、数据、计算和对齐共同优化

3.5 2022–2023：FlashAttention、vLLM 与推理服务工程化

当大模型进入商业化服务后，瓶颈不再只是训练，而是推理成本与服务效率。每个用户请求都会消耗 GPU 资源，长上下文和多轮对话还会产生大量 KV cache。

这一阶段的关键技术包括：

FlashAttention：通过 IO-aware 的注意力计算减少 GPU HBM 与 SRAM 之间的数据读写，提高训练和推理效率；
vLLM / PagedAttention：用类似操作系统分页的方式管理 KV cache，减少显存碎片和浪费；
dynamic batching：把不同用户请求动态合批，提高吞吐；
speculative decoding：用小模型或草稿模型提前预测 token，再由大模型验证；
quantization：用低精度计算降低显存和推理成本。

商业化意义非常明确：

模型能力决定上限；
推理系统决定成本、延迟和规模化能力。

同样的模型，如果 serving 系统不同，商业利润率可能完全不同。

3.6 2023：DPO、工具调用与 Agent 雏形

DPO 将偏好优化转化为更简单稳定的分类式目标，降低了传统 RLHF 中训练 reward model 和执行 PPO 的复杂度。它让偏好对齐更容易被开源社区和中小团队采用。

同时，Toolformer、ReAct、function calling 等路线推动模型从“回答问题”走向“调用工具”。模型不再只生成文本，而是可以决定：

是否需要调用工具；
调用哪个工具；
传入什么参数；
如何读取工具返回值；
是否继续调用下一步工具；
最后如何组织答案。

这就是 Agent 的早期形态。

3.7 2024：MoE、长上下文、多模态与结构化输出成为主流

2024 年以后，商业模型竞争明显分化：

MoE 成为扩展模型容量的重要路线
Mixtral、DeepSeek-V2/V3、腾讯混元等模型都体现了稀疏激活路线的重要性。MoE 允许总参数量很大，但每个 token 只激活部分专家，从而在能力和成本之间取得折中。
长上下文成为商业卖点
法律合同、代码仓库、研究报告、企业文档、会议记录等场景要求模型处理几十万甚至上百万 token 的上下文。
多模态进入产品主线
文本、图像、音频、视频、文档、屏幕理解逐步融合。商业应用从“聊天”扩展到“看图、听音频、读 PDF、理解视频、操作电脑”。
结构化输出成为工程刚需
企业系统需要 JSON、表格、函数参数、数据库查询、工单字段等稳定格式，而不是自由文本。因此 structured output、JSON schema、function calling 成为平台基本能力。

3.8 2025–2026：推理模型、Agent 平台与上下文协议化

2025–2026 年的核心趋势是：大模型从“生成式助手”进一步走向“可执行任务系统”。

代表性变化包括：

Reasoning Model
- 通过强化学习、过程监督、可验证奖励、代码执行反馈等方式提升数学、代码、规划和复杂推理能力；
- DeepSeek-R1 说明大规模 RL 可以激发复杂推理行为；
- OpenAI、Anthropic、Google 等供应商也都在模型产品中区分普通模型、快速模型和深度推理模型。
Agent Platform
- OpenAI Responses API、Anthropic tool use / computer use、Google Gemini function calling、AWS Bedrock Agents 等，说明工具调用和 Agent 编排已经从研究范式变成商业平台能力；
- Agent 不再只是 prompt trick，而是需要会话状态、工具权限、错误恢复、日志追踪、预算控制和安全边界。
MCP 与工具协议化
- Anthropic 提出的 Model Context Protocol 试图标准化模型与外部工具、数据源之间的连接方式；
- 这反映了一个趋势：未来竞争不只是模型 API，而是“模型如何接入世界”。
多模型路由与成本优化
- 商业平台会根据任务难度、延迟要求、预算、安全等级自动选择模型；
- 简单任务给小模型，复杂任务给大模型，强推理任务给 reasoning model；
- 这使大模型服务更像云计算资源调度，而不是单模型调用。

4. 第一层：基础设施层

基础设施层是大模型商业化的物理底座。它决定了模型能否训练出来、能否低成本推理、能否支撑高并发用户访问。

4.1 计算硬件

主流硬件包括：

NVIDIA GPU：A100、H100、H200、B200 等；
Google TPU；
AWS Trainium / Inferentia；
国内 NPU / AI 加速卡；
推理专用芯片；
边缘端侧芯片。

训练和推理对硬件的要求不同：

场景	核心需求
预训练	大规模并行计算、高带宽互联、大显存、稳定长时间训练
微调	中等规模计算、较好显存、训练框架兼容性
推理	低延迟、高吞吐、低成本、KV cache 管理
Agent	多轮调用、工具交互、上下文复用、调度稳定性
多模态	图像/音频/视频编码器额外计算，输入输出带宽更高

4.2 分布式训练

大模型训练通常需要多种并行策略组合：

Data Parallelism：不同 GPU 处理不同 batch
Tensor Parallelism：切分单层矩阵计算
Pipeline Parallelism：把模型不同层放到不同设备
Sequence Parallelism：切分序列维度
Expert Parallelism：MoE 中把不同专家分布到不同设备
ZeRO / FSDP：切分优化器状态、梯度和参数

对于商业化供应商，分布式训练能力是核心壁垒之一。它不仅需要算法和框架，还需要硬件调度、网络拓扑、容错、检查点、数据流和稳定性工程。

4.3 存储与数据管道

大模型训练高度依赖数据管道：

原始数据采集 → 清洗 → 去重 → 质量过滤 → 安全过滤 → 分桶 → tokenization → 混合采样 → 训练流式读取

数据管道的挑战包括：

数据规模巨大；
数据来源复杂；
重复数据会浪费训练预算；
低质量数据会损害模型能力；
有害数据和隐私数据会带来安全风险；
训练数据污染会影响评测可信度。

4.4 推理集群与弹性调度

商业服务中的推理请求具有明显波动：

用户高峰期；
企业批处理任务；
Agent 多步任务；
长上下文请求；
多模态请求；
高价 reasoning 请求。

因此，成熟平台需要：

GPU 池化；
多模型实例管理；
自动扩缩容；
请求排队；
优先级调度；
失败重试；
跨区域部署；
SLA 监控；
成本统计。

5. 第二层：数据层

数据层决定模型的知识覆盖、语言风格、领域能力、安全边界和商业可用性。大模型不是“直接学会智能”，而是在大规模数据和训练目标中形成可泛化的模式。

5.1 预训练数据

预训练数据通常包括：

网页文本；
书籍；
论文；
新闻；
代码；
问答；
百科；
论坛；
多语言文本；
数学和科学资料；
合成数据。

预训练数据的核心问题不是越多越好，而是：

质量、覆盖、去重、安全、版权、时效性、领域平衡、语言平衡。

Chinchilla 之后，业界更重视数据 token 数和模型参数之间的计算最优平衡，而不只是盲目扩大参数量。

5.2 指令数据

指令数据用于把基础语言模型转化为可交互助手。典型形式是：

用户指令 → 理想回答

它提升：

指令遵循；
多轮对话；
格式控制；
任务泛化；
礼貌性和可用性；
复杂任务拆解。

商业模型中的指令数据往往来自：

人工编写；
用户日志筛选；
高质量开源数据；
强模型合成；
领域专家数据；
自动评测筛选。

5.3 偏好数据

偏好数据通常是：

prompt + chosen answer + rejected answer

它用于训练 reward model、DPO、RLHF/RLAIF 或其他偏好优化方法。

偏好数据表达的不是“唯一正确答案”，而是“在多个可行回答中，哪个更符合人类偏好”。它对商业模型非常重要，因为真实用户关心的不只是正确，还包括：

是否有帮助；
是否简洁；
是否安全；
是否诚实；
是否遵循格式；
是否避免幻觉；
是否符合语气和场景。

5.4 合成数据

合成数据是前沿模型训练的重要组成部分。常见用途包括：

生成指令微调数据；
生成数学推理题；
生成代码测试样例；
生成工具调用轨迹；
生成安全拒答样例；
生成多语言数据；
生成多模态问答；
蒸馏强模型能力。

合成数据的优势是规模大、成本低、可控；风险是模式单一、错误复制、风格坍缩和训练目标偏移。因此商业供应商通常会结合自动过滤、模型打分、人类抽检和真实用户反馈。

5.5 多模态数据

多模态模型需要文本之外的数据：

图像-文本对；
文档截图；
OCR 数据；
视频字幕；
音频转写；
语音-文本对；
屏幕操作数据；
图表和表格；
视觉问答；
视频问答；
机器人或 GUI 操作轨迹。

多模态商业化的关键不是“能看图”，而是能把视觉、语言、工具和任务结合起来。例如：

读 PDF → 理解图表 → 提取字段 → 调用数据库 → 生成报告

5.6 企业私有数据

企业场景的数据包括：

文档；
邮件；
工单；
CRM；
ERP；
数据库；
代码仓库；
合同；
会议记录；
知识库；
业务流程日志。

这些数据通常不会直接用于供应商的通用模型训练，而是通过 RAG、私有知识库、专属微调、权限过滤和安全网关接入模型系统。

6. 第三层：模型层

模型层是商业大模型服务的核心能力来源，但它并不是全部。模型层通常包括多个模型，而不是一个模型。

6.1 Dense Transformer

Dense 模型指每个 token 都经过完整参数计算的模型。它的优点是：

结构简单；
训练稳定；
推理实现成熟；
适合中小模型和低延迟服务；
易于微调和部署。

缺点是参数量越大，推理成本越高。对于商业服务，dense 模型常用于：

轻量聊天；
低成本 API；
端侧部署；
专用任务；
小模型路由；
embedding 和 reranker。

6.2 MoE 模型

MoE 即 Mixture-of-Experts。它的核心思想是：

模型有很多专家参数，但每个 token 只激活其中一小部分。

优势：

总参数量可以很大；
每次推理激活参数较少；
可以提升模型容量；
对多领域、多语言、多任务建模有吸引力。

挑战：

路由负载均衡；
expert 并行通信成本；
训练不稳定；
推理系统复杂；
batch 中 token 分布不均；
多机部署难度高。

商业化意义：

MoE 是大模型能力扩展和成本控制之间的重要折中。

DeepSeek-V3 的 671B 总参数、37B 激活参数路线，体现了 MoE 在高性价比模型中的价值。

6.3 Reasoning Model

Reasoning Model 不是一种固定架构，而是一类产品和训练路线。它通常强调：

数学推理；
代码生成与调试；
复杂规划；
多步问题求解；
自我检查；
工具调用；
可验证任务优化。

它的训练可能包括：

冷启动推理数据 → SFT → RL → 自我验证 → 蒸馏 → 安全对齐

相比普通聊天模型，reasoning model 通常：

响应更慢；
token 消耗更多；
成本更高；
在复杂任务上更强；
更适合高价值任务。

商业平台常将其作为高价模型层级，用于代码、数学、研究、金融分析、法律分析和 Agent 规划。

6.4 多模态模型

多模态模型将文本与其他模态连接起来。常见结构包括：

视觉编码器 + 投影层 + 语言模型
音频编码器 + 语言模型
视频帧编码器 + 时间建模 + 语言模型
统一多模态 token 表示

能力包括：

图像理解；
OCR；
图表理解；
文档理解；
视频理解；
语音对话；
屏幕理解；
GUI 操作；
图像生成；
视频生成。

商业化中，多模态的价值非常高，因为真实业务输入往往不是纯文本，而是文档、截图、表格、图片、语音和视频。

6.5 Embedding 模型

Embedding 模型将文本、图片或其他对象映射为向量，用于相似度检索。

典型用途：

RAG 文档检索；
语义搜索；
推荐；
聚类；
去重；
相似问匹配；
企业知识库召回。

在企业 RAG 中，embedding 模型质量往往决定系统上限。如果召回不到正确证据，再强的生成模型也很难可靠回答。

6.6 Reranker 模型

Reranker 用于对初步召回结果重新排序。典型流程是：

用户问题 → embedding 召回 top-k 文档 → reranker 精排 → LLM 生成答案

Reranker 的价值在于提升证据质量，尤其适合：

长文档；
多段证据；
法律合同；
技术文档；
企业知识库；
多语言检索。

6.7 Small Model

商业平台越来越重视小模型。小模型不只是“弱模型”，而是系统中的重要组件：

简单问题回答；
分类；
意图识别；
安全过滤；
query rewrite；
文档切分；
路由；
草稿模型；
端侧执行；
低成本批处理。

未来商业大模型系统会越来越像“模型集群”，由不同大小、不同模态、不同成本的模型协同工作。

7. 第四层：训练与对齐层

训练与对齐层决定模型从“会预测下一个 token”变成“可用、可靠、可商业化”的 AI 服务。

7.1 Pretraining

预训练目标通常是 next-token prediction：

给定前文 token，预测下一个 token。

这一目标简单、可扩展、适合海量数据。它让模型学习：

语言结构；
世界知识；
代码模式；
推理模式；
多语言能力；
文体和格式；
隐含任务模式。

但预训练模型并不天然懂得“如何做助手”。它可能续写、胡编、重复、违反指令或输出不安全内容。

7.2 Continued Pretraining

继续预训练用于增强特定能力：

代码；
数学；
医疗；
金融；
法律；
多语言；
长上下文；
企业领域；
多模态对齐。

它介于通用预训练和指令微调之间，常用于让模型获得某个领域的语言和知识分布。

7.3 Supervised Fine-Tuning, SFT

SFT 用高质量指令-回答数据训练模型，使其学会按照用户指令回答。

SFT 主要解决：

指令遵循；
对话格式；
基本任务泛化；
安全拒答初步模式；
风格和语气；
工具调用格式。

但 SFT 只能模仿数据中的回答，不一定能优化“哪个回答更好”。这就需要偏好优化。

7.4 RLHF

RLHF 的典型流程是：

SFT 模型 → 生成多个回答 → 人类排序 → 训练 reward model → PPO 等 RL 优化 → 对齐模型

它提升模型对人类偏好的匹配程度。InstructGPT/ChatGPT 类产品的成功，使 RLHF 成为商业模型对齐的重要路线。

RLHF 的挑战是：

人类标注成本高；
reward model 可能被 exploit；
PPO 训练不稳定；
偏好标准难以统一；
安全与有用性存在张力。

7.5 RLAIF

RLAIF 使用 AI 反馈替代或补充人类反馈。它的优势是：

成本低；
扩展快；
可用于大规模自动偏好生成；
适合安全、格式、推理过程等标准化评估。

风险是：

judge model 偏差；
错误偏好被放大；
模型之间互相蒸馏导致风格同质化；
对复杂价值判断不可靠。

商业平台通常会混合使用人类反馈、AI 反馈、规则过滤和线上用户反馈。

7.6 DPO 与偏好优化

DPO 将偏好优化简化为直接优化 chosen 与 rejected 的概率差异。相比传统 RLHF，它不需要显式训练 reward model，也不需要复杂 PPO 采样流程，因此更稳定、更容易实现。

DPO 的商业意义是：

让偏好对齐从少数大公司专属能力，变成开源社区和企业微调也能采用的技术。

后续还出现了 IPO、KTO、ORPO、SimPO、GRPO 等变体，用于不同场景下的偏好、排序或强化训练。

7.7 Reasoning RL

推理模型的训练重点从“回答更像人”转向“复杂任务能做对”。常见信号包括：

数学答案是否正确；
代码是否通过测试；
工具调用是否成功；
格式是否符合要求；
多步任务是否完成；
计划是否有效；
自我验证是否发现错误。

DeepSeek-R1 说明，大规模 RL 可以激发反思、验证、策略调整等复杂推理行为。商业上，这推动了 reasoning model 成为单独产品层级。

7.8 Safety Alignment

安全对齐贯穿训练全过程，包括：

有害内容过滤；
隐私保护；
拒答策略；
jailbreak 防御；
prompt injection 防御；
工具调用权限；
模型行为边界；
企业数据隔离；
红队测试。

商业模型需要在“有用性”和“安全性”之间权衡。拒答太少会带来风险，拒答太多会影响产品体验。

8. 第五层：推理服务层

推理服务层决定模型能否变成可规模化商业服务。

8.1 Serving Engine

常见 serving 框架包括：

TensorRT-LLM；
vLLM；
SGLang；
TGI；
llama.cpp；
Ollama；
DeepSpeed-MII；
自研推理引擎。

Serving engine 需要处理：

模型加载；
请求调度；
batch 合并；
KV cache；
并发；
streaming；
structured decoding；
多 GPU 并行；
LoRA adapter；
多模型部署；
日志与监控。

8.2 KV Cache

自回归生成中，每生成一个 token，都需要依赖前面所有 token 的 key/value。为了避免重复计算，系统会缓存历史 token 的 key/value，这就是 KV cache。

KV cache 的问题是：

上下文越长，缓存越大；
用户越多，缓存越多；
多轮对话越多，显存压力越大。

因此，商业系统必须优化：

cache 分配；
cache 复用；
cache 驱逐；
prefix cache；
paged cache；
长上下文 cache 压缩。

8.3 Dynamic Batching

多个用户请求可以合并成一个 batch，提高 GPU 利用率。但不同请求长度、到达时间和生成速度不同，导致调度复杂。

核心权衡：

batch 越大，吞吐越高；
等待越久，延迟越高。

商业平台需要在吞吐、延迟、优先级和 SLA 之间动态平衡。

8.4 Speculative Decoding

Speculative decoding 的基本思想是：

小模型先草拟多个 token；
大模型并行验证这些 token；
验证通过则一次接受多个 token。

它可以降低生成延迟，尤其适合大模型推理。关键难点是草稿模型质量、接受率、实现复杂度和与 batching 的协同。

8.5 Quantization

量化用低精度表示模型权重或激活，例如：

FP8；
INT8；
INT4；
GPTQ；
AWQ；
SmoothQuant；
GGUF。

量化可以降低显存、提升吞吐、降低成本，但可能影响模型质量，尤其是数学、代码、多语言和长上下文任务。

8.6 Model Routing

商业平台不会所有请求都调用最强模型。更常见的是模型路由：

简单问题 → 小模型
普通对话 → 中等模型
复杂推理 → reasoning model
图像问题 → 多模态模型
检索问题 → embedding + reranker + LLM
安全高风险问题 → 安全模型或人工审核

模型路由的目标是：

降低成本；
控制延迟；
提升成功率；
匹配任务类型；
避免过度使用昂贵模型。

8.7 Rate Limit 与计费

商业服务必须把模型调用变成可计费资源。常见计费单位包括：

输入 token；
输出 token；
cached token；
reasoning token；
image token；
audio token；
batch token；
fine-tuning token；
storage；
retrieval；
tool call；
dedicated capacity。

这也是为什么推理优化会直接影响商业模式：token 成本越低，平台越能打价格战、扩展用户和提高利润率。

9. 第六层：编排层

编排层是模型从“生成文本”走向“完成任务”的关键。

9.1 Prompt Template

Prompt template 是最基础的编排方式。它把用户输入包装成模型更容易理解的格式。

常见内容包括：

角色说明；
任务说明；
输入字段；
输出格式；
示例；
约束；
安全规则；
工具说明。

Prompt template 的问题是脆弱、难维护、难评测。成熟平台会把 prompt 纳入版本管理、评测和日志系统。

9.2 Function Calling

Function calling 让模型输出结构化工具调用参数，而不是直接调用真实工具。

流程通常是：

用户请求 → 模型判断需要工具 → 输出函数名和参数 → 外部系统执行 → 返回结果 → 模型继续生成

它解决了模型不能直接访问实时信息、数据库、计算器、业务系统的问题。

9.3 Structured Output

结构化输出要求模型输出符合 JSON Schema 或其他约束格式。它在商业场景中非常重要，因为下游系统需要稳定解析。

典型用途：

表单字段抽取；
工单分类；
数据库查询参数；
API 参数；
审批流；
信息抽取；
自动化脚本生成。

9.4 RAG

RAG 的基本流程是：

用户问题 → query rewrite → embedding 检索 → rerank → context assembly → LLM answer → citation / verification

成熟 RAG 系统不仅是“向量库 + 大模型”，还包括：

文档解析；
chunking；
metadata；
hybrid search；
reranking；
query rewriting；
multi-hop retrieval；
citation；
answer verification；
freshness control；
permission filtering；
evaluation。

9.5 Agent

Agent 可以理解为带有目标、工具、状态和反馈循环的模型系统。

典型结构：

Goal → Plan → Act → Observe → Reflect → Continue / Stop

Agent 与普通工具调用的区别在于：

多步任务；
中间状态；
自主规划；
错误恢复；
工具组合；
长程执行；
结果验证。

商业 Agent 的难点不是让模型“会想”，而是让系统“可控、可观测、可恢复、可计费、可授权”。

9.6 Memory

Memory 分为多类：

类型	说明
短期记忆	当前上下文窗口中的内容
长期记忆	跨会话保存的用户偏好和事实
工作记忆	Agent 执行任务时的中间状态
外部记忆	向量库、数据库、文件系统
组织记忆	企业知识库、流程文档、历史工单

Memory 的关键问题是：

存什么；
何时写入；
何时读取；
如何遗忘；
如何避免错误记忆；
如何保护隐私；
如何区分用户级、团队级和企业级记忆。

9.7 Workflow

Workflow 是比 Agent 更可控的企业编排方式。它通常是预定义流程：

节点 1：解析输入
节点 2：检索资料
节点 3：调用工具
节点 4：生成草稿
节点 5：格式校验
节点 6：人工确认
节点 7：写入业务系统

与完全自主 Agent 相比，workflow 更稳定、更可控，更适合企业生产环境。

9.8 MCP 与工具协议

Model Context Protocol 的意义在于标准化模型客户端与外部工具、数据源之间的连接方式。它试图解决 M×N 集成问题：

没有协议：每个 AI 应用都要单独适配每个工具
有协议：AI 应用接入 MCP，工具提供 MCP server

这类似于编程领域的 Language Server Protocol。对于商业化 Agent，工具协议化是关键趋势，因为它可以降低工具生态接入成本。

10. 第七层：平台层

平台层把底层模型和编排能力包装成开发者、企业和应用团队可使用的产品。

10.1 API

API 是大模型商业化最基础的形态。现代大模型 API 通常支持：

chat completion；
responses；
embeddings；
image understanding；
audio；
structured output；
function calling；
batch；
streaming；
file search；
fine-tuning；
moderation；
evals。

API 的关键不是能调用模型，而是稳定性、文档、版本管理、错误处理、限流、计费、权限和生态兼容。

10.2 SDK

SDK 降低开发者接入成本。成熟供应商通常提供：

Python；
JavaScript / TypeScript；
Java；
Go；
C#；
REST；
CLI；
notebook 示例；
framework integration。

10.3 Model Studio

Model Studio 是可视化开发平台，常见功能包括：

prompt 调试；
模型选择；
参数配置；
知识库构建；
工具绑定；
workflow 编排；
Agent 测试；
批量评测；
部署发布。

国内平台如火山方舟、阿里百炼、百度千帆等，都会强调低代码/可视化的大模型应用开发。

10.4 Knowledge Base

企业知识库平台通常包括：

文件上传；
文档解析；
分块策略；
向量化；
检索；
rerank；
权限过滤；
引用来源；
更新同步；
评测与调优。

它是 RAG 商业化的产品形态。

10.5 Evaluation

大模型评测不再只是 benchmark。商业平台需要支持：

准确性评测；
格式合规；
幻觉检测；
安全评测；
工具调用成功率；
RAG citation 正确性；
Agent 任务完成率；
成本评测；
延迟评测；
回归测试；
A/B 测试。

Evaluation 是大模型应用能否进入生产环境的关键。

10.6 Observability

可观测性包括：

请求日志；
token 用量；
延迟；
错误率；
模型版本；
prompt 版本；
工具调用轨迹；
检索结果；
用户反馈；
成本报表；
安全拦截记录。

没有 observability，就无法调试 RAG、Agent 和生产事故。

10.7 Guardrails

Guardrails 是商业平台中的安全与质量约束层。它可以发生在：

输入前：检测用户请求风险
检索前：权限和数据过滤
生成中：约束格式和工具调用
输出后：安全检测、事实检查、PII 检测
执行前：确认高风险动作

Agent 场景下，guardrails 更重要，因为模型不仅输出文本，还可能调用工具、访问数据或执行操作。

11. 第八层：应用层

应用层是用户直接感知的部分。不同供应商的商业化差异往往体现在应用入口上。

11.1 Chatbot

Chatbot 是最通用入口，例如 ChatGPT、Claude、Gemini、豆包、Kimi、文心一言等。

它的价值是：

低门槛；
高频交互；
用户反馈丰富；
适合展示模型能力；
可以承载文件、图像、语音和工具。

11.2 Copilot

Copilot 指嵌入已有工作流的 AI 助手，例如：

Microsoft 365 Copilot；
GitHub Copilot；
Google Workspace AI；
企业办公助手；
IDE 编程助手。

Copilot 的核心不是让用户打开一个新聊天窗口，而是在原有工具中直接增强工作效率。

11.3 AI Search

AI Search 结合搜索、RAG 和生成式回答。它的优势是信息新、可引用、适合开放域问题。

关键技术包括：

query understanding；
web retrieval；
source ranking；
answer synthesis；
citation；
freshness；
hallucination control。

11.4 Code Assistant

代码助手是大模型最成熟的商业化场景之一。它需要：

代码补全；
仓库理解；
单元测试；
bug 修复；
PR review；
terminal 操作；
issue 理解；
文档生成；
agentic coding。

代码场景特殊之处在于，很多结果可以通过编译、测试和执行验证，因此特别适合强化学习和可验证奖励。

11.5 AI Office

AI Office 面向文档、表格、幻灯片、邮件、会议和日程。

核心能力包括：

总结；
改写；
起草；
表格分析；
PPT 生成；
会议纪要；
邮件回复；
任务跟踪。

这一方向的关键不是单点模型能力，而是与办公软件和企业数据的深度集成。

11.6 AI Customer Service

AI 客服是企业落地高频场景。它需要：

知识库问答；
工单分类；
情绪识别；
多轮澄清；
工具调用；
人工转接；
合规话术；
CRM 集成。

客服场景对稳定性、准确性、权限和可追溯性要求很高。

11.7 Industry Agent

行业 Agent 面向金融、法律、医疗、教育、制造、政务等场景。

核心难点是：

专业知识；
数据权限；
责任边界；
可解释性；
风险控制；
业务系统接入；
监管要求。

行业 Agent 不一定需要最强通用模型，但需要高度可靠的系统工程。

12. 横切层：安全、合规与治理

安全治理贯穿整个技术栈。

12.1 数据安全

包括：

用户数据不用于训练；
企业数据隔离；
加密存储；
访问控制；
数据脱敏；
数据删除；
审计日志；
区域合规。

12.2 内容安全

包括：

有害内容检测；
拒答策略；
敏感信息过滤；
政策合规；
未成年人保护；
版权风险控制。

12.3 Prompt Injection 防御

RAG 和 Agent 特别容易受到 prompt injection 攻击。例如，外部网页或文档可能包含恶意指令，诱导模型泄露数据或调用危险工具。

防御方式包括：

分离系统指令与外部内容；
对检索内容降权；
工具调用前权限检查；
输出前安全审查；
高风险动作人工确认；
instruction hierarchy；
sandbox 执行。

12.4 Agent Security

Agent 安全比普通聊天更复杂，因为 Agent 会执行动作。风险包括：

越权访问；
工具滥用；
数据泄露；
自动化错误操作；
无限循环；
成本失控；
被外部内容操控。

因此商业 Agent 必须具备：

最小权限；
工具白名单；
操作确认；
预算限制；
运行日志；
回滚机制；
沙箱环境；
人类监督。

13. 各层之间的依赖关系

商业化大模型系统不是线性堆叠，而是强耦合系统。

13.1 模型能力依赖数据与训练

没有高质量数据和对齐流程，模型参数再大也无法稳定服务真实用户。

数据质量 → 预训练能力 → 指令遵循 → 偏好对齐 → 产品体验

13.2 应用体验依赖推理系统

同样的模型，低延迟和高稳定性会显著改善用户体验。

KV cache → batching → decoding → routing → 延迟 / 成本 / 可用性

13.3 RAG 依赖检索质量

RAG 的主要失败原因常常不是生成模型差，而是检索不到、检索错、上下文拼接差或权限过滤错误。

文档解析 → chunking → embedding → rerank → context assembly → answer

13.4 Agent 依赖工具与治理

Agent 成功率不只取决于模型是否聪明，还取决于工具描述、错误返回、权限系统、状态管理和日志追踪。

Tool schema → tool selection → execution → observation → recovery → final answer

13.5 商业模式依赖成本结构

API 定价、用户订阅、企业合同和利润率，最终都与推理成本和资源调度相关。

模型大小 → 激活参数 → token 成本 → 延迟 → 价格 → 商业竞争力

14. 不同供应商在技术栈中的侧重点

供应商类型	技术栈重点	典型优势
前沿模型公司	模型层、训练对齐层、推理服务层、Agent 编排	模型能力强，产品迭代快
云厂商	平台层、基础设施层、治理层、企业集成	企业客户、合规、安全、云生态
开源模型公司	模型层、推理部署、社区生态	可部署、可微调、成本可控
应用公司	应用层、编排层、业务数据	场景深、用户体验强
国内互联网厂商	应用入口、模型 API、平台服务、价格竞争	高频场景、中文生态、工程规模
推理服务公司	推理服务层、硬件优化、模型托管	低延迟、高吞吐、成本优化

例如：

OpenAI 强在模型能力、产品化、Agent API 和多模态统一体验；
Anthropic 强在长上下文、安全对齐、代码与企业任务；
Google 强在多模态、搜索生态、TPU/Vertex AI 和云平台；
Microsoft 强在 Azure、Office、GitHub 和企业软件入口；
AWS 强在 Bedrock、多模型平台、企业基础设施和 Guardrails；
字节豆包强在高频产品反馈、低成本 API、内容生态和火山方舟平台；
阿里 Qwen 强在开源模型族、云平台和企业部署；
DeepSeek 强在高性价比 MoE、推理模型和开源扩散；
腾讯混元强在社交、内容、多模态生成和腾讯云集成；
百度文心强在搜索、知识增强和智能云企业服务。

15. 前沿技术趋势总结

15.1 模型族化

未来供应商不会只提供一个模型，而是提供完整模型族：

旗舰模型
快速模型
便宜模型
推理模型
代码模型
多模态模型
Embedding 模型
Reranker 模型
端侧模型
行业模型

模型族化的目标是让不同任务匹配不同成本和能力。

15.2 推理计算成为新瓶颈

过去主要瓶颈是训练，现在推理成本越来越重要。原因是：

用户规模增长；
长上下文增长；
reasoning token 增长；
Agent 多轮调用增长；
多模态输入输出增长。

因此，推理优化、模型路由、缓存、量化和专用硬件会越来越重要。

15.3 MoE 与高性价比模型继续扩散

MoE 已经成为前沿和开源模型的重要路线。它会推动：

更大总参数；
更低激活成本；
更复杂 serving；
更强路由优化；
更高工程门槛。

15.4 Reasoning RL 成为核心竞争点

数学、代码、复杂规划、科研和企业分析都需要更强推理。未来模型竞争会从“语言流畅”进一步转向：

能否正确推理；
能否验证中间结果；
能否调用工具；
能否发现错误；
能否完成长任务。

15.5 RAG 走向 Agentic RAG

传统 RAG 是一次检索，一次回答。Agentic RAG 会变成：

分析问题 → 规划检索 → 多轮查询 → 结构化证据 → 交叉验证 → 生成答案

这更适合复杂企业知识任务。

15.6 工具协议化与 Agent 基础设施化

MCP 代表一种趋势：模型与工具之间的连接需要标准协议。未来 Agent 生态可能会围绕：

工具注册；
权限传递；
schema 描述；
错误语义；
日志追踪；
安全边界；
成本预算。

15.7 多模态从“看懂”走向“操作”

多模态模型未来不只是理解图片，而是：

看屏幕；
读文档；
听语音；
理解视频；
操作软件；
生成图像和视频；
完成跨模态任务。

这会推动大模型从语言助手变成数字工作环境中的操作主体。

15.8 企业治理成为商业落地门槛

企业采用大模型时，最关心的不只是模型强不强，还包括：

数据是否安全；
权限是否可控；
成本是否可预测；
输出是否可审计；
错误是否可追踪；
是否符合合规要求；
能否接入现有系统。

因此，平台层和治理层会越来越重要。

16. 后续笔记建议

理解本篇后，后续底层技术可以按以下顺序展开：

02_Transformer与大模型基础.md
03_预训练数据与数据工程.md
04_指令微调与偏好对齐.md
05_RLHF_RLAIF_DPO与推理强化.md
06_Dense模型与MoE模型.md
07_长上下文技术.md
08_多模态大模型技术路线.md
09_大模型推理加速与Serving系统.md
10_RAG系统原理.md
11_Agent系统原理.md
12_大模型评测与安全治理.md

推荐优先顺序是：

先写 Transformer与大模型基础，打牢模型架构底座；
再写预训练数据与数据工程，理解模型能力来源；
再写指令微调与偏好对齐，理解 ChatGPT 类产品为什么可用；
再写大模型推理加速与Serving系统，理解商业化成本；
最后写 RAG系统原理和 Agent系统原理，进入企业应用和平台编排。

17. 本篇小结

商业化大模型服务不能被理解为单个模型，而应被理解为一套完整技术栈：

基础设施 → 数据 → 模型 → 训练对齐 → 推理服务 → 编排 → 平台 → 应用 → 治理

其中：

Transformer 解决了大规模序列建模的架构问题；
Scaling law 和数据工程解决了模型能力扩展问题；
SFT、RLHF、DPO 和 reasoning RL 解决了模型对齐和复杂推理问题；
FlashAttention、vLLM、SGLang、量化和 speculative decoding 解决了服务效率问题；
RAG 解决了外部知识和企业数据接入问题；
function calling、ReAct、Toolformer、MCP 和 Agent 解决了模型连接工具与执行任务的问题；
平台层和治理层解决了商业交付、企业集成和安全合规问题。

后续分析任何供应商时，都可以回到这张技术栈地图，判断它到底强在哪一层、弱在哪一层，以及它的商业化护城河来自模型能力、基础设施、应用入口、企业平台，还是生态整合。

参考资料

Vaswani et al., 2017. Attention Is All You Need.
Lewis et al., 2020. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
Fedus et al., 2021. Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity.
Ouyang et al., 2022. Training language models to follow instructions with human feedback.
Hoffmann et al., 2022. Training Compute-Optimal Large Language Models.
Dao et al., 2022. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness.
Yao et al., 2022. ReAct: Synergizing Reasoning and Acting in Language Models.
Schick et al., 2023. Toolformer: Language Models Can Teach Themselves to Use Tools.
Rafailov et al., 2023. Direct Preference Optimization: Your Language Model is Secretly a Reward Model.
Kwon et al., 2023. Efficient Memory Management for Large Language Model Serving with PagedAttention.
Jiang et al., 2024. Mixtral of Experts.
Zheng et al., 2024. SGLang: Efficient Execution of Structured Language Model Programs.
DeepSeek-AI, 2024. DeepSeek-V3 Technical Report.
DeepSeek-AI, 2025. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning.
OpenAI Platform Documentation: Responses API, Structured Outputs, Tools.
Anthropic Documentation: Claude Tool Use, Computer Use, Model Context Protocol.
Google Gemini / Vertex AI Documentation: Function Calling, Model APIs, Agent-related platform capabilities.
AWS Bedrock Documentation: Agents, Knowledge Bases, Guardrails.