大模型选型七步闭环 (LLM Model Selection)

Overview

把客户的业务需求与合规边界，转成可交付、可被追问、可被验证的模型选型方案。适用于写标书技术方案、方案沟通材料、客户答疑、售前被追问。

核心原则：

• 排除法优先：先问"哪些是不能选的"，再问"哪个最好"。四闸触发即出局，硬约束不参与比选
• 不制造质量差异：分数接近就写"无显著差异"，不许把 0.5% 说成优势
• 每个数字能指到来源：型号、参数量、显存、许可、单价，只允许来自客户原文或官方文档

When to Use

• 客户给了业务场景 + 合规要求，需要给出模型选型与理由
• 投标技术方案需要写"选型依据"章节
• 客户问"为什么不选 XX""为什么不用开源""自建还是调 API"
• 需要把"我们认为该选什么"变成客户能验收的结论

不要用于：模型微调 / 训练方案设计（用其他 skill）、GPU 采购选型、AI 平台产品选型、纯 API 接入开发。

什么时候根本不是「选型」

这一节比后面六步都重要。 很多标书里的"选型"其实是排除法的包装，硬跑七步反而暴露判断力不足。

方案层 vs 研发层的决策边界（越界就是编）：

客户原文只写品牌时，方案层就只写品牌 + 部署形态，型号标「由研发按客户算力定」。诚实划界比编一个型号可信得多。

必备 vs 可选输入

工作流（7 步）

严格按 1→7 顺序。 第 1 步没跑完不要进第 4 步——在已被排除的候选里比规格是白做。信息缺口在第 2 步一次问清（最多 3 个问题）。

1｜一票否决四闸

许可 / 硬件显存 / 数据驻留 / 来源国别，四条任一触发即排除，不做权衡。许可读具体 checkpoint 的 LICENSE；量化后 权重 + KV cache ≤ 可用显存 × 0.85；推理、存储、备份三个位置都要在法域内。

详见 references/constraints-and-veto.md。

2｜问客户 10 项

效果基线 / p95时延 / 数据分级 / 驻留法域 / 输出语言 / 许可类别 / 运维能力 / 年请求量 / 峰值并发 / 锁版要求。这 10 项任何模型清单都替代不了。 缺项用行业默认值补，但必须标「假设，需客户确认」。

详见 references/constraints-and-veto.md。

3｜定架构

交互式低并发 or 批量高吞吐 → 稠密 or MoE；要不要视觉/OCR；真实文档长度 P95。batch=1 稠密赢、batch>32 MoE 赢；MoE 省算力不省显存（总参数决定显存）。标称上下文 ≠ 可用上下文，按真实语料 P95 算。

详见 references/architecture-and-specs.md。

4｜比规格

先列候选池（至少 2 个模型家族），再横向比8 个维度：总参 / 激活参 / 架构 / 原生上下文 / 扩展方式 / 4-bit 权重显存 / KV cache / 许可。只在通过第 1、3 步的候选里比，型号必须回原始文件逐字核对。

详见 references/architecture-and-specs.md。

5｜跑 PoC

≥100 个真实业务用例（变化大则 500+），预留 20% 盲测集，三维度打分：质量 / 单任务成本 / 延迟。同一套 prompt 跑所有候选，业务方盲评仲裁，权重先定后跑。

详见 references/poc-and-cost.md。

6｜定结论 + 算成本

统计上接近时，按 成本 / 时延 / 治理 / 集成复杂度 选，不制造质量差异。成本必须按**「每个成功任务的成本」**算，不是每百万 token 单价：

C_api  = (T_in × P_in + T_out × P_out) × R / S
C_self = (年GPU 小时 × 单卡小时成本 + 年运维分摊) / 年成功任务数

算钱用年请求量法，验容量用峰值并发法——两个结论别混。

详见 references/poc-and-cost.md、references/decision-and-governance.md。

7｜上线治理

回归测试集 + 第二个已批准模型 + 测过 failover。重跑时机：供应商大版本 / 检索数据变更 / 用户行为变化 / 硬件换代。

详见 references/decision-and-governance.md。

输出物

主交付 = 单个 HTML 选型报告 + Markdown 副本。

详见 references/selection-report-template.md（表结构）、assets/selection-report-template.html（样式）。

交付前自检3 问

这三条比十页方案更能证明判断力。 每份报告交付前逐条过：

1. 如果客户明天改掉某条约束（C3 数据不出境、C6 需生成粤语），这个结论会不会翻？ 不会翻 → 那条约束是装饰品，不是硬约束，删掉或标为"参考项"
2. 每个型号数字能指到官方 config.json / 模型卡，或客户方案原文的某一行吗？ 指不到 → 标「需核实」，不写进结论
3. 主推和备选的差别，是成本差还是硬约束差？ 如果只是成本差，要说清差多少个百分点；如果硬约束差，说清是哪个闸

硬性约束

完整 12 条见下方红线检查清单。 冲突时以红线清单为准。最容易踩的四条：

红线检查清单

• 四闸都跑过了，每条排除都有依据编号
• 10 项约束表填满，缺失项标了「假设，需客户确认」
• 已判定本次是排除法还是比选法，并在报告里说明
• 型号是逐字抄的，能指到 config.json / 模型卡 / 客户原文
• 每个候选的许可按该 checkpoint 单独查过，未按家族推断
• 每个结论标了约束编号（如 [C3][C7]），能反查到约束表
• 主推 + 备选 + 切换触发器齐全
• 成本给的是每成功任务成本，含放大系数 R 与成功率 S
• 所有单价字段标了来源，没有编造数字
• 统计接近处写的是「无显著差异」，没有拔高
• 结论不是「参数越大越好」，落在效果/成本/时延/治理之一
• 已划清方案层与研发层的决策边界
• PoC 用同一套 prompt，权重先定后跑，盲测集 ≥ 20%
• 交付前自检 3 问都过了
• 全文无赋能 / 抓手 / 闭环 / 打造 / 深度融合 等 AI 味词
• 全文无客户实名、无报价金额
• 模型版本标了检索日期，距今不超过 6 个月

Resources

references/

• constraints-and-veto.md — 第 1–2 步：四闸判定 + 问客户 10 项（含非 NVIDIA 加速卡判定顺序）
• architecture-and-specs.md — 第 3–4 步：稠密/MoE 判断 + 候选池构建 + 横向规格比
• poc-and-cost.md — 第 5–6 步前半：PoC 设计 + 成本测算公式
• decision-and-governance.md — 第 6 步后半–7 步：定结论 + 上线治理
• selection-report-template.md — ★ 报告 8 块表结构（核心交付物）
• objection-handling.md — 客户异议应答 + 诚信边界（七步之外，用于答疑与评审现场，不是流程节点）
• hk-context.md — 香港语境：繁中拐点 / 粤语 / 政府云取向 / 金融监管
• model-landscape.md — 模型生态快照（有检索日期，超 6 个月必须重核；不是型号库，候选池需自己构建）
• anti-ai-style.md — 去 AI 味替换词典（售前方案语域，跨文件共用）

assets/

• selection-report-template.html — 报告统一样式 HTML（可选美化产物，结构以 md 为准）

scripts/

本 skill 不需要脚本。需要核实型号规格或许可时，用 WebFetch / WebSearch 查官方 config.json、模型卡、厂商定价页。