经过 14.1 到 14.3 节的分析，你已经初步圈定了候选范围：也许是闭源 API 与开源私有化之间二选一，也许是在 7B、70B 和 MoE 架构之间做权衡。但纸面参数只能帮你排除明显不匹配的选项，最终决策必须靠实测。本节提供一套可直接落地的“选型测试 SOP”，帮助你在 2–4 周内完成从候选清单到最终定型的闭环。
一、核心原则：不是找“最强”的，而是找“最匹配”的
大模型领域没有通吃的“天下第一”。GPT-4 级模型在客服场景可能因过度推理而答非所问，某开源 7B 模型在特定法律条文检索上经微调后反而更精准。评估的本质是将业务需求翻译成技术指标，再用可控实验验证匹配度。
选型黄金公式：
选型得分 = 业务任务准确率 × 工程可用性系数 ÷ 全生命周期成本
二、建立三维评估指标体系
在动手测试前，必须先建一张“评分卡”。我们建议从能力、工程、成本三个维度拆解决策权重，通常按业务类型分配如下：
| 维度 | 典型权重 | 关键指标 | 说明 |
|------|---------|---------|------|
| 能力维度 | 40%–50% | 业务任务准确率、幻觉率、指令遵循率、安全拒答率 | 不要只看通用 Benchmark，必须叠加私有业务测试集 |
| 工程维度 | 25%–35% | 首 Token 延迟（TTFT）、吞吐（Tokens/s）、并发稳定性、长上下文衰减点 | 决定用户体验能否上线 |
| 成本维度 | 20%–30% | 单次推理成本、微调成本、运维人力、授权合规成本 | 包含显性和隐性成本 |
呼应前文：能力维度的通用测试可复用 11.1 节的公开基准（MMLU、GSM8K、HumanEval、C-Eval 等）；工程维度需结合 22.1 节的推理核心指标；成本维度直接落地 14.3 节的核算模型。
三、五步选型测试流程
Step 1：需求拆解与候选池初筛（第 1 周）
目标：把业务语言翻译成技术约束，产出 3–5 个候选模型。
- 业务需求拆解示例：
- 金融合规问答 → 需要高准确率、低幻觉、可追溯（RAG 友好）、支持长文本（>50K Token）
- 代码助手 → 需要低延迟（<500ms）、高代码通过率、支持 Function Calling
- 内部客服 → 需要多轮记忆、安全拒答、易微调、低成本
- 初筛动作：
- 排除明显不匹配的架构（如需端侧部署则直接排除 70B+ dense 模型）
- 闭源模型查官方能力边界（上下文长度、是否支持 JSON mode/Function Calling）
- 开源模型查授权协议（Llama 系列社区许可、Qwen 商用许可等，参考 13.6 节）
Step 2：公开基准快速跑分（第 1–2 周）
目标：用低成本方式验证候选模型的基础能力基线。
- 必跑 Benchmark：
- 知识覆盖：MMLU、C-Eval（中文）
- 数学推理：GSM8K
- 代码能力：HumanEval、MBPP
- 长文本：Needle in a Haystack（大海捞针测试，验证标称上下文是否注水）
- 工具推荐：OpenCompass、EleutherAI 的
lm-evaluation-harness，或闭源 API 直接调用官方 Playground。
- 避坑要点：
- 警惕数据污染：部分开源模型在预训练时混入过测试集，导致 Benchmark 虚高。若某 7B 模型 GSM8K 分数接近 GPT-4，需保持怀疑。
- 区分 Base 与 Instruct：跑对话任务必须用 Chat/Instruct 版本，不要拿预训练基座模型直接测。
- 中文场景必须测中文榜：有些模型英文 Benchmark 亮眼，但在 C-Eval 或 CMMLU 上断崖式下跌。
Step 3：构建私有业务测试集与 POC（第 2–3 周）
目标：这是选型的胜负手。公开 Benchmark 只能证明“会不会考试”，私有测试集才能证明“能不能干活”。
- 测试集构建规范：
- 数量：500–2000 条即可，覆盖核心链路而非 exhaustive。
- 分层抽样：
- 简单 Query（40%）：常规业务问题，测基本可用性
- 复杂任务（30%）：多条件推理、长文档摘要、多轮对话
- 边界 Case（20%）：模糊问法、中英文混杂、超长输入、诱导性提问
- 对抗/安全 Case（10%）：越狱尝试、偏见诱导、敏感信息泄露
- 脱敏：若使用闭源 API 测试，必须对真实业务数据做脱敏/泛化处理，或基于真实分布构造模拟数据。
- 评估方法：
- 客观指标：准确率、F1、SQL/代码执行通过率、RAG 检索答案相关性（用 BLEU/ROUGE 或 BERTScore 辅助）
- 主观评估：人工按 5 分制打分（有用性、事实性、流畅度、安全性）；或引入“模型裁判”（如用 GPT-4 打分），但需注意立场偏差（裁判模型可能更偏向与自己同源的模型）。
- 必测专项：
- 幻觉测试：对已知事实（训练截止前）和未知事实（编造的产品/人名）分别提问，统计“自信编造”的比例。
- 上下文衰减测试：在 4K、16K、64K 等不同长度下嵌入关键指令，观察模型是否还能遵循（很多模型标称 128K，但超过 32K 后指令遵循率暴跌）。
- Prompt 鲁棒性：同一意图换 3 种不同表述，观察结果方差。方差大的模型上线后维护成本极高。
Step 4：工程压测与部署验证（第 3 周）
目标：证明模型在目标架构上跑得起来、稳得住。
- 若走闭源 API：
- 压测不同并发（1/10/50/100 QPS）下的 TTFT 和吞吐
- 验证 SLA：是否经常触发限速（Rate Limit）？错误率是否可接受？
- 测试 Function Calling 的延迟和准确率
- 若走开源自建：
- 在目标 GPU（如 A100 80G 或 RTX 4090）上部署，测试：
- 无量化 / INT8 / INT4 下的显存占用
vLLM或TensorRT-LLM框架下的实际吞吐- 长文本并发时的 OOM（显存溢出）临界点
- 明确所需卡数：是单机多卡即可，还是需要分布式推理？
关键决策输入：此步骤输出的“延迟-吞吐-成本”三角数据，直接决定你是否需要放弃某个效果略好但工程上不可行的模型（例如，70B 模型在业务峰值下需要 8 张 A100，而 13B 量化模型在效果可接受的前提下只需 1 张卡）。
Step 5：综合评分与决策（第 4 周）
目标：用结构化评分消除主观拍脑袋。
- 评分表示例（满分 100）：
| 评估项 | 权重 | 候选 A（GPT-4o） | 候选 B（Qwen2-72B） | 候选 C（Llama 3 8B+微调） |
|--------|------|------------------|---------------------|--------------------------|
| 业务准确率 | 30% | 28 | 26 | 22 |
| 长文本稳定性 | 15% | 14 | 13 | 8 |
| 推理延迟（<300ms） | 15% | 10 | 8 | 14 |
| 单次调用成本 | 15% | 5 | 10 | 14 |
| 私有化可控性 | 10% | 6 | 9 | 10 |
| 安全合规 | 10% | 8 | 9 | 7 |
| 微调/运维成本 | 5% | 4 | 3 | 4 |
| 加权总分 | 100 | 75 | 78 | 79 |
- 决策逻辑：
- 若候选分数接近（差距 < 5 分），优先选工程风险低、团队掌控力强的方案。
- 若核心业务强依赖模型不可控的能力（如超强推理），宁可承担闭源 API 成本和合规风险，也不要为了省钱选开源但效果不达标的方案。
四、建立选型后的持续验证机制
模型选型不是一锤子买卖，行业变化极快（闭源模型静默升级、开源模型每周发新版）。建议建立：
- 季度回归测试：用同一套私有测试集重新跑新模型版本，若新模型显著超越当前方案（如准确率提升 > 5% 且成本下降），启动迁移评估。
- 线上 Shadow 测试：新模型先以“影子模式”运行，与线上模型并行输出但不暴露给用户，对比差异率后再切流。
- 错题本机制：把线上 Bad Case 按周回流到测试集中，确保测试集与业务退化同步。
五、常见陷阱与避坑指南
- Benchmark 迷信症：GSM8K 90 分的模型在你的客服场景可能输给一个 70 分的专用小模型。基准测试是必要非充分条件。
- 上下文长度注水：厂商标称的 128K 或 1M 上下文，往往指“能处理这么多 Token”，而非“处理这么多 Token 后还能精准遵循指令”。必须自己做 Needle Test。
- 忽略 Tokenizer 差异：不同模型对中文的切词密度不同（如 1 个汉字可能是 1 个 Token，也可能是 1.5–2 个 Token）。在评估成本时，必须用真实业务语料测算 Token 数，而非按字数估算。
- Prompt 工程不公平：测试时必须固定 Prompt 策略。不能给 GPT-4 用精心优化的 Few-shot，给开源模型只丢一句裸问。
- 微调潜力误判：开源模型在零样本（Zero-shot）下可能弱于闭源，但若你的场景有 1 万条高质量标注数据，经 LoRA 微调后（参考 10.2 节）可能反超。零样本跑分差不代表最终选型差。
六、小结
模型能力评估与选型测试，本质上是用可控实验将不确定性转化为可量化的风险。它的最终交付物不是一份“谁分数高”的排行榜，而是一张清晰的风险-收益矩阵：这个模型在什么场景下够用、什么场景下会崩、崩了有没有兜底方案、成本是否可控。
走完这套流程，第四篇“主流模型对比”的方法论才算真正落地。接下来，如果你已经选定模型并准备私有化部署，第五篇将带你进入硬件原理与算力层的深水区——理解 GPU 为何成为大模型的“蒸汽机”，以及如何在有限的电力和预算内，让这台蒸汽机持续稳定地运转。