开源模型如何选：不要从排行榜开始

排行榜回答的是“某个模型在某组公开任务上得了多少分”，企业要回答的却是“它能否在我们的数据、硬件和责任边界内稳定完成任务”。两者之间隔着许可证、语言分布、输入长度、量化方式、并发、失败代价和升级策略。榜单可以用来发现候选模型，但不适合决定最后部署谁。

一个更可靠的顺序是：先排除不能合法或经济运行的模型，再用真实任务确认质量，最后比较全链路成本。这样得到的结果可能不是能力最强的模型，却更接近可以长期维护的系统。

先确认你获得了哪些权利

“可以下载权重”不等于“开源”，也不等于允许任意商业用途。开放源代码促进会的 Open Source AI Definition 1.0从使用、研究、修改和分享四类自由定义开放 AI，并要求提供进行修改所需的首选形式和相关信息。这比“开放权重”更严格，也提醒采购团队不要只看仓库是否公开。

审查时至少记录许可证名称、商业使用限制、可接受使用政策、再分发要求、衍生模型条款、训练数据披露和适用法域。许可证不明确时，不应把“社区普遍这样用”当作法律结论；需要由能承担责任的人做正式判断。

Hugging Face 的模型卡文档要求说明预期用途、限制、训练数据和评测结果。模型卡不是合规证明，但它是一张检查缺失信息的清单：如果连语言覆盖、上下文长度、已知限制和评测条件都没有，后续工程风险会由使用方承担。

还要区分模型原始版本、社区微调版和量化版。三者可能使用不同许可证、聊天模板与安全对齐，模型卡中的结果也不一定适用于二次转换后的权重。生产清单应记录仓库提交、文件校验值和实际加载配置，而不只写一个家族名称。

把硬约束放在能力评测之前

先写清部署环境：允许使用的显存和内存、峰值并发、首 token 延迟、持续吞吐、上下文上限、是否离线运行、数据能否离开设备。然后对候选模型采用计划中的量化精度和推理引擎实测。模型参数量只是容量线索，不能替代目标硬件上的测量。

MLPerf Inference把数据中心和边缘场景分开，并在给定质量约束下比较延迟或吞吐。这种设计比单看每秒 token 更接近工程问题：如果为了速度降低精度后任务质量跌出门槛，那个吞吐数字就没有业务意义。

测量时同时报告冷启动、稳定负载与峰值负载。长上下文会改变显存占用和首 token 延迟，批处理能提高吞吐却可能增加单个请求等待。平均值之外至少保留 P50、P95、失败率和测试时的并发、输入长度分布，避免把实验室最优点当作服务承诺。

评测集要从失败记录里长出来

先收集 100 至 300 条真实任务样本，并有意识加入旧系统最容易失败的案例：混合语言、长表格、缺字段、相互冲突的指令、格式约束和拒答边界。把样本分成开发集和冻结测试集，避免针对测试答案反复调提示。

指标应与任务一致。结构化抽取可以计算字段级准确率、格式通过率和遗漏率；客服草稿需要事实忠实度、政策合规和人工修改量；代码任务需要在隔离环境运行测试，而不是让另一个模型只评价“看起来不错”。所有模型使用相同模板、解码参数和工具条件，结果才有可比性。

评测还要重复运行一部分样本，观察非确定性带来的波动。若一个模型平均分达标，却在同一高风险问题上偶尔越过约束，应把这类尾部失败单独设门槛。评审人员不知道候选模型名称，可以减少品牌预期对主观评分的影响。

维度	示例权重	必须记录的证据	一票否决条件
许可与数据边界	20%	许可证原文、数据流向、日志策略	商业用途不允许或条款不清
任务质量	35%	冻结测试集、失败类型、置信区间	关键字段错误超过容忍值
性能	20%	目标硬件 P50/P95 延迟与吞吐	峰值负载无法满足服务级别
总成本	15%	硬件、能耗、工程、监控和升级	预算只覆盖推理而忽略运维
可替换性	10%	接口适配、回归集、回滚时间	业务逻辑与单一模型强绑定

评分只用于通过硬门槛后的候选模型；不能用高总分抵消许可证或安全上的不可接受风险。

总拥有成本不等于 GPU 租金

可以把月度成本拆成：计算资源、闲置容量、存储与网络、推理平台维护、评测与监控、事故处理和升级迁移。小流量业务自建 GPU 的闲置成本可能高于 API；稳定高吞吐或强数据边界场景，自托管才更可能显出优势。

还要计算“每个成功任务”的成本，而不是每百万 token。假设模型 A 单次便宜 30%，但需要更多重试和人工修正，它的有效成本可能更高。最简单的计算是：月总成本除以通过业务验收的任务数，并单独报告高风险错误，避免平均值掩盖事故。

一次工单抽取选型应该怎样做

假设任务是从中英文售后工单提取产品、问题、紧急程度和下一步动作。先用许可证和 16GB 显存限制筛掉不合适候选，再在目标量化版本上运行冻结集。质量门槛设为关键字段准确率和 JSON 格式通过率，性能门槛设为峰值并发下的 P95 延迟；通过者再比较人工修正分钟数和月总成本。

如果两个模型质量接近，优先选择部署链成熟、模型卡完整、升级路径清楚的一个，而不是为了榜单上微小差异承担额外运维复杂度。如果没有模型达到关键字段门槛，应调整任务边界或保留人工确认，而不是降低验收标准来证明选型成功。

为替换而设计，而不是为某个模型定制系统

模型更新很快，真正长期有效的资产是任务数据、评测脚本、结构化接口和失败记录。把提示版本、模型版本、量化配置和评测结果一起保存；业务逻辑留在代码与规则层；对模型输出使用明确 schema 和校验。

最终决策应是一份可以复跑的记录：为什么这些模型进入候选、在哪个版本和硬件测试、通过了哪些门槛、失败集中在哪里、切换需要多少工作。还要注明批准人、复查日期和停止使用的触发条件。这样下一次模型发布或输入分布变化时，团队只需重跑证据，而不必重新陷入排行榜争论。