模型部署流程

模型部署不是把权重下载下来、启动一个推理框架就结束。真正上线的是一套可复现、可评估、可灰度、可回滚的服务链路。

一句话概括：

模型部署流程的目标，是让模型版本、运行环境、评估结果、性能边界和回滚方案都处在可控状态。

一个典型流程如下：

需求确认
  -> 模型选择
  -> 许可证和合规检查
  -> 模型文件下载与校验
  -> tokenizer / chat template 检查
  -> 格式转换或量化
  -> 离线质量评估
  -> 性能压测
  -> 安全测试
  -> 推理服务配置
  -> 灰度发布
  -> 监控与回滚
  -> 版本归档

---

先明确上线目标

部署前要先回答几个问题：

• 服务面向什么业务场景？
• 是通用问答、代码、客服、RAG、工具调用，还是多模态？
• 需要多长上下文？
• 是否需要流式输出？
• 是否需要 JSON、tool calling、function calling 或结构化输出？
• 目标延迟、吞吐、并发和成本是多少？
• 是否允许调用外部 API 或内部数据？
• 是否有安全、审计、隐私或许可证约束？

不同目标会直接影响模型选择和服务配置。一个适合离线总结的大模型，不一定适合低延迟客服；一个榜单分数很高的模型，也不一定适合稳定工具调用。

---

选择基座模型或微调模型

模型选择要同时看能力、成本和工程兼容性。

常见维度包括：

• 参数规模和架构：Dense、MoE、长上下文、多模态。
• 语言和领域能力：中文、英文、代码、数学、专业知识。
• 上下文长度：官方标称长度和实际可用长度要分开验证。
• 推理框架支持：vLLM、SGLang、Transformers、llama.cpp 等是否兼容。
• tokenizer 和 chat template 是否完整。
• 工具调用、JSON mode、reasoning mode 是否稳定。
• 显存、吞吐和单位 token 成本。
• 许可证是否允许商用、再分发、微调或托管服务。

微调模型还要额外检查：

• 基座模型版本是否明确。
• adapter 是否和基座权重匹配。
• 是否需要 merge LoRA。
• 微调数据是否覆盖目标任务。
• 微调后是否退化了通用能力、安全能力或格式能力。

不要只看单轮 demo。上线模型至少要通过真实任务集、边界样例和失败样例的评估。

---

确认许可证和使用边界

许可证检查要在模型下载和集成之前完成。

重点确认：

• 是否允许商用。
• 是否允许 SaaS 或 API 托管服务。
• 是否允许微调和再分发。
• 是否要求保留版权声明。
• 是否限制特定行业或用途。
• 是否有模型输出内容的附加条款。
• 训练数据、评测数据和业务数据是否有合规边界。

对企业系统来说，许可证不是文档角落里的附属信息，而是上线门禁。模型、权重、adapter、embedding 模型、rerank 模型和推理框架都需要分别确认。

---

下载和校验模型文件

模型文件应当进入可追踪的制品管理流程，而不是手工复制到服务器。

需要记录：

• 模型来源。
• repo id 或下载地址。
• commit hash、revision 或 release tag。
• 文件清单。
• 文件大小。
• checksum。
• 下载时间。
• 操作人或流水线任务。

常见模型资产包括：

• 权重文件，例如 *.safetensors、*.bin、*.gguf。
• config.json。
• tokenizer 文件。
• generation_config.json。
• chat template。
• processor 或 image processor。
• adapter 权重。
• 量化配置。
• 模型卡和许可证文件。

校验重点：

• 文件是否完整。
• 权重分片数量是否正确。
• tokenizer 是否和模型匹配。
• config.json 中的架构、层数、head 数、上下文长度是否合理。
• 推理框架是否能识别模型类型。
• 是否混入旧版本文件。

很多部署事故不是模型能力问题，而是模型资产版本不一致。

---

检查上下文与位置编码配置

上线前要单独核对一遍模型的上下文长度和位置编码相关配置。
这些内容不属于“概念理解”，而属于很典型的部署兼容性检查项。

常见字段包括：

字段	含义
max_position_embeddings	模型配置声明的最大位置数
rope_theta	RoPE 的频率基数
rope_scaling	RoPE 的缩放配置
sliding_window	滑动窗口 attention 的窗口大小
max_sequence_length / max_model_len	推理服务允许的最大序列长度
original_max_position_embeddings	某些长上下文扩展模型记录的原始训练长度

这些字段不是单独生效的。部署时要一起核对：

• 模型权重和 config.json 是否匹配。
• tokenizer 的 padding 方向是否和推理框架一致。
• 推理引擎的上下文上限是否超过模型真实能力。
• position_ids、attention_mask 和 KV Cache 的实现是否一致。
• 长上下文扩展模型的 rope_scaling、rope_theta 是否和官方配置一致。

如果这里配置错了，模型往往不会直接报错，更常见的表现是：

• 短输入正常，长输入明显变差。
• 长文档问答经常漏后半段或中间内容。
• 输出重复、断裂、格式混乱。
• 多轮对话里突然忘记前文。
• 同一模型在不同推理框架中的效果差异很大。

如果要理解这些字段背后的原理，可以看：

• 位置编码
• 提示工程
• KV Cache

---

检查 tokenizer 与 chat template

上线前必须确认模型实际看到的 prompt 是否正确。

检查项包括：

• bos_token、eos_token、pad_token 是否正确。
• special tokens 是否完整。
• system、user、assistant 边界是否正确。
• 多轮对话是否按训练格式渲染。
• thinking、tool calling、多模态占位符是否按模型要求出现。
• stop token 是否和模板匹配。
• token 计数是否符合预期。
• 中文、代码、JSON、长文本是否能正常编码和解码。

建议把渲染后的 prompt 作为部署验收材料保存。这样线上出现“模型不听 system prompt”“工具调用格式异常”“回答混入角色标记”时，可以快速判断是模型问题、模板问题还是服务拼接问题。

相关阅读：

• Tokenizer
• Chat Template

---

格式转换与量化

不同推理框架可能需要不同格式。

常见转换包括：

• Hugging Face 权重转推理框架内部格式。
• LoRA adapter merge 到基座权重。
• FP16 / BF16 转 INT8、INT4、AWQ、GPTQ、GGUF 等。
• 多分片权重重新切分。
• safetensors 与其他格式互转。

量化可以降低显存和成本，但也可能影响：

• 困惑度。
• 事实性。
• 数学和代码能力。
• 长上下文稳定性。
• 工具调用 JSON 格式。
• 多语言表现。
• 生成速度和吞吐。

量化后不能只看模型能否启动，要重新跑质量评估和格式评估。尤其是 RAG、工具调用、代码生成和结构化输出场景，低比特量化可能带来不明显但致命的格式退化。

---

离线质量评估

离线评估用于判断模型是否有资格进入压测和灰度。

建议至少覆盖：

• 真实业务问题。
• 高频问题。
• 长尾问题。
• 拒答样例。
• 安全样例。
• 多轮对话。
• 长上下文样例。
• JSON 或工具调用样例。
• RAG 有答案和无答案样例。
• 多语言或混合语言样例。

评估方式可以组合使用：

类型	适合场景
规则评估	JSON、字段、引用、格式、关键词
人工评审	主观质量、业务可用性、风险判断
LLM-as-judge	大规模语义评分和对比评估
回归集	防止新模型破坏已有能力
对抗集	检查越权、幻觉和安全边界

评估结果要和模型版本、prompt 版本、推理参数、数据集版本绑定。否则同一个分数无法复现，也无法判断改动到底来自哪里。

相关阅读：

• 质量与评估

---

性能压测

LLM 压测不能只看 HTTP QPS。更关键的是 token 维度。

需要记录：

• input token 分布。
• output token 分布。
• 并发请求数。
• TTFT。
• ITL。
• E2E latency。
• tokens/s。
• 请求成功率。
• GPU 利用率。
• 显存占用。
• KV Cache 命中和占用。
• 队列等待时间。

压测样例要接近真实流量。只用短 prompt 测出来的吞吐，会严重高估长上下文场景的能力；只用固定输出长度压测，也看不到用户追问、RAG 拼接和工具调用带来的波动。

常见压测结论包括：

• 单卡或单实例最大并发。
• p95 / p99 延迟边界。
• 最大可接受上下文长度。
• 单请求最大输出 token。
• 是否需要副本扩容。
• 是否需要拆分长任务和短任务队列。
• 是否需要限制用户侧参数。

相关阅读：

• 并发与批处理
• KV Cache
• 容量与成本规划

---

安全测试

安全测试要覆盖模型本身和系统链路。

模型侧关注：

• 越狱。
• 有害内容。
• 隐私泄露。
• 编造事实。
• 拒答边界。
• 高风险建议。
• prompt injection。

系统侧关注：

• RAG 文档权限是否正确。
• 工具调用是否越权。
• 是否能访问未授权数据。
• 日志是否泄露敏感信息。
• 用户输入是否污染系统 prompt。
• 外部工具返回内容是否被模型盲信。
• 是否存在 SSRF、命令执行、SQL 注入等传统安全风险。

大模型系统的安全边界不只在 prompt。权限、工具、数据、日志、网络和人工审核都要进入安全设计。

---

推理服务配置

上线前要固化推理服务配置。

常见配置包括：

• 模型路径。
• tokenizer 路径。
• tensor parallel / pipeline parallel。
• 最大上下文长度。
• 最大并发。
• 最大 batch token。
• GPU memory utilization。
• dtype。
• quantization。
• 默认 temperature、top_p、max_tokens、stop。
• 是否启用流式输出。
• 是否启用工具调用 parser。
• 健康检查接口。
• 日志采样策略。

推理参数也应当有边界。不能让调用方随意传入超长上下文、超大输出或高随机性参数，否则评估结果和线上行为会脱节。

相关阅读：

• 推理服务架构
• 推理参数

---

灰度发布

通过离线评估和压测后，仍然不应该直接全量上线。

常见灰度方式：

• shadow traffic：复制真实请求到新模型，但不影响用户。
• canary：少量用户真实使用新模型。
• A/B test：不同用户分流到不同版本。
• 白名单：先给内部用户或特定客户使用。
• 路由分层：低风险场景先切，高风险场景后切。

灰度期间要重点观察：

• 错误率。
• 延迟。
• token 成本。
• 用户反馈。
• 人工质检结果。
• 拒答率。
• RAG 命中率。
• 工具调用成功率。
• 安全拦截率。
• 和旧版本相比的质量差异。

灰度不是走形式，而是用真实流量验证离线评估没有覆盖到的问题。

相关阅读：

• 灰度发布与回滚

---

回滚方案

上线前必须有回滚方案。

可回滚对象包括：

• 模型权重。
• tokenizer。
• chat template。
• prompt。
• 推理参数。
• 量化版本。
• RAG 检索策略。
• embedding 或 rerank 模型。
• 工具 schema。
• 路由规则。
• 服务镜像。

常见回滚触发条件：

• 错误率超过阈值。
• p95 / p99 延迟超过阈值。
• 成本异常升高。
• 安全问题。
• 大量用户投诉。
• 核心任务质量下降。
• 工具调用失败率上升。
• RAG 引用错误率上升。

回滚方案要能被执行，而不是只写在文档里。至少要确认旧版本制品仍可用、路由能快速切换、配置能恢复、回滚后数据兼容。

---

版本记录和复现

每次上线都应该形成版本记录。

建议记录：

• 模型名称和版本。
• 权重 revision。
• tokenizer revision。
• chat template 版本。
• prompt 版本。
• 推理框架和镜像版本。
• 推理参数默认值。
• 量化方式。
• 评估数据集版本。
• 评估结果。
• 压测结果。
• 灰度时间和范围。
• 回滚方案。
• 已知问题。

好的版本记录能回答三个问题：

1. 线上现在跑的是什么？
2. 为什么允许它上线？
3. 出问题时如何恢复和复现？

---

常见上线问题

问题	常见原因
模型能启动但回答异常	tokenizer、chat template 或 stop token 不匹配
离线效果好，线上效果差	prompt、参数、RAG、用户输入分布不一致
压测结果很好，线上延迟高	压测样例 token 分布太短
显存突然爆掉	长上下文、KV Cache、并发或 batch token 超限
工具调用格式不稳定	模板、parser、schema 或温度参数不合适
引用经常错误	RAG 召回、重排或上下文拼接有问题
灰度无法判断好坏	缺少基线指标和人工质检样本
回滚后仍异常	prompt、路由、缓存或下游配置没有一起回滚

---

上线检查清单

• 模型许可证已确认。
• 模型文件和 checksum 已记录。
• tokenizer 和 chat template 已验证。
• 推理框架兼容性已验证。
• 量化或格式转换后重新评估。
• 离线质量评估通过。
• 安全评估通过。
• 压测覆盖真实 token 分布。
• 推理参数边界已设置。
• 日志、指标和 trace 已接入。
• 灰度方案已确定。
• 回滚方案已演练或至少可执行。
• 版本记录已归档。

模型部署的关键不是“跑起来”，而是把每一次模型变更都纳入可验证、可观测、可回滚的工程流程。