大模型分级选型指南：能力、成本与缓存优化

一、分档选型成为常态

同一套应用中，复杂推理、长文档分析、简单分类和格式转换对模型的要求差异很大。如果所有请求都交给能力最强的模型，成本会快速上升。如果全部交给最便宜的模型，复杂任务的质量又无法保证。因此，按能力划分档位，再把任务分派到合适的档位，是工程实践中较为普遍的做法。

分档的价值在于把选型从”挑一个模型”变成”建立一套分配规则”。规则稳定后，团队可以预估预算、量化质量，并在模型迭代时单独替换某一档，而不影响其他档位的业务逻辑。

二、三类档位的选型维度

常见的分档方式可以归纳为三类：

档位	典型定位	适合的任务	主要关注点
旗舰档	能力上限	多步推理、复杂规划、高风险内容审核	输出质量、稳定性
均衡档	质量与成本平衡	通用问答、摘要、代码辅助、常规文档处理	性价比、响应延迟
轻量档	速度与单位成本	意图分类、信息抽取、批量改写、路由判断	延迟、单次成本

选择档位时，可以从以下几个维度判断：

• 任务复杂度：任务需要多少步推理，错误的代价有多大。
• 质量容忍度：输出是否需要人工复核，错误能否被下游校验拦截。
• 延迟要求：面向用户的实时交互对响应速度敏感，离线批处理则可以接受更长等待。
• 上下文长度：输入文本越长，输入成本和处理时间越高。
• 调用量：高频调用场景中，单次成本的微小差异会被放大。
• 数据敏感度：涉及敏感信息的请求，需要结合合规要求确定部署方式，而不仅看性能与价格。

三、理解token计费结构

token是模型处理文本的基本计量单位。中文与英文的切分方式不同，相同字数对应的token数并不固定，因此预算估算应以实际统计数据为准，不能只凭字数推算。

多数按量计费的服务包含三部分费用：

1. 新输入token：本次请求中未命中缓存、需要重新处理的输入内容。
2. 缓存输入token：命中缓存的前缀部分，通常享受低于普通输入的单价。
3. 输出token：模型生成的内容。由于生成过程是逐个token进行的，输出单价一般高于输入单价。

单次请求的成本可以用下面的公式估算：

单次成本 = (新输入token × 输入单价 + 缓存输入token × 缓存单价 + 输出token × 输出单价) ÷ 1,000,000

其中，新输入token等于总输入token减去缓存命中部分。缓存折扣比例因服务方而异，应以所用服务的官方价目表为准。

四、成本估算示例

下面的单价全部为假设值，用于演示计算方法，不代表任何实际服务的价格。单位统一为”元/百万token”。

# 假设单价，仅用于演示计算方法
PRICING = {
    "flagship": {"input": 10.0, "output": 40.0, "cached_input": 1.0},
    "balanced": {"input": 3.0,  "output": 15.0, "cached_input": 0.3},
    "light":    {"input": 0.5,  "output": 2.0,  "cached_input": 0.05},
}
def request_cost(tier: str, input_tokens: int, output_tokens: int,
                 cached_tokens: int = 0) -> float:
    """返回单次请求成本（元）。"""
    p = PRICING[tier]
    fresh_tokens = max(input_tokens - cached_tokens, 0)
    cost = (
        fresh_tokens * p["input"]
        + cached_tokens * p["cached_input"]
        + output_tokens * p["output"]
    )
    return cost / 1_000_000
# 场景：2000个输入token，500个输出token，无缓存
for tier in ("flagship", "balanced", "light"):
    per_call = request_cost(tier, 2000, 500)
    print(f"{tier}: 单次 {per_call:.4f} 元，10万次 {per_call * 100_000:.0f} 元")

运行结果如下：

• 旗舰档：单次约0.04元，10万次约4000元。
• 均衡档：单次约0.0135元，10万次约1350元。
• 轻量档：单次约0.002元，10万次约200元。

在这个假设场景中，旗舰档的成本是轻量档的20倍。若业务中有九成请求属于分类、抽取这类简单任务，把它们迁移到轻量档，总成本会明显下降，而复杂请求仍由旗舰档处理，质量不受影响。

五、缓存复用策略

缓存只对稳定的前缀生效。请求结构设计得当，才能持续命中缓存：

• 固定前缀前置：系统提示词、角色设定、参考文档等不变内容放在请求最前面，动态的用户问题放在最后。
• 避免前缀中混入动态内容：时间戳、随机ID、每次不同的检索结果如果插在前缀中，会导致缓存失效。
• 同一文档多次问答时复用前缀：批量处理同一份材料时，保持前缀完全一致，可以显著提高命中率。
• 监控命中率：命中率持续偏低，通常说明前缀不稳定，应回头检查提示词拼接逻辑。

推荐的请求结构如下：

[固定系统提示词]
[固定参考文档或知识片段]
[动态用户问题]

六、任务路由实现

路由层负责把请求分派到合适的档位。最简单的做法是按任务类型和输入长度设定规则：

SIMPLE_TASKS = {"classify", "extract", "rewrite"}
REASONING_TASKS = {"reason", "plan", "review"}
def route(task_type: str, text_length: int) -> str:
    if task_type in SIMPLE_TASKS:
        return "light"
    if task_type in REASONING_TASKS or text_length > 20000:
        return "flagship"
    return "balanced"

规则只是起点，还需要配合结果校验。轻量档输出后，先用格式检查、字段校验或规则判断确认结果可用；校验失败时自动升级到上一档重试，并记录每次升级的额外成本。这样既能控制平均成本，又能兜住少数复杂样本的质量问题。

七、落地流程

1. 收集真实请求样本：从线上日志中抽取有代表性的请求，并标注任务类型。
2. 建立统一评测集：在各档位上运行同一套样本，记录质量指标、延迟和单次成本。
3. 确定每类任务的档位：选择满足质量要求且性价比最高的档位，并设定升级条件。
4. 灰度上线：先放开少量流量，监控质量、延迟、成本和缓存命中率。
5. 定期复评：模型版本更新或价格调整时，重新运行评测集，检查分配规则是否仍然合理。

八、常见误区

• 只看单价，不看用量：总成本由单价、输入长度、输出长度和调用次数共同决定。一个单价较低但输出冗长的方案，成本可能更高。
• 用一次评测代替长期结论：样本量小或分布单一时，评测结论容易偏差，需要覆盖真实的长尾场景。
• 忽视延迟：轻量档响应快，对交互体验的提升很明显。只按成本选型，可能让用户等待过久。
• 把档位名称当成能力保证：档位名只表示定位，具体能力、参数限制和价格应以服务方的官方文档和自身实测为准。