交付上线

一、走向生产环境的三座大山

1. 成本：API Token 费用 → 微调/蒸馏小模型降本
2. 部署：单机 → 服务器部署（高可用/监控）
3. 安全合规：用户输入泄露/模型不当输出 → 合规要求

二、蒸馏：让小模型掌握专业能力

2.1 蒸馏 vs 微调

• 蒸馏的本质是在微调之前增加一步高质量数据构建环节
• 不需要先把教师模型微调到极致再蒸馏，直接用当前最强 API 模型生成数据即可
• 行业实例：DistilQwen2.5 系列（0.5B-7B）多模型协作教师蒸馏；DeepSeek-R1 将 671B 的 80 万条推理轨迹蒸馏到 7B，数学推理超越 LLaMA-2 70B

2.2 蒸馏三条路径

暗知识/软标签概念（白盒蒸馏）：

• 教师模型输出最终答案时的概率分布（如"HR 70%、行政 25%、IT 5%"）包含了"HR 和行政有点像"的隐含知识（暗知识），比只看最终答案信息量更大
• 白盒蒸馏让学生拟合教师的概率分布，精度更高

选数据合成的三条理由（本章场景）：

1. 教师模型是 API，无法访问权重（白盒 KD 不可行）
2. 任务是单步判断，不需要 CoT 推理轨迹
3. 结构化输出可用 JSON Schema 自动校验，数据质量有保障

2.3 适合蒸馏的任务特征

• 输出格式固定（JSON schema）
• 不依赖外部知识
• 高频调用链路
• 成本敏感

2.4 不适合蒸馏的场景及替代方案

2.5 蒸馏的能力边界

• 0.6B 模型适合"高频、固定域、单步判断"的专用任务，不是小号通用助手
• 在系统中角色是预处理器，不是全能替代品

三种典型失败场景：

1. 意图间有依赖关系的多意图（如"请假后自动调整考勤"，0.6B 难以捕捉因果关系）
2. 训练集未覆盖的罕见组合（如"IT支持 + 差旅申请"）
3. 极度含糊的表达（如"那个事情帮我处理一下"）

数据分布与生产不匹配陷阱：

• 合成数据的表达模式可能与真实用户提问方式存在差异
• 缓解：适当混入真实数据，帮助模型适应实际分布

2.6 数据合成流程

1. 生成多样化提问（覆盖多种意图/部门/表达风格，约 30% 多意图问题）
2. 教师标注（大模型 + temperature=0.1 + 严格 System Prompt）
3. 质量过滤：JSON 解析失败 / 必填字段缺失 / 取值越界
4. 格式化：转为 ms-swift 的 messages 格式（system/user/assistant）

质量过滤方法论：

• 使用结果校验（检查输出是否符合 schema），而非过程校验（检查推理过程）
• 对结构化提取任务，结果校验更简单有效

2.7 评测指标

• JSON 合规率：能否解析为合法 JSON 且包含所有必填字段
• intents F1：意图识别 F1 值（精确率 + 召回率综合）
  • 为什么用 F1 而非准确率：意图是多选的，准确率无法区分"漏了一个"和"全错"；F1 同时反映"找全了"（召回率）和"没找错"（精确率）
  • 计算方式：对每条样本的预测意图集合和真实意图集合分别求精确率和召回率 → 取调和平均 → 所有样本取算术平均
• route 准确率：路由决策是否正确
• 语义正确 vs 字符串匹配：关注语义正确性（字段值在预定义范围内且符合语义），而非字符串完全匹配

2.8 LoRA 微调原理

概念：LoRA秩(rank)决定可训练参数量，选择时需综合考虑硬件限制、数据规模、任务复杂度和基础模型规模。
核心思想：不修改原始权重 W，在旁边挂低秩矩阵 ΔW = A×B 学习变化量

• 当 d=4096, r=8 时，参数量仅为全参数微调的 0.4%
• 保留模型 97% 以上基础能力，避免灾难性遗忘

损失函数与梯度下降：

• 损失函数：量化"预测与期望的差距"，损失越小输出越接近训练数据
• 梯度下降：每步沿"损失下降最快方向"调整参数
• 学习率：太大→反复震荡无法收敛；太小→收敛极慢；合适→稳步逼近

训练状态判断：

训练关键参数：

训练常见问题：

2.9 成本收益分析

• 大模型 API（qwen-plus）：日均 2 万次 → 月成本约 960 元
• 蒸馏小模型 GPU 部署（T4 实例 3.6 元/小时）：工作时间运行 → 月成本约 864 元
• 盈亏平衡点：~1.8 万次/日(工作日) 或 ~5.4 万次/日(24h)
• 额外优势：延迟低(~50ms vs ~500ms)、数据不出域、离线可用、稳定性高

2.10 混合架构

• 蒸馏模型做预处理 → RAG 做知识查询 → 大模型做最终回答（三者各司其职）
• 流程：员工提问 → [蒸馏模型]结构化理解({intents, route}) → [RAG系统]查询知识库 → [大模型]生成回复

⚠️ 合规提醒：开源模型(Apache 2.0)做教师可自由商用；商业模型条款可能禁止用其输出训练竞品

快速验证流程：正式训练前，先用少量样本做快速实验。若基座模型已能基本完成需求，或微调后提升不明显，重新评估任务选择

三、模型部署

3.1 直接调用（无需部署）

• 适用：业务初期或中小规模
• 优势：零部署、按 token 计费
• 注意：QPM/TPM 限流；微调模型或未支持的模型无法直接调用

3.2 测试环境部署（vLLM）

• 专为大模型推理设计的开源框架
• 步骤：下载模型 → 安装 vllm → vllm serve 启动
• 兼容 OpenAI API（/v1/chat/completions、/v1/models）
• 压测工具：wrk，模拟不同并发量测试 QPS 和延迟
• 结论：并发 1→10，QPS 提升 ~6 倍，平均延迟增加 ~30%

3.3 云上部署方案对比

3.4 部署决策维度

1. 核心需求（快速上线/低成本/常规模型/自定义环境）
2. 模型兼容性（千问→百炼；通用→FC/EAS/ECS/ACK）
3. 运维复杂度与团队能力
4. 成本：FC 按请求付费 < EAS 按实例付费 < ECS 按量/包月 < ACK 综合最高

3.5 扩展部署模式

四、大模型应用生产实践

4.1 业务需求分析

功能性需求（定义"模型做什么"）：

• 模型准确度可使用自定义或公开评测集评估（MMLU 语言理解、BBH 复杂推理）

非功能性需求（确保"做得怎么样"达标）：性能、成本、稳定性

4.2 性能优化

系统性能提升策略：

GPU 为什么必要：

• LLM 推理本质是大规模矩阵运算
• CPU：少量强大核心（8-64），适合复杂逻辑/串行任务
• GPU：海量简单核心（数千到数万），适合大规模并行计算
• 用 CPU 集群替代 GPU 不能有效提升 LLM 推理速度（架构不适合矩阵并行运算）

三种并行化详解：

• 数据并行：将输入数据分片到多个设备
• 模型并行：将不同层或参数分配到不同设备
• 流水线并行：将计算分为顺序阶段

max_tokens vs 提示词引导的对比：

• max_tokens 设计哲学：是"安全阀"而非内容控制机制——宁可生成可续的中间结果，也不让一次调用变成无限增长的成本/延迟/资源消耗

SLO 关键指标：

用户感知优化：流式输出、分块处理、展示任务进度、完善错误处理（分类+友好提示+重试/降级）、用户反馈入口

错误处理三原则：

1. 清晰易懂（避免技术术语）
2. 具体明确（说明原因+提供解决方案）
3. 情感友好（温和语气，避免沮丧用户）

• 自动重试应设置最大重试次数和间隔（过大过短都增加资源消耗）

4.3 成本优化

• 性能优化方法本身即可降本
• GPU 实例规格选择：模型参数量 → 显存需求 + KV Cache + 精度设置

GPU 实例选择计算示例（DeepSeek-R1 671B）：

• 模型存储：625GB (FP8)
• KV Cache（MLA 优化）：70KB/token/卡
• 64K token 长度 8 卡：KV Cache ≈ 35GB
• 总计 ≈ 660GB，适合 ecs.ebmgn8v.48xlarge（8×96GB）
• 并发限制：64K token 长度 8 卡仅能服务 ~4 并发请求

计费方式：

4.4 稳定性

• 降低资源消耗：模型小型化、异步批处理、缓存高频结果
• 自动化扩缩容：ESS 动态调整实例 + SLB 负载均衡
• 评测基线管理：
  1. 从简单开始建立基线（如关键词匹配客服达 70% 准确率）
  2. 跨时间和场景维度定期测试
  3. 数据/业务变化时动态调整基线
  4. 集成到自动化流程（自动拦截不合格模型 + 5% 用户灰度发布）
• 实时监控与告警：成本(Token 消耗)、性能(响应时间/SLO)、质量安全(敏感内容)
• 容灾设计：
  • 降级与熔断（切换备份模型/规则引擎兜底）
  • 跨地域部署
  • 定期故障演练（模拟模型异常、网络中断、服务器崩溃等验证容灾方案）
  • 快速创建备用环境

4.5 可观测性

• ARMS（阿里云应用实时监控服务）：基于 OpenTelemetry 标准

设计阶段指标阈值示例：

• 部署四步法：盘点(确定观测指标) → 设计(目标值+告警阈值) → 接入(先观测再管控) → 运营(看板→调用链→日志→新告警)

扩展：

• 多卡 PD 分离(Prefill/Decode 分离)：DistServe 将 prefill 和 decode 阶段分配到不同卡，chunked prefill + 异步流水线显著提升吞吐降低延迟
• MLOps：ML + DevOps 组合，自动化和标准化 ML 模型全生命周期管理

五、安全合规

5.1 安全攻击类型

关键术语：

• 提示词注入 (Prompt Injection)：注入新指令覆盖/劫持模型原有任务
• 指令注入 (Command Injection)：通过 Agent 工具注入可执行代码（区别于提示词注入）
• 幻觉 (Hallucination)：模型在缺乏数据时自信编造看似合理的错误答案
• 知识库投毒：向 RAG 知识库注入恶意/错误内容

关键词过滤的三大局限：

1. 同义词绕过（如"差旅标准"→"招待预算"）
2. 编码混淆（base64 等伪装恶意内容）
3. 猫鼠游戏永无止境

法律后果实例：

• 个人信息风险：违反《个人信息保护法》；OpenAI 和 Google 面临数十亿美元集体诉讼
• 内容安全风险：歧视性内容引发舆论风暴
• 知识产权风险：Stability AI 被 Getty Images 起诉

5.2 为什么用安全护栏而非大模型自身防御？

• 大模型确实通过对齐训练拒绝了大部分攻击
• 但在 Agent 场景中，需要明确稳定的响应格式（如 error: data_inspection_failed）以编程式终止执行
• 依赖模型自防御需额外开发工具，尤其多模型时拒绝格式不同
• 专用安全服务更可靠

5.3 AI 安全纵深防御体系（五层）

层1：资产盘点与布防

• 核心资产：模型权重、数据(知识库+交互日志)、应用(逻辑/配置/System Prompt)、基础设施
• 资产监控三法：
  1. 识别已知风险：云安全中心、云防火墙、WAF、RASP、SDDP 扫描防御空隙
  2. 监控资产异常：CTDR、AI-SPM、AI-BOM、API 安全监控
  3. 人工审计：定期安全审计防火墙策略、资产清单、最新威胁情报
• 布防三原则：
  1. 统一流量入口：强制所有流量经过 WAF 和云防火墙
  2. 建立行为基线：定义正常行为、限制 IP 访问频率、异常地理访问告警
  3. 分级保护：模型和知识库严格访问控制和监控

层2：基础设施安全

• 传统加固：VPC 网络隔离、系统补丁、KMS 静态数据加密、RAM 最小权限
• 零信任：永不信任，始终验证
• 可信计算：TPM 芯片逐级度量启动链，构建不可篡改信任链
• 机密计算：CPU 硬件创建 TEE(可信执行环境)，数据"使用中"也全程加密
• 远程证明：
  • 证明报告包含：硬件身份证明（CPU 厂商根钥签名）+ 软件完整性证明（即将加载到 TEE 代码的实时哈希）
  • 两步验证：用 CPU 厂商公钥验证硬件身份 → 对比报告中代码"指纹"与本地原始代码指纹
• 安全推理的"高考"类比：可信计算=考场(可信环境)；机密计算=独立座位(隔离计算空间)；远程证明=考前验证(验证正确的"人"带正确的"试卷"在正确的"空间")
• 异构机密计算实例安全推理流程：
  1. 离线：加密模型+密钥存 KMS，配置访问策略仅允许 Trustee 访问
  2. 运行时：TEE 向 Trustee 申请密钥，提供硬件签名证明报告，Trustee 验证后通过加密通道投递密钥
  3. 推理：TEE 从 OSS 拉取加密模型，在 TEE 内解密，明文模型加载到受 TEE 保护的 GPU 显存
• 隐私计算：联邦学习 / 多方安全计算 / 机密计算

层3：大模型安全

• 训练数据风险 → 数据治理与清洗、PII 脱敏、SDDP 深度扫描
• 对抗性攻击 → 对抗性训练：主动引入精心构造的对抗样本（微小扰动导致模型误判的样本），迫使模型学习更鲁棒特征
• 模型窃取 → RAM 访问控制 + WAF 频率控制 + 数字水印溯源
• 大模型安全三要素：
  • 公平性(Fairness)：数据审计 + 算法优化消除偏见
  • 鲁棒性(Robustness)：压力测试确保对抗干扰下稳定
  • 可解释性(Interpretability)：生成清晰"决策报告"，摆脱黑盒

层4：应用安全（实时三层防御）

• RAG 高级防护：
  • 知识库访问控制：
    1. 根据用户信息查询数据访问权限
    2. 检索 Top-K 文档后检查访问控制属性
    3. 过滤无权限文档后再送入 LLM
    • 示例：普通员工只能查看自己的薪酬方案；管理者可查看下属方案
  • 知识库双重加密：
    • 文本 AES-CTR-256 加密：保护文本内容
    • 向量 DCPE 加密：保护向量数据
      • 为什么要加密向量？(1) 攻击者可通过分析向量距离和聚类模式推断敏感主题（如 CEO 薪酬附近的向量大概率也涉及高管薪酬）(2) 研究表明向量在某些场景可近似反推出原始文本
    • 加密保留近似距离关系，破坏精确数值结构
    • 流程：(1) 加密存储：分别加密文本块和向量 (2) 密文检索：加密用户问题向量，与库中加密向量匹配 (3) 解密推理：解密检索到的文本块连同原始问题送入 LLM
    • 使用 rai_sam 库实现

层5：合规与备案

• 企业行动：合规前置（纳入上线检查清单）、善用平台工具、明确合规负责人

5.4 阿里云 AI 安全护栏

• 核心能力：内容安全审查、多模态防护（文本+图像）、超长上下文、流式处理
• 百炼调用：添加请求头 X-DashScope-DataInspection: {"input":"cip","output":"cip"}
• 拦截返回：error.code = "data_inspection_failed"
• 词库管理：自定义敏感词库，命中返回 label: customized
• 防护覆盖：内容合规、数据泄露、提示词注入、幻觉、越狱