模型选型不是排行榜：创业团队如何选择大模型

上个月，一个做客服 SaaS 的朋友找我聊：他们的产品接了某个跑分第一的模型，效果确实好，但月底账单直接翻了三倍。用户量只涨了 40%，成本涨了 200%。他问我要不要换模型。

我说，问题不在于「换不换」，而在于你们一开始就没有建立选型的判断框架。模型排行榜能告诉你哪个模型「最强」，但不能告诉你哪个模型「最适合你」。这两件事的差距，就是创业团队在模型选型上最容易踩的坑。

模型选型到底在选什么

很多人把模型选型当成一次性的技术决策——挑一个，接上去，上线。实际上，选型是一个多维度的工程权衡。我通常从六个维度来评估：

这六个维度里，成本和延迟通常会先于绝对质量成为产品瓶颈。一个模型在 MMLU 上多拿 3 分，如果换来 5 倍的调用成本和 2 倍的响应延迟，对你的产品来说可能是负收益。

为什么排行榜不能直接当选型依据

我见过太多团队拿着 LMSYS Chatbot Arena 或者 OpenLLMetry 的排名去选模型。排行榜的问题不在于数据不准确，而在于它回答的问题和你真正要解决的问题对不上。

通用基准已经饱和。 MMLU 上头部模型集中在 88%-94%，GSM8K 超过 95%，HumanEval 达到 95%-99%。这些分数差距在实际使用中很难感知，但在账单上差异巨大。

垂直任务需要垂直基准。 做代码生成看 SWE-bench Verified，做科学推理看 GPQA Diamond，做工具调用看 BFCL v4，做长上下文看 RULER。这些基准才能区分模型在你关心的方向上的真实差距。

你的数据不在排行榜上。 排行榜测的是公开数据集，你的客服、写作、数据抽取任务有自己独特的分布、格式约束和质量标准。

2026 年 3 月的数据显示，SWE-bench Verified 上七个模型的分数差距在 2.8 个百分点以内，包括开源的 MiniMax M2.5 达到了 80.2%。这意味着在代码场景下，你可能不需要为前沿模型多付 3-5 倍的价格。

任务复杂度分层：选对模型的前提

选型的第一步不是比较模型，而是搞清楚自己的任务到底需要多强的「智力」。我把任务分成十个层级，对应不同的模型档位：

这里有一个关键概念叫「能力阈值」——一旦模型在某个任务上的成功率过了 90% 这条线，更贵的模型即使把分数推到 95% 也不值得。因为那 5% 的提升，可能带来 300% 的成本增加。反过来，如果一个便宜模型的成功率只有 70%，那省下来的钱会被用户体验损失和人工兜底成本吃掉。

上下文窗口的真相

厂商标称的上下文长度和实际可用的上下文之间有一条巨大的鸿沟。根据 NVIDIA 的 RULER 基准测试，模型可靠使用的上下文通常只有标称值的 50%-65%。

如果你的业务场景真的需要处理 50 万 token 的文档，Gemini 3.1 Pro 和 Claude Opus 4.6 是少数实际可用的选项。但更重要的是，你需要用自己的真实数据做测试，而不是看标称值做决策。

一个实用的测试方法：准备 20 条覆盖你业务场景的长文档样本，对模型做「大海捞针」测试。把关键信息放在文档的不同位置（开头、中间、结尾），看模型是否能准确提取。如果准确率低于 85%，说明这个上下文长度对这个模型来说不可靠。

成本不是单价，是系统性的事

讨论模型成本时，很多人只盯着每百万 token 的输入输出价格。这只是冰山一角。真实的成本结构至少包含四层：

总成本 = 直接调用成本 + 重试成本 + 缓存命中节省 + 路由优化空间

2026 年 3 月的 API 价格参考：

注意输出 token 通常是输入 token 的 3-8 倍价格。如果你的任务输出很长，实际成本会比直觉预期的更高。API 价格过去一年下降了约 80%，但这个趋势不代表你不需要优化——因为流量增长通常会吃掉价格下降的红利。

模型路由：从单次选型到系统设计

真正成熟的选型不是一次性的，而是一个持续运行的路由系统。核心思路是：用便宜模型处理大多数请求，只在必要时升级到贵的模型。

这个架构的实际效果：假设你的工作负载中 60% 是简单任务、25% 是中等任务、15% 是复杂任务。如果全部用 Opus 处理，输出 token 成本是 $25/M；用路由架构后，混合成本降到约 $10.50/M——节省 58%。

路由的判断逻辑可以用代码实现。下面是一个典型的路由函数：

interface RouteDecision {
  model: string
  reason: string
}
 
function routeRequest(task: {
  type: string
  tokenCount: number
  complexityScore: number
  requiresTools: boolean
}): RouteDecision {
  // 硬规则：超长上下文直接走大模型
  if (task.tokenCount > 32000) {
    return { model: 'claude-opus-4.6', reason: 'long-context' }
  }
 
  // 硬规则：需要工具调用的走可靠模型
  if (task.requiresTools) {
    return { model: 'claude-sonnet-4.6', reason: 'tool-calling' }
  }
 
  // 复杂度分级
  if (task.complexityScore > 0.8) {
    return { model: 'claude-opus-4.6', reason: 'high-complexity' }
  }
 
  if (task.complexityScore > 0.5) {
    return { model: 'claude-sonnet-4.6', reason: 'medium-complexity' }
  }
 
  // 简单分类、抽取、格式化走小模型
  if (['extract', 'classify', 'format'].includes(task.type)) {
    return { model: 'gpt-5-nano', reason: 'simple-task' }
  }
 
  return { model: 'claude-haiku-4.5', reason: 'default' }
}

质量兜底的路由同样重要。当小模型输出不达标时，自动升级到更大的模型重试：

async function callWithFallback(
  prompt: string,
  tiers: string[] = ['gpt-5-nano', 'claude-haiku-4.5', 'claude-sonnet-4.6'],
  qualityThreshold = 0.85
): Promise<{ content: string; model: string; cost: number }> {
  for (const model of tiers) {
    const response = await callModel(model, prompt)
    const quality = await evaluateQuality(response, prompt)
 
    if (quality.score >= qualityThreshold) {
      return {
        content: response.content,
        model,
        cost: calculateCost(model, response.usage),
      }
    }
  }
 
  // 所有层级都失败，返回最后一次结果并告警
  throw new ModelFallbackError('All tiers failed quality check')
}

缓存是另一个成本杠杆。Prompt caching 可以降低 45%-80% 的 API 支出，同时把首 token 延迟降低 13%-31%。关键是把动态内容放在 prompt 末尾，最大化可缓存的前缀：

// ❌ 错误做法：动态内容插在中间，破坏缓存
const badPrompt = `
System: 你是一个客服助手
User: ${userMessage}
Context: ${productInfo}
Rules: 回复要简洁友好
`
 
// ✅ 正确做法：静态内容在前，动态内容在最后
const goodPrompt = `
System: 你是一个客服助手
Rules: 回复要简洁友好
Context: ${productInfo}
User: ${userMessage}
`

语义缓存适合 FAQ 类场景——把 query 做 embedding，在缓存中找相似问题，如果相似度超过阈值就直接返回缓存答案。合理的缓存命中率：FAQ 应用 40%-60%，动态对话 10%-30%，工作流自动化 30%-50%。

三个真实选型场景

案例一：客服 SaaS——从 Opus 降级到 Haiku + 路由

前面提到的那个朋友，他们的问题是全量用了 Opus。客服场景 80% 的对话是FAQ、订单查询、简单投诉分类——这些任务 Haiku 就够用，成功率 93%。只有 15% 的复杂投诉和 5% 的退款决策需要 Opus 级别的推理。

引入路由后，他们的月度成本从 $12,000 降到 $4,800，用户满意度反而提高了 2 个百分点——因为简单问题的响应速度从 3.2 秒降到了 0.8 秒。

案例二：代码分析平台——SWE-bench 分数相近，选工程适配度更好的

一个做代码审查工具的团队在 Claude Sonnet 4.6 和 Gemini 3 Flash 之间犹豫。两者的 SWE-bench 分数差距不到 3 个百分点（79.6% vs 78%），但 Sonnet 的工具调用稳定性明显更好，格式遵从率更高。对他们来说，Sonnet 是更好的选择，因为代码分析的输出格式必须严格符合 JSON schema，格式错误会直接导致下游 pipeline 崩溃。

价格差在这里不重要——他们的日均调用量只有 5 万 token，模型价格差每月不到 $50。工程稳定性才是决策因素。

案例三：内容生成平台——多模型混合

一个做营销文案生成的平台，用了三层模型架构：

这种混合架构让他们的单篇文案生成成本从 $0.12 降到 $0.03，同时生成速度提升了 60%。

自建 Eval 的正确姿势

选型不能停在「试了几个模型感觉还行」的阶段。你需要一个小型但严谨的评估体系：

第一步：准备测试集。 30-100 条真实或接近真实的任务样本。覆盖 happy path（50%-60%）、边界情况（20%-30%）、对抗输入（10%-15%）和回归用例（5%-10%）。

第二步：定义评判标准。 用二元判定（通过/不通过）比打分更可靠。如果必须打分，给每个分数等级写清楚 worked example，避免评估者之间的理解偏差。

第三步：记录多维指标。 不只是准确率，还要记录人工可接受率、平均延迟、P95 延迟、单次成本、幻觉率、格式遵从率。

第四步：LLM-as-Judge 校准。 用一个大模型做自动评判时，先和人工评判做校准，要求一致率超过 80% 才能用。

interface EvalCase {
  id: string
  input: string
  expectedOutput: string
  failureTypes: string[] // 可能的失败类型
  allowPartial: boolean // 是否允许部分正确
  rubric: string // 评判规则
}
 
interface EvalResult {
  model: string
  accuracy: number
  humanAcceptRate: number
  avgLatencyMs: number
  p95LatencyMs: number
  costPerCall: number
  hallucinationRate: number
  formatCompliance: number
}
 
async function runEval(
  models: string[],
  cases: EvalCase[]
): Promise<EvalResult[]> {
  const results: EvalResult[] = []
 
  for (const model of models) {
    const metrics = await evaluateModel(model, cases)
    results.push({ model, ...metrics })
  }
 
  return results
}

评估不是一次性的事。模型供应商会更新模型、调整定价、改变 API 行为。我建议每季度重新跑一轮评估，尤其是在供应商发布新模型或调整价格之后。DataVLab 的研究也指出，任何选型决策都应在 6 个月内重新验证。

选型检查清单

在你宣布「我们选了这个模型」之前，逐项确认：

• 已按任务类型对候选模型分别评测，而不是只看通用跑分
• 已在自己的真实数据上测试过上下文长度，确认有效上下文满足需求
• 已测量平均延迟和 P95 延迟，确认在产品体验预算内
• 已按实际调用量计算月度成本，包括输出 token、重试和升级调用
• 已测试工具调用的稳定性和格式遵从率
• 已确认供应商的 SLA、区域合规和数据隔离策略
• 已设计模型路由方案，不把全部流量绑在单一模型
• 已建立 Eval 体系，能定期重新评估模型表现
• 已准备至少一个备用模型，能在主模型故障时切换
• 已评估 prompt 缓存和语义缓存的适用场景
• 已和团队确认：产品核心差异是模型能力还是工作流/数据/分发
• 已设定成本预警阈值，能在支出异常时及时介入
• 已明确选型有效期，承诺在 6 个月内重新评估

适用边界

早期团队不需要一上来就搭复杂的模型网关。先选一个主模型和一个备用模型，把 Eval 跑起来，等流量、成本或稳定性问题出现后再引入路由、缓存和批处理。

如果产品的核心差异来自模型能力本身——比如你做的是一个代码生成工具或者 AI 写作助手——选型需要更严谨，每个维度的评估都要扎实。如果差异主要来自工作流、数据和分发——比如你是一个 CRM 里嵌了 AI 功能——模型只要达到可用线就行，工程精力应该放在业务闭环上。

选型不是找最强的模型，是找最合适的模型。而「最合适」这个答案，会随着你的产品、用户量和成本结构的变化而变化。把它当成一个持续的工程实践，而不是一次性的技术决策。

参考资料

• Which LLM to Choose in 2026? Selection Guide + Benchmarks — 五步选型框架、十级任务复杂度分类和前沿模型基准快照
• LLM Benchmarks 2026: Which Model for Which Job — 基准选择指南和自定义评估构建方法
• LLM Benchmarks Compared: MMLU, HumanEval, GSM8K and More — 15 个主流基准对比，哪些还能用哪些已经饱和
• LLM Model Comparison 2026 | GPT-4.1 vs Claude 4.5 vs Gemini 2.5 — 16 个模型的企业级对比，含定价和基准
• LLM Cost Optimization in 2026: Routing, Caching, and Batching — 路由、缓存、批处理的成本优化实战
• LLM Cost Optimization: How Smart Routing Cuts API Spend by 75% — 智能路由的代码模式和成本节省案例
• Top 50 LLM Comparison: Price vs Performance 2026 — 50 个模型的价格-性能-价值评分对比
• Open-Source vs Commercial LLMs: The Complete Guide 2026 — 开源与商业模型的 TCO 对比和 Node.js 示例