企业大模型技术与解决方案实战

企业大模型技术与解决方案实战

面向火山引擎 AI / 大模型解决方案团队的 10 小时内部培训教材（训练、推理与开放权重模型增强版）

内部培训版

研究基线：2026-09-01

内部培训使用
本教材用于团队能力建设，不构成任何产品能力、价格、路线图或客户交付承诺。涉及模型版本、规格、价格和 Benchmark 的内容具有时效性，正式方案以执行时的官方文档、合同和实测结果为准。

导读：这本书真正要训练什么

这不是一本“大模型名词百科”，也不是把算法论文改写成中文。它面向需要站在客户、模型、平台和基础设施之间做判断的解决方案架构师。

客户很少会直接问：“请解释 Transformer。”客户更可能问：

• 为什么榜单更高的模型，在我们的 PoC 中反而更差？
• 为什么明明检索到了正确文档，知识库仍然答错？
• 为什么模型每秒输出 Token 很多，用户还是觉得慢？
• 为什么 H20、H100 和 B 系列运行同一模型差距很大？
• 为什么 Agent 演示时很好，一上生产就经常中断？
• 为什么 Token 单价已经下降，最终账单仍然失控？
• 为什么视频生成 1080P 不一定比 720P 更可用？

因此，全书始终沿着同一条链路展开：

客户业务问题 → 技术问题 → 模型能力 → Context / RAG / Tool / Agent → 推理系统 → GPU / Infra → 安全与成本 → 业务价值。

1. 五项培训目标

2. 三级学习路径

• [基础]：所有成员必须理解。能够回答“它是什么”。
• [进阶]：成熟 SA 必须掌握。能够回答“为什么这样工作、有什么 Trade-off”。
• [高级]：技术骨干建议掌握。能够回答“如何影响性能、成本、部署和架构决策”。

同一个知识点不分成三本教材，而是提供三个入口。例如：

3. 10 小时授课安排

教材深度高于课堂时长。课堂重点讲“认知模型、因果链、诊断方法和决策树”；算法细节、扩展术语和更多案例用于课后查阅。

第 0 章：2026 年的大模型技术版图

本章要解决的问题

为什么团队不能继续用 2023 年的“聊天机器人 + RAG”框架理解 2026 年的大模型？哪些知识仍然是底座，哪些行业叙事已经失去决策价值？

0.1 从“回答问题”到“完成工作”

截至 2026 年 9 月，前沿模型厂商的公开定位高度趋同：模型要能够处理更长的任务、调用工具、操作软件、完成代码工程和专业知识工作。OpenAI 的最新模型指导将 GPT-5.6 定位为复杂生产工作流的质量与效率基线；Anthropic 的 Opus 5 强调长时间运行的 Agent、Coding 和专业工作；Google 的 Gemini 3.7 Flash 重点面向 Coding 与 Agent；ByteDance Seed2.1 面向生产力、Agent 和代码工程；DeepSeek V4 同时提供 Thinking / Non-thinking 与 1M Context 的产品形态。OpenAI, 2026；Anthropic, 2026；Google DeepMind, 2026；ByteDance Seed, 2026；DeepSeek, 2026

这里最重要的不是“谁的模型第一”，而是产品竞争的基本单元已经发生变化：

过去：Prompt → Model → Answer
现在：Goal → Context → Model → Tool / Environment → Observation → Verify → Continue

模型能力仍然重要，但企业最终体验越来越由 Model + Context + Harness + Tool + Runtime + Governance 共同决定。

0.2 未来 1–2 年 SA 最值得掌握的 32 个变化

1. Reasoning 从“专用模型”转向可配置预算和动态路由。
2. Thinking Token 被纳入质量、延迟和成本统一管理。
3. RLVR 让数学、代码和可验证任务成为强化学习的高收益区。
4. Agent 能力从单次 Tool Call 转向长轨迹任务完成。
5. Harness Design 成为 Agent 能力的重要组成部分。
6. Coding Agent 成为 Agent 生产化最成熟的验证场。
7. Repository Context 从“把全仓塞进去”转向按需、分层和 Just-in-time 获取。
8. Sandbox 从开发工具升级为 Agent 基础设施和安全边界。
9. MCP 解决 Agent 与工具/资源的标准连接问题。
10. A2A 解决不同 Agent 系统间的发现、任务和互操作问题。
11. Long Context 与 RAG 不再是二选一，而是分层协同。
12. Context Engineering 的重要性超过单纯 Prompt Engineering。
13. 检索系统从纯向量召回转向 Dense + Sparse + Metadata + Rerank。
14. Benchmark 从知识考试转向 Coding、Computer Use、Tool Use 和专业工作。
15. Live Benchmark 用持续更新降低测试集污染。
16. 模型评测的最小单位从“答案”转向“完整任务轨迹”。
17. 推理系统的核心瓶颈从计算量延伸到 KV、调度、通信和尾延迟。
18. Prefill 与 Decode 的资源形态进一步解耦。
19. Disaggregated Serving 让两阶段可使用不同的实例与调度策略。
20. Prefix Cache 成为固定 System Prompt、长会话和多 Agent 场景的重要杠杆。
21. Continuous Batching 成为在线 Serving 的基本能力。
22. Paged KV 管理降低显存碎片和保守预分配。
23. FP4 等低精度开始从“压缩权重”进入硬件原生计算路径。
24. MoE 的决策重点从总参数量转向激活参数、通信和 Expert Parallel。
25. 多模态理解从图片扩展到音频、视频和屏幕操作。
26. 视频生成从单镜头美学转向多模态参考、编辑、音画联合与长叙事。
27. 生成视频的核心成本指标从“每秒价格”转向“每条可用素材成本”。
28. Model Gateway 从 API 转发层升级为路由、缓存、治理和成本控制中心。
29. 企业安全从内容审核扩展到 Prompt Injection、Tool Abuse、身份与供应链。
30. 选型指标从 Token 单价升级为 Cost per Successful Task。
31. 训练系统能力从“会启动任务”升级为对显存、并行、通信、容错和 Rollout 的联合优化。
32. Model Card 阅读成为 SA 基础能力：Total、Active、Attention、Context、Precision 和 License 必须翻译成工程含义。

0.3 已经过时或重要性下降的认知

0.4 最容易被行业宣传误导的概念

• “1M Context”：表示接口可接收的上限，不等于模型能可靠利用全部信息，也不等于 TTFT 和 KV 成本可忽略。
• “Thinking”：表示模型投入了额外推理过程，不保证更长过程必然更正确。
• “Open Source”：需要区分公开权重、公开代码、公开数据、训练配方和许可证。
• “FP4”：位宽减半不意味着真实端到端性能自动翻倍，硬件、Kernel、Scale 和精度保持缺一不可。
• “Agent”：会调用工具不等于能稳定完成长任务。
• “1080P / 2K”：分辨率是像素规格，不是人物一致性、文字准确性和商品真实性。
• “SWE-bench 分数”：分数强依赖模型、Prompt、Harness、工具、测试环境和评测版本。

本章 SA 结论

面对任何新品，不要先问“它是不是最强”，而应沿六层检查：①模型基础能力；②后训练或推理预算；③ Context 与 Tool；④ Harness 与验证闭环；⑤ Serving、硬件与成本；⑥对客户成功任务率的可验证影响。

第 1 章：大模型到底是什么

本章要解决的客户问题

“模型参数里是不是存着互联网？”
“为什么模型会一个字一个字输出？”
“参数更大、Context 更长，是不是效果一定更好？”

本章前置知识

不要求掌握线性代数推导，不要求会训练模型。只需要理解：计算机把文字转成数字，神经网络通过大量权重对数字做变换。

1.1 [基础] 从“下一 Token 预测”建立统一模型

大语言模型最核心的动作可以概括为：根据已有上下文，预测下一个 Token 的概率分布。

例如输入“北京是中国的”，模型不会从数据库里查出完整句子，而会计算候选 Token 的概率：“首都”可能很高，“城市”次之，“香蕉”很低。选出一个 Token 后，它被追加到上下文，模型再预测下一步。

这解释了三个常见现象：

1. 输出是逐步产生的，因为每一步依赖前一步结果。
2. 模型可能出现事实错误，因为它优化的是“概率上合理的续写”，不是数据库约束下的精确查询。
3. Temperature、Top-p 等采样参数会改变输出多样性，因为它们改变如何从概率分布中选择 Token。

术语卡：Token

术语卡：Autoregressive Generation

1.2 [基础] Embedding：模型为什么能计算文字

计算单元不能直接理解“客户”“合同”“视频”这些词。Embedding 的作用，是把离散 Token 映射到连续向量空间。向量不是字典释义，而是模型训练中形成的可计算表示。

需要区分两个常被混淆的概念：

• LLM 内部 Embedding Layer：把 Token ID 转成模型内部表示。
• Embedding Model：把句子或文档转成用于语义检索、聚类、匹配的向量。

它们都叫 Embedding，但用途、训练目标和输出形态不同。

1.3 [进阶] Transformer：Attention 与 FFN 的分工

2017 年的 Transformer 论文提出以 Attention 为核心、摆脱循环结构的序列模型架构，并显著提高了并行训练能力。Vaswani et al., 2017

一个简化的 Transformer Block 可以理解为：

输入表示
  ↓
Self-Attention：从上下文读取相关信息
  ↓
Residual + Normalization：保留原信息并稳定训练
  ↓
FFN：对每个位置进行非线性特征变换
  ↓
Residual + Normalization

Q、K、V 的通俗解释

• Query（Q）：当前位置在找什么。
• Key（K）：每个历史位置可以用什么特征被匹配。
• Value（V）：匹配后真正取回的信息。

在“张三把合同发给李四，因为他需要审核”中，“他”指谁取决于上下文关系。Attention 让模型针对当前 Token 动态计算哪些位置更重要。

为什么要 Multi-Head Attention

单一 Attention 关系很难同时表达语法、指代、主题、位置和逻辑关系。Multi-Head 让多个子空间并行学习不同关系。不要把每个 Head 简化为一个固定的人类可解释功能；它更像多个并行的信息读取通道。

FFN 为什么重要

Attention 负责“从哪里取信息”，FFN 更像“取回来以后如何变换”。现代 LLM 中 FFN 往往占据大量参数和计算；MoE 通常主要把 FFN 部分拆成多个专家。

1.4 [进阶] 参数到底存了什么

模型参数是训练过程中为了降低预测误差而调整的大量数值权重。它们共同编码语言模式、事实相关性、技能和行为倾向，但不是一张可逐条读取的知识表。

因此：

• 参数记忆可能是模糊、分布式的；
• 多个事实可能共享或干扰相同参数区域；
• 模型可能“知道”某个事实，却因为 Prompt、Context 或后训练行为没有正确输出；
• 通过 Fine-tuning 写入动态知识，更新和删除都不如外部知识库可控。

1.5 [进阶] Dense 与 MoE

错误问法：“600B MoE 是不是比 300B Dense 慢一倍？”
正确问法：“每个 Token 激活多少参数？专家如何跨卡分布？通信是否成为瓶颈？”

1.6 [高级] Scaling Law：参数不是唯一变量

Scaling Law 描述模型损失随模型规模、训练数据和计算预算变化的经验规律。Chinchilla 工作指出，在固定训练计算下，模型规模和训练 Token 数需要更平衡地增长；较小但训练更充分的模型可能优于更大但数据不足的模型。Hoffmann et al., 2022

对 SA 最重要的结论不是背公式，而是：

1. 模型大小必须与数据和训练预算配套。
2. 参数规模不能替代数据质量、后训练和任务匹配。
3. 只优化训练成本不够，还要考虑生命周期内的推理需求。
4. 2026 年能力增长越来越来自 Pre-training + Post-training + Test-time Compute + Tool/Environment 的组合。

1.7 Context Window：能放进去，不等于能用好

Context Window 是一次请求中模型可处理的 Token 上限。它至少有四个不同层面的含义：

1. 接口上限：API 是否允许提交这么长。
2. 模型训练能力：模型是否针对长序列训练或扩展。
3. 有效利用能力：关键信息在不同位置时，模型是否稳定找到并正确使用。
4. 系统经济性：长输入带来的 Prefill、KV Cache、TTFT 和费用是否可接受。

因此，“支持 1M Context”不能直接推出“可以把整个企业知识库放进去”。

1.8 常见误区

1.9 客户问题：参数更大是不是一定更好

普通回答：通常更大的模型能力更强，但不是绝对。

专业 SA 回答：参数量只是能力先验。还要看 Dense/MoE、激活参数、训练 Token、数据质量、后训练、上下文和工具。客户选型应使用自己的任务集评测质量、延迟和成本。

更深一层：最终业务效果可用以下 Mental Model 表达：

Business Quality
≈ Model Capability
× Context Quality
× Tool / Environment Reliability
× Evaluation Fit

任何一项接近零，换更大模型也可能没有明显收益。

继续追问客户：

• 任务是知识问答、代码、抽取、推理还是生成？
• 错误是事实错误、格式错误、漏信息还是任务未完成？
• 当前 Prompt、上下文和工具是否完全相同？
• 是否比较了成功任务成本，而不只是单次 Token 价格？

1.10 本章 Decision Tree

客户问“模型强不强”
  ├─ 任务是否明确？否 → 先定义任务和失败
  ├─ 是否需要外部知识？是 → 同时评估 RAG / Tool
  ├─ 是否是长任务？是 → 评估 Agent Harness 与验证
  ├─ 是否有强时延约束？是 → 看模型档位与 Reasoning Budget
  └─ 用客户真实样本做质量、延迟、成本三维 PoC

本章测试题与参考答案

1. 为什么聊天模型通常逐 Token 输出？
   因为自回归生成的下一步依赖已经生成的历史，每一步都要重新执行一次 Decode。
2. Attention 和 FFN 的简化分工是什么？
   Attention 动态读取上下文，FFN 对读取后的表示做非线性变换。
3. MoE 总参数为什么不能直接代表每 Token 成本？
   因为每个 Token 只激活部分 Expert，实际计算取决于激活参数和通信。
4. Context Window 的四层含义是什么？
   接口上限、训练能力、有效利用能力和系统经济性。
5. 为什么模型参数不适合承担频繁变化的企业事实？
   更新、删除、追溯和权限控制都不如外部知识系统可控。

延伸阅读

• Attention Is All You Need, 2017
• Training Compute-Optimal Large Language Models, 2022
• DeepSeek V4 Preview：总参数与激活参数示例, 2026
  

第 2 章：模型是怎么训练出来的

本章要解决的客户问题

“预训练后模型已经会回答问题，为什么还需要 SFT？”
“RLHF、DPO、GRPO 到底改变了什么？”
“客户知识更新，为什么不建议直接 Fine-tune？”

本章前置知识

需要理解 Token、自回归生成和参数。无需掌握强化学习数学推导；本章重点是不同训练阶段对模型行为的影响。

2.1 一张图理解完整训练链

原始数据
  ↓ 数据清洗、去重、质量分层、混合配比
Pre-training
  ↓ 形成基础语言、知识、代码、视觉和模式能力
SFT / Instruction Tuning
  ↓ 学会按照指令、格式和角色进行输出
Preference Optimization
  ↓ 学会更符合人类偏好、规则和安全要求
Reasoning RL / RLVR
  ↓ 在可验证任务上强化搜索、反思和正确答案
Distillation / Domain Adaptation
  ↓ 把能力迁移到更小模型或特定场景
Agent RL
  ↓ 在环境中通过多步动作完成任务

每个阶段解决的问题不同。把所有效果问题都归结为“再训一次”，就像把所有软件问题都归结为“重写代码”：成本很高，而且经常解决错问题。

2.2 [基础] Pre-training：模型为什么会“知道很多”

Pre-training 通常使用海量文本、代码和多模态数据，让模型学习预测下一个 Token 或相关训练目标。它不需要为每条数据人工标注“正确答案”，因此被称为自监督学习。

模型在训练中不断压缩数据中的统计结构：

• 哪些词通常一起出现；
• 语法和篇章如何组织；
• 事实之间有哪些关联；
• 代码语法、库调用和常见模式；
• 不同语言之间如何对应；
• 图像、音频、视频与文字如何关联。

重要边界：Pre-training 学到的是概率结构，不是对每个事实建立可审计记录。它能形成强大的泛化能力，也会继承数据中的错误、偏见和时效性问题。

数据质量比“数据越多越好”更重要

企业团队容易只看到“训练了多少万亿 Token”，但需要继续问：

1. 数据是否去重？重复数据会增加记忆和污染风险。
2. 高质量代码、数学、专业资料占比是多少？
3. 多语言数据是否平衡？
4. 合成数据如何生成、过滤和验证？
5. 数据时间窗口和新鲜度是什么？
6. 版权、隐私和许可证如何管理？

训练数据不只是原料，也是模型能力边界和风险边界。

2.3 [基础] SFT：把“会续写”变成“会按要求工作”

SFT（Supervised Fine-Tuning，监督微调）使用高质量的“输入—理想输出”样本继续训练模型。

例如基础模型看到：

用户：把下面合同条款提取成 JSON。
助手：{"party_a": ..., "term": ...}

反复学习后，它更容易理解对话角色、遵循指令并输出指定格式。

SFT 最适合改变什么

• 任务格式：JSON、表格、固定字段；
• 回答风格：简洁、专业、特定语气；
• 稳定技能：特定分类、抽取、改写模式；
• 工具调用样式：何时选择哪个函数、如何填参数；
• 领域表达：术语、文风和业务流程。

SFT 不擅长解决什么

• 每天变化的产品价格、库存、政策；
• 需要严格权限控制的企业知识；
• 数据量很少但任务复杂的场景；
• 外部系统执行和实时状态；
• 根因其实是检索、Prompt 或工具失败的问题。

2.4 Fine-tuning、LoRA 与全量微调

SA 原则：先用 Prompt、Context、RAG 和 Tool 证明任务可行，再判断是否需要微调。Fine-tuning 是能力工程手段，不是需求不清时的默认答案。

2.5 [基础] 一个训练步骤到底发生了什么

解决方案架构师不需要推导反向传播，但必须知道一次训练迭代为什么会同时消耗计算、显存、网络和存储。

读取一批训练样本
  ↓ Tokenize / Pack / Build Batch
Forward：模型产生预测
  ↓
Loss：预测与训练目标之间的误差
  ↓
Backward：把误差逐层传回，计算 Gradient
  ↓
Gradient Synchronization：多卡汇总或切分梯度
  ↓
Optimizer Step：根据梯度更新参数
  ↓
清理 / 累积状态，进入下一步

术语卡：Batch 与 Micro-batch

术语卡：Gradient

术语卡：Optimizer

2.6 [进阶] 训练显存由什么组成

训练时显存通常包括：

1. Model Parameters：模型权重；
2. Gradients：反向传播产生的梯度；
3. Optimizer States：例如 Adam 的一阶和二阶动量；
4. Master Weights：部分混合精度方案保留的 FP32 参数副本；
5. Activations：Forward 中为 Backward 保留的中间结果；
6. Communication Buffers：All-Reduce、All-Gather、Reduce-Scatter 等通信缓冲；
7. Temporary Workspace：Attention、GEMM、MoE 等 Kernel 的临时空间；
8. Allocator Fragmentation：显存分配碎片和框架保留空间。

一个用于数量级判断的简化式是：

Training Memory
≈ Parameters + Gradients + Optimizer States
  + Master Weights + Activations + Buffers + Workspace

70B 模型的数量级示例

假设有 70B 参数，经典混合精度 Adam 实现中采用：

• BF16 权重：2 Bytes / 参数；
• BF16 梯度：2 Bytes / 参数；
• FP32 Master Weights：4 Bytes / 参数；
• Adam m、v：各 4 Bytes / 参数。

则模型状态的粗略数量级为：

(2 + 2 + 4 + 4 + 4) Bytes × 70B
≈ 1.12 TB

这还没有计入 Activation、通信 Buffer、临时 Workspace 和碎片。不同框架、优化器、精度和分片方式会改变数字，因此这不是固定报价公式，而是用于识别“70B 权重 140GB，所以两张 80GB 卡就能全量训练”这一错误判断。

LoRA 为什么省显存，但不是“几乎不占显存”

LoRA 只为部分线性层增加低秩可训练增量，因此显著减少：

• 可训练参数；
• 对应梯度；
• 对应优化器状态。

但以下部分仍然存在：

• 基础模型权重仍需加载；
• Forward / Backward 的 Activation 仍需保存或重算；
• 长序列、较大 Micro-batch 仍会推高显存；
• 多卡通信、临时 Workspace 和框架开销不会自动消失。

因此，LoRA 主要改变“模型状态显存”，不完全解决“Activation 显存”和“吞吐”问题。

2.7 [进阶] 四类常用训练显存与效率优化

Mixed Precision 不是简单“把所有数据改成低精度”

现代训练通常在不同对象上使用不同精度：

• 计算可能使用 BF16 / FP8；
• 部分累积或归一化保留更高精度；
• Master Weights 可能保留 FP32；
• 梯度通信可选择 BF16 或 FP32；
• 特殊层和不稳定算子可能回退到较高精度。

因此，低精度收益来自 模型训练配方 × GPU 原生能力 × Transformer Engine / Kernel × Scale 策略，不是更改一个文件格式。

Activation Checkpointing 的直觉

不做 Checkpoint：Forward 保存更多中间结果 → Backward 直接读取
做 Checkpoint：Forward 只保存少数节点 → Backward 重新做部分 Forward

它是典型的“计算换显存”。如果 GPU 算力富余、显存紧张，通常有价值；如果训练已经受计算限制，过度重算会显著拉长周期。

2.8 [进阶] 分布式训练：先问“切哪一个维度”

NVIDIA Megatron Core 的并行指南明确将 DP、TP、PP、CP、EP 和 FSDP 视为可以组合的正交策略，而不是互相替代的单选项。Megatron Core Parallelism Guide, 2026

四种 Collective Communication 要能听懂

• All-Reduce：各卡先聚合，再都获得相同结果；常见于梯度同步。
• Reduce-Scatter：先聚合，再把结果的不同分片分给各卡；常用于梯度/状态分片。
• All-Gather：每张卡拿到其他卡的分片，拼成完整对象；FSDP / ZeRO-3 常在计算前重建参数。
• All-to-All：不同卡互相发送不同数据；MoE Expert Routing 的典型通信。

SA 不需要手写 NCCL 配置，但必须知道：TP 和 EP 的扩展效果高度依赖网络拓扑；“再加一倍 GPU”可能同时增加更多通信。

2.9 [进阶] ZeRO 与 FSDP：它们到底切分了什么

传统 Data Parallel 中，每个训练进程通常都保存完整权重、梯度和优化器状态。ZeRO / FSDP 的核心思路是：让 Data Parallel Rank 只长期保存其中一部分，需要计算时再聚合。

DeepSpeed 将 ZeRO 的目标描述为分阶段消除数据并行中的模型状态冗余；Megatron-FSDP 也提供与 ZeRO-1/2/3 概念接近的状态分片模式。DeepSpeed ZeRO；Megatron-FSDP, 2026

ZeRO/FSDP 与 TP 不是同一个问题

• TP 把一个层的矩阵计算切开，让超大层能够计算；
• ZeRO/FSDP 把 Data Parallel 中重复保存的模型状态切开；
• 二者可以组合，但会同时引入不同通信；
• 最优方案取决于模型结构、节点内互联、节点间网络、序列长度和训练规模。

2.10 [高级] 为什么增加 GPU 不一定线性加速

理想情况下，GPU 翻倍，训练时间减半。但现实中存在：

1. 梯度、参数、Activation 和 Expert 的通信；
2. Pipeline Bubble；
3. Data Loader 或分布式存储供数不足；
4. 不同 GPU 或样本长度导致 Straggler；
5. Checkpoint 写入与恢复；
6. 小 Micro-batch 无法充分利用 Tensor Core；
7. 训练框架和 Kernel 未命中最优路径；
8. 故障、重试和集群调度损失。

术语卡：MFU

Strong Scaling 与 Weak Scaling

• Strong Scaling：固定总工作量，增加 GPU，观察时间缩短多少。
• Weak Scaling：每张 GPU 的工作量大致不变，增加 GPU 同时扩大总任务，观察效率是否保持。

客户说“扩到 1,000 卡效率下降”时，需要先确认讨论的是哪一种 Scaling。

训练性能诊断顺序

训练慢 / 利用率低
  ↓
先看每步耗时分解：Data → Forward → Backward → Communication → Optimizer → Checkpoint
  ↓
再看 GPU Compute、HBM、Network、Storage、CPU 与 Data Loader
  ↓
确认 Micro-batch、Sequence Length、并行拓扑和重算策略
  ↓
最后才决定换 GPU、改并行度或改训练框架

2.11 [高级] Reasoning / Agent RL 的训练系统为什么更复杂

Reasoning RL 不只是“训练器多跑几步”，它通常引入大规模生成：

Prompt / Task
  ↓
Rollout Engine 批量生成多个轨迹
  ↓
Verifier / Reward 计算得分
  ↓
过滤、分组、构造 Advantage
  ↓
Trainer 更新 Policy
  ↓
新权重同步到 Rollout Engine

这里可能出现新的瓶颈：

• Rollout 生成比参数更新更慢；
• 长 Thinking 轨迹带来大量 Decode 成本；
• Verifier 或 Sandbox 执行成为瓶颈；
• Policy 更新后，旧 Rollout 与新 Policy 存在 Staleness；
• 训练器和推理引擎需要共享或快速同步权重；
• Agent 环境需要并发隔离、复位、回放和可验证结果。

对 SA 的能力边界

全员不需要配置 Megatron、NCCL 或 CUDA Kernel，但应该能：

1. 解释训练显存为什么远高于权重；
2. 判断客户需要 Pre-training、SFT、LoRA、RL，还是其实只需要 RAG/Tool；
3. 看懂 DP、TP、PP、CP、EP、ZeRO/FSDP 各在切什么；
4. 识别计算、通信、存储和数据中的主要风险；
5. 给训练 PoC 设计资源、指标、退出条件，而不是直接承诺训练周期。

2.12 [进阶] RLHF：为什么有了 SFT 还需要偏好对齐

SFT 要求存在一个“理想答案”，但很多任务没有唯一答案。例如两份总结都事实正确，哪一份更清晰、更有帮助？偏好数据可以让标注者比较 A/B 回答，而不必逐字写出完美答案。

InstructGPT 展示了经典 RLHF 流程：

1. 使用人工示范数据做 SFT；
2. 对同一 Prompt 采样多个回答；
3. 人工排序回答，训练 Reward Model；
4. 使用 PPO 等强化学习方法，让策略模型获得更高奖励，同时避免偏离原模型过远。Ouyang et al., 2022

术语卡：Reward Model

术语卡：PPO

2.13 [进阶] DPO：把偏好优化变得更直接

DPO（Direct Preference Optimization）使用“更优回答 / 更差回答”对，直接提升模型对优选回答的相对概率，不显式训练 Reward Model，也不需要完整的在线 RL 循环。原论文显示，DPO 可以用更简单的训练流程获得有竞争力的偏好对齐效果。Rafailov et al., 2023

DPO 的价值与边界

• 价值：工程简单、稳定、复现成本相对低。
• 边界：依赖高质量偏好对；偏好数据中的长度、风格和标注偏差会被学到；它不是所有复杂推理和 Agent 环境的替代品。

2.14 [进阶] GRPO：为什么它在 Reasoning 模型中流行

GRPO（Group Relative Policy Optimization）由 DeepSeekMath 公开提出。核心直觉是：对同一道题采样一组回答，用组内相对奖励估计哪些回答更好，从而减少对单独 Value Model 的依赖。Shao et al., 2024

用一个例子理解

对数学题采样 8 个答案：

• 3 个最终答案正确；
• 5 个错误；
• 通过规则自动验证最终答案。

GRPO 不要求人工写出每一步标准推理，而是利用组内结果差异更新策略。模型逐渐提高产生可验证正确答案的概率。

为什么“相对奖励”有效

绝对奖励的尺度可能不稳定，但在同一道题的一组回答中，“谁更好”通常更容易比较。它降低部分资源开销，但没有消除强化学习的其他难点：采样成本、奖励设计、训练稳定、分布偏移仍然存在。

2.15 [进阶] RLVR：代码与数学为什么特别适合强化学习

RLVR（Reinforcement Learning with Verifiable Rewards）使用可自动验证的结果作为奖励。

DeepSeek-R1 的公开工作显示，强化学习可以激励模型形成反思、验证和策略调整等推理行为；但 R1 也采用冷启动数据和多阶段训练改善可读性与通用性，而不是简单“纯 RL 解决全部问题”。Guo et al., 2025

RLVR 的两个核心前提

1. 奖励可靠：测试本身不能有漏洞，不能让模型钻空子。
2. 任务可探索：模型要有机会采样到一部分正确轨迹，否则奖励过于稀疏。

2.16 [高级] Process Reward 与 Outcome Reward

• Outcome Reward：只看最终答案是否正确。
• Process Reward：对中间步骤、局部推理或动作进行评价。

Outcome Reward 简单、客观，但可能无法告诉模型哪里错了；Process Reward 信息密度高，但标注和验证成本高，也可能把某一种“标准推理写法”错误地当成唯一正确过程。

企业 Agent 中常采用混合设计：

最终业务状态奖励
+ 工具调用合法性奖励
+ 中间检查点奖励
- 高风险动作惩罚
- 无效循环和资源浪费惩罚

2.17 [高级] Agent RL 为什么比问答 RL 难

问答任务通常是单回合：输入 → 输出 → 得分。

Agent 任务是长轨迹：

状态 S0
→ 动作 A1
→ 环境变成 S1
→ 动作 A2
→ ...
→ 最终成功或失败

难点包括：

• Credit Assignment：最终失败由哪一步造成？
• Sparse Reward：几十步后才知道成功与否。
• Environment Variance：网页、API、权限和数据会变化。
• Irreversible Action：发邮件、删除数据、下单不能随意试错。
• Long-horizon Error Accumulation：单步成功率高，也会随步数累积失败。

因此，生产 Agent 不能只依赖更强模型，还要设计环境、工具、检查点、回滚和人工审批。

2.18 能力变化对照表

2.19 客户问题：知识更新为什么不直接 Fine-tune

普通回答：微调更适合教行为，不适合频繁变化的事实。

专业 SA 回答：动态知识需要最新、可追溯、可删除和按权限访问。RAG 或 Tool 把知识保存在外部系统，更容易更新和审计；SFT 更适合稳定的格式、风格和领域技能。

更深一层：先按四个变量判断：

2.20 训练方案 Decision Tree

客户说“效果不好”
  ├─ 是知识缺失/过期？ → RAG / Tool
  ├─ 是格式和风格不稳定？ → Prompt → SFT / LoRA
  ├─ 是偏好问题？ → 偏好数据 → DPO / RLHF
  ├─ 是可验证推理任务？ → RLVR / Reasoning RL
  ├─ 是工具长任务？ → 先改 Harness / Environment，再考虑 Agent RL
  └─ 数据量和评测不够？ → 先建立 Dataset + Eval，不进入训练

本章测试题与参考答案

1. Pre-training 与 SFT 最核心的区别是什么？
   前者形成基础预测与知识能力，后者塑造按指令完成任务的行为。
2. DPO 为什么比经典 RLHF 流程更简单？
   它直接用偏好对优化策略，不显式训练 Reward Model 和运行完整 PPO 循环。
3. GRPO 为什么适合一题多采样的推理训练？
   它利用组内相对奖励估计回答优劣，降低对 Value Model 的依赖。
4. RLVR 的两个必要条件是什么？
   可靠验证器和模型可探索到正奖励轨迹的能力。
5. 为什么 Agent RL 更难？
   长轨迹、稀疏奖励、环境变化、不可逆动作和错误累积。

延伸阅读

• Training Language Models to Follow Instructions with Human Feedback, 2022
• Direct Preference Optimization, 2023
• DeepSeekMath / GRPO, 2024
• DeepSeek-R1, 2025
  

第 3 章：Reasoning 与 Test-time Compute

本章要解决的客户问题

“Thinking 模型是不是一定更聪明？”
“为什么同一个问题多想一会儿有时更好，有时反而更差？”
“Reasoning Token 应该怎么控制成本？”

本章前置知识

需要理解自回归生成、SFT、RLVR 和 Verifier 的基本概念。

3.1 [基础] Reasoning 不是一个神秘模块

在产品层面，Reasoning Model 通常会在最终答案前消耗更多计算，用于问题分解、候选搜索、检查、工具调用或更长的内部推理轨迹。

需要避免两个极端：

• 极端一：“模型只是统计续写，所以不存在任何推理能力。”
• 极端二：“输出了一段思考文字，就等于拥有可靠的人类思维过程。”

更实用的工程定义是：模型能否在复杂任务中，通过额外计算提高可验证正确率和任务完成率。

3.2 Chain of Thought、Thinking 与最终答案

Chain of Thought（CoT）指模型生成中间推理步骤。它可能帮助模型分解问题，但不能把自然语言推理轨迹自动当成真实、完整、因果忠实的内部过程。

对企业系统而言，应关注：

1. 最终答案是否正确；
2. 证据和工具结果是否可验证；
3. 推理过程是否泄露敏感信息；
4. 是否需要向用户展示过程；
5. 过程是否增加不必要 Token。

很多系统会把详细内部推理与面向用户的简洁解释分开：用户需要可核验的依据，不一定需要全部原始思考轨迹。

3.3 [进阶] Test-time Compute 的五种形态

Qwen3 的公开技术报告将 Thinking 与 Non-thinking 整合在统一模型框架中，允许按任务动态控制思考模式。这说明“是否思考”正在从模型选择问题，转为运行时预算分配问题。Qwen Team, 2025

3.4 [进阶] 为什么更多 Thinking Token 有时无效

原因一：任务本身不需要复杂搜索

例如抽取发票号、分类工单、翻译固定文本。增加推理只会扩大延迟和偏离格式的概率。

原因二：模型在错误方向上持续展开

更长轨迹可能让错误假设自我强化。没有外部证据或 Verifier 时，“多想”不等于“纠错”。

原因三：问题缺少信息

客户要求模型判断一份未提供的合同是否合规。再多推理也无法弥补缺失输入。

原因四：验证器不可靠

Best-of-N 只有在评分器能选出好答案时才有价值。弱 Judge 可能稳定选择更长、更自信但错误的回答。

原因五：成本与 SLA 不允许

回答正确率提高 1%，但 P95 从 3 秒变成 30 秒，可能不符合在线客服业务目标。

3.5 Verifier：Reasoning 系统的放大器

术语卡：Verifier

验证器强度分层

1. 硬验证：编译是否通过、金额是否相等、状态是否已写入数据库。
2. 半结构验证：字段完整性、规则匹配、引用是否支持结论。
3. 软判断：文风是否自然、方案是否有洞察、广告是否吸引人。

越接近硬验证，自动搜索与 RL 的收益通常越容易兑现。

3.6 [高级] Reasoning Router

生产系统可以先用一个轻量分类器或主模型的低成本模式判断任务难度，再路由到不同策略：

低复杂度：Fast Model / No-thinking
中复杂度：主模型 + Medium Reasoning
高复杂度：强模型 + High Reasoning + Tool
高风险：强模型 + Verifier + Human Approval

路由需要的输入特征

• Prompt 类型和长度；
• 任务是否有多步约束；
• 是否需要外部最新信息；
• 用户等级和 SLA；
• 错误损失；
• 是否可验证；
• 历史同类任务的成功率。

路由需要的反馈

• 最终成功率；
• Reasoning Token；
• P50/P95 时延；
• Tool Call 次数和失败率；
• 人工接管率；
• 单成功任务成本。

3.7 客户问题：所有请求是否都应该开深度思考

普通回答：不需要，简单任务不值得支付额外时间和成本。

专业 SA 回答：按任务复杂度、错误代价和可验证性分层。简单抽取、分类和固定格式使用 Fast 模式；复杂分析和代码使用动态 Reasoning；高风险任务增加工具验证和人工审批。

更深一层：优化目标不是单题极限分数，而是：

在 SLA 和预算约束下，最大化业务成功率

这本质上是一个路由和资源分配问题，而不是“永远选择最强模型”。

3.8 常见误区

3.9 本章 Decision Tree

任务到达
  ├─ 是否可由规则/传统程序完成？是 → 不调用 LLM 或只做辅助
  ├─ 是否简单、低风险、格式明确？是 → Fast / No-thinking
  ├─ 是否需要外部事实或计算？是 → Tool-assisted
  ├─ 是否有可靠 Verifier？是 → Search / Best-of-N / Auto-repair
  ├─ 是否高风险或不可逆？是 → Human Approval
  └─ 按业务指标动态调整 Reasoning Budget

本章测试题与参考答案

1. Test-time Compute 包含哪些形式？
   更长推理、多样本、搜索、验证器和工具调用等。
2. 为什么简单抽取不应默认使用深度思考？
   额外推理通常不提高任务本质能力，却增加时延、成本和格式偏离。
3. Best-of-N 的关键前提是什么？
   存在能够可靠选择更优候选的 Verifier 或 Judge。
4. 硬验证与软判断的区别是什么？
   硬验证有客观可执行标准，软判断依赖主观质量判断。
5. Reasoning Router 的最终优化目标是什么？
   在 SLA 和预算约束下最大化业务成功率。
   

第 4 章：模型评测与企业 PoC

本章要解决的客户问题

“这个模型榜单第一，为什么在我们场景里不行？”
“PoC 应该测多少条，测什么指标？”
“LLM-as-a-Judge 能不能直接代替人工？”

本章前置知识

需要理解模型输出受 Prompt、Context、采样、Tool 和 Reasoning Budget 影响。

4.1 评测的第一原则：先定义失败

“效果不好”不是可操作的问题。必须把失败转换成可观察事件。例如：

• 事实错误；
• 漏掉关键字段；
• 引用与结论不一致；
• JSON 解析失败；
• 工具参数错误；
• 代码测试未通过；
• 视频商品结构变形；
• Agent 未完成最终状态；
• 延迟超过 SLA；
• 单成功任务成本过高。

如果失败定义不清，评测只会变成主观争论。

4.2 Public Benchmark 到底测什么

MMLU 原始工作覆盖 57 个任务；GPQA 使用 448 道由领域专家编写的高难问题；SWE-bench 原始集合包含 2,294 个真实软件工程问题；LiveCodeBench 通过持续收集新题降低污染风险。MMLU；GPQA；SWE-bench；LiveCodeBench

为什么 Benchmark 会失真

1. Data Contamination：题目或答案可能进入训练数据。
2. Benchmark Saturation：模型接近高分后，题目区分度下降。
3. Scaffold 差异：是否允许 Tool、搜索、多 Agent 和重试会显著改变分数。
4. Sampling 差异：Temperature、次数、Pass@k 和最大 Token 不同。
5. Judge 差异：自动评分 Prompt 和模型不同。
6. 任务分布差异：公开题与客户真实数据不一致。

4.3 四层企业评测体系

第一层：Public Benchmark

用途：快速了解模型能力先验，缩小候选模型范围。

不应用途：直接决定采购和生产切换。

第二层：Offline Domain Eval

使用客户历史数据或专家构造样本，保证可重复。至少需要：

• 正常样本；
• 边界样本；
• 长尾样本；
• 对抗样本；
• 高风险样本；
• 需要拒答或升级人工的样本。

第三层：Business Process Eval

评价完整流程，不只评价最终文本：

• Agent 是否选择正确工具；
• 是否满足前置权限；
• 是否完成最终状态；
• 总步骤数和无效循环；
• 人工接管发生在哪一步；
• 是否可恢复、可回滚。

第四层：Online Production Eval

真正关注业务 KPI：

• 客服一次解决率；
• 审核处理时长；
• 代码合并周期和缺陷率；
• 内容素材通过率和转化率；
• 人工节省时长；
• 风险事件率；
• Cost per Successful Task。

4.4 如何建立 PoC 样本集

样本数量不是唯一问题

100 条高质量、覆盖真实失败分布的样本，可能比 10,000 条随机历史日志更有决策价值。

建议分层：

避免样本泄漏

参与 Prompt 调试、模型选择和阈值设置的样本属于开发集；最终决策需要独立测试集。否则团队会对 PoC 样本“过拟合”。

4.5 指标设计：质量、时延、成本必须同时存在

文本任务常用指标

• Accuracy / Exact Match；
• Precision、Recall、F1；
• Citation Precision / Recall；
• Faithfulness / Groundedness；
• Format Valid Rate；
• Refusal Accuracy；
• Human Preference Win Rate。

Agent 任务常用指标

• End-to-end Task Success；
• Tool Selection Accuracy；
• Tool Execution Success；
• Steps per Successful Task；
• Retry Rate；
• Human Takeover Rate；
• Irreversible Error Rate；
• Recovery Success Rate。

性能与成本指标

• TTFT P50 / P95；
• TPOT / ITL；
• End-to-end Latency；
• Input / Output / Reasoning Token；
• Cache Hit Rate；
• Cost per Request；
• Cost per Successful Task。

4.6 LLM-as-a-Judge：可以用，但不能盲信

LLM Judge 适合：

• 大规模初筛；
• 明确评分 Rubric 的文本比较；
• 配合少量人工校准；
• 对同一模型版本做回归测试。

需要防范：

• 位置偏差：偏好 A 或 B 的位置；
• 长度偏差：更长回答被误判为更好；
• 风格偏差：更自信或更正式的回答得分更高；
• 自模型偏好：模型偏好相似风格；
• 知识盲区：Judge 本身不知道正确答案；
• Prompt 敏感：评分标准稍改，结果发生变化。

最稳妥的组合

硬规则 / 可执行验证
+ LLM Judge
+ 专家抽样复核
+ 线上业务指标

4.7 Bad Case 根因标签体系

4.8 一个可直接使用的客户 PoC 流程

1. 定义业务目标：例如把合同审查平均耗时从 30 分钟降到 10 分钟。
2. 定义失败与风险：漏掉高风险条款的损失远高于多报一个风险。
3. 冻结测试协议：模型版本、Prompt、工具、采样、上下文和超时。
4. 建立分层样本集：包含真实 Bad Case 和高风险样本。
5. 并行测试候选方案：模型、RAG、Reasoning 和工具保持可比。
6. 记录全链路 Trace：最终答案之外保存检索、上下文、调用和时延。
7. 根因分析：不要只报平均分。
8. 小流量上线：设置人工兜底和回滚。
9. 以业务 KPI 复核：测节省时间、成功率、风险和成本。
10. 形成上线门槛：定义何时扩大流量、何时停止。

4.9 客户问题：榜单第一为什么 PoC 还输

普通回答：榜单任务与客户任务不同。

专业 SA 回答：Public Benchmark 是能力先验。客户结果还受 Prompt、Context、Tool、Harness、采样、时延和成本影响。需要用相同协议在真实数据上进行可复现评测。

更深一层：先判断差异来自哪里：

模型本体差异？
还是 Context / Tool / Harness 差异？
还是评测协议差异？
还是业务任务分布差异？

只比较厂商披露的一个分数，无法回答这些问题。

4.10 本章 Decision Tree

准备 PoC
  ├─ 业务目标是否量化？否 → 先定义 KPI
  ├─ 失败是否分类？否 → 建立 Bad Case Taxonomy
  ├─ 是否有独立测试集？否 → 划分开发集/测试集
  ├─ 是否记录全链路 Trace？否 → 先补可观测性
  ├─ 是否同时测质量/时延/成本？否 → 评测不完整
  └─ 通过离线门槛后，小流量线上验证业务价值

本章测试题与参考答案

1. Public Benchmark 的正确用途是什么？
   提供能力先验和缩小候选集，不直接替代客户 PoC。
2. 为什么开发集和测试集必须分开？
   防止团队对样本和 Prompt 过拟合，虚高最终结果。
3. Agent 为什么要测完整轨迹？
   最终答案可能看似正确，但中间存在越权、无效循环或不可恢复错误。
4. LLM Judge 最稳妥的使用方式是什么？
   与硬验证、专家抽样和线上业务指标组合，并先校准偏差。
5. PoC 最终应以什么决策？
   业务成功率、风险、SLA 和 Cost per Successful Task。

延伸阅读

• MMLU, 2020
• GPQA, 2023
• SWE-bench, 2023
• LiveCodeBench, 2024
  

第 5 章：GPU 与大模型推理——同一个模型为什么能差几倍

本章要解决的客户问题

“同一个模型为什么在不同云、不同 GPU 上性能差这么多？”
“TPS 很高，为什么用户仍然觉得慢？”
“FP4 比 FP8 少一半位宽，为什么实际性能没有翻倍？”
“模型能装进显存，为什么并发一上来就 OOM？”

本章前置知识

需要理解 Token、自回归生成、Attention 和 MoE 的基本概念。不要求掌握 CUDA 编程，但要能区分“计算速度”“显存容量”“显存带宽”和“网络通信”。

5.1 先把一次请求拆开

用户点击发送，到完整答案结束，并不是一个不可分割的“模型耗时”。更有用的分解是：

End-to-End Latency
= Queue / Admission
+ Prompt Processing（Prefill）
+ First Decode Step
+ Remaining Decode Steps
+ Tool / Network / Post-processing

这一步非常重要。客户说“慢”，可能是完全不同的问题：

• 排队慢：容量不足、调度不合理、限流或突发流量；
• 首字慢：Prompt 太长、Prefill 慢、Prefix Cache 未命中；
• 输出慢：Decode 的 TPOT 高；
• 总完成慢：输出太长、Thinking Token 多、Agent 调用链长；
• 偶尔特别慢：P95 / P99 尾延迟、资源争抢或跨节点通信抖动。

术语卡：Latency 与 Throughput

术语卡：TTFT

术语卡：TPOT 与 ITL

SA 原则：客户说“TPS 高但仍然慢”时，先问这个 TPS 是单请求、单卡、实例总吞吐还是集群吞吐；再拆 TTFT、TPOT、输入长度、输出长度和并发。

5.2 GPU 的四个基础变量

可以把 GPU 简化成四类资源：

1. 计算单元：执行矩阵乘法等计算；
2. HBM 容量：能放多少权重、激活和 KV Cache；
3. HBM 带宽：单位时间能搬运多少数据；
4. 互联带宽：多卡之间交换张量和 Expert 数据的速度。

术语卡：FLOPS

术语卡：HBM Capacity 与 Memory Bandwidth

• HBM Capacity：仓库有多大。决定能否放下模型、KV、临时张量，以及能容纳多少并发。
• Memory Bandwidth：仓库到生产线的传送带有多快。决定每秒可以搬多少权重和 KV 数据。

两者不能互相替代。显存容量更大可以避免 OOM、增大 Batch；带宽更高则可能直接改善以数据搬运为瓶颈的 Decode。

Compute Bound 与 Memory Bound

• Compute Bound：计算单元忙满，数据供应跟得上；加算力或更高效矩阵 Kernel 有明显收益。
• Memory Bound：计算单元经常等数据；增加 FLOPS 不一定有效，减少数据量或提高带宽更重要。

一个简化判断是算术强度：

Arithmetic Intensity = 完成的运算量 / 从内存搬运的数据量

算术强度高，更可能受计算限制；算术强度低，更可能受内存带宽限制。在线 LLM 的 Prefill 往往具有较高并行度，容易更接近 Compute Bound；单请求 Decode 每一步只新增少量 Token，却需要读取大量权重和历史 KV，通常更容易 Memory Bound。

这不是绝对结论。模型架构、Batch、序列长度、量化、并行和 Kernel 都会改变瓶颈位置。

5.3 Prefill 与 Decode 为什么是两种不同的工作负载

vLLM 的当前文档明确将 Prefill 描述为更偏 Compute Bound、Decode 更偏 Memory Bound，并通过 Chunked Prefill 将大 Prompt 切成块，与 Decode 请求混合调度，以平衡吞吐和延迟。vLLM Optimization Guide, 2026

Chunked Prefill 的价值

假设一个用户提交 100K Token 的长文档。如果系统一次性完成全部 Prefill，其他正在 Decode 的聊天请求可能长时间得不到调度，产生明显卡顿。Chunked Prefill 将长输入切成若干块：

超长 Prefill
→ 分成多个 Token Chunk
→ 与正在 Decode 的请求交错调度
→ 控制 TTFT、TPOT 和吞吐之间的冲突

代价是调度更复杂，参数配置不当也可能损害 Prefill 效率。

5.4 KV Cache：长上下文背后的显存经济学

在自回归 Decode 中，如果每生成一个 Token 都重新计算所有历史 Token 的 Attention，成本会非常高。KV Cache 保存每层历史 Token 的 Key 和 Value，使下一步只计算当前 Token 的新表示，再读取历史 KV。

一个常见的近似公式是：

KV Cache Bytes
≈ 2 × Layers × KV Heads × Head Dimension
  × Sequence Length × Bytes per Element × Batch Size

其中第一个 2 表示同时保存 K 和 V。

一个数量级示例

假设模型有：

• 80 层；
• 8 个 KV Head；
• Head Dimension = 128；
• BF16，每个元素 2 Bytes；
• 单请求上下文 128K Token。

则单请求 KV Cache 约为：

2 × 80 × 8 × 128 × 131,072 × 2 Bytes
≈ 40 GiB

这还没有包含模型权重、激活、工作区、碎片和其他并发请求。这个例子解释了为什么“模型支持 128K/1M Context”与“系统可以高并发、低成本地使用这么长的 Context”完全是两个问题。

MHA、GQA 与 MQA

很多现代模型采用 GQA 或更复杂的潜在 Attention 结构，目的之一就是控制 KV 与推理成本。SA 在估算显存时不能只看参数量，还必须看层数、KV Head、Head Dimension、Context、精度和并发。

PagedAttention 为什么重要

传统系统常为每个请求预留一块连续 KV 空间。真实请求长度不同、随时结束，会造成内部碎片和保守预分配。PagedAttention 借鉴虚拟内存分页思想，把 KV 拆成固定大小 Block，并通过映射表管理非连续物理空间，从而提高显存利用率。vLLM 的原始工作将 PagedAttention 作为其高吞吐 Serving 的核心机制。Kwon et al., 2023

它解决的是“KV 怎么更高效地放”，并没有消除 KV 本身随序列长度增长的事实。

5.5 六类常见推理优化

5.5.1 Continuous Batching

静态 Batching 要等同一批请求全部结束再换下一批；LLM 输出长度差异很大，短请求完成后留下“空位”。Continuous Batching 在每个 Decode 迭代动态加入新请求、移除完成请求，使 GPU 长时间保持较高利用率。

Trade-off：

• 有利于吞吐；
• 可能增加请求间资源竞争；
• 调度策略会影响 P95/P99；
• 不同租户和优先级需要公平性控制。

5.5.2 FlashAttention

FlashAttention 并不是改变 Attention 数学结果，而是通过 Tiling 和 IO-aware 设计减少 HBM 与片上存储之间的读写，避免显式物化巨大的 Attention Matrix，从而提高速度并降低内存占用。Dao et al., 2022

通俗地说：不是少做逻辑上的 Attention，而是用更聪明的搬运顺序完成同样的工作。

5.5.3 Prefix Cache

很多请求共享相同前缀：

• 固定 System Prompt；
• 同一个 Agent 的工具说明；
• 相同知识库背景；
• 同一文档上的多轮提问；
• 多个分支共享同一历史轨迹。

Prefix Cache 复用该前缀已经计算出的 KV，减少重复 Prefill。收益由命中率、前缀长度和缓存回收策略决定。不要在“每个请求前缀都不同”的场景预期巨大收益。

5.5.4 Speculative Decoding

核心思路是：先由便宜的 Draft Model 或轻量预测器一次提出多个候选 Token，再由 Target Model 并行验证；被接受的 Token 可以一次前进多步。只要验证协议正确，理论上可以保持目标分布不变。Leviathan et al., 2023

收益取决于：

候选生成开销
+ Target 验证效率
+ Acceptance Rate
+ Batch / Sequence 特征

如果 Draft 与 Target 差异大、接受率低，额外工作可能抵消收益。

5.5.5 Guided / Constrained Decoding

JSON Schema、正则、语法树等约束可以在生成时屏蔽不合法 Token，提升结构化输出可靠性。它不是“让模型更懂业务”，而是缩小输出空间。

Trade-off：复杂约束可能引入 CPU/状态机开销；约束错误会把正确答案排除。

5.5.6 Prefill / Decode Disaggregation

Prefill 与 Decode 的资源形态不同，可以拆到不同实例池：

长 Prompt → Prefill Pool → KV Transfer → Decode Pool → 输出

优势是独立扩缩容、选择不同 GPU、减少长 Prompt 对交互 Decode 的干扰。代价是 KV 传输、网络、调度和系统复杂度。只有当规模、负载差异和 SLA 足够明显时，解耦才可能覆盖额外成本。

5.6 量化：为什么位宽更低不等于端到端更快

量化在做什么

量化用更少位数表示权重、激活或 KV：

• 减少显存占用；
• 减少内存带宽；
• 在硬件支持时提高矩阵吞吐；
• 可能带来精度损失、转换和 Scale 开销。

常见精度的直觉

Weight-only 与 Weight-and-Activation

• Weight-only Quantization：权重低位，运行时可能反量化到较高精度做计算。主要节省模型加载和内存带宽。
• Weight-and-Activation Quantization：权重和激活都进入低精度矩阵计算，潜在吞吐更高，但对硬件、Calibration 和模型稳定性要求更高。

为什么 FP4 不一定比 FP8 快两倍

因为端到端时间还包含：

1. 不是所有算子都走 FP4；
2. Scale、格式转换和 Dequantization 有开销；
3. Kernel 可能尚未成熟；
4. 工作负载可能由 KV、通信或 CPU 调度限制；
5. Batch 太小无法利用峰值；
6. 为保持精度，部分层仍需高精度；
7. GPU 必须原生支持对应格式。

NVIDIA 官方资料指出，Blackwell 第五代 Tensor Core 原生实现 NVFP4，并处理分组、动态缩放和 4-bit 矩阵运算。这正说明低精度性能不是“文件格式”属性，而是模型格式、Kernel 和硬件的联合能力。NVIDIA NVFP4, 2025–2026

5.7 多卡并行：模型放得下只是第一步

Tensor Parallel（TP）

把一个层内的矩阵切到多张卡，并在层内频繁通信。适合降低单卡权重和计算压力，但对 NVLink / 网络延迟敏感。

Pipeline Parallel（PP）

把不同层放在不同卡或节点，请求按流水线经过。通信频率可低于 TP，但存在 Pipeline Bubble、调度和微批复杂度。

Data Parallel（DP）

每个副本持有完整模型，处理不同请求。最适合模型能装进单实例、请求量大的场景；横向扩展简单，但每个副本都占完整权重显存。

Expert Parallel（EP）

MoE 的不同 Expert 分布在不同卡。Token 需按 Router 结果进行 All-to-All 交换。激活参数少不等于通信少；Expert 负载不均也会形成长尾。

实际部署通常组合使用。最优组合由模型结构、节点内互联、节点间网络、SLA 和负载决定。

5.8 vLLM、SGLang 与 TensorRT-LLM 怎么看

这里不做“谁永远最快”的结论。框架选择取决于模型支持、硬件、开发速度、可观测性和团队能力。

当前 vLLM 文档列出 PagedAttention、Continuous Batching、Chunked Prefill、Prefix Caching，以及 FP8、MXFP4、NVFP4、INT4 等多种量化；SGLang 文档强调 RadixAttention、Prefix Caching 与多 GPU 并行；TensorRT-LLM 当前文档覆盖 KV Cache、Paged Attention、并行、量化、Speculative Decoding 和 Disaggregated Serving。vLLM；SGLang；TensorRT-LLM

SA 选型方法：先冻结模型、精度、硬件、输入/输出分布和 SLA，再对候选引擎做同协议 Benchmark。不要引用不同版本、不同 Batch、不同长度的公开数字直接下结论。

5.9 H100、H200 与 B200：比较硬件时看什么

以 NVIDIA 官方公开规格为例：H100 SXM 的 HBM 带宽约为 3.35 TB/s；H200 提供 141GB HBM3e 和 4.8 TB/s 带宽；DGX B200 的 8 GPU 系统为 1,440GB 总 HBM、64 TB/s 总带宽，即平均每 GPU 180GB 和约 8 TB/s，并提供 Blackwell 原生 FP4 路径。NVIDIA H100；NVIDIA H200；NVIDIA DGX B200

这些规格不应被理解成固定性能倍数。实际差异还取决于：

• 模型能否用上对应低精度；
• 是 Dense、MoE、GQA 还是 MLA；
• 单卡还是多卡；
• NVLink / NVSwitch 与节点间网络；
• Context、Batch 和请求长度分布；
• 推理引擎与 Kernel 版本；
• 目标是最低 TPOT、最高吞吐还是最低成本。

为什么“某模型在 H20/H100 不如 B 系列”可能成立

更准确的解释不是“旧卡不行”，而是：

模型的数值格式和算子结构
× 推理引擎是否有优化 Kernel
× GPU 是否原生支持
× HBM / 通信是否匹配
× 当前负载能否利用硬件

如果模型主要优化路径依赖 Blackwell 的 NVFP4、特定 MoE Kernel 或更大 HBM，那么 Hopper 可能需要 Fallback、较高精度或更复杂切分，性能差距会被放大。反过来，在小模型、低并发或 CPU/网络受限场景，换更强 GPU 未必带来等比例收益。

5.10 [进阶] 先建立 Workload Fingerprint，再谈优化

同一个模型面对不同负载，最优配置可能完全相反。推理优化第一步不是打开框架文档，而是建立负载画像。

最小压测矩阵

不能只测一个“平均请求”。至少要覆盖：

ISL：P50 / P95 / Max
× OSL：P50 / P95 / Max
× Concurrency：低 / 目标 / 峰值
× Cache：冷 / 热
× Reasoning：关 / 常规 / 高预算

每个格子记录：TTFT、TPOT、E2E、P50/P95/P99、吞吐、错误率、取消率、HBM、GPU 利用率和单位成功任务成本。

5.11 [高级] 用 Roofline 和“每 Token 搬多少数据”建立性能下界直觉

Roofline Model 的核心是把工作负载放在两个上限之间：

• 峰值计算能力；
• 峰值内存带宽。

简化表示：

可达到性能 ≤ min（峰值 FLOPS，Memory Bandwidth × Arithmetic Intensity）

对于低 Batch 的自回归 Decode，一个有用但非常粗的下界直觉是：

理想的单 Token 时间
≥ 每步需要读取的数据量 / 可用 HBM Bandwidth

如果每一步几乎需要读取整份权重，那么量化权重、提高 Batch 以摊薄权重读取、使用更高 HBM 带宽都会有帮助。但这个式子忽略了：

• 权重并不总是以最简单方式读取；
• MoE 每步只激活部分 Expert，但全部权重仍需驻留或分布；
• Attention、KV、通信、Kernel Launch 和 CPU 调度也占时间；
• 多卡 TP / EP 会引入 Collective；
• Batch 提高可能改善吞吐，却恶化单请求排队和尾延迟。

因此，该模型用于识别瓶颈方向，不能直接替代真实 Benchmark。

什么时候提高 Batch 有效

Batch 增加后，多条序列可以共同使用一次权重读取，提高算术强度和设备利用率。但 Batch 不是无限增益：

• 不同长度序列造成 Padding 或调度碎片；
• KV Cache 线性增加；
• 请求等待形成排队；
• P95/P99 可能恶化；
• MoE Expert 负载可能变得不均。

在线系统的最优 Batch 是吞吐、TTFT、TPOT 和 HBM 的平衡点，而不是“显存能放多少就放多少”。

5.12 [进阶] Scheduler、Admission Control 与多租户公平性

推理引擎除了执行模型，还必须决定“谁先算、一次算多少、何时拒绝”。

Scheduler 需要处理的冲突

1. 长 Prefill 会阻塞短 Decode；
2. 超长输出会长期占用 KV；
3. 高优先级交互请求与离线 Batch 竞争；
4. 已取消请求若不能及时回收，会浪费算力和 KV；
5. 大客户流量可能挤占其他租户；
6. Cache 热点可能形成不公平优势。

Admission Control 不等于简单限流

Admission Control 应综合：

• 当前 Queue；
• 预计 Prefill Token；
• 预计最大输出；
• KV Block 余量；
• 请求优先级；
• 租户 Quota；
• 超时与取消概率；
• 降级模型或异步执行选项。

请求到达
  ├─ 资源充足 → 接收
  ├─ 可降级 → 小模型 / 低 Reasoning / 缩短 Context
  ├─ 可异步 → 进入离线队列
  └─ 风险过高 → 快速拒绝，而不是接收后 OOM

Prefix Cache 的隔离问题

Prefix Cache 通常要求 Token 序列精确匹配，但工程上还要处理：

• 不同 Tenant 能否共享同一缓存；
• Prompt 中是否包含敏感信息；
• 模型版本、LoRA Adapter、RoPE / Position 和采样配置是否兼容；
• 缓存键是否防止碰撞或越权；
• 更新 System Prompt 后如何失效；
• 缓存收益是否抵得过管理开销。

因此 Prefix Cache 同时是性能机制和安全治理对象。

5.13 [进阶] 长上下文架构优化了什么，又没有解决什么

最重要的边界是：

模型“支持 1M Context”
≠ 1M 信息都能同等有效利用
≠ 1M 请求具有可接受 TTFT
≠ 1M KV 能以目标并发承载
≠ 1M 任务的成本可以接受

需要区分：宣称上限、原生训练长度、扩展长度、有效利用长度和可负担长度。

5.14 [高级] MoE、Prefill/Decode 解耦与可观测性

MoE 的三个不同“大小”

1. Total Parameters：全部专家和共享层权重，主要影响存储和集群驻留；
2. Activated Parameters：一个 Token 实际经过的部分 Expert，影响 FFN 计算量；
3. Communication Footprint：Token 路由、Dispatch / Combine 和 All-to-All，可能成为独立瓶颈。

所以：

2T 总参数、100B 激活
不等于 100B Dense 的存储
也不等于 100B Dense 的通信
更不等于相同的实际 TPS

Expert Parallel 需要观察什么

• 每个 Expert 的 Token 数量；
• Expert Load Balance；
• Dispatch / Combine 时间；
• All-to-All 带宽与尾延迟；
• Shared Expert 和 Routed Expert 的计算占比；
• EP Group 是否跨节点；
• 是否存在 Expert Capacity Overflow 或 Token Drop。

Prefill / Decode Disaggregation 的收益与代价

收益：

• Prefill 池可使用高计算配置；
• Decode 池可使用高 HBM 带宽、低 TPOT 配置；
• 两阶段可以独立扩缩容和排队。

代价：

• Prefill 后需要传输 KV；
• 路由、状态、故障恢复和缓存一致性更复杂；
• KV 传输延迟可能抵消收益；
• 小 Prompt 或低并发场景未必值得解耦。

生产系统最少应暴露的观测项

没有这些指标，推理优化只能依赖猜测。

5.15 一套可直接用于客户现场的性能诊断流程

客户反馈：模型慢 / 贵 / 不稳定
  ↓
1. 固定模型版本、精度、引擎和硬件
  ↓
2. 采集 ISL / OSL / 并发分布，而不是只看平均值
  ↓
3. 拆 TTFT、TPOT、E2E、P50/P95/P99
  ↓
4. 判断 Queue、Prefill、Decode、Tool 哪段占比最高
  ↓
5. 看 GPU Util、HBM、KV、Batch、Cache Hit、Network
  ↓
6. 确认实际 Kernel / Quantization 是否命中
  ↓
7. 做单变量 A/B，而不是同时换模型、卡和参数
  ↓
8. 用 Cost per Successful Task 决策

必问指标清单

• Input Sequence Length（ISL）分布；
• Output Sequence Length（OSL）分布；
• TTFT / TPOT / E2E 的 P50、P95、P99；
• Request / Token Throughput；
• 并发和队列长度；
• GPU 利用率、HBM 占用、OOM；
• Prefix Cache Hit Rate；
• Batch 和 Scheduler 配置；
• 量化格式与实际执行精度；
• TP / PP / EP 拓扑；
• 错误率、取消率和重试率。

5.16 客户问题：TPS 很高，为什么用户仍然觉得慢

普通回答：总吞吐高不代表单个用户响应快。

专业 SA 回答：请把集群 Throughput 与单请求 TTFT、TPOT 分开。高并发 Batching 可以提升总 TPS，但可能增加排队和单请求时延；如果 Prompt 长，TTFT 仍会很高。

更深一层：检查：

1. TPS 的统计口径；
2. ISL / OSL；
3. P95 Queue Time；
4. Prefill 与 Decode 占比；
5. 是否为吞吐配置牺牲了交互 SLA；
6. 是否存在 Agent/Tool 等模型外耗时。

5.17 客户问题：模型能装进显存，为什么并发一上来就 OOM

普通回答：权重不是唯一显存占用。

专业 SA 回答：还需要 KV Cache、激活、CUDA Graph、临时工作区和碎片空间。长 Context 与高并发会使 KV 占用快速增长。

更深一层：根据模型 KV 结构、精度、Context 和 Batch 估算 KV Bytes；检查 Paged KV 配置、最大序列保留、请求取消后的回收，以及是否能使用 GQA、KV 量化、Prefix Cache 或更合理的长度限额。

5.18 常见误区

误区一：GPU FLOPS 越高，任何推理都越快

只有在计算是主要瓶颈且 Kernel 能利用算力时才成立。Memory Bound、通信受限或小 Batch 场景可能无法兑现峰值。

误区二：模型能跑起来，就代表可以生产部署

生产部署还要求：SLA、尾延迟、隔离、扩缩容、故障恢复、成本和可观测性。

误区三：吞吐越高，体验越好

离线 Batch 任务通常追求吞吐；在线交互更关心 TTFT、TPOT 和尾延迟。目标函数不同，配置也不同。

误区四：所有请求都允许最大 Context，可以提高能力

最大 Context 会扩大 KV、Prefill 和风险半径。应按业务任务设置配额、截断、摘要、RAG 和缓存策略。

5.19 本章 Decision Tree

客户要优化推理
  ├─ 目标是低 TTFT？
  │    ├─ 长 Prompt → Prefix Cache / Prompt 压缩 / 更快 Prefill
  │    └─ 排队高 → 容量 / 优先级 / Admission Control
  ├─ 目标是低 TPOT？
  │    ├─ Memory Bound → 量化 / 更高带宽 / Batch / KV 优化
  │    └─ 通信高 → 调整 TP/EP、拓扑与 Kernel
  ├─ 目标是高吞吐？
  │    ├─ Continuous Batching / 调度 / 副本数
  │    └─ 检查 SLA 是否被牺牲
  ├─ 目标是低成本？
  │    ├─ 提升利用率、缓存和有效 Batch
  │    └─ 降低无效 Token、重试与过度 Reasoning
  └─ 任何结论都需在真实 ISL/OSL/并发分布上复测

本章测试题与参考答案

1. TTFT 与 TPOT 的区别是什么？
   TTFT 是请求到首 Token 的时间；TPOT 是开始输出后每个 Token 的平均生成时间。
2. 为什么 Decode 常见 Memory Bound？
   单步新增 Token 少，却反复读取大量权重和历史 KV，算术强度相对低。
3. PagedAttention 消除了 KV 随 Context 增长吗？
   没有。它提高 KV 的内存管理效率，不能改变 KV 数据量的基本增长关系。
4. FP4 为什么不自动比 FP8 快两倍？
   端到端还受硬件原生支持、Kernel、Scale/转换、KV、通信和 Batch 等限制。
5. MoE 推理为什么要关注 Expert Parallel？
   Token 要在不同 Expert 间路由，All-to-All 通信和负载不均可能成为瓶颈。

课堂练习

给定一个聊天业务：输入 P50=2K、P95=32K；输出 P50=300、P95=3K；高峰并发 1,000。请分别提出：

• 交互体验指标；
• 容量压测矩阵；
• Prefix Cache 适用性；
• 长请求隔离策略；
• 应避免使用的“单一平均值”。

延伸阅读

• Efficient Memory Management for Large Language Model Serving with PagedAttention
• FlashAttention
• Fast Inference from Transformers via Speculative Decoding
• vLLM Documentation
• SGLang Documentation
• TensorRT-LLM Documentation
  

专题工作坊：国内开放权重模型参数阅读与部署判断

为什么要加入这一模块

这部分不是“国产模型参数大全”，也不要求团队背诵模型层数和专家数量。目标是训练一种稳定能力：看到任何新的 Model Card，能够把参数翻译成存储、计算、KV、通信、框架兼容性、成本和客户适用性。

截至 2026 年 9 月，国内代表性开放权重模型已经大量采用超大规模 MoE、稀疏/线性/压缩注意力、百万上下文和混合 FP4/FP8。继续只用“7B、32B、72B”比较模型，会产生严重误判。

W.1 先区分“开源”与“开放权重”

模型开放不是一个二元标签，需要拆成：

因此，本教材优先使用“开放权重模型”作为中性表述。即使仓库自称 Open Source，企业采用前仍要由法务和安全团队核验具体许可证。

W.2 Model Card 的 12 个必读字段

1. 模型版本与发布日期；
2. License；
3. Dense 还是 MoE；
4. Total Parameters；
5. Activated Parameters；
6. Layers、Hidden Size、Head Dimension；
7. Experts、Top-k、Shared Experts；
8. Attention 类型和 KV Head；
9. 原生 Context 与扩展 Context；
10. 权重、Activation 与 KV 的精度；
11. 文本、视觉、音频等 Modality；
12. Transformers、vLLM、SGLang、TensorRT-LLM 等部署支持。

任何一项缺失，都应该进入“待验证”，不能靠经验补全。

W.3 参数如何翻译成工程含义

1. Total Parameters：主要回答“全部权重有多大”

一个粗略的原始权重存储下限：

Raw Weight Bytes ≈ Total Parameters × Bits per Parameter / 8

例如：

这些只是数学下限，不是生产 GPU 配置。实际部署还需考虑：Scale / Metadata、非统一精度、Embedding / Vision Encoder、KV、CUDA Graph、Workspace、通信 Buffer、冗余和框架加载峰值。

2. Activated Parameters：主要回答“每 Token 的部分 FFN 计算”

MoE 的 Activated Parameters 通常描述每个 Token 经过的部分 Expert 参数量，但不能直接推出：

• 全部权重存储；
• Attention 计算；
• KV Cache；
• Router 与 Shared Expert；
• All-to-All；
• 实际 TPS。

Total Parameters → 权重驻留、下载和集群规模
Activated Parameters → 部分单 Token 计算量
Attention / KV → 长上下文与 Decode
Expert Routing → 通信、负载均衡和尾延迟

3. Context：至少区分五个口径

• Advertised Context：对外宣称的输入上限；
• Native Context：训练中原生覆盖的长度；
• Extended Context：通过 RoPE Scaling 等扩展的长度；
• Effective Context：在目标任务上仍能稳定利用的长度；
• Affordable Context：满足 TTFT、并发和成本约束时可实际使用的长度。

4. Precision：要问“谁是低精度”

模型卡写 FP4 / FP8 时，必须继续问：

• Expert 权重还是全部权重？
• Weight-only，还是 Weight + Activation？
• 是否 QAT；
• 非矩阵算子使用什么精度；
• KV Cache 是什么精度；
• 目标 GPU 是否有原生 Kernel；
• 官方权重格式是否被当前 Serving 引擎支持。

W.4 2026-09-01 国内代表性开放权重模型快照

本表只用于练习参数阅读，不用于宣布模型优劣。所有能力和性能数字应视为对应厂商 Model Card / 官方仓库口径，正式选型必须在相同 Harness、精度、硬件和业务数据上复测。

架构与规模

来源：DeepSeek-V4 Model Card；Qwen3.8 Model Card；GLM-5 Repository；Kimi K3 Repository；MiniMax M3 Repository；Seed-OSS Repository；Step 3.7 Flash Model Card。

从参数到部署：每个模型应该继续追问什么

W.5 两个详细解读示例

示例一：Qwen3.8-2.4T-A95B

Model Card 给出 2.4T Total、95B Activated、512 Experts、每 Token 激活 10 Routed + 1 Shared、262K 原生 Context，可扩至约 1.01M，并采用 3 组 Gated DeltaNet 层与 1 组 Gated Attention 层循环的混合布局。Qwen3.8 Model Card, 2026

可以推断：

• 这是超大 MoE，全部 BF16 原始权重约 4.8TB；即使 4-bit 数学下限也约 1.2TB；
• 95B Active 说明单 Token 不执行全部 2.4T Expert，但不能消除全部权重驻留；
• 512 Experts 和 Top-k 路由意味着 EP、All-to-All 与 Load Balance 是核心问题；
• 4 个 KV Head 的 Gated Attention 有利于降低 KV；
• 线性 Attention 与标准 Attention 混合，意味着 Serving 引擎必须支持自定义架构和高效 Kernel；
• 1.01M 是扩展上限，客户仍需验证有效上下文、TTFT、并发和成本。

不能从参数卡直接推断：

• 在客户 Coding PoC 中一定优于其他模型；
• 在 H20/H100/B 系列上的具体 TPS；
• 95B Active 就等于 95B Dense 的成本；
• 1M 内容都能可靠召回并推理。

示例二：Seed-OSS-36B

Seed-OSS-36B 是 Dense 模型，采用 64 层、GQA、80 个 Q Head 和 8 个 K/V Head，原生训练至 512K Context，仓库采用 Apache-2.0。Seed-OSS Model Card

可以推断：

• BF16 原始权重约 72GB，单张 80GB 卡“理论上接近可装”，但生产 Serving 还需要 KV、Workspace 和安全余量；
• FP8 原始权重下限约 36GB，4-bit 下限约 18GB，但精度和 Kernel 必须实测；
• GQA 的 8 个 KV Head 比 MHA 显著节省 KV；
• 512K 是原生长上下文，但高并发 512K Serving 仍然会面临巨大 Prefill 与 KV 压力；
• Dense 架构没有 MoE All-to-All，但每 Token 会经过全部 36B 参数。

这两个例子说明：Dense “小模型”可能部署简单，但每 Token 计算全部参数；超大 MoE 激活少，但存储和通信复杂。不存在只靠 Total 或 Active 一个数字就能做出的答案。

W.6 框架兼容性检查表

开放权重并不等于可立即生产部署。至少验证：

• ☐ 官方 Transformers 版本和 trust_remote_code 要求；
• ☐ vLLM / SGLang / TensorRT-LLM 的最低版本；
• ☐ 是否需要厂商 Patch、自定义 Kernel 或 Nightly Build；
• ☐ Chat Template、Tool Parser、Reasoning Content 的协议；
• ☐ FP8 / FP4 / INT4 权重是否能直接加载；
• ☐ TP / EP / PP 支持和推荐拓扑；
• ☐ Prefix Cache、Speculative Decoding、KV Quantization 是否兼容；
• ☐ 多模态 Processor、Vision Encoder 和视频输入限制；
• ☐ Monitoring、Metrics、取消、超时和错误恢复；
• ☐ License、安全扫描、模型文件供应链与校验值。

W.7 课堂工作坊

每组选择一个模型，填写：

汇报必须回答

1. 哪些结论可以从 Model Card 直接得到？
2. 哪些只是架构推断？
3. 哪些必须通过部署 Benchmark 得到？
4. 为什么不能只看 Active Parameters？
5. 客户现有 GPU、网络和 SLA 是否匹配？
6. 如果效果相近，哪一个方案的 Cost per Successful Task 更低？

W.8 本模块 Decision Tree

拿到一个新开放权重模型
  ↓
先确认版本、许可证和权重完整性
  ↓
Dense / MoE / Multimodal？
  ↓
Total → 原始权重与节点规模
Active → 部分计算量
Attention / KV → 长上下文与 Decode
Experts / Top-k → EP 与 All-to-All
Precision → GPU / Kernel / 精度风险
Framework → 上线成熟度
  ↓
用客户 ISL / OSL / 并发 / SLA 做压测
  ↓
质量 + 性能 + 稳定性 + 成本 + 治理共同决策

本模块测试题与参考答案

1. 2T-A100B 是否等同于 100B Dense？ 不是。Active 只描述部分计算；2T 权重存储、Attention、KV 和 EP 通信仍然不同。
2. 支持 1M Context 是否说明 1M 任务可生产使用？ 不是。还需验证原生/扩展、有效利用、TTFT、KV、并发和成本。
3. 开放权重是否意味着可以无条件商用？ 不是。需要检查具体 License、再分发和规模限制。
4. 模型卡写 FP4 是否代表任何 GPU 都能获得 FP4 加速？ 不是。要看格式、QAT/PTQ、Activation、Kernel 和硬件原生支持。
5. 为什么官方 TPS 不能直接用于客户容量规划？ 必须知道硬件、精度、Batch、ISL/OSL、并发、缓存和统计口径，并在客户负载上复测。
   

第 6 章：RAG 与 Context Engineering——知识库为什么经常“检索对了仍然答错”

本章要解决的客户问题

“把公司文档放进向量数据库，不就是企业知识库了吗？”
“检索结果里明明有答案，模型为什么还会答错？”
“模型已经支持 1M Context，还需要 RAG 吗？”
“知识变了，为什么不能直接 Fine-tune？”

本章前置知识

需要理解 Token、Context Window、Embedding Model 与生成模型的区别。无需先掌握数据库和搜索引擎内部算法。

6.1 RAG 不是一个组件，而是一条信息供应链

RAG 的原始思想，是把参数化生成模型与外部非参数知识源结合：先检索，再基于证据生成。Lewis et al., 2020

企业落地时，更完整的链路是：

数据接入
→ 解析 / 清洗 / 权限 / 版本
→ Chunking / Metadata / Index
→ Query Understanding / Rewrite
→ Dense + Sparse + Filter Recall
→ Rerank
→ Context Assembly
→ LLM Reasoning / Generation
→ Citation / Verification
→ Feedback / Evaluation

如果只做“PDF 切块→Embedding→TopK→LLM”，往往会在复杂文档、权限、数字、表格、版本和多轮问题上迅速触顶。

6.2 为什么“知识在文档里”不等于“模型能用到”

一个问题要被正确回答，至少经过五道门：

1. 可解析：文字、表格、图片、页眉页脚有没有正确提取；
2. 可召回：用户问题能否找到包含证据的 Chunk；
3. 可选择：正确证据能否从相似但错误的内容中被排到前面；
4. 可组织：证据是否以足够完整、无冲突、不过载的方式进入 Context；
5. 可推理与引用：模型能否基于证据完成比较、计算、归纳并保持 Grounded。

可用一个故障定位 Mental Model 表达：

Answer Quality
≈ Data Quality
× Retrieval Recall
× Evidence Precision
× Context Assembly
× Model Reasoning
× Grounding / Policy

这不是严格数学公式，而是提醒团队：任何一项接近零，最终答案都会失败。

6.3 数据接入：最容易被低估的上游

6.3.1 Parsing

企业文档不是只有干净文本，还包括：

• 扫描 PDF；
• 多栏排版；
• 合并单元格；
• 表格与脚注；
• 图片内文字；
• 标题层级；
• 附件、链接和版本；
• 代码、公式和图表。

解析错误会被后续 Embedding 和 LLM “合理化”，最终看起来像模型幻觉。生产系统应保留：

• 原始文件；
• 解析后结构；
• 页码 / 坐标；
• 表格单元格关系；
• 版本号；
• 数据来源；
• 权限主体。

6.3.2 Freshness 与 Versioning

同一制度可能有 2024、2025、2026 三个版本。只按语义相似度检索，旧版本也可能排在前面。需要把生效日期、废止状态、组织和地域等放入 Metadata，并在查询时做过滤和版本优先级。

6.3.3 ACL 不是检索后的补丁

Access Control List（ACL）表示谁能读取什么资源。权限过滤应在检索阶段生效，而不是模型生成答案后再遮盖。否则未授权内容可能已经进入 Context、日志或缓存。

企业知识库的第一原则：答案权限不能大于用户对原始知识的权限。

6.4 Chunking：切多大没有统一答案

术语卡：Chunk

过小与过大的 Trade-off

实际应根据任务设计：

• FAQ：问题—答案为一个单元；
• 合同：条款、定义和引用关系需要结构化链接；
• 产品手册：标题层级 + Parent-Child Retrieval；
• 代码：函数、类、调用关系；
• 表格：表头、行列语义不能拆散；
• 会议纪要：时间、人物、议题和结论需要保留。

Parent-Child Retrieval

可以用小 Chunk 做召回，提高精度；命中后回取更大的父级段落，补充完整上下文。这是“检索粒度”和“阅读粒度”分离的典型方法。

6.5 Dense、Sparse、Hybrid 与 Metadata Filter

Dense Retrieval

使用 Embedding 把 Query 和文档映射到向量空间，按语义相似度召回。擅长同义表达和自然语言语义，但对精确编号、缩写、稀有实体可能不够稳定。

Sparse Retrieval

以关键词、词频和倒排索引为基础，例如 BM25。擅长精确名称、型号、合同编号和代码符号，但对同义改写较弱。

Hybrid Search

将 Dense 与 Sparse 结果融合，再结合 Metadata Filter：

Semantic Similarity
+ Exact Keyword Match
+ Product / Region / Date / ACL Filter
→ Candidate Set

企业场景中，Hybrid 往往比单一向量检索稳健，因为业务问题同时包含语义和精确实体。

术语卡：Embedding Model

当前 Qwen3 Embedding 系列同时提供 Embedding 与 Reranker，并覆盖文本检索、代码检索、跨语言和多种尺寸，体现了“召回模型 + 精排模型”协同的主流路线。Qwen3 Embedding, 2025–2026

6.6 Rerank：召回之后再做一次精细判断

第一阶段检索通常追求“不漏”，候选中会混入噪声。Reranker 对 Query 与每个候选做更精细的相关性判断，再把最有用证据放到前面。

为什么 TopK 不是越大越好

TopK 增大可能提高 Recall，但也会：

• 引入相似旧版本；
• 加入与问题无关的上下文；
• 增加 Prompt Token；
• 让模型在冲突证据间摇摆；
• 降低“Lost in the Middle”条件下的有效利用。

更合理的策略是：

高召回候选
→ Rerank
→ 去重 / 版本选择 / 权限过滤
→ 按问题需要动态决定 Context 数量

术语卡：Reranker

6.7 Query Understanding 与 Rewrite

用户很少用文档中的原话提问。多轮对话中，“它的保修多久”缺少明确主语。Query Layer 可以完成：

• 指代消解；
• 缩写展开；
• 意图识别；
• 多查询扩展；
• 子问题拆解；
• 结构化 Filter 抽取；
• HyDE 等假设文档生成；
• 是否需要检索的判断。

Rewrite 的风险

Query Rewrite 不是越复杂越好。模型可能在改写时错误补全实体，导致检索方向整体偏移。生产系统应保存 Original Query 和 Rewritten Query，并在评测中单独标注 Rewrite Error。

6.8 Context Assembly：检索结果如何进入模型

检索命中只是“找到了”，Context Assembly 决定模型“看到什么、按什么顺序看到”。

需要处理：

• 去重；
• 旧版本剔除；
• 证据排序；
• 父子段落补全；
• 引用 ID；
• 冲突声明；
• Token Budget；
• 多轮历史裁剪；
• Tool 结果与文档的优先级；
• 安全与权限标签。

一个实用 Prompt 结构是：

Task / Policy
→ User Question
→ Evidence Pack（每段有 Source ID / Date / Scope）
→ Answer Rules（只基于证据、冲突时显式说明）
→ Required Output Schema

Lost in the Middle

模型对超长 Context 中不同位置的信息利用并不均匀。即使接口接受 1M Token，也不代表把所有候选资料直接拼接进去是最佳方案。Context Engineering 的目标不是“塞得最多”，而是“在最小必要上下文中提供足够证据与操作指令”。Anthropic 的 Context Engineering 实践也强调按需、渐进地提供信息，而不是把全部状态一次性装入上下文。Anthropic, 2025–2026

6.9 RAG、Long Context 与 Fine-tuning 怎么选

三者不是互斥关系。例如：Fine-tuning 让模型学会领域输出格式，RAG 提供最新制度，Long Context 临时读取完整合同。

决策原则

事实是否频繁变化？是 → 优先外部知识 / Tool
是否需要逐条引用？是 → RAG / Long Context
是否主要改变行为、格式、风格？是 → SFT / Fine-tuning
是否是一次性长材料任务？是 → Long Context + 结构化检索

6.10 多模态 RAG 与表格问答

文档中的关键证据可能存在于图片、流程图、扫描页和表格中。多模态 RAG 需要：

• OCR / Layout Parsing；
• 图像区域与文字位置关系；
• 表格结构；
• Page Screenshot 或 Region Crop；
• 视觉 Embedding；
• 文本与视觉证据联合引用。

对于财务报表或价格表，单纯把表格转成一串文本会丢失行列关系。更稳妥的方案可能是：

1. 解析成结构化表；
2. 根据问题生成 SQL / DataFrame 操作；
3. 由工具执行计算；
4. LLM 负责解释结果；
5. 保留原始单元格和页码引用。

这体现了一个重要边界：能用确定性工具算的，不应让 LLM 靠语言猜。

6.11 RAG 应该如何评测

Retrieval 指标

Answer 指标

• Correctness：答案是否正确；
• Faithfulness / Groundedness：答案是否被证据支持；
• Citation Accuracy：引用是否对应真实支持内容；
• Completeness：是否遗漏关键条件和例外；
• Refusal Quality：证据不足时是否正确拒答；
• Permission Safety：是否越权泄露；
• Latency / Cost：为了提升质量付出了多少代价。

评测集要包含什么

• 可直接命中的事实问题；
• 需要跨段落合并的问题；
• 多版本冲突；
• 表格计算；
• 无答案问题；
• 权限边界；
• 缩写和错别字；
• 多轮指代；
• Prompt Injection 文档；
• 旧制度与新制度同时存在。

6.12 一个企业 RAG 生产架构

Sources
  ├─ Files / Wiki / DB / Ticket / API
  ↓
Ingestion & Parsing
  ├─ OCR / Layout / Table / Version / ACL
  ↓
Index Layer
  ├─ Dense / Sparse / Metadata / Graph
  ↓
Query Layer
  ├─ Intent / Rewrite / Decompose / Filter
  ↓
Retrieval & Rerank
  ↓
Context Builder
  ├─ Dedup / Version / Token Budget / Citation
  ↓
LLM / Tool
  ↓
Answer + Evidence + Trace
  ↓
Eval / Feedback / Re-index

必须横向加入：租户隔离、权限、审计、加密、缓存策略、数据删除和索引更新 SLA。

6.13 Case B：传统大型企业知识助手

错误的起点

“把 500 万份内部文档全部向量化，再接一个最强模型。”

正确的拆解

1. 哪些部门、角色和系统先进入范围？
2. 哪些问题需要搜索文档，哪些需要查结构化系统？
3. 权限是文档级、段落级还是字段级？
4. 制度版本如何判定生效？
5. 哪些回答必须引用原文？
6. 哪些高风险领域必须人工复核？
7. 数据更新和删除多久生效？
8. 失败应表现为“不知道”，还是给出转人工路径？

第一阶段建议

选择一个知识边界清晰、数据质量较高、可量化节省时间的场景，例如 IT 运维手册、HR 制度查询或产品售后知识。先建立端到端评测，再扩展到合同、财务等高风险领域。

6.14 客户问题：检索已经找到正确文档，为什么模型还答错

普通回答：找到文档不等于模型拿到了正确、完整的证据。

专业 SA 回答：请检查最终 Prompt，而不是只看检索页面。可能出现 Chunk 截断、Rerank 顺序错误、旧版本冲突、证据被过多噪声稀释，或模型无法完成跨段推理。

更深一层：把失败分成：

Retrieval Error
Context Assembly Error
Reasoning Error
Grounding / Output Error

为每一层保存 Trace 和独立指标，才能知道应该调索引、Reranker、Prompt、模型还是工具。

6.15 客户问题：有 1M Context，为什么还需要 RAG

普通回答：能放进去，不等于应该全部放进去。

专业 SA 回答：长 Context 适合一次性阅读大材料，但会增加 Prefill、KV、延迟和成本；RAG 还提供权限过滤、版本控制、动态更新和引用组织。

更深一层：比较的是：

把多少信息送给模型
× 模型能否有效利用
× 信息是否有权限和版本约束
× 端到端时延与成本

生产方案通常是 Long Context、RAG、摘要、缓存和 Tool 的组合，而不是二选一。

6.16 常见误区

误区一：Embedding 模型越大，RAG 一定越好

领域、语言、Query 类型、Chunk 结构和 Rerank 都会影响结果。必须在客户数据上测 Retrieval Recall 和最终回答。

误区二：TopK 越大越不容易漏

Recall 可能提高，但噪声、冲突和成本也会增加。正确做法是高召回 + 精排 + 动态 Context。

误区三：RAG 可以彻底解决幻觉

RAG 提供证据，不保证模型一定遵守证据。还需要 Grounding Prompt、引用、Verifier、拒答和业务约束。

误区四：GraphRAG 一定比普通 RAG 高级

只有问题需要实体关系、多跳路径、全局主题，且数据可以可靠构图时，图结构才可能带来价值。简单 FAQ 使用复杂图谱可能只是增加维护成本。

6.17 本章 Decision Tree

客户有知识问题
  ├─ 知识是否动态 / 私有 / 需引用？是 → RAG / Tool
  ├─ 主要是一次性长材料？是 → Long Context + 结构化读取
  ├─ 主要是输出行为或格式？是 → SFT / Fine-tuning
  ├─ 数据是结构化表？是 → Query / SQL Tool，不要只做向量化
  ├─ 召回不稳定？
  │    ├─ 检查 Parsing / Chunk / Embedding / Hybrid / Filter
  │    └─ 再引入 Rerank
  ├─ 召回正确但答案错？
  │    ├─ 检查 Context Assembly / 冲突 / 截断
  │    └─ 检查模型推理与 Grounding
  └─ 上生产前必须完成权限、版本、无答案和 Injection 测试

本章测试题与参考答案

1. 为什么企业知识库不是“向量数据库 + LLM”？
   因为还包含解析、版本、权限、查询理解、混合检索、精排、上下文组织、引用和评测。
2. Chunk 太小和太大的主要风险是什么？
   太小导致语义断裂；太大导致相似度稀释、噪声和 Token 浪费。
3. Dense 与 Sparse 为什么经常要混合？
   Dense 擅长语义，Sparse 擅长精确实体、编号和稀有词。
4. 检索正确但答案错误时先看什么？
   看最终进入模型的 Context、版本、排序、截断和证据冲突，再判断模型能力。
5. 权限过滤为什么必须在检索阶段做？
   防止未授权内容进入 Context、日志、缓存和模型输出链路。

课堂练习

选择一个真实客户知识场景，把 20 个 Bad Case 分成 Parsing、Retrieval、Rerank、Context、Reasoning、Grounding、Permission 七类，并为每类定义一个可观测指标和一个优先修复动作。

延伸阅读

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Anthropic: Effective Context Engineering for AI Agents
• Qwen3 Embedding
  

第 7 章：Agent、Tool、MCP 与 Sandbox——从“能回答”到“能完成”

本章要解决的客户问题

“只要模型会 Function Calling，就是 Agent 吗？”
“为什么 Agent Demo 很惊艳，生产环境却经常卡住？”
“MCP、Tool Calling、A2A 分别解决什么问题？”
“Agent 为什么必须有 Sandbox？”
“Multi-Agent 是不是一定比单 Agent 强？”

本章前置知识

需要理解 LLM 的自回归生成、Context、Tool 调用与基本评测。不要求掌握强化学习算法。

7.1 Agent 的最小定义

一个实用而不过度神化的定义是：

Agent 是一个以目标为输入，能够基于当前状态选择动作、作用于外部环境、读取新观察并持续调整，直到完成、失败或被中止的系统。

它与普通聊天的差异，不是“回答更长”，而是结果会改变外部状态：创建文件、修改代码、查询数据库、提交工单、操作浏览器或调用业务 API。

最小循环：

Goal
→ Observe current state
→ Decide / Plan
→ Select Action / Tool
→ Environment changes
→ Read Observation
→ Verify progress
→ Continue / Stop / Ask for help

术语卡：Action 与 Observation

Agent 的能力不是 LLM 单独提供的，而是：

Agent Capability
= Model Reasoning
× Context Quality
× Tool Quality
× Environment Reliability
× State Management
× Verification
× Governance

7.2 Function Calling、Tool Calling、MCP 与 A2A

这些概念经常被混在一起，但解决的是不同层的问题。

Function / Tool Calling

模型根据工具 Schema，输出结构化的工具名称和参数。应用负责真正执行，再把结果返回模型。

User → LLM → {tool: "query_order", args: {...}}
                  ↓
              Application executes
                  ↓
             Tool result → LLM

它解决“模型如何表达一次工具调用”，不负责工具发现、身份、远程通信、生命周期和跨 Agent 协作。

MCP：Model Context Protocol

MCP 以标准方式让 AI 应用连接 Tools、Resources 与 Prompts，降低每个 Agent 与每个数据源/工具单独适配的 N×M 成本。2026-07-28 版规范继续覆盖 Client、Server、Capabilities、Authorization 等协议层内容。MCP Specification, 2026-07-28

通俗类比：

• Tool Calling 像模型填写“我要调用哪个功能、参数是什么”；
• MCP 像统一插座和设备说明，使不同客户端更容易接入不同工具服务器。

MCP 不自动解决：

• 工具本身是否可靠；
• 用户是否有权限；
• 参数是否符合业务语义；
• Prompt Injection；
• 高风险动作审批；
• 任务是否应由 Agent 执行。

A2A：Agent-to-Agent

A2A 面向不同 Agent 系统之间的发现、能力描述、任务委派和状态交换。它更接近“一个 Agent 如何把任务交给另一个 Agent”，而 MCP 更接近“Agent 如何连接工具和上下文”。Google 将 A2A 作为开放协议发布，官方 GitHub 持续维护其规范与实现。Google A2A

一张对比表

7.3 Workflow 与 Agent：不是“低级”和“高级”

什么时候不应该使用 Agent

• 明确的审批流；
• 固定 ETL；
• 稳定的表单校验；
• 高风险且规则可完全表达的操作；
• 极低延迟、极高吞吐的简单分类；
• 没有可验证反馈的关键业务动作。

可以使用“Agent 决策 + Workflow 执行”的混合模式：模型负责理解非结构化输入和选择路径，确定性系统负责执行、校验和记账。

SA 原则：自主程度不是价值本身。业务价值来自用最小必要自主性解决不确定性。

7.4 为什么 Demo 成功率不能代表生产成功率

Agent 是长轨迹系统。即使每一步成功率很高，多步组合后也会下降。

例如：每一步独立成功率 98%，连续 20 步都成功的概率近似为：

0.98^20 ≈ 66.8%

这个计算不是为了给出真实生产准确率，而是说明：

• 单步 98% 看起来很好；
• 长任务仍可能频繁失败；
• 步数、状态依赖和错误传播比单轮 Benchmark 更重要。

真实情况更复杂：错误并不独立，某一步失败可能污染后续 Context；外部系统也可能变化。因此生产 Agent 必须设计恢复机制，而不是寄希望于模型永远正确。

7.5 Agent 的七个核心组件

7.5.1 Goal / Task Contract

任务目标必须明确完成条件、约束、权限和输出。例如“整理客户会议材料”过于模糊，应该定义：

• 数据源；
• 时间范围；
• 不允许访问的系统；
• 输出格式；
• 事实必须有引用；
• 未知信息如何处理；
• 何时需要人工确认。

7.5.2 Planner

Planner 将目标拆成可执行步骤。规划可以是：

• 隐式：模型边做边想；
• 显式：先输出计划，再执行；
• 分层：高层目标 + 动态子任务；
• 规则辅助：预定义关键阶段，阶段内由 Agent 自主。

规划越详细不一定越好。环境变化后，过早规划的后续步骤可能失效。更实用的是滚动规划：执行少量步骤后基于新 Observation 更新计划。

7.5.3 Tool Layer

高质量 Tool 应具备：

• 清晰、短而不歧义的名称和描述；
• 严格参数 Schema；
• 明确错误码；
• 幂等或幂等键；
• 超时与取消；
• 最小权限；
• Dry-run；
• 可观察 Trace；
• 风险等级与审批规则。

不要把一个 Tool 做成“万能自然语言接口”。工具语义越模糊，模型越难稳定选择和填写参数。

7.5.4 Memory / State

“Memory”容易被泛化。应区分：

重要状态不能只存在模型 Context 中。Context 会被截断、摘要或污染；生产任务的关键状态需要结构化持久化。

7.5.5 Environment

Environment 是 Agent 可以观察和改变的外部世界，包括浏览器、代码仓、文件系统、CRM、ERP、数据库或仿真器。环境应尽量提供确定性反馈：

• 当前页面 URL；
• 操作是否成功；
• 文件 diff；
• 测试结果；
• 数据版本；
• 资源锁；
• 权限错误。

7.5.6 Verifier

Verifier 判断“是否完成、是否正确、是否安全”。可分为：

• 规则验证：Schema、范围、权限；
• 程序验证：编译、测试、SQL 约束；
• 业务验证：审批规则、金额阈值；
• 模型验证：审阅内容、检查一致性；
• 人工验证：高风险动作最终确认。

没有 Verifier 的 Agent，只是在连续产生动作，并不真正知道自己是否成功。

7.5.7 Runtime / Orchestrator

负责：

• 任务队列；
• 调度；
• Context 构建；
• Tool 执行；
• Checkpoint；
• Retry；
• 超时；
• 并发；
• 日志；
• 成本预算；
• 人工接管；
• 状态恢复。

这就是为什么“Agent 产品”不是简单套一层 Prompt。

7.6 Sandbox：Agent 执行能力的安全边界

术语卡：Sandbox

为什么不能直接在生产主机执行

Agent 生成的命令具有不确定性，外部内容还可能通过 Prompt Injection 诱导其执行恶意动作。Sandbox 需要限制：

• CPU / GPU / Memory；
• 最大运行时间；
• 文件系统挂载；
• 出网域名；
• 凭证可见范围；
• 系统调用；
• 进程数量；
• 数据持久化；
• 租户间隔离。

Sandbox 不是绝对安全

它只是降低风险，不消除风险。还需要：

• 最小权限 IAM；
• 短期凭证；
• Secret Broker；
• Egress Control；
• 镜像签名与扫描；
• 工具审批；
• 审计；
• 数据脱敏；
• 高风险动作 Human Approval。

OpenAI 的 Codex 云端模式公开描述了隔离 Sandbox 中执行任务、运行测试并生成可审阅结果的路径；GitHub Coding Agent 也在 GitHub Actions 提供的安全开发环境中进行后台工作。这些产品说明了 Sandbox 已成为 Coding Agent 的基础设施，而不是附加功能。OpenAI Codex；GitHub Copilot Coding Agent

7.7 Retry、Checkpoint、Idempotency 与 Compensation

Retry

重试不是简单重复同一个 Prompt。应按错误类型处理：

• 临时网络错误：指数退避；
• 参数错误：让模型基于错误码修正；
• 权限错误：停止并申请授权；
• 业务冲突：重新读取最新状态；
• 模型循环：改变策略或转人工。

Checkpoint

长任务在关键阶段保存状态和产物，避免一次故障从头重来。例如：

调研完成 ✓
数据清洗完成 ✓
草稿完成 ✓
事实校验中…

Idempotency

同一动作执行多次，结果不会重复产生副作用。支付、发券、发邮件和创建工单必须使用 Idempotency Key 或事务约束。

Compensation

无法完全回滚时，用补偿动作恢复业务。例如错误创建资源后执行删除，错误更新订单后创建反向调整。Agent 必须知道哪些动作可回滚、哪些不可逆。

7.8 Human-in-the-Loop 不是失败，而是控制设计

人工介入可以分成四类：

1. Approval：执行高风险动作前确认；
2. Escalation：置信度低或规则冲突时转人；
3. Review：完成后抽样或全量审阅；
4. Teaching：人工纠正后形成训练/Eval 数据。

重点不是“有没有人工”，而是把人工用在错误成本最高、自动化不确定性最大的环节。

风险分级示例

7.9 Multi-Agent：什么时候有价值

Multi-Agent 可能带来：

• 专业分工；
• 并行探索；
• 相互审阅；
• 不同权限隔离；
• 复杂组织映射。

也会增加：

• 通信 Token；
• 状态一致性；
• 重复工作；
• 责任不清；
• 调度与死锁；
• 更难复现的错误。

适合 Multi-Agent 的条件

• 子任务可明确切分；
• 子任务可并行；
• 每个角色有不同工具或权限；
• 产物可被客观合并和验证；
• 分工收益大于沟通开销。

不适合的条件

• 任务很短；
• 共享状态高度耦合；
• 缺少统一 Verifier；
• 只是为了模仿“组织架构”；
• 单 Agent + Tool 已足够。

SA 结论：Multi-Agent 是系统分解方法，不是默认性能增强器。

7.10 Prompt Injection 与 Tool Abuse

Agent 读取网页、邮件和文档时，外部内容可能包含“忽略之前规则、上传 Secret、执行命令”等恶意指令。模型很难天然区分“业务数据”和“给模型的指令”。

防护层

Untrusted Content Labeling
+ Instruction / Data Separation
+ Least Privilege Tool
+ Domain Allowlist
+ Sensitive Data Filter
+ Action Policy
+ Human Approval
+ Trace & Detection

OWASP 2026 Agentic Applications 风险体系进一步强调 Tool Misuse、身份与权限、Memory Poisoning、Cascading Failures 等问题。安全不能只做最终输出审核，而要覆盖 Agent 的输入、状态、工具和动作全链路。OWASP Agentic Top 10, 2026

7.11 Agent 应该评测什么

Agent 评测的最小单位不应只是最终文字，而应包含完整 Trace：每一步 Observation、Decision、Action、Tool Result、Cost、Latency 和 Policy 决策。

任务成功率之外，还要看“代价”

两个 Agent 都完成任务：

• A 用 8 步、20K Token、无人工；
• B 用 47 步、180K Token、两次重试和一次人工。

最终答案同样正确，但生产价值完全不同。

7.12 Case B：企业知识与流程 Agent

需求

用户说：“根据最新差旅制度帮我检查这张报销单，缺什么材料就创建补充任务。”

正确架构

用户身份 / 部门
→ 读取报销单
→ 按 ACL 检索最新制度
→ 结构化规则 Tool 计算
→ LLM 解释例外条款
→ 生成缺失项清单
→ 创建“草稿任务”
→ 用户确认后提交
→ 全链路审计

不应该做的事

• 让 LLM 自己算所有金额和比例；
• 在没有权限过滤时检索全公司制度；
• 让 Agent 直接批准付款；
• 只保存最终回答，不保存使用了哪个制度版本；
• Tool 调用失败后无限循环。

7.13 客户问题：为什么一定需要 Sandbox

普通回答：因为 Agent 生成的代码和命令不一定安全。

专业 SA 回答：Sandbox 把任务限制在隔离环境中，控制文件、网络、凭证、资源和生命周期，同时提供可重复执行与测试环境。

更深一层：Sandbox 还解决并发和环境一致性：每个任务从可追溯镜像启动，产物可审阅，失败后可销毁或从 Checkpoint 重建。它与 IAM、Secret Broker、Egress Policy 和审计共同构成执行安全，而不是单独解决全部风险。

7.14 客户问题：MCP 接好以后，Agent 是否就能稳定工作

普通回答：不能，MCP 主要解决连接标准。

专业 SA 回答：还需要工具 Schema、权限、业务错误码、状态、规划、验证、重试和运行时治理。协议可降低集成成本，但不会自动提升业务成功率。

更深一层：评估一个 MCP Server 时，应检查：

• Tool 粒度；
• 输入输出 Schema；
• Auth 与 Scope；
• Resource 是否会暴露敏感数据；
• Prompt Injection 边界；
• 超时、限流和幂等；
• 版本兼容；
• 审计和撤销。

7.15 常见误区

误区一：会调用工具就是 Agent

一次 Tool Call 只是能力部件；Agent 还要管理目标、状态、循环、验证和停止。

误区二：Agent 越自主越好

自主性扩大灵活性，也扩大风险和成本。生产设计追求“最小必要自主”。

误区三：模型升级会自动解决 Agent 稳定性

更强模型能改善规划和工具选择，但接口错误、权限、状态、幂等、恢复和验证仍是系统问题。

误区四：多 Agent 可以互相纠错，所以一定更可靠

没有独立证据和 Verifier 时，多个 Agent 可能共享同一错误并增加沟通成本。

7.16 本章 Decision Tree

客户提出 Agent 需求
  ├─ 路径是否明确、规则是否稳定？是 → Workflow 优先
  ├─ 是否需要动态观察并调整？是 → 引入 Agent
  ├─ 动作是否改变真实系统？
  │    ├─ 是 → Sandbox / IAM / Approval / Audit
  │    └─ 否 → 可先做只读 Copilot
  ├─ 是否有明确完成条件和 Verifier？否 → 不宜全自动
  ├─ 任务是否长且易中断？是 → State / Checkpoint / Retry
  ├─ 是否需要跨工具标准接入？是 → 评估 MCP
  ├─ 是否需 Agent 间委派？是 → 再评估 A2A / Multi-Agent
  └─ 上线指标必须覆盖 Task、Trajectory、Tool、Safety、Cost

本章测试题与参考答案

1. Workflow 与 Agent 的根本区别是什么？
   Workflow 路径预定义；Agent 根据运行时 Observation 动态选择后续动作。
2. MCP 主要解决什么？
   AI 客户端与工具、资源之间的标准化连接和能力协商，而不是业务正确性。
3. Sandbox 为什么不能替代 IAM？
   Sandbox 提供隔离环境，IAM 控制身份和资源权限；两者解决不同层的风险。
4. 为什么长轨迹任务需要 Checkpoint？
   避免局部故障导致全部重做，并支持恢复、审计和人工接管。
5. Multi-Agent 何时有价值？
   子任务可清晰切分、并行、角色工具/权限不同，且结果可验证合并时。

课堂练习

把“自动完成客户 PoC 报告”拆成：

• 可确定性 Workflow 的步骤；
• 需要 Agent 动态决策的步骤；
• 只读 Tool；
• 写操作 Tool；
• 必须人工审批的动作；
• 每个阶段的 Verifier；
• 失败后的 Checkpoint 与恢复策略。

延伸阅读

• ReAct: Synergizing Reasoning and Acting in Language Models
• Model Context Protocol Specification
• A2A Protocol
• Anthropic: Building Effective Agents
• OWASP Top 10 for LLM and Agentic Applications
  

第 8 章：AI Coding——为什么它是当前最成熟的 Agent 场景之一

本章要解决的客户问题

“AI Coding 的效果是不是只由模型决定？”
“为什么同一个模型在不同 Coding 产品里差异很大？”
“企业购买的是 IDE、模型，还是 Agent？”
“大仓、内部框架和安全要求应该怎么解决？”
“如何证明 AI Coding 真正提高了研发效率？”

本章前置知识

需要理解 Agent Loop、RAG、Sandbox、Verifier 与企业治理。无需是专业开发者，但应理解代码仓、Git、测试和 CI/CD 的基本作用。

8.1 为什么代码特别适合 Agent

代码任务比许多开放业务任务更容易形成高质量反馈闭环：

因此 Coding Agent 可以执行：

理解任务
→ 搜索代码
→ 制定计划
→ 修改文件
→ 编译 / 运行测试
→ 读取错误
→ 修复
→ 生成 Diff / PR
→ 人工 Review

这比“让 Agent 完成一个没有明确成功标准的市场分析”更容易验证。

8.2 从代码补全到 Agentic Software Engineering

AI Coding 产品可粗略分为五个阶段：

1. Completion：预测光标后的代码；
2. Chat / Edit：问答、解释、局部修改；
3. IDE Agent：读仓、编辑多文件、执行终端和测试；
4. Background / Cloud Agent：在远程环境中异步完成 Issue 和 PR；
5. Agentic Engineering Platform：多 Agent、自动触发、代码审查、运维、知识和治理一体化。

阶段越高，不代表一定更适合所有任务。实时小修改需要低延迟和可控；大规模重构、测试生成和迁移更适合后台长任务。

术语卡：Agentic Coding

8.3 企业真正购买的是完整 Harness

Coding Outcome
= Model
× Repository Context
× Tool / Terminal
× Execution Environment
× Test / Verifier
× Rules / Skills
× Human Review
× Enterprise Governance

这里的 Harness 指围绕模型组织上下文、工具、执行、验证和状态的系统。模型是发动机，Harness 是变速箱、底盘、仪表盘和安全系统。

为什么同一个模型在不同产品中差异明显

• System Prompt 不同；
• 文件搜索与索引不同；
• Tool 粒度与错误反馈不同；
• Context 裁剪和摘要不同；
• 是否有 Worktree / Sandbox；
• 测试、Lint 和编译是否自动执行；
• Stop / Retry / Verification 策略不同；
• 规则、技能和团队知识注入方式不同。

因此，SWE-bench 上的裸模型能力只是一个变量。客户应比较“模型 + Agent Harness + 真实仓库环境”的端到端成功率。

8.4 Repository Context：不是把全仓库塞进 Context

Context 的四个来源

1. 显式输入：Issue、需求、选中的文件；
2. 按需搜索：Grep、Symbol Search、语义搜索；
3. 持久规则：AGENTS.md、项目规范、Team Rules、Skills；
4. 动态观察：编译、测试、运行日志和 Diff。

为什么“全仓索引”不等于“全仓理解”

索引解决候选搜索，不保证 Agent 能找到最关键的调用链和隐含约束。大仓常见问题包括：

• 同名类和历史版本；
• Generated Code 干扰；
• 多语言和多构建系统；
• 内部框架文档缺失；
• 跨仓依赖；
• 权限边界；
• 几百万行代码无法同时进入 Context。

更好的策略是 Just-in-time Context：先由任务和符号定位，再按调用关系、测试失败和新观察逐步获取。

Anthropic 的 Claude Code 最佳实践明确提醒，文件读取、命令输出和对话都会快速占满 Context，Context 变满后性能可能下降。这说明“上下文管理”本身就是 Coding Agent 的核心工程。Claude Code Best Practices, 2026

术语卡：Code Index

8.5 Rules、Skills 与 Spec：把个人经验变成团队资产

Coding Agent 默认不了解企业内部约束，例如：

• 新服务必须使用哪个基础库；
• API 错误码规范；
• 数据库迁移流程；
• 代码安全红线；
• 测试覆盖要求；
• PR 模板和发布流程。

这些知识可以通过不同层注入：

Cursor 当前官方文档将 Rules 分为 Project、User、Team 与 AGENTS.md；OpenAI Codex 公开强调可用 Skills 教给 Agent 团队标准和工作流；TRAE Enterprise 公开描述了企业规则、知识库和 Agent 配置能力。共同趋势是：企业差异化不只在模型，而在可复用的工程 Context。Cursor Rules；OpenAI Codex；TRAE Enterprise

Rules 设计原则

• 只保留模型无法可靠推断的约束；
• 使用可执行、可验证的表述；
• 说明适用目录和语言；
• 不在多个位置重复不同版本；
• 与 Lint、Test、CI 等硬规则联动；
• 建立 Owner、版本和失效日期。

8.6 本地 Agent、云 Agent 与混合模式

本地 Agent

优点：

• 与开发者现有环境紧密结合；
• 交互快；
• 容易直接观察和干预；
• 某些数据不离开本地执行环境。

问题：

• 环境不一致；
• 占用开发机资源；
• 电脑离线任务中断；
• 并行 Agent 数有限；
• 凭证和网络权限难标准化。

云 / Background Agent

优点：

• 独立 Sandbox；
• 可并行；
• 环境可复现；
• 适合长任务；
• 容易集成 PR 和 CI。

问题：

• 环境准备；
• 代码和 Secret 边界；
• 网络和依赖访问；
• 成本与排队；
• 与本地状态同步。

OpenAI Codex 将独立云 Sandbox、并行任务、测试证据和可审阅变更作为核心工作方式；GitHub Copilot Coding Agent 在 GitHub Actions 环境中执行并通过 Draft PR 交付；Cursor Cloud Agents 使用隔离 VM，并提供本地/云切换；这些路线都把“可复现执行环境”放在模型之外的核心位置。OpenAI Codex；GitHub Copilot Coding Agent；Cursor Cloud Agents

8.7 当前主流产品应该如何比较

下表只总结官方公开的产品形态，不代表效果排名；具体能力会随版本快速变化，正式选型必须实测。

不能只比“支持哪个模型”

客户真正需要比较：

1. 任务成功率；
2. 大仓检索与跨仓能力；
3. 工具和测试闭环；
4. IDE / CLI / Cloud 的工作方式；
5. 内部模型和自建 MaaS 接入；
6. VPC / 私有网络 / 数据保留；
7. SSO、RBAC、审计；
8. Rules、Skills、MCP；
9. 用量、成本和模型路由；
10. 插件、依赖和供应链风险；
11. 人工 Review 与现有 CI/CD；
12. 组织推广和支持能力。

8.8 Coding Agent 的正确任务分层

高成功率起点

• 解释陌生代码；
• 生成注释和文档；
• 补充单元测试；
• 小范围重构；
• 修复可复现 Bug；
• 依赖升级中的机械修改；
• SQL / 脚本和内部工具；
• PR Review 辅助。

需要更强验证的任务

• 跨服务架构重构；
• 数据库迁移；
• 权限和安全代码；
• 性能关键路径；
• 大规模版本升级；
• 生产故障自动修复；
• 缺少测试的遗留系统。

不应直接全自动的任务

• 无明确验收标准的战略架构；
• 高风险生产变更；
• 业务规则本身尚未明确；
• 无法搭建运行环境和测试的代码；
• 许可证和来源不清的代码复制。

8.9 为什么领域专家仍然重要

Anthropic 2026 年对约 40 万次 Claude Code 会话的隐私保护研究发现，典型会话中人更多决定“做什么”，Claude 更多决定“怎么做”；领域经验更强的用户往往能给出更好的方向并更有效恢复错误。这说明 Coding Agent 更可能先放大领域判断，而不是消除领域判断。Anthropic, 2026

对解决方案团队的启示：

• 产品和运营人员也可以通过 Agent 构建原型、脚本和分析；
• 但他们仍需理解业务目标、数据和验收标准；
• “不会写代码”与“不会判断需求”是两件不同的事；
• Coding Agent 降低实现门槛，却提高了 Spec、Review 和责任边界的重要性。

8.10 如何评测 Coding Agent

不要只测代码是否生成

端到端指标包括：

AI 生成代码行数不是核心 ROI

“AI-authored lines”容易被游戏化，且代码越多不一定价值越大。更好的问题是：

• 从 Issue 到合并是否更快；
• 缺陷率是否上升；
• Review 负担是否下降；
• 测试覆盖是否提高；
• 研发是否能完成原本不会做或没时间做的任务；
• 单个成功任务的 Agent 成本和人工成本是多少。

内部 Benchmark 怎么设计

建立 30–100 个真实仓库任务：

• 不同语言和仓库规模；
• Bug、测试、重构、文档、升级；
• 包含明确验收命令；
• 冻结基础 Commit；
• 每个产品使用同等权限；
• 记录完整 Trace；
• 人工 Blind Review；
• 多次运行观察方差。

8.11 企业安全与治理清单

代码和数据

• 代码是否用于训练；
• 数据保留与删除；
• Region；
• 传输与存储加密；
• 哪些文件可被索引；
• 内部仓和子模块权限；
• Prompt / Trace 是否包含 Secret。

身份与权限

• SSO / SCIM；
• RBAC；
• Repo Scope；
• MCP Tool Scope；
• 临时凭证；
• 高风险命令审批；
• 管理员策略。

软件供应链

• IDE 插件来源；
• MCP Server；
• Dev Container 镜像；
• 自动下载依赖；
• 代码 License；
• 恶意仓库中的 Prompt Injection；
• Agent 是否可以执行项目脚本。

审计与成本

• 谁在何时使用了哪个模型；
• 读取和修改了哪些文件；
• 执行了哪些命令；
• 谁批准了 PR / Workflow；
• Token / 请求 / Agent Task 成本；
• 异常用量和风险动作告警。

8.12 Case A：大型互联网公司的 Coding Agent

背景

• 多语言 Monorepo；
• 数万研发；
• 自建模型平台；
• 不能全员长期使用最高价模型；
• 内部构建、测试和发布工具复杂；
• 强安全和审计要求。

推荐分层架构

Developer / PM / QA
→ IDE / CLI / Web / Issue
→ Enterprise Coding Gateway
   ├─ Identity / Policy / Budget
   ├─ Model Router
   ├─ Context / Index / Rules
   └─ Trace / Eval
→ Coding Agent Runtime
   ├─ Planner
   ├─ Tool / MCP
   ├─ Sandbox / Worktree
   └─ Test / Verifier
→ Repo / CI / Internal Platform

模型路由示例

• 补全、解释、简单编辑：低延迟低成本模型；
• 多文件 Bug 与复杂重构：强 Coding / Reasoning 模型；
• 代码审查：独立模型或独立 Agent；
• 高风险安全代码：模型 + 静态扫描 + 专家 Review；
• 批量后台任务：考虑价格、吞吐和并行配额。

推进顺序

1. 找 3–5 个高频、可验证任务；
2. 接入内部仓、构建和测试；
3. 建立内部 Eval；
4. 先推广愿意使用的种子团队；
5. 观察 Review 与缺陷，而不只看活跃率；
6. 将优秀 Prompt/Rules/Skills 产品化；
7. 再扩展后台 Agent 和自动化。

8.13 客户问题：TRAE、Claude Code、Codex、Cursor 到底怎么选

普通回答：没有脱离客户环境的统一最优产品。

专业 SA 回答：先明确客户是个人效率、团队 IDE、后台 Agent，还是企业工程效率平台；再比较真实仓库成功率、大仓 Context、模型接入、工具闭环、安全治理和 TCO。

更深一层：建议建立同协议 PoC：

• 相同仓库 Commit；
• 相同 Issue；
• 相同网络和工具权限；
• 相同验收 Test；
• 记录模型、Token、时延、人工干预、Diff 质量；
• 单独比较模型与 Harness 增量。

最终选择可能不是单一产品：企业可以允许不同团队使用不同前端，但通过统一模型网关、权限、审计和 Eval 管理。

8.14 客户问题：为什么接入更强模型后提升不明显

普通回答：瓶颈可能不在模型。

专业 SA 回答：检查 Repo 检索、Context、工具权限、构建环境、测试质量和任务描述。强模型无法弥补错误环境或没有 Verifier。

更深一层：对同一任务做消融测试：

弱模型 + 完整 Harness
强模型 + 完整 Harness
强模型 + 弱 Context
强模型 + 无 Test

用实验识别边际价值来自模型还是系统。

8.15 常见误区

误区一：AI Coding 等于代码补全

补全只是低延迟局部预测；Coding Agent 是长任务工程执行系统。

误区二：SWE-bench 高就适合所有企业仓库

内部框架、语言、依赖、工具和需求分布不同。公开 Benchmark 用于筛选，内部真实任务用于决策。

误区三：AI 生成代码越多，效率越高

真正指标是成功任务、质量、Review、Lead Time 和 TCO。

误区四：研发采用率低，是因为模型不够强

也可能是环境接入、延迟、额度、规则、信任、管理方式和任务选择错误。

8.16 本章 Decision Tree

客户需要 AI Coding
  ├─ 主要是补全/问答？→ IDE 低延迟体验优先
  ├─ 主要是多文件任务？→ Agent + Terminal + Test
  ├─ 需要后台并行？→ Cloud Agent / Sandbox / Worktree
  ├─ 大仓和内部框架？→ Index + Just-in-time Context + Rules
  ├─ 多模型与自建模型？→ Model Gateway / Router
  ├─ 高安全要求？→ VPC/网络、SSO/RBAC、审计、Secret、Approval
  ├─ 无测试或验收？→ 先补 Verifier，不宜全自动
  └─ ROI → 成功任务、交付周期、质量和成本，不只看代码行数

本章测试题与参考答案

1. 为什么 Coding Agent 比很多业务 Agent 更成熟？
   因为代码环境有搜索、编译、测试、Git 和 PR 等天然工具与可验证反馈。
2. Repository Index 与 Repository Understanding 有什么区别？
   Index 提供候选搜索；理解还需任务、调用关系、规则、动态日志和模型推理。
3. 企业购买 AI Coding 的完整对象是什么？
   Model + Context + Tool + Sandbox + Verifier + Governance + Cost Control。
4. 为什么 AI 生成代码行数不是核心 ROI？
   行数不等于价值，可能增加 Review 和维护负担；应看成功任务、质量和交付周期。
5. 强模型为什么可能没有提升？
   瓶颈可能是检索、环境、工具、测试或任务定义。

课堂练习

从本团队的客户中选择一个大型研发组织，设计一份 4 周 AI Coding PoC：

• 任务样本；
• 候选产品和模型；
• 环境接入；
• 安全边界；
• 成功指标；
• Bad Case 标签；
• 组织推广；
• 最终采购决策门槛。

延伸阅读

• Anthropic: Best Practices for Claude Code
• Anthropic: Agentic Coding and Persistent Returns to Expertise
• OpenAI Codex
• GitHub Copilot Coding Agent
• Cursor Agent Best Practices
• TRAE Enterprise
  

第 9 章：多模态、图像与视频生成——从“看起来好”到“生产可用”

本章要解决的客户问题

“视频模型为什么比图片模型难这么多？”
“为什么 1080P 有时反而比 720P 更差？”
“生成 30 秒，是不是 5 秒模型多算六倍就行？”
“一个 Demo 很惊艳，为什么批量生产抽卡率仍然高？”
“哪些内容能替代实拍，哪些只能辅助？”

本章前置知识

需要理解 Token、Transformer、模型推理和评测。无需掌握扩散模型公式，但应理解“压缩空间”“条件控制”和“采样”的概念。

9.1 先区分多模态理解与多模态生成

多模态理解

把图片、音频、视频、屏幕等输入转成模型可推理的表示，用于：

• 图像问答；
• 文档理解；
• 视频摘要；
• OCR 与表格；
• 屏幕操作；
• 质检与审核。

多模态生成

根据文本、图像、视频或音频条件生成新的媒体：

• Text-to-Image；
• Image Editing；
• Text-to-Video；
• Image-to-Video；
• Video-to-Video；
• 音视频联合生成；
• 视频延长、局部编辑和参考生成。

理解模型的目标是“看懂并回答”；生成模型的目标是“合成一个符合条件的新样本”。二者可以在一个统一模型或系统中协同，但评测标准不同。

9.2 图像/视频生成的最小 Mental Model

一个简化流程：

Text / Image / Video / Audio Conditions
  ↓
Condition Encoder
  ↓
生成模型在 Latent Space 中逐步形成目标表示
  ↓
VAE / Decoder
  ↓
Pixels / Frames / Audio
  ↓
Safety / Upscale / Interpolation / Post-processing

术语卡：Latent Space

术语卡：VAE

术语卡：Diffusion / Denoising

扩散模型训练时学习从带噪样本恢复更干净的样本；推理时从噪声出发，经过多步采样得到目标。通俗类比是：模型不是一次画完，而是不断把一团模糊噪声修正为更符合条件的结构。

术语卡：DiT

DiT（Diffusion Transformer）使用 Transformer 作为扩散式生成的核心骨干。原始 DiT 工作展示了 Transformer 可用于潜在空间扩散，并具有良好的规模化潜力。Peebles & Xie, 2022

术语卡：Flow Matching

Flow Matching 学习一个随时间变化的“速度场”，把简单分布逐步运输到数据分布。对 SA 来说，不需要推导微分方程，关键是理解：它是另一类生成训练/采样框架，可能改善训练稳定性或采样效率，但最终产品质量仍由数据、模型规模、条件、采样和解码共同决定。

9.3 为什么视频比图片难

一张图片只需在一个时刻满足空间一致性。视频还要同时满足：

1. Spatial Quality：每帧细节和美学；
2. Temporal Consistency：跨帧结构稳定；
3. Identity Consistency：人物、商品、服装和品牌不漂移；
4. Motion Quality：动作连续、速度合理；
5. Physical Plausibility：碰撞、重力、接触和遮挡合理；
6. Camera Language：景别、运镜、焦点和剪辑逻辑；
7. Narrative Consistency：前后事件和因果一致；
8. Audio-Visual Sync：口型、音效、对白与画面同步；
9. Instruction Following：复杂要求不丢失；
10. Controllability：可重复、可编辑、可延长。

错误会在时间维度传播

人物在第 20 帧手部结构错误，后续帧可能围绕错误状态继续生成；镜头切换后角色身份可能重新采样；物体被遮挡后再次出现，模型需要保持之前状态。

因此长视频难度不仅是帧数增加，更是：

时间跨度 ↑
→ 需要保持的状态 ↑
→ 条件冲突和误差累积 ↑
→ 一致性、叙事和编辑难度非线性上升

9.4 从像素数量理解分辨率成本

同样长宽比下：

• 720P：1280 × 720 ≈ 0.92 百万像素/帧；
• 1080P：1920 × 1080 ≈ 2.07 百万像素/帧；
• 4K：3840 × 2160 ≈ 8.29 百万像素/帧。

1080P 像素约为 720P 的 2.25 倍，4K 约为 1080P 的 4 倍。真实生成计算不会严格按像素线性缩放，因为 Latent 压缩、Patch、Attention、时长和模型结构都会影响，但数量级说明了为什么分辨率提高会显著增加显存、计算和生成时间。

为什么 1080P 可能比 720P 看起来更差

• 模型核心训练分辨率分布不足；
• 原生生成较低分辨率，再通过超分放大；
• VAE / Decoder 在高频细节上不稳定；
• 高分辨率放大了脸、手、文字和纹理错误；
• 为控制成本减少采样步数；
• 同一算力预算下，空间细节与时间一致性互相争夺容量；
• 客户把“像素更大”误当成“语义更正确”。

因此应拆分评测：

清晰度 / 锐度
≠ 人物一致性
≠ 商品真实性
≠ 动作正确
≠ 文字准确

9.5 Text-to-Video、I2V、Reference 与 Editing 的区别

产业竞争正在从“生成一个漂亮片段”转向：

多模态参考
+ 长时叙事
+ 可编辑
+ 音视频联合
+ 专业运镜
+ 生产工作流

ByteDance Seed 的公开资料显示，Seedance 2.0 使用统一多模态音视频联合生成架构，支持文本、图片、音频和视频输入，并提供 15 秒多镜头音视频输出；Seedance 2.5 在 2026-07-31 发布，官方说明将单次生成扩展至 30 秒、支持多轮延长，并增强多模态参考和时间戳级编辑。Google Veo 3.1 也强调原生音频、物理、提示遵循和创作控制；MiniMax H3 公开定位为统一文本、图像、视频、音频上下文的多模态生成模型。Seedance 2.0；Seedance 2.5；Veo 3.1；MiniMax H3

这些是厂商公开能力描述，不代表在所有业务样本上的统一排名。正式方案必须按客户素材、分辨率、语言、时长和风控实测。

9.6 Sora 技术案例：为什么“视觉 Patch”重要

OpenAI 2024 年 Sora 技术报告描述了：先把视频压缩到时空 Latent，再切成 Spacetime Patches，使用 Diffusion Transformer 在不同分辨率、时长和宽高比上训练。这一思路的重要性是把视频转成类似“视觉 Token”的统一表示，使规模化训练成为可能。OpenAI, 2024

截至 2026-04-26，OpenAI 官方页面已标明 Sora 产品不再提供，因此这里把它作为技术演进案例，而不是当前产品选型项。OpenAI Sora Status, 2026

9.7 Character、Product 与 Brand Consistency

Character Consistency

需要保持：

• 脸部结构；
• 发型、年龄、肤色；
• 服装和配饰；
• 声音；
• 身材；
• 行为习惯。

多张参考图要覆盖正面、侧面、全身、光照和表情，同时避免参考互相矛盾。身份一致不仅由人脸模型决定，还受遮挡、镜头切换、姿态和时长影响。

Product Consistency

电商和广告对“好看”的容忍度高，但对产品事实错误的容忍度低：

• Logo 不能变；
• 按钮、接口、刻度位置不能错；
• 材质与颜色需真实；
• 功能动作需符合物理和安全；
• 不能生成不存在的配件和效果。

这导致商品视频的评测与影视创意不同。一个极具美感但电钻钻头位置错误的视频，对商业生产仍是失败。

Brand Text Rendering

文字和 Logo 是高频难点。生成模型既要理解字符，又要在透视、运动、遮挡和镜头变化中保持稳定。生产上可以采用：

• 模型生成无文字干净画面；
• 后期图层叠字；
• 参考图/局部编辑；
• OCR 自动检测；
• Brand Asset Lock；
• 生成后 Compositing。

SA 原则：能用确定性后期完成的文字和 Logo，不必强迫生成模型端到端解决。

9.8 “能否替代人工”必须拆成制作环节

不要问“AI 视频能不能替代整个视频团队”，而应拆成：

创意构思
脚本 / 分镜
素材准备
拍摄 / 动画
表演 / 运镜
剪辑
配音 / 音效
字幕 / 包装
审核 / 上线

AI 可能在不同环节发挥不同作用：

更适合 AI 生成的条件

• 场景可以虚构；
• 单镜头或短时长；
• 产品细节要求较低；
• 容许多次生成选优；
• 后期可修；
• 素材生命周期短；
• 大量 SKU 和变体使传统制作不经济。

不适合直接替代实拍的条件

• 需要证明真实功效；
• 人身安全相关；
• 精密结构和尺寸；
• 法律要求真实展示；
• 长时间连续操作；
• 明星肖像、版权和授权复杂；
• 高价值品牌对每帧一致性要求极高。

9.9 模型效果评测：不要只做“主观好看”投票

生成质量的多维指标

人评协议

• 同一 Prompt 多 Seed；
• 盲评隐藏模型名；
• 样本覆盖客户真实分布；
• 给评委清晰评分锚点；
• 区分“美学偏好”和“业务错误”；
• 记录失败标签，而不只给总分；
• 对可用结果统计后期修复时间。

抽卡率与可用率

假设生成一次价格低，但每条可用素材平均需要 5 次生成，且还需人工筛选和后期，那么真实成本是：

Cost per Usable Asset
=（全部生成成本 + 人工筛选 + 后期修复 + 审核 + 失败重做）
  / 最终可用素材数

这比“每秒视频价格”更接近业务价值。

9.10 生产工作流：模型只是中间一环

Brief / Product Data
→ Script / Storyboard
→ Prompt & Reference Pack
→ Batch Generation
→ Automated QC
   ├─ OCR / Logo
   ├─ Face / Product Consistency
   ├─ Safety
   └─ Technical Specs
→ Human Selection
→ Editing / Subtitle / Branding
→ Business Review
→ Publish & Performance Feedback

企业级能力包括：

• 资产管理；
• Prompt / Reference 版本；
• 批量任务；
• 并发、队列和重试；
• 生成结果追踪；
• 风控申诉；
• 水印与 Provenance；
• 成本归集；
• 业务转化反馈。

9.11 Case C：电商和广告公司的视频生产

目标

每天为大量 SKU 生成商品短视频和广告变体，降低传统拍摄成本。

错误评测

选择 20 个“最适合模型”的商品，每个只生成一次，由内部团队判断“很惊艳”。

正确评测

按品类和业务价值分层：

• 服饰、美妆、食品、3C、家具、工具、汽车配件；
• 高销量头部 SKU 与长尾 SKU；
• 静态氛围、人物使用、功能演示、拆解结构；
• 不同分辨率、时长和语言；
• 品牌文字和真实规格；
• 每 Prompt 多 Seed；
• 统计可用率、修复时间、点击/转化与投诉。

决策矩阵

可替代性高 × 市场规模大 → 模型和工作流重点投入
可替代性高 × 市场规模小 → 标准能力覆盖
可替代性低 × 市场规模大 → 优先优化模型/控制/后期链路
可替代性低 × 市场规模小 → 不做定制

工具类商品的特殊边界

电钻、切割机、厨房电器等可使用 AI 生成氛围、场景、镜头和部分低风险演示；但涉及安全操作、真实材料效果、产品结构和功能承诺时，应使用实拍、3D/数字孪生或严格受控的参考视频。核心不是“工具类能不能做”，而是具体镜头在承担创意表达还是事实证明。

9.12 客户问题：为什么生成 30 秒不是 5 秒多算六倍

普通回答：越长越需要保持前后状态。

专业 SA 回答：除了帧数，模型要跨更长时间维持人物、物体、动作、镜头、叙事和声音。误差会累积，镜头切换还会重新引入身份和场景不确定性。

更深一层：评测时要拆：

• 单镜头连续运动；
• 多镜头叙事；
• 是否使用 Extension；
• Reference 是否跨段保持；
• 前后状态约束；
• 音视频同步；
• 长视频的后期可编辑性。

9.13 客户问题：模型 Demo 不弱，为什么客户仍不切量

普通回答：Demo 效果不等于生产稳定性。

专业 SA 回答：客户看的是可用率、抽卡、风控、并发、价格、编辑、稳定性和存量流程迁移成本。单个最佳案例不能代表批量分布。

更深一层：检查：

模型质量差距
+ 每条可用素材成本
+ 失败类型是否可修
+ API/队列/SLA
+ 风控和申诉
+ 现有素材/Prompt 迁移
+ 业务效果与组织切换成本

技术评测通过后，还需要业务和运营闭环才能转化为切量。

9.14 常见误区

误区一：分辨率越高，模型越强

像素规格只是一个维度；需要同时看语义、时间、身份、动作和可编辑性。

误区二：视频越长，价值越高

广告可能只需要 3–6 秒高可用镜头；长视频若不可控、无法编辑，业务价值有限。

误区三：参考素材越多，一致性一定越好

参考之间可能冲突，模型还要理解每个素材分别用于人物、动作、镜头还是声音。需要 Reference Pack 设计。

误区四：AI 视频便宜，所以一定值得替代人工

必须看可用率、抽卡、筛选、后期、审核和业务转化的总成本。

9.15 本章 Decision Tree

客户提出视频生成需求
  ├─ 目标是创意探索还是事实展示？
  │    ├─ 创意探索 → AI 替代空间较大
  │    └─ 事实/功能证明 → 实拍/3D/受控参考优先
  ├─ 是否要求人物/商品长期一致？是 → Reference + 分镜 + QC
  ├─ 是否要求准确文字/Logo？是 → 生成 + 确定性后期
  ├─ 是否要求长叙事？是 → 按镜头、Extension、一致性单独评测
  ├─ 是否要求原生音频？是 → 评测对白、音效和 AV Sync
  ├─ 是否批量生产？是 → 测可用率、抽卡、队列、风控、成本
  └─ 决策指标 → Cost per Usable Asset + 业务效果

本章测试题与参考答案

1. 为什么视频生成比图片生成难？
   多了时间维度，需要跨帧保持身份、物理、动作、镜头、叙事和声音。
2. Latent Space 的主要价值是什么？
   压缩高维媒体，降低生成计算；代价是压缩器会限制细节上限。
3. 为什么 1080P 不等于更可用？
   分辨率可能放大语义、身份、文字和解码错误。
4. 抽卡率为什么是商业指标？
   它决定每条可用素材需要多少次生成、筛选和后期，直接影响总成本。
5. 电商功能演示什么时候不应完全 AI 生成？
   当视频承担真实功效、安全、尺寸、结构或法律承诺证明时。

课堂练习

选三个品类：服饰、电钻、美妆。分别列出：

• 可完全 AI 生成的镜头；
• 需要实拍/3D 事实锚点的镜头；
• 必须自动检测的错误；
• 可用率门槛；
• Cost per Usable Asset 计算方式；
• 是否值得投入专项模型优化。

延伸阅读

• Scalable Diffusion Models with Transformers
• OpenAI: Video Generation Models as World Simulators
• Seedance 2.0 Official Launch
• Seedance 2.5
• Google DeepMind Veo
• MiniMax H3
  

第 10 章：企业 AI 架构、治理与模型经济学

本章要解决的客户问题

“企业是不是接一个模型 API 就够了？”
“为什么要建设 Model Gateway？”
“SaaS、专属实例、VPC 和自建模型怎么选？”
“模型单价已经很低，为什么 TCO 还是高？”
“安全、审计和模型效果怎样放进同一套架构？”

本章前置知识

需要理解模型、RAG、Agent、Inference 与基本成本指标。本章不要求掌握某一家云的具体产品名称，而是建立可跨平台复用的企业架构。

10.1 企业 AI 不是一个 API，而是一套控制系统

完整架构可以分为七层：

1. Experience / Application
2. Workflow / Agent Runtime
3. Knowledge / Tool / Context
4. Model Gateway / Control Plane
5. Model Services
6. Inference / Data / Cloud Infrastructure
7. Governance / Security / Observability（横向）

每层解决不同问题。

企业真正购买和建设的，是“模型能力可以安全、稳定、可评测、可替换地进入业务”的系统。

10.2 Application 层：从业务任务开始，不从模型开始

先定义业务任务

错误方式：

“我们要上一个企业 Agent。”

正确方式：

“把售后工单首响时间从 20 分钟降到 5 分钟，同时保持错误承诺率低于既定门槛；涉及退款的动作必须人工确认。”

任务定义需要：

• 用户；
• 触发条件；
• 输入和数据源；
• 输出和动作；
• 成功标准；
• 失败成本；
• 人工边界；
• SLA；
• 合规要求。

Copilot 与 Autopilot

• Copilot：给建议、生成草稿，用户执行；
• Autopilot：系统直接执行并改变业务状态。

多数企业应从 Copilot 或“可预览、可撤销”的半自动模式开始。随着 Verifier、数据和治理成熟，再逐步扩大自主动作。

10.3 Model Gateway：为什么会成为企业 AI 控制面

术语卡：Model Gateway

核心能力

1. 统一 API / Protocol Adaptation：Chat、Responses、Embedding、Media 等接口适配；
2. Authentication / Tenant：用户、应用、部门、项目身份；
3. Model Registry：模型版本、能力、Region、上下文、价格、状态；
4. Routing：按任务、成本、SLA、风险和负载选择模型；
5. Fallback：超时、限流、故障时降级；
6. Rate Limit / Quota：控制组织和应用用量；
7. Cache：语义缓存、Prompt Prefix、结果缓存；
8. Policy / Guardrail：内容、数据和动作策略；
9. Observability：Prompt、Token、时延、错误、质量和 Trace；
10. Billing / Allocation：成本分摊和预算；
11. Evaluation / Release：灰度、A/B、回归和版本退出。

Gateway 不应该做成什么

• 只做 HTTP 反向代理；
• 把所有厂商字段强行压成最低公分母；
• 在不记录原生能力的情况下“统一接口”；
• 只记录调用量，不记录业务任务；
• 无模型版本和 Prompt 版本；
• 无路由解释和故障回溯。

统一接口与保留差异需要平衡。企业可以定义公共能力层，同时允许高级应用访问厂商特有能力。

10.4 多模型路由：最强模型不是所有请求的默认答案

可以按什么路由

• 任务类型：抽取、分类、代码、推理、图片、视频；
• 难度：简单、复杂、不确定；
• SLA：实时、近实时、离线；
• 风险：内部草稿、外部发布、资金动作；
• 成本预算；
• Region 与数据边界；
• Context Length；
• Model Health；
• 用户或部门配额。

一个三级路由示例

Tier 1：低成本低延迟模型
  → 分类、改写、简单抽取、路由
Tier 2：通用强模型
  → 大多数知识工作、RAG、普通代码
Tier 3：高推理 / 专业模型
  → 难题、复杂代码、关键分析、失败升级

路由器怎么判断难度

• 规则：输入长度、任务类型、风险标签；
• 小模型分类；
• 初步回答置信度；
• Verifier 失败；
• 历史任务数据；
• 用户手动指定。

动态路由必须评测“错误路由成本”。把复杂任务错误送到弱模型，可能因重试导致总成本更高。

10.5 数据与身份：VPC 不是全部安全答案

数据生命周期

Collect → Transform → Send → Store → Cache → Log → Train / Evaluate → Delete

每一步都要回答：

• 数据属于谁；
• 是否包含个人/商业敏感信息；
• 在哪个 Region；
• 谁可以访问；
• 保留多久；
• 是否用于模型训练；
• 是否可删除；
• 是否进入 Trace、Cache、评测集。

网络隔离解决什么

VPC、专线和私网 Endpoint 可以减少公网暴露并控制网络路径，但不能替代：

• 身份认证；
• 细粒度授权；
• 应用层输入验证；
• Prompt Injection 防护；
• Tool 最小权限；
• 日志脱敏；
• 供应链安全；
• 模型行为评测。

租户隔离

需要考虑：

• 请求路由；
• 模型实例；
• KV / Prefix Cache；
• 向量索引；
• 日志；
• Sandbox；
• Object Storage；
• Cost Center。

共享基础设施并不必然不安全，但必须定义逻辑隔离、密钥、缓存和审计边界。

10.6 AI 安全：从输出审核扩展到全链路

NIST AI RMF 将 AI 风险管理组织为可持续的治理活动，其 Generative AI Profile 用于帮助组织识别生成式 AI 特有风险；ISO/IEC 42001 则给出建立、实施和持续改进 AI Management System 的管理体系要求。OWASP 2026 LLM 与 Agentic Top 10 强调 Prompt Injection、Sensitive Information Disclosure、Supply Chain、Excessive Agency、Tool 与身份等应用风险。NIST AI RMF；NIST GenAI Profile；ISO/IEC 42001；OWASP GenAI 2026

六类安全对象

1. Input：恶意 Prompt、Injection、敏感数据；
2. Model：越狱、偏差、模型供应链；
3. Context：RAG 污染、Memory Poisoning、权限；
4. Tool：越权、参数注入、危险动作；
5. Output：不安全代码、虚假承诺、敏感泄露；
6. Operations：DoS、成本失控、模型版本和日志。

Guardrail 的分层

不存在单一“安全模型”可以代替系统控制。

10.7 Observability：必须看完整 Trace

传统 API 监控主要看 QPS、错误率和时延。LLM / Agent 还需要记录：

• User / App / Tenant；
• 业务 Task ID；
• Model 与版本；
• System Prompt / Template 版本；
• Input、Output、Reasoning 元数据；
• RAG Query、候选、Rerank、最终 Context；
• Tool Call、参数、结果和权限；
• Agent Step、State、Retry 和 Stop Reason；
• TTFT、TPOT、Token、Cache Hit；
• Guardrail 决策；
• 人工修改和最终业务结果；
• 成本归集。

隐私与可观测性的冲突

完整 Trace 有利于调试，但也可能记录敏感信息。需要：

• 分级日志；
• 默认脱敏；
• 加密；
• 访问审计；
• 保留周期；
• 高敏任务只记录 Hash / Metadata；
• 生产样本进入 Eval 前重新授权和脱敏。

10.8 可靠性：模型也需要发布工程

模型版本升级为什么会破坏业务

新模型可能：

• 输出更详细，导致 Token 成本增加；
• 更严格拒答；
• JSON 格式细节变化；
• Tool Calling 策略变化；
• 思考时长增加；
• 旧 Prompt 失效；
• RAG 引用风格变化。

因此要有：

Model Registry
→ Offline Regression
→ Shadow Traffic
→ Canary
→ A/B
→ Rollout
→ Monitor
→ Rollback / Deprecation

Circuit Breaker 与 Fallback

• 错误率或延迟超过阈值时停止发送；
• 切到备选模型；
• 降低 Reasoning Budget；
• 关闭非关键 Tool；
• 返回可解释的降级结果；
• 避免无上限重试造成雪崩。

Fallback 不只是“换一个模型”。不同模型的 Prompt、Tool Schema 和输出格式可能不兼容，需要提前验证。

10.9 模型经济学：从 Token Price 到成功任务成本

API 调用成本

基础形式：

Model Cost
= Input Tokens × Input Unit Price
+ Cached Input Tokens × Cache Price
+ Output / Reasoning Tokens × Output Unit Price
+ Tool / Search / Media Charges

但企业业务最终应看：

Cost per Successful Task
=（模型 + RAG + Tool + Media + Infra + Retry + Human Review）
  / 成功完成的业务任务数

一个例子

模型 A 每次任务成本 0.20 元，成功率 60%；模型 B 每次 0.30 元，成功率 90%。忽略其他成本时：

A：0.20 / 0.60 ≈ 0.33 元 / 成功任务
B：0.30 / 0.90 ≈ 0.33 元 / 成功任务

两者单次价格差 50%，成功任务成本却接近。若 A 的失败还需要人工处理，B 可能更便宜。

Agent 成本为什么容易失控

一个用户任务可能触发：

• 路由模型；
• 规划模型；
• 多次搜索；
• 多轮 Tool Call；
• Verifier；
• 失败重试；
• 子 Agent；
• 最终总结。

所以 Agent 应设置：

• Max Steps；
• Token Budget；
• Tool Budget；
• Wall-clock Timeout；
• Cost Ceiling；
• 高价模型升级条件；
• Stop / Escalation。

10.10 自建推理成本怎么估

基础公式

有效 GPU 小时成本
= GPU 租赁/折旧
+ 服务器、网络、存储
+ 软件与运维
+ 冗余与闲置

单位有效 Token 成本
= 总 GPU 小时成本 / 实际成功输出的有效 Token

关键不是理论峰值，而是有效利用率：

Effective Utilization
= 真实业务负载下被有效计算使用的资源
  / 已购买或已预留资源

峰均比

客户平均需要 100 张卡，高峰需要 400 张卡。如果为了 SLA 固定预留 400 张，平均利用率可能很低。需要评估：

• 弹性扩缩；
• 在线与离线混部；
• 多租户调度；
• 预留 + 按需组合；
• 不同优先级排队；
• 高峰降级；
• 跨 Region 容量。

自建成本常被遗漏的部分

• 模型适配和 Kernel；
• Driver / CUDA / Framework 版本；
• 监控和 Incident；
• 模型下载和存储；
• 灰度和回滚；
• GPU 故障与碎片资源；
• 安全和合规；
• 24×7 运维；
• 研发机会成本。

10.11 API、专属实例与自建怎么选

决策变量

• 流量规模和增长；
• 峰均比；
• 数据合规；
• 延迟和 Region；
• 模型更新频率；
• 是否需要定制 Kernel / Fine-tuning；
• 团队运维能力；
• 供应商锁定风险；
• 业务连续性；
• 三年 TCO。

不要把“私有化”自动等同于“更安全、更便宜”。它把更多控制权交给客户，也把补丁、监控、模型更新和 Incident 责任交给客户。

10.12 企业 AI 的组织治理

技术平台之外，需要明确：

角色

• Business Owner：定义业务价值和风险；
• Model / Platform Owner：模型与平台 SLA；
• Data Owner：数据授权和质量；
• Security / Legal：风险与合规；
• Application Team：业务实现；
• Eval Owner：独立评测和发布门槛；
• Incident Owner：问题响应和复盘。

Model / Use Case Inventory

组织应知道：

• 在用哪些模型；
• 哪些应用；
• 访问哪些数据；
• 是否能执行动作；
• 风险等级；
• Owner；
• 评测状态；
• 供应商和合同；
• 退出/替换方案。

AI 变更管理

• Prompt、Rules、Index、Tool 和模型都应版本化；
• 高风险变更需要评审；
• 保留回滚；
• 定期重测；
• 安全事件和 Bad Case 进入知识库；
• 停用模型时检查依赖应用。

10.13 三个 Case 的总体架构结论

Case A：大型互联网公司

重点不是买一个最强模型，而是：

• 统一 Model Gateway；
• 自建/外部模型混合路由；
• 高利用率 Serving；
• Coding Agent Harness；
• 大仓 Context；
• 组织配额和成本；
• 全链路 Eval。

Case B：传统大型企业

重点不是最大参数，而是：

• 权限和数据边界；
• RAG 质量；
• Workflow 优先；
• 高风险动作审批；
• VPC/私网与身份；
• 审计、可解释和运维简单；
• 从一个可量化场景扩展。

Case C：内容、电商和广告公司

重点不是单次生成单价，而是：

• 素材与 Prompt 工作流；
• 多模态生成队列；
• 自动 QC；
• 人工选择和后期；
• 风控与版权；
• Cost per Usable Asset；
• 业务转化数据反馈。

10.14 客户问题：为什么要建设 Model Gateway，直接调 API 不行吗

普通回答：少量试验可以直接调，规模化后需要统一管理。

专业 SA 回答：多个应用和模型会产生认证、配额、路由、版本、缓存、审计、成本和故障切换需求。Gateway 将这些能力从每个应用中抽离。

更深一层：判断是否建设的变量包括应用数量、模型供应商、合规、流量、SLA 和组织成本。不要过早建设一个复杂平台，也不要在几十个应用各自重复实现同一控制逻辑。

10.15 客户问题：选最便宜的模型是否就能降本

普通回答：不一定，要看完成任务的总成本。

专业 SA 回答：低价模型可能输出更长、失败更多、重试更多、需要人工审核；强模型也可能通过更少 Token 和更高工具成功率降低 TCO。

更深一层：对真实任务比较：

单次调用成本
× 每任务调用次数
× 重试
+ 人工
+ 失败业务成本

并建立按难度路由，而不是所有请求统一使用最弱或最强模型。

10.16 客户问题：私有化是否一定更安全

普通回答：私有化增加控制，但不自动安全。

专业 SA 回答：安全取决于网络、身份、补丁、权限、日志、模型供应链、Sandbox 和运维。自建后这些责任转移给客户。

更深一层：用 Threat Model 比较公共 API、专属实例和私有化，列出数据流、攻击面、责任分界、恢复能力和审计证据，再决策。

10.17 常见误区

误区一：接入多个模型就等于避免供应商锁定

如果 Prompt、Tool、Eval、数据格式和应用逻辑依赖某个模型特性，换 API 仍然困难。真正解耦需要公共能力抽象和持续回归。

误区二：Guardrail 会解决所有安全问题

内容审核无法解决 Tool 越权、数据权限、Secret、供应链和错误业务动作。

误区三：自建 GPU 一定比 API 便宜

只有流量稳定、利用率高、团队有运维能力且模型适配成本可控时才可能成立。

误区四：成本优化就是压低 Token 单价

更大的杠杆可能是减少无效 Context、Reasoning、重试、工具调用和人工处理。

10.18 本章 Decision Tree

客户建设企业 AI 平台
  ├─ 是否只有单一试验应用？是 → 避免过度平台化
  ├─ 是否多应用/多模型/强治理？是 → Model Gateway
  ├─ 数据和动作风险高？是 → IAM / ACL / Sandbox / Approval / Audit
  ├─ 流量小且波动大？→ 公共 API / 弹性优先
  ├─ 流量大且稳定、需隔离？→ Dedicated / 专属实例
  ├─ 强定制、合规且具备运维？→ 评估自建
  ├─ 模型选型 → 业务 Eval + SLA + Cost per Successful Task
  └─ 上线后 → Trace、回归、灰度、Incident 与持续治理

本章测试题与参考答案

1. Model Gateway 与普通反向代理的区别是什么？
   Gateway 还承担模型注册、路由、版本、配额、缓存、策略、观测、评测和成本控制。
2. VPC 为什么不能替代应用安全？
   它控制网络路径，不解决身份、权限、Injection、Tool Abuse 和输出风险。
3. Cost per Successful Task 为什么优于单 Token 价格？
   它把成功率、重试、工具、人工和业务完成纳入同一口径。
4. 自建推理什么时候可能有优势？
   大而稳定的流量、高利用率、强定制/合规需求和成熟运维能力同时存在时。
5. 模型升级为什么必须回归？
   新模型可能改变格式、拒答、Tool 策略、Token 和延迟，破坏现有业务。

课堂练习

为一个“企业全员 AI 工作台”画出架构，并回答：

• 哪些请求走哪一档模型；
• 哪些知识使用 RAG，哪些使用 Tool；
• 哪些动作需要 Sandbox 与审批；
• 如何按部门计费；
• 模型故障如何降级；
• Prompt、模型和知识库版本如何回溯；
• 用什么指标决定扩大推广。

延伸阅读

• NIST AI Risk Management Framework
• NIST Generative AI Profile
• ISO/IEC 42001: AI Management Systems
• OWASP GenAI LLM Top 10 2026
• OWASP Top 10 for Agentic Applications 2026
  

第 11 章：综合实战——把技术知识变成客户决策

本章目标

前十章分别讲模型、系统和基础设施。本章要求团队把它们合成一条完整的解决方案逻辑：

业务目标
→ 任务与风险
→ 数据与环境
→ 模型 / RAG / Agent 设计
→ Inference / Infra
→ Eval / SLA / Security
→ Cost / ROI
→ 分阶段实施

本章建议用 30 分钟课堂讨论，课后作为团队工作坊模板。

11.1 Case A：大型互联网公司的模型与 Coding Agent 平台

客户背景

• 研发人员 20,000+；
• Java、Go、Python、前端和移动端多技术栈；
• 多个大型 Monorepo 和内部研发平台；
• 已采购多家模型，也有自建模型和 GPU；
• 高峰 Token 成本快速增长；
• 管理层要求证明研发效率收益；
• 安全团队要求代码和执行环境可控。