不碰代码，如何将LLM API成本砍掉70%

一位开发者最近公开了自己的LLM API账单优化经历：在用户量和请求量基本不变的情况下，月支出从212美元降到了61美元，降幅约70%。关键在于他没有重写应用逻辑，只调整了API层的调用结构。原文作者在博客中完整拆解了这套方法。

LLM API成本优化实践

默认用旗舰模型，是成本失控的根源

大多数开发者集成LLM时的第一反应是"选最强的"。作者最初的架构就是这样：从简单的邮件分类到完整文档改写，所有请求都打到最贵的端点上。

价格差距是数量级的：

GPT-4o：输入 $5.00 / 1M tokens，输出 $15.00 / 1M tokens
Claude 3.5 Sonnet：输入 $3.00 / 1M，输出 $15.00 / 1M
小型模型（如 GPT-4o-mini）：输入 $0.15 / 1M，输出 $0.60 / 1M

输入端差30倍，输出端差25倍。作者复盘后发现，约70%的调用属于简单分类、实体提取或短文本摘要——这些任务小模型不仅能做，延迟还更低。

LLM API的计费以 token 为基本单位，可粗略理解为模型处理的文本片段。英文中1个token约等于0.75个单词，中文约1.5到2个汉字。计价分为输入（prompt）和输出（completion）两部分，输出通常贵3到5倍，因为自回归生成需要逐token反复前向计算。这意味着输入与输出必须分开估算成本：一段1000 token的输入和1000 token的输出，账单并不相等。此外，上下文窗口大小和模型是否支持结构化输出等能力，也会影响实际可用性和隐性开销。理解token经济是后面所有优化策略的计量基础——按任务分层、设max_tokens、精简system prompt，本质上都是在减少不必要的token消耗。

策略一：按任务分层路由模型

作者把应用里所有API调用分成三个层级：

简单任务：关键词提取、情感分析、标签生成、短翻译
中等任务：摘要、代码解释、结构化数据提取
复杂任务：长文创作、多步推理、从零生成代码

只有第三层才走旗舰模型端。实现上就是一个简单的配置映射：

class ModelRouter:
    ROUTES = {
        "classify": ("openai", "gpt-4o-mini", 50),
        "extract": ("openai", "gpt-4o-mini", 200),
        "summarize": ("anthropic", "claude-3-5-haiku", 500),
        "code_review": ("anthropic", "claude-3-5-sonnet", 1500),
        "long_form": ("openai", "gpt-4o", 4000),
    }

    @staticmethod
    def get_endpoint(task_type: str):
        return ModelRouter.ROUTES.get(
            task_type,
            ModelRouter.ROUTES["long_form"]
        )

函数签名不变，调用点依然是 call_llm("summarize", text)，但底层端点和参数已经切换。这一项单独就砍掉了约35%的账单，是所有策略里效果最大的。

策略二：语义缓存，而不只是精确匹配

应用层用Redis缓存很常见，但作者指出一个被忽略的事实：很多请求在语义上相同，文本上却不同。用户问退款政策时可能说"can I get a refund"、"how do refunds work"、"money back process"——这些请求之前各自打了一次LLM。

他在LLM前面加了一层轻量语义缓存：每个prompt先走一次embedding，如果与历史缓存的余弦相似度超过阈值（他用0.92），且模型一致，就直接返回缓存结果。

def llm_with_cache(prompt, task_type, threshold=0.92):
    emb = client.embeddings.create(
        input=prompt,
        model="text-embedding-3-small"
    ).data[0].embedding

    for cached_prompt, cached_response in cache.items():
        if np.dot(emb, cached_prompt) > threshold:
            return cached_response
    response = call_llm(task_type, prompt)
    cache[tuple(emb)] = response
    return response

embedding调用成本远低于LLM调用，而一次缓存命中能省下0.01到0.50美元。作者的数据是约30%的重复用户查询命中了缓存，整体支出再降约20%。

Embedding 是把文本映射为高维向量的技术，语义相近的句子在向量空间中距离更近。系统用embedding模型（如 text-embedding-3-small）把prompt转成向量，再通过余弦相似度比较两个向量的夹角余弦值，范围通常在-1到1之间，越接近1表示语义越相似。阈值0.92意味着两个请求即使措辞不同，只要语义高度接近就视为同一类查询，可直接复用缓存结果。这里存在一个权衡：阈值过高会漏掉可复用的请求，过低则可能把语义不同的问题误判为相同而返回错误答案。因此阈值需要结合业务容错度调优，并用少量人工抽检验证缓存命中质量。Embedding调用价格通常比LLM调用低一到两个数量级，这是语义缓存经济上成立的前提。

策略三：别为用不到的token付费

这项优化最让作者感到尴尬。他之前对分类任务不设输出约束，模型动辄输出三段话，而实际只需要一个"yes"或"no"的标签。

修复方式很直接：在路由配置里为每个任务类型显式设置 max_tokens，并尽量使用JSON模式或结构化输出约束。在旗舰模型上，200 token和2000 token的输出成本差约10倍，而逻辑结果完全一样。仅这一项每月就省了20到30美元。

策略四：多供应商之间的定价套利

不同供应商对同等质量的模型定价差异明显。作者整理的对比：

供应商 / 模型	输入（每1M）	输出（每1M）	说明
OpenAI GPT-4o	$5.00	$15.00	综合能力强
Anthropic Claude 3.5 Sonnet	$3.00	$15.00	长上下文更好
Google Gemini 1.5 Pro	$3.50	$10.50	代码能力强
中小型供应商	$0.15–$1.00	$0.60–$5.00	多数任务够用

作者发现约80%的工作负载用中等模型和替代供应商时，用户满意度完全没有差别。他设置了降级链：优先走便宜供应商，报错或超时再回退到旗舰模型。应用代码不变，只是换了API base URL加一层wrapper。

他还提到现在有统一的API网关可以动态切换供应商。原文中他推荐了自己在用的一个按量付费网关服务（tai.shadie-oneapi.com），声明为个人使用而非赞助。

API 网关 是介于应用和各家大模型API之间的中间层，对外暴露统一的请求格式，内部完成鉴权、路由、限流、重试和格式转换。应用只需把base URL指向网关，无需为每个供应商写不同的SDK代码。当某家供应商超时或报错时，网关可自动把请求转发到备选模型，实现文中提到的降级链。这类网关通常按调用量计费或抽成，也有的提供统一账单和用量看板。使用第三方网关时需注意数据经过第三方、供应商锁定和合规风险，尤其是涉及敏感数据的场景；自建轻量wrapper或使用云厂商自带的托管网关也是常见替代方案。

常被忽略的一项：上下文窗口里的隐形开销

作者额外提醒了一个容易踩的坑：系统提示词过长。如果system prompt有500 token而实际输入只有50 token，等于91%的钱花在了样板文字上。他对所有system prompt做了审计，去掉重复内容，把静态指令移到应用层，基础提示词缩减了40%。

70%来自哪里

作者给出的成本拆解：

任务与模型匹配：约35%
语义缓存：约20%
Token预算修剪：约10%
多供应商价差：约5%

这套方法没有引入新框架，没有重构业务代码，核心动作只有三个：路由、缓存、预算控制。对于月LLM支出超过50美元的应用，作者的判断是：花一个下午做完审计和分层路由，70%的成本削减在多数重度依赖LLM的生产应用中是可复现的。

目前的LLM API市场定价仍然分散，默认选最强模型的习惯短期内不会消失——但账单会替你做决定。