能力边界、成本与适用场景

小象实战讲义 · 自然语言处理

在掌握了预训练大模型的核心原理与架构后，将其投入实际应用时，我们必须面对两个现实问题：它到底能做什么、不能做什么？以及，使用它的成本是多少，如何高效地控制成本？本节将系统性地剖析大模型的能力边界、成本构成与换算方法，并提供一个清晰的决策框架，帮助你在实际项目中判断何时使用大模型，以及如何经济、安全地使用它。

💡 核心导读

• 成本结构：理解大模型服务的计价模式，掌握输入/输出分开计价、缓存折扣、批量通道等关键概念，从工程结构上优化成本。
• 换算方法：学会将抽象的“每百万token单价”换算为具体的“每次问答成本”和“月度预算”，掌握量级估算与成本优化的纪律。
• 能力边界：识别四类大模型“看起来能做，实则容易翻车”的任务，避免将其用于不擅长的场景。
• 适用场景判断：通过“四问”框架（确定性、敏感性、实时性、错误代价），快速评估任务是否适合使用大模型。

一、成本结构：贵在哪、怎么省

大模型服务的成本并非单一数字，而是一个由多个因素构成的结构。理解这个结构，是进行成本优化的第一步。请注意，本节只讨论成本的结构性特征和换算方法，所有示例单价均为“示例值，非官方报价”。

• 输入与输出分开计价：这是最核心的计价模式。模型处理输入token（理解你的问题）和生成输出token（给出回答）的计算开销不同。输出token需要逐个生成、串行推进，计算复杂度更高，因此输出token的单价通常显著高于输入token。这意味着“少问、精问”和“缩短回答”对成本的杠杆效应是不同的——控制输出长度往往能带来更直接的成本节省。

• 缓存 / 命中折扣：当同一段长前缀（例如系统提示词、固定的知识库片段）在多次请求中重复出现时，部分服务提供商会提供缓存命中折扣。其工程含义是：把稳定不变的长上下文放在提示词的前面，把每次请求的变量（如用户的具体问题）放在后面。这是一种通过优化提示词结构来省钱的有效做法。

• 批量折扣 / 离线通道：对于不要求实时响应的任务（如批量文本摘要、分类），可以走批量处理通道。这种通道的单价更低，但延迟更高。这是一次清晰的 “用时间换钱” 的权衡。

• 阶梯价与按量：用量越大，单价可能越低。但在预算规划时，需要先算清“每天请求次数 × 每次平均token消耗”，设置预算上限，避免不可控的费用增长。

• 非生成类接口单独计费：大模型生态中不止有对话模型。向量化（embedding）、重排序（rerank）等接口通常按token或按请求单独计费，与对话模型的价目表不同。在构建RAG（检索增强生成）系统时，这部分成本常被遗漏，需要一并纳入考量。

二、成本换算方法

本节的核心技能是将服务商公布的“每百万token单价”换算成你能直观理解的“每千次问答需要多少钱”或“月度成本”。掌握这个换算能力，是进行技术选型和预算评估的基础。

成本计算遵循以下公式： 每次请求成本 $C_{\text{req}}$ = 输入token数 $N_{\text{in}}$ × 输入单价 $P_{\text{in}}$ + 输出token数 $N_{\text{out}}$ × 输出单价 $P_{\text{out}}$ 月度成本 $C_{\text{month}}$ = $C_{\text{req}}$ × 日请求数 $R_{\text{day}}$ × 30

其中，单价 $P$ 的单位是“每百万token”。换算时有两条重要纪律：

1. 单位统一：必须先将单价统一到“每百万token”再进行计算，否则量级会差一千倍，导致严重错误。
2. 先估算，后优化：先基于业务量做一个粗略的成本量级估算。如果月成本本身很低（例如只有几十单位），那么花费大量工程时间去做极致的缓存优化可能并不划算。

下面我们通过一个Python示例来演示完整的换算流程。

def calculate_request_cost(input_tokens, output_tokens, price_per_million_input, price_per_million_output):
    """
    计算单次请求的成本。
    参数：
        input_tokens: 输入token数
        output_tokens: 输出token数
        price_per_million_input: 输入单价（每百万token）
        price_per_million_output: 输出单价（每百万token）
    返回：
        单次请求成本（单位与单价一致）
    """
    # 单位换算：单价是每百万token，所以除以 1e6
    input_cost = input_tokens * price_per_million_input / 1_000_000
    output_cost = output_tokens * price_per_million_output / 1_000_000
    total_cost = input_cost + output_cost
    return total_cost

def calculate_monthly_cost(input_tokens, output_tokens, price_per_million_input, price_per_million_output, daily_requests):
    """
    计算月度成本。
    参数：
        daily_requests: 日均请求次数
    返回：
        (单次请求成本, 月度成本)
    """
    per_request = calculate_request_cost(input_tokens, output_tokens, price_per_million_input, price_per_million_output)
    monthly = per_request * daily_requests * 30
    return per_request, monthly

# 例题参数设定（示例值，非官方报价）
# 某问答场景：每次输入800 token，输出300 token
input_tokens_example = 800
output_tokens_example = 300
# 示例单价：输入 0.5 单位/百万token，输出 1.5 单位/百万token
price_input_example = 0.5
price_output_example = 1.5
# 日均请求量：1万次
daily_requests_example = 10_000

# 计算
per_req_cost, monthly_cost = calculate_monthly_cost(
    input_tokens_example, output_tokens_example,
    price_input_example, price_output_example,
    daily_requests_example
)

print(f"单次请求成本: {per_req_cost:.6f} 单位")
print(f"输入部分: {input_tokens_example * price_input_example / 1_000_000:.6f} 单位")
print(f"输出部分: {output_tokens_example * price_output_example / 1_000_000:.6f} 单位")
print(f"日均成本: {per_req_cost * daily_requests_example:.2f} 单位")
print(f"月度成本: {monthly_cost:.2f} 单位")

单次请求成本: 0.000850 单位
输入部分: 0.000400 单位
输出部分: 0.000450 单位
日均成本: 8.50 单位
月度成本: 255.00 单位

从计算结果可以看出，尽管输出 token 数（300）少于输入（800），但由于输出单价更高，其成本（0.000450 单位）反而超过了输入成本（0.000400 单位）。日均 1 万次的请求，月成本达到 255.00 单位。这个量级的估算，是决定是否值得做工程优化（如启用缓存、走批量通道）的重要依据。

缓存到底能省几个点：算一遍再决定

「缓存命中给折扣」听起来很划算，但它只作用于输入，碰不到输出。所以实际省下的比例永远低于折扣比例——这点必须算出来才知道，否则容易高估收益。

场景：每次输入 2000 token，其中 1500 token 是稳定前缀（系统提示 + 固定知识片段），500 token 是每次变化的用户问题；输出 300 token；示例单价沿用上面的输入 0.5、输出 1.5（单位/百万 token）；命中部分按输入价的 0.2 倍计（示例值，非官方报价）。

# 缓存命中能省多少（示例单价，非官方报价）
in_total = 2000          # 每次请求的输入 token
cached = 1500            # 其中稳定前缀（系统提示 + 固定知识片段）
fresh = in_total - cached
p_in = 0.5               # 输入单价：单位/百万 token
p_out = 1.5              # 输出单价：单位/百万 token
out_tok = 300
cache_discount = 0.2     # 命中价按输入价的 0.2 倍计（示例值）

cost_before = (in_total * p_in + out_tok * p_out) / 1e6
cost_after = (cached * p_in * cache_discount + fresh * p_in + out_tok * p_out) / 1e6

print(f"不命中: 输入 {in_total * p_in / 1e6:.6f} + 输出 {out_tok * p_out / 1e6:.6f} = {cost_before:.6f}")
print(f"命中后: 缓存 {cached * p_in * cache_discount / 1e6:.6f} + 新增 {fresh * p_in / 1e6:.6f} + 输出 {out_tok * p_out / 1e6:.6f} = {cost_after:.6f}")
print(f"单次省下: {cost_before - cost_after:.6f}，占比 {(cost_before - cost_after) / cost_before:.2%}")

不命中: 输入 0.001000 + 输出 0.000450 = 0.001450
命中后: 缓存 0.000150 + 新增 0.000250 + 输出 0.000450 = 0.000850
单次省下: 0.000600，占比 41.38%

三条读数：

1. 输入成本自己降了 60%（0.001000 → 0.000400，因为 1500/2000 的输入打了 0.2 折），但整体只降 41.38%——输出那 0.000450 一分没省。
2. 输出越长，缓存收益越被摊薄。想要真正降成本，「缩短输出」和「缓存前缀」要一起用，只做后者会得到一个低于预期的数字。
3. 前缀必须是稳定的。如果每次请求都改系统提示（比如把时间戳、用户 ID 拼进去），缓存就永远命中不了——这不是技术问题，是提示词结构问题。

三、能力边界：四类“容易翻车”的任务

大模型能力强大，但并非万能。清晰认识其边界，是避免项目失败的关键。以下是四类大模型“看起来能做，其实容易翻车”的任务：

1. 需要精确计算/查表的任务：包括算术运算、日期推算、单位换算、大数比较等。语言模型的本质是“基于概率生成最可能的下一个token”，而不是“执行确定性算法”。让它做计算，相当于要求一个文科生心算微积分，出错是常态。正确做法是将计算逻辑交给代码或专用工具（工具调用将在后续章节展开）。

2. 知识时效与私有事实：模型训练数据有截止日期，无法知晓之后的新事件；同时，它也无法知晓未公开的企业内部资料、个人隐私等信息。对于这类需求，模型只能“猜得像”，无法保证正确。正确做法是结合检索（RAG）或工具调用来获取实时、私有的信息。

3. 长尾与低资源任务：指在模型训练数据分布中非常稀少的任务，例如小众语言的处理、特定领域的生僻术语、格式要求极其严格的输出（如必须包含固定字段的特定JSON结构）。模型在这些任务上的表现会明显下降，且这种下降在通用的评测榜单（如GLUE、SuperGLUE）上往往看不出来。必须用自己业务场景的一小批真实样本进行测试评估。

4. 多步推理与自洽性：需要多跳逻辑推理、或需要「先规划再执行」的复杂任务。模型在单次生成中容易半途走偏、前后矛盾或陷入循环。常见的应对策略是把任务拆成多步、让模型分步推进并调用工具，或引入外部校验机制。关于幻觉的成因与系统化治理，在「幻觉与事实性问题」一节专门展开，本节只把它列为一条能力边界。

四、适用场景的判断框架

面对一个具体任务，如何快速判断是否适合使用大模型？你可以按顺序问自己以下四个问题，任何一问的答案为“是”且无法规避，都可能意味着需要调整方案或引入辅助组件。

1. 这任务需要确定性正确吗？

   • 需要 → 优先考虑使用规则系统、数据库查询、确定性算法或检索系统来保证正确性。大模型可以只承担“理解用户意图”和“组织自然语言表述”的角色。
   • 不需要 → 可以接受一定的模糊性或创意性，适合使用大模型。

2. 数据敏感吗？

   • 敏感 → 考虑私有化部署方案，或将数据脱敏、匿名化后再通过外部API处理。绝对不要将原始敏感数据直接拼接到提示词中发送给第三方服务。
   • 不敏感 → 可以使用公有云API。

3. 要求实时吗？

   • 要求 → 需要关注服务的首 token 延迟和并发处理能力（这与 KV cache 的显存占用直接相关，机制见「上下文窗口与长文本处理」一节）。
   • 不要求 → 可以优先考虑使用批量处理通道，以显著降低成本。

4. 错了代价大吗？

   • 大 → 必须设计人工复核流程，或采用双重校验、多模型投票等机制来降低错误率。
   • 不大 → 可以为了提升开发效率和系统吞吐量，而接受一个可控范围内的错误率。

四个问题不是独立打分，而是要合起来看组合。同一类任务在不同约束下，最优组合差别很大：

表的用法是先填左边四列，再看右边那列——四列里只要有一列是”高危”（确定性必须、数据敏感、错代价大），就不该让模型单独承担输出。

五、与相邻章节的边界

为确保知识体系的清晰，本节内容与课程其他部分有明确分工：

• 上下文长度与长文本成本的详细计算（涉及 KV cache 公式）在「上下文窗口与长文本处理」一节讲解，本节只引用其结论。
• 幻觉的成因与系统化治理方案在「幻觉与事实性问题」一节专门展开，本节仅指出其为能力边界问题。
• 检索与 RAG 的工程落地细节分别在「语义检索与向量库实战」「RAG 知识库问答」两节讲解。
• 模型对齐与 RLHF 的三步流水线已在「指令微调与 RLHF」一节讲授，本节不再重复。

延伸阅读

本节为方法论与框架性内容，主要基于行业工程实践总结，未直接引用特定论文。关于成本优化、能力边界评估的更多工程细节，可参考各大云服务商（如AWS, Google Cloud, Azure）及主流模型提供商（如OpenAI, Anthropic）的官方架构最佳实践文档。

📝 动手练一练

1. 概念辨析：假设你要开发一个智能客服系统，需要处理用户的商品售后问题（可能涉及查询订单、计算退款金额、生成回复话术）。请运用本节“适用场景判断框架”的四个问题，简要分析在这个系统中，大模型最适合承担哪部分工作？哪些部分不适合直接交给大模型？

2. 成本计算：一个新的内容审核场景，需要模型对每篇约 1500 字的文章（按本场景的估算口径约合 2000 token）生成摘要，并判断其类别；产出是一段约 150 字的摘要（约合 200 token）加一个类别标签。假设输入单价为 0.3 单位/百万 token，输出单价为 0.9 单位/百万 token，每天处理 500 篇。请计算月成本大约是多少？

# 重新定义计算函数，确保块内自包含
def calc_cost(in_tok, out_tok, price_in, price_out, daily_req):
    per_req = (in_tok * price_in / 1_000_000) + (out_tok * price_out / 1_000_000)
    monthly = per_req * daily_req * 30
    return per_req, monthly

# 给定参数
input_tokens = 2000
output_tokens = 200
price_input = 0.3  # 单位/百万token
price_output = 0.9 # 单位/百万token
daily_requests = 500

per_request, monthly_total = calc_cost(input_tokens, output_tokens, price_input, price_output, daily_requests)

print(f"单次处理成本: {per_request:.6f} 单位")
print(f"月度成本: {monthly_total:.2f} 单位")

单次处理成本: 0.000780 单位
月度成本: 11.70 单位

本章小结

本节我们系统性地探讨了将大模型投入实际应用时必须考虑的现实因素。我们学习了如何拆解大模型服务的成本结构，掌握了从“单价”到“项目预算”的换算方法，并明确了模型在精确计算、实时知识、长尾任务和复杂推理方面的能力边界。最后，我们提供了一个“四问”决策框架，帮助你在项目中快速、理性地判断大模型的适用性。

📋 行动清单

• 动手算一算：为你正在构思或负责的项目，估算一个大模型API调用的月度成本量级。
• 边界自查：列出项目中对大模型的能力要求，对照本节提到的四类“易翻车”任务，检查是否存在风险点。
• 方案设计：运用“四问”框架，为你项目中的核心功能设计一个融合大模型与其他组件（规则、检索、工具）的技术方案草图。

—— 小象教研组