财务仪表板上的 AI 功能成本行有个有趣的特性：它随着流量非线性地增长，而且 你的产品越受欢迎，它就越糟糕。下面是我们见过真正能扭转局面的五项杠杆最大 的技巧，每一项都配有可直接运行的代码。
实例算一笔账：一个聊天产品每天调用 10 万次，平均每次 3K 输入 / 500 输出 token，跑在 Claude Sonnet 4.6 上，直接成本约为每月 $4,500。同样的负载， 套用下面这五项技巧后，通常会落到每月 $900～$1,200 左右 —— 在不明显损害 输出质量的前提下削减 70～80%。
1. 提示缓存 —— 单项最大的杠杆
如果你的系统提示或上下文块超过约 2K token，又会在多次调用之间复用，那你 就在多付钱。Anthropic 和 Google 对缓存输入的计费大约都只有正常输入的 0.1×～0.2× —— 缓存预热之后，每一次调用都能省下 5～10 倍。Brievio 把这份 节省原封不动地透传给你，并运行一个亲和性路由器，让重复的提示持续命中同一个 上游节点，于是即便并发很低，缓存也能保持存活。
完整指南见 /docs/caching。
import anthropic
client = anthropic.Anthropic(
api_key="sk-brievio-...",
base_url="https://api.brievio.com",
)
# 把提示里又长又固定的部分标记为可缓存。下一次用相同前缀
# 发起的调用会命中 Anthropic 的缓存 —— 只花 10% 的成本。
resp = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
system=[
{
"type": "text",
"text": "<<你那段 2 万 token 的系统提示 —— schema、规则、示例>>",
"cache_control": {"type": "ephemeral"}, # 标记为可缓存
},
],
messages=[{"role": "user", "content": "最新的问题…"}],
)预期节省：对长系统提示的负载，输入成本可省 40～70%。这往往 是单项幅度最大的改进。
2. 模型分层 —— 别为你用不上的能力买单
在仍能产出可接受输出的前提下，最便宜的合理模型获胜。大多数 LLM 负载的 难度都呈长尾分布 —— 一般的分类或摘要任务并不需要 Opus。
搭一个简单的难度估算（用启发式规则、分类器，或干脆让 Haiku 自己来做 分诊），再据此路由。在 50 多个 Brievio 账户上，我们见过仅凭这一项就把 聊天成本削减了 40～60%。
def pick_model(task_difficulty: int) -> str:
"""
够用的前提下，越便宜的模型越赢。
先按感知到的难度挑选，再用输出质量来验证。
"""
if task_difficulty <= 2:
return "claude-haiku-4-5" # 比 Opus 便宜约 10 倍
if task_difficulty <= 4:
return "gemini-2.5-flash" # 非常能打，输出还更便宜
if task_difficulty <= 7:
return "claude-sonnet-4-6"
return "claude-opus-4-7" # 只在真正需要时才用预期节省：一旦有相当一部分流量被路由到 Haiku / Gemini Flash，聊天类负载可省 40～60%。
3. 输出封顶与消费上限
输出 token 的成本大约是输入的 5 倍。一个 bug 让某段提示在紧凑的循环里 请求 16K token 的回复，就是有人一下午不小心花掉 $400 的原因。两层都要 守住 —— 每次调用的 max_tokens，以及仪表板里钱包级别的 消费上限。
# 双层封顶：每次调用的 max_tokens，再加上密钥上的硬性钱包上限。
resp = client.chat.completions.create(
model="claude-sonnet-4-6",
messages=[...],
max_tokens=800, # 给每次调用的输出封顶
stop=["</answer>"], # 在已知的终止符处截断
)
# 在 Brievio 仪表板里：/app/keys → 给每个密钥设置「消费上限」。
# 生产密钥：$50/天。实验密钥：$5/天。CI 密钥：$1/天。在 Brievio 上：/app/keys 让你给每个密钥 设置按天计的上限。CI/测试密钥设为 $1/天，可以拦住失控的脚本；生产密钥 则可以保持宽松。
4. 并行 —— 并发并不等于更贵
串行调用相比并行调用并不省钱 —— 但它确实浪费墙上时钟时间，而这往往会被 「给 LLM 更多上下文或换个更大的模型」来「解决」。把彼此独立的调用并行 发出去；更快跑完；再往下降一层。
# 当 N 个任务彼此独立时，别为串行推理白白买单。
import asyncio
from openai import AsyncOpenAI
client = AsyncOpenAI(
api_key=os.environ["BRIEVIO_API_KEY"],
base_url="https://api.brievio.com/v1",
)
async def classify_one(text: str) -> str:
resp = await client.chat.completions.create(
model="claude-haiku-4-5", # 并行 + 便宜 = 双赢
messages=[{"role": "user", "content": f"Classify: {text}"}],
max_tokens=20,
)
return resp.choices[0].message.content
results = await asyncio.gather(*(classify_one(t) for t in batch))预期节省：间接收益 —— 通常能省 10～20%，靠的是避开 「为了更快就升级模型」这个陷阱。
5. 不会重复计费的重试
在 Brievio 上，失败的请求（4xx、5xx）从不计费 —— 但只有那次失败的调用是免费的。如果你的重试逻辑在每一次临时抖动上都不带退避地触发，那么 在上游糟糕的一天里，你可能把成本翻上 2～3 倍。照着 Retry-After来，把 4xx（你的 bug）和 5xx（临时故障）区分开，并给尝试次数封顶。
from openai import APIError, RateLimitError
import time, random
def call_with_backoff(client, **kwargs):
for attempt in range(5):
try:
return client.chat.completions.create(**kwargs)
except RateLimitError as e:
# 如果返回了 Retry-After，就照它来。
ra = getattr(e, "retry_after", None) or (2 ** attempt + random.random())
time.sleep(min(ra, 30))
except APIError as e:
if 500 <= e.status_code < 600:
time.sleep(2 ** attempt + random.random())
continue
raise # 4xx —— 是你的 bug，不是临时故障
raise RuntimeError("exhausted retries")完整的重试规则见 /docs/errors。
复利效应
每项技巧单独用，只带来温和的削减。叠在一起，它们会产生复利：缓存省下 50% × 分层省下 50% × 封顶省下 10% = 原始成本的 22% = 省下 78%。这就是 AI 究竟是一个预算项，还是一个为生产毛利做贡献者之间的区别。
Brievio 自身的定价 —— 每个模型都比官方报价低约 15%，按真实 token 数 计费 —— 是叠加在这五项技巧之上的一个固定乘数。在 2026 年运行前沿 AI 最 聪明的方式是：在稳定可用的基础设施上选择货真价实的模型，再从它们身上 榨出正确的技巧。两层都重要。
想免费看一遍你当前的用量，找出杠杆所在吗？把大致情况写封邮件发到 contact@brievio.com，我们来帮你 做分析。