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

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

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

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

例如：

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

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

实用的模型阶梯

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

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"}
    ]
)

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

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

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

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

下面是一种适合生产环境的模式：

1. 先尝试预计能够胜任的最便宜模型。
2. 通过程序化检查验证输出。
3. 仅依据可观察的标准，要求模型进行经过校准的自检。
4. 如果验证失败、置信度低或风险高，就升级到更强的模型。
5. 记录路由选择和结果，供后续调优使用。

路由器示例：

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 的置信度并不是经过校准的概率。不过，将其限定在具体检查项上时，它仍然有用：“输入是否包含足够的信息来回答？”比“你有多大把握？”更好。

延迟、价格与用户体验

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

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

不要只用一个加载动画掩盖缓慢的推理过程，而不给出反馈。如果 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 或每次调用的成本。
• 保持路由器足够简单，以便在压力下调试。
• 将模型选择视为可持续调整的工程控制项，而不是一次性的供应商决策。