Source: https://aiprimetech.io/zh/blog/choosing-the-right-model-cost/

2026 年 21 日，六月 · 6 分钟 · API 

# 为任务和预算选择合适的模型 

 A  作者 [AI Prime Tech](https://aiprimetech.io/zh/)  · AI 辅助撰写    

某个星期二凌晨 9:17 点，我们的支持工单摘要系统在仪表盘上看起来很“健康”：成功率为 99.4%，p95 延迟低于 3 秒，没有队列积压。但账单反映的是另一番景象。我们花着 Opus 级别的费用，为这样的工单生成摘要： 

```
{
  "subject": "Can I reset my password?",
  "messages": 3,
  "language": "en",
  "attachments": 0
}
```

这不是推理问题，也不是需要 1M 上下文的问题，甚至算不上什么语言处理难题。 

解决办法并不是“所有场景都用最便宜的模型”。一旦遇到退款争议、错综复杂的错误报告或涉及合规敏感事项的升级处理，这种做法就会失效。解决办法是路由：先用低成本模型，评估置信度，只有任务确实需要时才升级到更强的模型。 

选择合适的模型，与其说是寻找“最好的 AI 模型”，不如说是构建一个朴实、可靠的决策系统：  
- 这项任务需要什么？ 
- 能容忍模型多大程度的错误？ 
- 需要多少上下文？ 
- 用户能容忍多长的延迟？ 
- 重试或升级路径是什么？  

在这样的框架下，Haiku、Sonnet、Opus、Fable、GPT、Gemini 和开放权重模型都能找到真正适合自己的位置。 

## 实用的思维框架：先看任务形态，再选模型 

在实践中，我甚至还没开始看模型名称，就会先沿五个维度对大语言模型工作负载进行分类： 

 | 任务形态 | 示例 | 最佳首选 | 升级时机

 | 简单转换 | 改写、分类、总结短文本 | Haiku 级别模型或小型开放模型 | 输出格式错误或置信度低

 | 结构化提取 | 解析发票、工单、日志 | Haiku/Sonnet 或受约束的开放模型 | 字段含义不明确，或记录价值较高

 | 产品相关推理 | 智能体规划、调试、多步骤支持 | Sonnet/GPT/Gemini 级别模型 | 工具调用失败、存在矛盾、置信度低

 | 深度分析 | 架构审查、偏法律性质的政策比较、复杂代码推理 | Opus/GPT-5.5/Gemini 3 | 如果风险较高，通常直接从这里开始

 | 超大上下文综合分析 | 完整仓库、大型对话记录归档、长文档 | Fable 5 或长上下文模型 | 检索后需要精确的局部推理

 | 大规模私有或离线处理 | 内容审核预筛选、与嵌入相关的分类、内部批处理任务 | 开放权重的 Llama/Qwen/DeepSeek/MiniMax/Kimi | 边缘情况、受监管的决策 

当你不再问“哪个模型最聪明？”，而开始问“我花钱是在降低哪种失败风险？”时，模型选择就会容易得多。 

例如：  
- 密码重置摘要工具需要一致性和低成本。 
- 代码迁移助手需要推理能力和工具使用能力。 
- 合同差异比较工具需要长上下文，也需要谨慎标注信息来源。 
- 面向客户的智能体更需要可预测的延迟，而非顶尖的基准测试表现。 
- 批量数据补充流水线可能更关注单位成本的吞吐量，而非回答是否优雅。  

选错模型，往往不是技术上有问题，而是经济上不划算。 

## 实用的模型阶梯 

这是我在大多数生产系统中使用的模型阶梯。 

### Haiku 级别模型：低成本、快速语言处理任务的默认选择 

Haiku 级别模型非常适合承担首轮处理工作。我会用它们处理答案简短、输入干净且输出格式受约束的任务。 

适合的任务：  
- 工单标签标注 
- 简短摘要 
- 情感分类 
- 邮件主题规范化 
- 常见问题匹配 
- 简单的 JSON 提取 
- 低风险内容审核预筛选  

低成本初筛分类器的提示词示例： 

```
{
  "model": "claude-haiku-4.5",
  "temperature": 0,
  "max_tokens": 120,
  "response_format": { "type": "json" },
  "messages": [
    {
      "role": "system",
      "content": "Classify the support ticket. Return only valid JSON."
    },
    {
      "role": "user",
      "content": "Subject: Refund not received\nBody: I canceled two weeks ago and still see a charge."
    }
  ]
}
```

预期输出： 

```
{
  "category": "billing",
  "urgency": "medium",
  "needs_human": true,
  "reason": "Refund dispute involving payment status"
}
```

一个常见陷阱是：团队要求低成本模型一次性完成推理，并完美遵循输出格式。如果模型偶尔输出无效的 JSON，不要立刻转用 Opus。先把任务要求收紧：  
- 设置 temperature: 0 
- 使用 JSON 模式或工具调用 
- 缩小指令范围 
- 将分类与解释分开 
- 验证输出，并重试一次  

对于许多生产任务，使用 Haiku 级模型重试一次，仍然比默认使用前沿推理模型更便宜、更快。 

## Sonnet 级模型：实际产品逻辑的主力 

对于交互式产品功能，我通常会选择 Sonnet 级模型。它们的推理能力足够强，工具使用足够稳定，速度通常也足以满足面向用户的流程需求。 

适合的任务：  
- 起草客户支持回复 
- 使用工具的智能体工作流 
- 代码解释与轻量重构 
- 多步骤文档问答 
- 销售或客户成功助手工作流 
- 从杂乱输入中提取结构化信息  

在实践中，Sonnet 往往是“不想在路由上花太多心思”时的最佳选择。如果新功能只能集成一个模型档位，就从这里开始。 

示例：能够查看订单、政策和历史工单的支持智能体。 

```
SYSTEM = """
You are a support resolution assistant.
Use tools before making claims about orders, refunds, or account state.
If policy is ambiguous, say what is ambiguous and escalate.
Return:
- summary
- recommended_action
- customer_reply
- escalate: true/false
"""

request = {
    "model": "claude-sonnet-4.6",
    "temperature": 0.2,
    "max_tokens": 900,
    "tools": [
        {"name": "get_order", "description": "Fetch order state"},
        {"name": "get_refund_policy", "description": "Fetch current refund rules"},
        {"name": "search_prior_tickets", "description": "Search customer history"}
    ],
    "messages": [
        {"role": "system", "content": SYSTEM},
        {"role": "user", "content": "Customer says they returned item A but were charged again."}
    ]
}
```

这类工作流在生产环境中运行时，实际情况是：大多数失败并不是因为“模型太笨”，而是集成出了问题。  
- 工具返回了过时的状态。 
- 模型收到过多无关上下文。 
- 政策文档中存在相互矛盾的内容。 
- 工具调用失败后，智能体仍被允许继续执行。 
- 提示词同时要求内部分析和可直接提供给客户的文本，却没有将两者分开。  

Sonnet 级模型的智能水平足以应对一些混乱情况，但这并不能替代清晰的工具接口契约。 

## Opus 级模型：价格高昂，但有时比犯错更便宜 

Opus 级模型适用于错误答案的代价远高于推理成本的任务。 

在以下情况下，我会选择 Opus：  
- 输入含糊不清，且后果重大 
- 存在许多相互影响的约束 
- 用户期待深入推理 
- 任务涉及代码、政策或架构上的权衡 
- 低成本尝试一旦失败，就会浪费人工时间  

示例：  
- 审查数据库迁移计划 
- 分析生产事故时间线 
- 生成复杂的法律与政策对比，供人工审查 
- 调试涉及多个服务的智能体故障 
- 评估自动化操作是否安全  

我不会对每个“重要”任务都使用 Opus。重要性和难度是两回事。海量密码重置工单对用户很重要，但每张工单本身并不难处理。而一次涉及微妙数据删除问题的迁移，可能既重要又困难。 

一个实用模式是“遇到不确定性就升级”： 

```
def choose_model(task):
    if task["context_tokens"] > 700_000:
        return "fable-5"

    if task["risk"] == "high" and task["requires_reasoning"]:
        return "claude-opus-4.8"

    if task["requires_tools"] or task["multi_step"]:
        return "claude-sonnet-4.6"

    return "claude-haiku-4.5"
```

这里刻意保持简单。路由器应该足够朴素，让团队在凌晨 2 点也能调试它。 

## Fable 5 与 1M 上下文：当检索成为难题时使用 

长上下文模型很有吸引力，因为它们省去了大量检索工程工作。Fable 5 的 1M 上下文窗口改变了你可以直接尝试的任务范围：全文档审查、超大篇幅转录文本综合分析、大型代码仓库检查，以及跨文件政策分析。 

但长上下文并非万能。 

当难点在于“相关事实可能出现在任何地方”时，1M token 的窗口会有所帮助。但它无法保证模型能对上百万 token 的全部内容进行完美推理，也不会让无关上下文变得毫无成本。长提示词仍然会增加费用和延迟，还可能分散注意力。 

在以下情况下，我会使用 Fable 这类长上下文模型：  
- 语料之间的关联过于紧密，不适合简单分块 
- 遗漏一个细节的代价高于为额外上下文付费 
- 用户能够接受较慢的响应 
- 查看原始周边材料有助于完成任务  

大型文档审查的架构示例： 

```
User request
  -> lightweight classifier
  -> retrieve obvious relevant sections
  -> if confidence high: Sonnet answer with citations/quotes from chunks
  -> if confidence low or query is global: Fable 5 over full document set
  -> optional Opus review for high-risk final answer
```

这种混合方案比“总是把所有内容都塞进上下文”效果更好。在实践中，长上下文模型最有价值的用途，是在检索置信度较低时作为备用方案。 

## 开放权重模型：控制权、成本与吞吐量 

Llama、Qwen、DeepSeek、MiniMax 和 Kimi 等开放权重模型并不只是“更便宜的替代品”。它们也是运维层面的选择。 

当你有以下需求时，它们值得考虑：  
- 本地或 VPC 部署 
- 可预测的大批量处理成本 
- 微调或蒸馏 
- 自定义推理优化 
- 数据驻留控制 
- 完成部署后极低的边际成本  

它们尤其适合范围明确、重复执行的任务。例如，通过 vLLM 提供服务的 Qwen 或 Llama 变体，在控制提示词长度和输出格式的前提下，可以高吞吐量地处理分类、提取和内部信息补充任务。 

本地服务部署形式示例： 

```
vllm serve Qwen/Qwen3-14B \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90
```

然后通过兼容 OpenAI 的客户端调用它： 

```
from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="local"
)

result = client.chat.completions.create(
    model="Qwen/Qwen3-14B",
    temperature=0,
    messages=[
        {"role": "system", "content": "Return valid JSON only."},
        {"role": "user", "content": "Classify: user cannot access invoice PDF"}
    ]
)
```

代价在于，你需要承担工程维护责任。使用托管的前沿模型时，容量、补丁、量化方案选择和内核级性能优化都由服务提供方负责。使用开放模型时，这些就成了你的工作。 

工作负载稳定时，开放权重模型非常合适。如果产品每周都在变化，而且提示词质量比单纯的服务运行成本更重要，它们就不那么合适了。 

## 低成本优先、按需升级的路由 

好的路由器不是排行榜，而是风险控制系统。 

下面是一种适合生产环境的模式：  
- 先尝试预计能够胜任的最便宜模型。 
- 通过程序化检查验证输出。 
- 仅依据可观察的标准，要求模型进行经过校准的自检。 
- 如果验证失败、置信度低或风险高，就升级到更强的模型。 
- 记录路由选择和结果，供后续调优使用。  

路由器示例： 

```
def run_with_escalation(task, input_text):
    first_model = pick_first_model(task)

    response = call_model(
        model=first_model,
        input=input_text,
        schema=task["schema"],
        temperature=0
    )

    validation = validate(response, task["schema"])

    if not validation.ok:
        return call_model(
            model="claude-sonnet-4.6",
            input=input_text,
            schema=task["schema"],
            temperature=0
        )

    if task["risk"] == "high" and response.get("needs_review"):
        return call_model(
            model="claude-opus-4.8",
            input=input_text,
            schema=task["schema"],
            temperature=0
        )

    return response
```

关键在于，升级应基于可衡量的信号，而不是凭感觉。 

有用的升级信号：  
- 无效的 JSON 
- 缺少必填字段 
- 答案相互矛盾 
- 工具调用失败 
- 检索到的证据薄弱 
- 用户要求执行不可逆操作 
- 输入超出正常长度 
- 模型明确标注不确定性 
- 分类器检测到法律、医疗、安全或金融内容  

避免仅用“模型置信度”作为数值评分。LLM 的置信度并不是经过校准的概率。不过，将其限定在具体检查项上时，它仍然有用：“输入是否包含足够的信息来回答？”比“你有多大把握？”更好。 

## 延迟、价格与用户体验 

最快的模型不一定带来最佳用户体验。最佳用户体验是让用户在可接受的等待时间内获得正确结果。 

对于交互式系统，我会从延迟预算的角度考虑： 

 | 体验 | 大致预算 | 模型策略

 | 自动补全或行内辅助 | 感知延迟 100–500 毫秒 | 小型或开放模型、流式输出、积极使用缓存

 | 聊天响应 | 1–5 秒 | 支持流式输出的 Haiku/Sonnet 级模型

 | 智能体工具工作流 | 5–20 秒 | Sonnet 级模型、并行工具调用、进度更新

 | 深度分析 | 30–180 秒 | Opus/Fable/GPT/Gemini 级模型、异步任务

 | 批处理 | 数分钟到数小时 | 开放权重模型或托管服务中最便宜的档位 

不要只用一个加载动画掩盖缓慢的推理过程，而不给出反馈。如果 Opus 或 Fable 任务需要 90 秒，就将其明确呈现为一项分析任务： 

```
Analyzing 184 files...
✓ Indexed repository structure
✓ Found 12 migration scripts
✓ Checking rollback safety
```

这会改变用户的感受，因为系统正在开展可见的工作。 

此外，应尽可能使用流式输出。流式输出不会缩短总完成时间，但能显著改善聊天和起草工作流中的感知延迟。 

## 针对具体任务的实际选择 

以下是我现在会做出的具体选择。 

### 支持工单分流 

优先使用 Haiku。  
- 输入：简短的工单文本 
- 输出：类别、紧急程度、分派队列 
- 遇到账单争议、愤怒的客户或政策含糊的情况时，升级到 Sonnet 
- 超过阈值的退款交由人工审核  

这是典型的低成本优先工作流。 

### 面向客户的支持智能体 

使用 Sonnet。  
- 需要使用工具 
- 需要控制语气 
- 需要处理政策相关问题 
- 需要平稳转交处理  

仅将 Haiku 用于预处理。对于高风险案例，使用 Opus 进行监督复核。 

### 代码审查助手 

普通 PR 审查使用 Sonnet。涉及架构敏感变更、并发、安全、数据迁移以及细微正确性问题的工作，使用 Opus。 

一个常见错误是默认将整个代码仓库输入模型。应先提供差异、依赖关系图和相关的周边文件。只有当变更跨越多个领域时，才升级到 Fable 或其他长上下文模型。 

### 长篇合同或政策比较 

对于范围较窄的问题，使用检索加 Sonnet。对于全局性问题，例如“找出这些文档之间的所有矛盾”，使用 Fable 5。 

如果输出会影响实际的法律或合规决策，应使用模型准备分析，而不是让它作出决策。 

### 大规模数据增强 

如果数据量大且任务稳定，使用开放权重模型。 

示例：  
- 规范化公司名称 
- 提取行业标签 
- 对收到的潜在客户线索进行分类 
- 生成简短的内部摘要  

每晚运行批处理，验证抽样结果，并将边缘案例升级交由托管模型处理。 

### 面向大型档案库的研究助手 

根据上下文长度和推理需求，使用 Gemini 3、GPT-5.5、Opus 或 Fable。除非查询明显简单，否则我不会采用低成本优先策略。研究中的失败往往不易察觉：模型给出了看似合理的答案，却遗漏了关键文档。 

## 制定预算时不要自欺欺人 

最容易导致超支的做法，是只优化单次调用成本，却忽略重试、人工纠正和失败的工作流。 

按任务类型和模型跟踪以下指标：  
- 输入词元 
- 输出 token 数 
- 延迟 p50/p95 
- 验证失败率 
- 升级处理率 
- 人工覆盖率 
- 用户重试率 
- 每次成功完成任务的成本，而不是每次调用的成本  

最后一项很重要。一个便宜的模型如果需要重试三次，最终仍需人工审核，可能比 Sonnet 更昂贵。一次 Opus 调用如果避免了错误的迁移，可能就是本周成本最低的决策。 

如果你使用多模型网关，包括 AI Prime Tech 这类提供 Claude、GPT 和 Gemini 系列 API 访问的服务，主要收益不仅是可以灵活选择供应商，还在于更容易在不同模型类别之间进行路由和衡量。但难点仍然是任务设计。 

## 实践要点  
- 从任务类型入手：转换、提取、推理、长上下文综合分析，或批量数据增强。 
- 对于成本低、速度快、约束明确且可通过机械化方式验证的工作，使用 Haiku 级模型。 
- 对于需要推理、工具或面向用户的输出质量的产品功能，默认使用 Sonnet 级模型。 
- 当错误代价高、歧义大，或深度推理很重要时，使用 Opus 级模型。 
- 当检索的不确定性是主要问题时，使用 Fable 5 这类长上下文模型，而不是将其作为默认策略，把所有内容一股脑塞进提示词。 
- 当工作负载稳定性、隐私、吞吐量或部署控制方面的需求足以支持自行运行推理时，使用开放权重模型。 
- 构建低成本优先的路由机制，并设置明确的升级信号：无效输出、证据不足、工具失败、高风险操作和不确定性。 
- 衡量每次成功完成任务的成本，而不是每个 token 或每次调用的成本。 
- 保持路由器足够简单，以便在压力下调试。 
- 将模型选择视为可持续调整的工程控制项，而不是一次性的供应商决策。  

[模型](/zh/blog/tag/models/)[API](/zh/blog/tag/api/) 

A

[AI Prime Tech](https://aiprimetech.io/zh/)

本博客由 AI Prime Tech 发布。文章借助 AI 辅助起草；在据此采取行动前，请对照官方文档核实模型 ID、价格和限额等特定版本的细节。 

 以更低价格接入 Claude API 

一个 API 密钥即可使用 Claude Opus 5.5、Sonnet 5、Haiku 4.5 和 Fable 5.1，以及 GPT-6 个模型。按量付费，无需订阅。 [获取 API 密钥 →](/register)  

AI Prime Tech 是独立的第三方 API 网关。Claude™ 和 Anthropic® 是 Anthropic, PBC 的商标。此处不暗示任何关联或背书。