开放权重模型如何落地生产：AI 团队迁移清单

Demo 往往没问题。真正的麻烦出现在账单之后：模型升级改变了 tokenizer，采购突然问许可证，或者一张 GPU 不可用时，整条 Agent 流程开始排队。到了这一步，“我们能运行开放权重模型”就不再是架构选择，而是一项运维项目。

我不会从排行榜开始。先明确你想消除的风险：供应商锁定、数据驻留、吞吐可控，还是必须让模型和自有工具待在同一环境里。然后把许可证、权重、服务、评测和回滚整条路径一起验证，再迁移流量。

先说结论

• 开放权重只减少一层依赖，不会消除 GPU、服务、升级和合规工作。
• 必须用自己的任务集把模型和 serving stack 一起评测。
• 在延迟、成本和质量有真实流量数据前，保留托管模型回退。
• 模型 revision、tokenizer、量化方式和服务配置应作为一个发布单元固定。

“开放”到底要检查什么

“开放权重”不是许可证类别。至少把下面 4 个问题分别记录：

问题	要收集的证据	为什么会改变决策
能否下载权重？	模型仓库和访问条款	需要申请时，部署时间会改变。
能否商业使用？	License 文本和 acceptable-use policy	公开 checkpoint 仍可能有限制。
能否修改或量化？	License 和供应商说明	量化、微调可能形成衍生物。
能否再分发？	License、model card、打包条款	内部服务和交付模型不是一回事。

Hugging Face 模型索引适合发现候选，但排序不是许可证结论。生产记录仍应保存 model card 和 license URL。

图 1：模型索引帮助找到候选，真正决定能否使用的是仓库的许可证和 model card。

不要只测 tokens per second

纸面上便宜的模型，算上 GPU 内存、batch、冷启动和运维时间后可能并不便宜。建议至少测：

• 目标并发下的首 token 时间和 tokens per second；
• 符合真实请求的 prompt 长度；
• 结构化输出和 tool call 成功率；
• 接近上下文上限时的失败表现；
• 每个成功任务的成本，而不是每个生成 token 的成本。

托管基线和自托管候选必须使用同一批 prompt。记录模型 revision、量化方式、GPU、runtime、batch 配置和 tokenizer，否则升级后无法复现比较。

Serving layer 要单独选

vLLM 之类的项目可以提供面向生产的推理服务，但 server 不是完整平台。鉴权、配额、请求 tracing、自动扩缩容、健康检查和超长 prompt 策略仍然需要你负责。

图 2：推理服务器只是部署的一层，应用策略和可观测性仍由团队负责。

先说个坑：还没测排队时间就开始优化吞吐。tokens per second 很高，并不代表 p95 体验好；大 batch 可能让请求一直等在队列里。

让应用契约保持稳定

应用应该调用稳定的内部契约，模型路由则放在可配置的 adapter 里。权重或量化变化时，触发和改应用代码一样的评测与回滚流程。

MODEL = {
    "name": "provider/model-revision",
    "tokenizer": "provider/tokenizer-revision",
    "quantization": "bf16",
    "max_context": 32768,
}

def evaluate_response(response: dict) -> bool:
    return bool(response.get("text")) and response.get("finish_reason") in {"stop", "tool_calls"}

迁移最容易漏掉的失败

1. 内存压力： prompt 变长或并发 batch 导致 OOM。需要准入限制和明确的 429 路径。
2. 质量漂移： 新量化方式改变 tool call 格式。保留 golden task 和 schema 校验。
3. 容量缺口： 单张 GPU 不可用时，不要无限排队，切换到托管回退。
4. 安全缺口： 下载制品和日志可能包含敏感 prompt。限制出网、扫描镜像并定义保留期。

托管回退不是失败，而是把受控实验和线上事故分开的方法。

SandBase 在架构里的位置

SandBase 可以提供托管模型/API 这一侧，让团队在自有基础设施上评估开放权重路径。边界要写清楚：SandBase 不会把第三方 checkpoint 变成自托管模型；自托管也不会替你解决稳定 API 契约。

如果工作流不只有 LLM，还需要搜索、社交数据、图片或视频 API，就把这些调用放进各自 adapter。可以先看统一 API 指南，再用 Docs quickstart确认当前鉴权和请求路径。

图 3：评估自托管路径时，也要把托管回退的鉴权和请求契约固定下来。

生产签字前

• 许可证和再分发条款已经由明确负责人审核。
• 模型、tokenizer、量化、runtime 和 server 配置全部固定。
• 针对任务质量和 tool call 的测试通过托管基线对照。
• p50/p95 延迟、排队时间、错误率和成功任务成本有记录。
• 回滚和托管回退真正演练过，而不是只写在文档里。
• 日志、下载制品和出网策略有 Owner。

最后的结论可能仍然是“继续使用托管模型”。当运维成本大于它消除的依赖时，这就是正确答案。

来源

• Hugging Face 文本生成模型
• vLLM 文档
• SandBase Docs