降低大语言模型成本：令牌优化策略

通过智能令牌优化，将大语言模型成本降低80%

目录

令牌优化是区分成本效益高的LLM应用与耗费预算的实验的关键技能。

由于API成本与令牌使用量成线性增长，理解并实施优化策略可以在保持质量的同时将费用减少60-80%。

智能架构

理解令牌经济学

在优化之前，你需要了解不同LLM提供商中令牌和定价的工作方式。

令牌基础

令牌是LLM处理的基本单位，大致相当于英文中的4个字符或0.75个单词。“Hello, world!”这个字符串大约包含4个令牌。不同的模型使用不同的分词器（GPT使用tiktoken，Claude使用他们自己的），因此不同提供商之间的令牌计数略有差异。

定价模型比较

OpenAI定价（截至2025年）：

  • GPT-4 Turbo：每1K个令牌输入$0.01 / 输出$0.03
  • GPT-3.5 Turbo：每1K个令牌输入$0.0005 / 输出$0.0015
  • GPT-4o：每1K个令牌输入$0.005 / 输出$0.015

Anthropic定价：

  • Claude 3 Opus：每1K个令牌输入$0.015 / 输出$0.075
  • Claude 3 Sonnet：每1K个令牌输入$0.003 / 输出$0.015
  • Claude 3 Haiku：每1K个令牌输入$0.00025 / 输出$0.00125

要查看包括详细定价、功能和使用案例的云LLM提供商的全面比较，请参阅我们的专用指南。

关键见解： 输出令牌的成本是输入令牌的2-5倍。限制输出长度对成本有显著影响。

提示工程提高效率

有效的提示工程可以显著减少令牌消耗，而不会牺牲质量。

1. 消除冗余

差的例子（127个令牌）：

你是一个乐于助人的助手。请帮助我完成以下任务。
我想让你分析以下文本并提供一个摘要。这是我想让你总结的文本：
[text]
请提供一个主要要点的简洁摘要。

优化后的版本（38个令牌）：

总结关键点：
[text]

节省： 70%的令牌减少，输出质量相同。

2. 使用结构化格式

JSON和结构化输出可以减少自然语言的冗长浪费。

不要使用：

请从这段文字中提取人的姓名、年龄和职业，并清晰地格式化你的回答。

使用：

提取为JSON：{name, age, occupation}
文本：[输入]

3. 少样本学习优化

少样本示例非常强大但昂贵。通过以下方式优化：

  • 使用最少的示例（1-3个通常足够）
  • 保持示例简洁 - 删除不必要的词语
  • 共享公共前缀 - 减少重复的指令
# 优化后的少样本提示
prompt = """分类情感（pos/neg）：
文本："Great product!" -> pos
文本："Disappointed" -> neg
文本："{user_input}" ->"""

有关更多Python优化模式和语法快捷方式，请参阅我们的Python速查表。

上下文缓存策略

对于具有重复静态内容的应用程序，上下文缓存是最重要的优化策略。

上下文缓存的工作原理

像OpenAI和Anthropic这样的提供商会缓存在多个请求中出现的提示前缀。缓存部分的成本比普通令牌低50-90%。

要求：

  • 最小缓存内容：1024个令牌（OpenAI）或2048个令牌（Anthropic）
  • 缓存TTL：根据提供商不同，5-60分钟
  • 内容必须相同，并且出现在提示的开头

实施示例

from openai import OpenAI

client = OpenAI()

# 跨请求缓存的系统消息
SYSTEM_PROMPT = """你是TechCorp的客户服务AI。
公司政策：
[大型政策文件 - 2000个令牌]
"""

# 这会自动缓存
response = client.chat.completions.create(
    model="gpt-4-turbo",
    messages=[
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": "如何退货？"}
    ]
)

# 在缓存TTL内后续调用使用缓存的系统提示
# 仅支付用户消息 + 输出的费用

实际影响： 具有知识库或长指令的应用程序可减少60-80%的成本。

模型选择策略

为每个任务使用正确的模型对于成本优化至关重要。

模型阶梯

  1. GPT-4 / Claude Opus - 复杂推理、创意任务、关键准确性
  2. GPT-4o / Claude Sonnet - 性能与成本平衡，通用用途
  3. GPT-3.5 / Claude Haiku - 简单任务、分类、提取
  4. 微调的小型模型 - 专用重复任务

路由模式

def route_request(task_complexity, user_query):
    """根据复杂性路由到适当的模型"""
    
    # 简单分类 - 使用Haiku
    if task_complexity == "simple":
        return call_llm("claude-3-haiku", user_query)
    
    # 中等 - 使用Sonnet
    elif task_complexity == "moderate":
        return call_llm("claude-3-sonnet", user_query)
    
    # 复杂推理 - 使用Opus
    else:
        return call_llm("claude-3-opus", user_query)

案例研究： 一个客户服务聊天机器人将80%的查询路由到GPT-3.5，20%路由到GPT-4，与使用GPT-4处理所有查询相比，成本减少了75%。

批处理

对于非时间敏感的工作负载，批处理可提供50%的折扣。

OpenAI批处理API

from openai import OpenAI
client = OpenAI()

# 创建批处理文件
batch_requests = [
    {"custom_id": f"request-{i}", 
     "method": "POST",
     "url": "/v1/chat/completions",
     "body": {
         "model": "gpt-3.5-turbo",
         "messages": [{"role": "user", "content": query}]
     }}
    for i, query in enumerate(queries)
]

# 提交批处理（50%折扣，24小时处理）
batch = client.batches.create(
    input_file_id=upload_batch_file(batch_requests),
    endpoint="/v1/chat/completions",
    completion_window="24h"
)

使用案例：

  • 数据标注和注释
  • 博客/SEO内容生成
  • 报告生成
  • 批量翻译
  • 数据集合成生成

输出控制技术

由于输出令牌的成本是输入令牌的2-5倍，控制输出长度至关重要。

1. 设置最大令牌数

response = client.chat.completions.create(
    model="gpt-4",
    messages=messages,
    max_tokens=150  # 硬限制防止费用失控
)

2. 使用停止序列

response = client.chat.completions.create(
    model="gpt-4",
    messages=messages,
    stop=["END", "\n\n\n"]  # 在标记处停止
)

3. 请求简洁格式

添加指令如：

  • “在50字以内回答”
  • “仅提供项目符号”
  • “仅返回JSON，不加解释”

流式传输以获得更好的用户体验

虽然流式传输不会减少成本，但可以提高感知性能并实现早期终止。

stream = client.chat.completions.create(
    model="gpt-4",
    messages=messages,
    stream=True
)

for chunk in stream:
    if chunk.choices[0].delta.content:
        token = chunk.choices[0].delta.content
        print(token, end="")
        
        # 如果响应偏离轨道，提前终止
        if undesired_pattern(token):
            break

RAG优化

检索增强生成（RAG）添加上下文，但未优化的RAG会浪费令牌。

高效RAG模式

def optimized_rag(query, vector_db):
    # 1. 检索相关块
    chunks = vector_db.search(query, top_k=3)  # 不要太多
    
    # 2. 压缩块 - 删除冗余
    compressed = compress_chunks(chunks)  # 自定义压缩
    
    # 3. 截断到令牌限制
    context = truncate_to_tokens(compressed, max_tokens=2000)
    
    # 4. 结构化提示
    prompt = f"上下文：\n{context}\n\nQ: {query}\nA:"
    
    return call_llm(prompt)

优化技术：

  • 使用语义分块（而不是固定大小）
  • 从检索块中删除Markdown格式
  • 实施重新排序以获取最相关的内容
  • 对于大型文档，考虑块摘要

响应缓存

缓存相同或相似的请求以完全避免API调用。

使用Redis实现

import redis
import hashlib
import json

redis_client = redis.Redis()

def cached_llm_call(prompt, model="gpt-4", ttl=3600):
    # 从提示 + 模型创建缓存键
    cache_key = hashlib.md5(
        f"{model}:{prompt}".encode()
    ).hexdigest()
    
    # 检查缓存
    cached = redis_client.get(cache_key)
    if cached:
        return json.loads(cached)
    
    # 调用LLM
    response = call_llm(model, prompt)
    
    # 缓存结果
    redis_client.setex(
        cache_key, 
        ttl, 
        json.dumps(response)
    )
    
    return response

语义缓存： 对于相似（而非相同）的查询，使用向量嵌入来查找缓存的响应。

监控和分析

跟踪令牌使用情况以识别优化机会。

关键指标

class TokenTracker:
    def __init__(self):
        self.metrics = {
            'total_tokens': 0,
            'input_tokens': 0,
            'output_tokens': 0,
            'cost': 0.0,
            'requests': 0
        }
    
    def track_request(self, response, model):
        usage = response.usage
        self.metrics['input_tokens'] += usage.prompt_tokens
        self.metrics['output_tokens'] += usage.completion_tokens
        self.metrics['total_tokens'] += usage.total_tokens
        self.metrics['cost'] += calculate_cost(usage, model)
        self.metrics['requests'] += 1
    
    def report(self):
        return {
            'avg_tokens_per_request': 
                self.metrics['total_tokens'] / self.metrics['requests'],
            'total_cost': self.metrics['cost'],
            'input_output_ratio': 
                self.metrics['input_tokens'] / self.metrics['output_tokens']
        }

成本警报

设置使用量超过阈值时的警报：

def check_cost_threshold(daily_cost, threshold=100):
    if daily_cost > threshold:
        send_alert(f"每日成本${daily_cost}超过${threshold}")

高级技术

1. 提示压缩模型

使用专用模型压缩提示：

  • LongLLMLingua
  • AutoCompressors
  • 学习压缩令牌

这些可以实现10倍的压缩率，同时保持90%以上的任务性能。

2. 推测解码

运行一个小模型与大模型并行以预测令牌，减少大模型调用。通常可实现2-3倍的速度和成本减少，同时保持相似的质量。

3. 量化

对于自托管模型，量化（4位、8位）减少内存和计算：

  • 4位：约75%的内存减少，质量损失最小
  • 8位：约50%的内存减少，质量损失可忽略

如果你在本地运行LLMs，Ollama提供了部署量化模型的出色平台，配置最少。对于硬件选择和性能基准测试，我们的NVIDIA DGX Spark vs Mac Studio vs RTX-4080比较展示了不同硬件配置下运行大型量化模型的实际性能。

成本优化检查表

  • 为每个端点分析当前令牌使用情况和成本
  • 审查提示中的冗余 - 删除不必要的词语
  • 对于静态内容 > 1K 令牌，实现上下文缓存
  • 设置模型路由（小型用于简单任务，大型用于复杂任务）
  • 为所有请求添加max_tokens限制
  • 对于相同查询，实现响应缓存
  • 对于非紧急工作负载，使用批处理API
  • 启用流式传输以获得更好的用户体验
  • 优化RAG：更少的块，更好的排序
  • 使用令牌跟踪和成本警报进行监控
  • 考虑对重复任务进行微调
  • 评估小型模型（Haiku、GPT-3.5）用于分类

实际案例研究

场景： 客户支持聊天机器人，每月100,000次请求

优化前：

  • 模型：所有请求使用GPT-4
  • 平均输入令牌：800
  • 平均输出令牌：300
  • 成本：100,000 × (800 × 0.00003 + 300 × 0.00006) = 每月$4,200

优化后：

  • 模型路由：80%使用GPT-3.5，20%使用GPT-4
  • 上下文缓存：70%的提示被缓存
  • 提示压缩：减少40%
  • 响应缓存：15%的缓存命中率

结果：

  • 85%的请求避免使用GPT-4
  • 70%受益于上下文缓存折扣
  • 输入令牌减少40%
  • 有效成本：每月$780
  • 节省：81%（每月$3,420）

有用的链接

结论

令牌优化将LLM经济学从过于昂贵转变为可持续扩展。通过实施提示压缩、上下文缓存、智能模型选择和响应缓存，大多数应用可以在不牺牲质量的情况下实现60-80%的成本减少。

从快速胜利开始：审查你的提示，启用上下文缓存，并将简单任务路由到小型模型。宗教般地监控你的令牌使用情况 - 被测量的东西会被优化。成本效益高的LLM应用与昂贵的应用之间的区别不是技术 - 它是优化策略。

相关文章