开源模型选型与部署
问题
如何选择并部署开放权重模型？模型显存、KV Cache、量化、批处理、推理引擎、弹性扩缩、安全和可观测性应该怎样设计？
开源模型部署不是“下载权重、起一个接口”这么简单。要同时做六件事：
- 按任务评测模型，不按榜单或参数量选型。
- 审核模型、数据和代码许可证，确认商业与分发边界。
- 估算权重、KV Cache、激活和运行时开销，再决定量化与硬件。
- 根据数据中心吞吐、低延迟或端侧需求选择推理引擎。
- 建设鉴权、配额、输入输出安全、隔离和供应链校验。
- 以“每个成功任务成本”为目标，观测质量、延迟、吞吐和失败。
一、为什么部署开放权重模型
适合的动机包括：
- 数据必须留在指定网络或设备。
- 需要控制权重、量化、推理引擎和升级节奏。
- 稳定高负载下，自建单位成本可能更可控。
- 要在边缘设备、浏览器或离线环境运行。
- 需要加载 LoRA Adapter 或做深度任务定制。
不适合的情况也很常见：请求量小且波动大、团队没有 GPU 运维能力、供应商 API 已满足合规和质量要求，或业务需要平台独有的实时能力。应比较总拥有成本，而不是只比较 token 单价。
二、模型选型清单
1. 任务能力
建立自己的代表性评测集，至少覆盖：
- 中文、英文、代码、多轮、长上下文和结构化输出。
- RAG 引用、工具调用、无答案与拒答。
- Prompt Injection、越权请求和敏感数据。
- 目标硬件量化后的真实质量，而不是只测原始精度。
2. 许可证与血缘
“可以下载”不等于“可以任意商用”。检查：
- 权重许可证、可接受使用政策和地域限制。
- 是否允许商业使用、再分发、衍生模型和蒸馏。
- 推理代码、Tokenizer、量化文件和数据集各自的许可证。
- 模型卡中的训练范围、已知限制和安全评估。
许可证会变化，发布时保存准确版本和文本快照；涉及商业决策时由法务确认。
3. 工程兼容性
- 架构是否被目标引擎和硬件支持。
- Chat Template、Tokenizer、RoPE/长上下文配置是否一致。
- Tool Calling、JSON Schema、多模态和推理内容块是否兼容。
- 社区权重文件是否来自可信发布者，是否有哈希或签名。
三、显存如何估算
权重
粗略估算：
权重显存 ≈ 参数量 × 每参数字节 + 量化元数据与运行时开销
FP16/BF16 通常按每参数约 2 字节估算；低比特量化不能简单按理论位数计算，还要考虑 scale、zero point、分组和未量化层。
KV Cache
KV Cache 随并发、上下文长度、层数和模型结构增长，常常决定服务能承载多少长对话：
KV Cache ≈ 并发序列 × token 数 × 每 token 的 K/V 状态大小
采用 GQA/MQA、低精度 KV Cache、分页管理或缩短上下文可以降低压力，但都要验证质量和兼容性。
其他开销
- CUDA/驱动上下文和推理引擎工作区。
- 激活、采样、Logits 和临时 Buffer。
- 多模态编码器、Adapter 和 Speculative Draft Model。
- 碎片与安全余量。
因此容量规划必须用目标引擎、真实序列分布和并发做压测，不能只靠公式把显存装满。
四、量化的取舍
| 方案 | 主要收益 | 主要风险 |
|---|---|---|
| 权重量化 | 降低权重显存、提高可部署性 | 质量下降、内核支持不一致 |
| 权重与激活量化 | 可能提升吞吐和利用专用硬件 | 校准更复杂、任务敏感 |
| KV Cache 量化 | 增加长上下文并发 | 长上下文质量和数值稳定性 |
| CPU/端侧格式 | 在普通硬件运行 | 速度、算子和上下文受限 |
量化选择不要只报告“几比特”，还要记录算法、分组、校准数据、计算 dtype、内核和硬件。相同位宽的实现，性能与质量可能明显不同。
五、推理引擎如何选择
| 场景 | 常见选择 | 关注点 |
|---|---|---|
| GPU 数据中心高吞吐 API | vLLM、SGLang 等 | 连续批处理、分页 KV、并行、结构化输出 |
| 复杂 Agent/结构化生成 | SGLang 等 | 前缀复用、约束解码、运行时编排 |
| CPU、Apple Silicon、边缘设备 | llama.cpp 生态 | 量化格式、设备卸载、单用户延迟 |
| 浏览器 | WebGPU 推理框架 | 下载体积、兼容性、内存和降级 |
| 专用加速器 | 厂商运行时 | 编译、算子覆盖、锁定风险 |
这里没有永久“最快”的引擎。模型架构、输入输出长度、并发、硬件和版本都会改变结果，选型必须基于本地压测。
六、服务架构
Gateway 负责稳定协议和治理，推理后端专注生成。即使后端提供 OpenAI-compatible API，也不要假设所有字段、流事件、工具调用和错误语义完全相同，应在网关做能力协商与规范化。
interface ModelEndpoint {
id: string;
revision: string;
capabilities: {
chat: boolean;
tools: boolean;
jsonSchema: boolean;
vision: boolean;
reasoning: boolean;
};
limits: {
contextTokens: number;
maxOutputTokens: number;
maxConcurrency: number;
};
}
七、吞吐和延迟优化
连续批处理
把不同时间到达、不同长度的请求动态组成批次，提高 GPU 利用率。批次越大不一定体验越好，要分别观测 TTFT 和每 token 延迟。
分页 KV Cache
通过页式管理减少 KV 内存碎片，让更多序列共享显存池。它改善容量管理，但不会消除长上下文的计算成本。
前缀缓存
系统 Prompt 或共享文档前缀可复用时，缓存其计算结果。缓存键必须包含模型、Tokenizer、模板、Adapter、前缀内容和安全域，防止跨租户泄漏。
Speculative Decoding
Draft Model 先提出 token，Target Model 批量验证；接受率足够高时可以降低生成延迟。收益取决于两个模型的匹配、输出分布和硬件开销。
并行策略
- Tensor Parallel：单层计算跨设备拆分，通信频繁。
- Pipeline Parallel：模型层分阶段，需处理流水线空泡。
- Data Parallel：复制模型处理不同请求，适合可放入单实例的模型。
- Expert Parallel：MoE 专家跨设备分布，关注路由和负载不均。
优先选最简单、能满足 SLO 的方案；并行越复杂，故障面和通信成本越高。
八、弹性与调度
- 按队列长度、在途 token、KV 使用率和 SLO 扩缩，而不只看 GPU 利用率。
- 区分短请求、长上下文和批处理，避免大请求阻塞交互流量。
- 设置最大输入、最大输出、并发、步骤和租户预算。
- 冷启动较长时保留最小容量，或使用请求排队与明确等待状态。
- 过载时拒绝或降级到小模型，不能无限排队拖垮整个集群。
九、安全与供应链
模型制品
- 只从允许的仓库和发布者拉取，固定 revision 与哈希。
- 优先使用不可执行的权重格式；谨慎加载可执行自定义代码。
- 扫描镜像、依赖和模型仓库，不在生产自动追踪
latest。 - 模型、Tokenizer、模板和安全策略作为一个可回滚发布单元。
运行时
- 网关统一鉴权、限流和审计，推理端不直接暴露公网。
- 多租户缓存、Adapter、日志和批处理需要隔离。
- 对工具调用和 RAG 做资源级授权，模型不能替代权限系统。
- Prompt 和输出默认不完整记录；必要采样先脱敏并限制保留。
十、可观测性与压测
至少记录：
- TTFT、inter-token latency、总耗时和排队时间。
- 输入/输出 token、并发序列、批次大小和结束原因。
- KV Cache 使用、命中/驱逐、显存和碎片。
- 吞吐、过载拒绝、OOM、重启和硬件错误。
- 模型/Tokenizer/模板/量化/引擎精确版本。
- 任务质量、安全切片和每个成功任务成本。
压测流量要保留真实的输入长度、输出长度、并发和取消分布。只用短 Prompt 跑最大 QPS，无法代表生产长对话。
十一、上线检查清单
- 任务评测优于可接受基线，量化版本也已单独评估。
- 许可证、用途、模型卡和供应链来源完成审查。
- 容量测试覆盖长上下文、并发、流取消和过载。
- API 能力、错误和流事件在网关被规范化。
- 权限、配额、租户隔离和日志脱敏已验证。
- 模型制品可追踪、可灰度、可快速回滚。
- 故障时有降级模型、排队上限或明确拒绝策略。
十二、面试常见问题
Q1：自建模型一定比调用 API 便宜吗？
答案：不一定。要计算 GPU 闲置、峰值容量、运维、人力、网络、存储和升级成本，并比较每个成功任务成本。低流量或波动大时 API 往往更简单。
Q2：模型显存为什么不等于权重文件大小？
答案：还包括量化元数据、KV Cache、激活、引擎工作区、Adapter、上下文和碎片；并发和序列长度常让 KV Cache 成为主要变量。
Q3：什么是连续批处理？
答案：运行时动态把不同到达时间和长度的序列加入/移出批次，提高 GPU 利用率，同时兼顾流式请求。
Q4：什么是 PagedAttention？
答案：它用类似分页的方式管理 KV Cache，减少连续大块内存需求和碎片。它主要改善内存管理，不等于模型推理本身没有计算成本。
Q5：量化会不会降低效果？
答案：可能，且不同任务敏感度不同。必须在目标硬件、目标内核和代表性数据上比较原精度版本，不能只看通用榜单。
Q6：vLLM、SGLang 和 llama.cpp 怎么选？
答案：数据中心高吞吐通常评估 vLLM/SGLang，CPU 与端侧常评估 llama.cpp；最终根据模型支持、延迟、吞吐、结构化输出和运维复杂度压测决定。
Q7：为什么要在推理服务前放 Gateway？
答案：统一鉴权、配额、路由、协议、审计和降级，避免业务直接依赖某个引擎的非标准行为，也缩小推理节点的公网攻击面。
Q8：如何做多租户隔离？
答案：在鉴权、队列、缓存键、日志、Adapter、RAG 权限和配额各层绑定租户；不能只在请求 Prompt 里写租户名。
Q9：为什么不能只按 GPU 利用率扩容？
答案：GPU 高利用率可能是健康批处理，也可能是长请求堵塞。应结合队列、在途 token、KV 使用率、TTFT 和 SLO。
Q10：OpenAI-compatible 是否代表完全兼容？
答案：通常只表示主要 HTTP 形状相近，工具、Schema、Usage、流事件和错误可能不同。需要能力声明、契约测试和网关适配。
Q11：如何安全加载社区模型？
答案：固定可信 revision 和哈希，审查许可证，避免未经审计的远程可执行代码，扫描依赖，并让制品经过注册表后再发布。
Q12：部署优化应该先看吞吐还是延迟？
答案：看产品 SLO。交互应用优先 TTFT 和取消体验，批处理优先总吞吐；二者都要在质量不退化的前提下优化。