How to Reduce LLM API Costs
Without Breaking Quality如何降低 LLM API 成本
同时守住质量
Start with measurement, then reduce tokens, route by workload, cache stable work, and govern every request. Cheap models alone are not a cost strategy.
先测量,再减少 token、按工作负载路由、缓存稳定结果并治理每次请求。只换便宜模型并不是完整成本策略。
TL;DR
Attribute spend by feature, customer, environment, model, and request type before changing prompts or providers.
Route simple workloads to smaller models and reserve frontier models for tasks where evaluation proves they add value.
Remove repeated context, cap outputs, cache stable prefixes and deterministic results, and stop retries that cannot succeed.
Use a gateway for budgets and model routing; use QVeris for discoverable tool and data calls so agents do not spend tokens inventing facts.
修改提示词或供应商前,先按功能、客户、环境、模型和请求类型归因成本。
把简单工作负载路由给小模型,只在评测证明有价值的任务上使用前沿模型。
删除重复上下文、限制输出、缓存稳定前缀与确定性结果,并停止不可能成功的重试。
网关负责预算和模型路由;QVeris 负责可发现工具与数据调用,避免 Agent 用 token 猜测事实。
The LLM cost equation teams should measure团队应该测量的 LLM 成本公式
LLM API cost is not simply input tokens multiplied by one price plus output tokens multiplied by another. A production request can include cached-token rates, reasoning tokens, image or audio units, tool retries, fallback attempts, failed calls, platform fees, storage, evaluation traffic, and engineering overhead. Start with a request-level ledger that reflects the bill you actually pay.
The useful unit is cost per successful business outcome: cost per resolved ticket, accepted extraction, completed research task, generated report, or retained user. A lower cost per request can be misleading if output quality falls and the application repeats work or sends more cases to humans.
Optimization should follow a controlled loop: measure, segment, change one lever, evaluate quality and latency, then roll out gradually. Every cost change needs a guardrail metric so a cheaper model or shorter prompt cannot silently damage the product.
LLM API 成本不只是输入 token 乘价格再加输出 token 乘价格。生产请求还可能包含缓存 token 价格、推理 token、图像或音频单位、工具重试、回退尝试、失败调用、平台费、存储、评测流量和工程开销。首先要建立与真实账单一致的请求级成本账本。
更有用的单位是每个成功业务结果的成本,例如每个解决工单、被接受的抽取、完成的研究任务、生成的报告或留存用户成本。如果质量下降导致重复工作或更多人工处理,单次请求成本降低也可能是假象。
优化应遵循受控循环:测量、分群、一次改变一个杠杆、评估质量与延迟,再逐步放量。每项成本变化都需要护栏指标,防止便宜模型或更短提示词静默损害产品。
12 strategies to reduce LLM API costs降低 LLM API 成本的 12 个策略
| Lever成本杠杆 | How it saves如何节省 | Quality guardrail质量护栏 | Metric指标 |
|---|---|---|---|
| Model routing模型路由 | Matches model cost to task difficulty让模型成本匹配任务难度 | Task-specific evaluation pass rate任务评测通过率 | Cost per accepted result每个可接受结果成本 |
| Prompt reduction提示词精简 | Removes repeated and low-value context删除重复与低价值上下文 | Instruction-following and accuracy指令遵循与准确性 | Input tokens per request每次请求输入 token |
| Output caps输出限制 | Prevents unnecessary generation避免不必要生成 | Completion and truncation rate完成率与截断率 | Output tokens per success每次成功输出 token |
| Caching缓存 | Reuses stable prefixes or results复用稳定前缀或结果 | Freshness and cache correctness新鲜度与缓存正确性 | Hit rate and avoided spend命中率与节省成本 |
| Batching批处理 | Moves asynchronous work to cheaper paths把异步工作移到更便宜路径 | Queue delay and completion SLA队列延迟与完成 SLA | Cost per batch item每个批任务成本 |
| Tool grounding工具事实支撑 | Replaces long speculative reasoning with exact data用准确数据替代冗长猜测 | Source correctness and tool success来源正确性与工具成功率 | Total model plus tool cost模型与工具总成本 |
Build a cost-aware model routing policy建立成本感知的模型路由策略
Separate extraction, classification, chat, code, research, planning, vision, and high-risk decisions. Each deserves a different model and evaluation threshold.
Define small, medium, and frontier routes with explicit escalation conditions based on confidence, validation failure, user tier, or task risk.
Include retries, fallback probability, cached rates, tool calls, platform fees, and quality-related rework, not only the advertised token price.
Route changes should pass offline evaluations, canary traffic, cost checks, and regression alerts before becoming the default.
分离抽取、分类、聊天、代码、研究、规划、视觉和高风险决策,每类任务应有不同模型与评测阈值。
定义小型、中型和前沿模型路由,并按置信度、验证失败、用户等级或任务风险明确升级条件。
除标称 token 价格外,还要包含重试、回退概率、缓存价格、工具调用、平台费和质量返工。
路由变化成为默认前,应通过离线评测、金丝雀流量、成本检查和回归告警。
A 30-day LLM cost optimization plan30 天 LLM 成本优化计划
Capture feature, customer, environment, route, provider, model, tokens, cache, retries, latency, success, and estimated cost for every request.
Delete duplicate context, cap outputs, stop runaway loops, fix retry storms, cache stable work, and turn off unused evaluation traffic.
Build a task evaluation set, test smaller models, introduce a model ladder, and canary the lowest-risk routes first.
Set budgets, anomaly alerts, customer limits, model allowlists, ownership reports, and a monthly cost-quality review.
为每个请求记录功能、客户、环境、路由、供应商、模型、token、缓存、重试、延迟、成功状态和估算成本。
删除重复上下文、限制输出、停止失控循环、修复重试风暴、缓存稳定工作,并关闭未使用的评测流量。
建立任务评测集、测试小模型、引入模型阶梯,并先对最低风险路由进行金丝雀测试。
设置预算、异常告警、客户限制、模型允许列表、归属报告,以及每月成本质量复盘。
Cost optimizations that often backfire经常适得其反的成本优化
Simple tasks may improve, but complex or high-risk work can create retries, rework, support cost, and user churn.
Removing the wrong examples, policies, retrieved evidence, or conversation turns can lower first-pass success and increase total spend.
A high hit rate is harmful when the result is stale, user-specific, permission-sensitive, or derived from changing market data.
A reliable data call can be cheaper than asking a large model to infer or repeatedly search for the same fact, but tool cost and failure must be measured too.
简单任务可能受益,但复杂或高风险任务会产生重试、返工、支持成本和用户流失。
删除错误的示例、策略、检索证据或对话轮次,会降低首次成功率并增加总成本。
当结果过期、与用户相关、受权限约束或来自变化市场数据时,高命中率反而有害。
可靠数据调用可能比让大模型猜测或反复搜索同一事实更便宜,但工具成本与失败也必须计量。
The 12 production strategies, explained12 个生产级降本策略详解
Tag feature, customer, environment, user tier, experiment, route, provider, and model. Cost without ownership becomes a monthly surprise; cost with ownership becomes an engineering metric that teams can explain and improve.
Do not resend static documentation, policy, examples, conversation history, or retrieved passages blindly. Deduplicate, summarize older turns, select only relevant evidence, and measure whether first-pass quality remains stable.
Set realistic output limits, stop sequences, JSON schemas, concise style instructions, and pagination. Track truncation and task completion so an aggressive cap cannot convert token savings into another full retry.
Use evaluated smaller models for classification, extraction, rewriting, and simple chat. Escalate to larger models only when confidence, validation, risk, customer tier, or task complexity crosses a documented threshold.
Use provider prompt caching when long instructions or reference context repeat. Model cache lifetime, minimum token thresholds, write and read prices, routing behavior, privacy, and invalidation rules before estimating savings.
Cache safe classification, extraction, transformation, and lookup results using inputs, versioned prompts, model route, policy, permissions, and freshness as key material. Never reuse user-specific or changing data across the wrong boundary.
Move offline extraction, embedding, classification, report generation, and evaluation to batch paths when the provider offers favorable economics. Include queue delay, retry behavior, completion SLA, and partial-failure handling in the decision.
Classify errors before retrying, honor retry-after, use bounded exponential backoff, prevent duplicate tool actions, and set maximum agent steps. A runaway loop can erase weeks of prompt optimization in minutes.
Fallback should consider quality, context, tools, region, latency, and total price. The cheapest backup is not economical if it breaks schema, triggers another model call, or sends the task to a human.
When a reliable API or dataset can answer an exact question, call it instead of asking a large model to infer, search repeatedly, or process an oversized context. Measure tool fees and failures alongside model savings.
Apply limits by project, customer, feature, environment, key, and time window. Alert on cost per success, token growth, retry spikes, cache regressions, route changes, and unusual customer behavior before the invoice closes.
Every change needs an offline evaluation set and production guardrails for quality, latency, safety, tool success, and user outcomes. Roll out through shadow traffic and canaries, then keep the cheaper route only when total outcome cost improves.
标记功能、客户、环境、用户等级、实验、路由、供应商和模型。没有归属的成本会变成月度意外;有归属的成本则成为团队能够解释和改进的工程指标。
不要盲目重复发送静态文档、策略、示例、对话历史或检索段落。进行去重、总结旧轮次、只选择相关证据,并衡量首次输出质量是否稳定。
设置合理输出上限、停止序列、JSON schema、简洁风格指令和分页,同时跟踪截断与任务完成,避免激进限制把 token 节省变成一次完整重试。
分类、抽取、改写和简单聊天可使用经过评测的小模型;只有置信度、验证、风险、客户等级或任务复杂度超过明确阈值时,才升级到大模型。
长指令或参考上下文重复时使用供应商提示词缓存。估算节省前要建模缓存生命周期、最低 token 阈值、写入读取价格、路由行为、隐私和失效规则。
对安全的分类、抽取、转换和查询结果进行缓存,并把输入、提示词版本、模型路由、策略、权限和新鲜度纳入缓存键。绝不能跨错误边界复用用户特定或变化数据。
当供应商提供更有利价格时,把离线抽取、嵌入、分类、报告生成和评测移到批处理路径,并把队列延迟、重试行为、完成 SLA 和部分失败处理纳入决策。
重试前先分类错误,遵守 retry-after,使用有上限的指数退避,防止重复工具动作,并设置 Agent 最大步骤。失控循环几分钟内就能抵消数周提示词优化。
回退必须考虑质量、上下文、工具、地区、延迟和总价格。如果最便宜的备用模型破坏 schema、触发再次调用或把任务交给人工,它并不经济。
当可靠 API 或数据集能回答准确问题时,应直接调用,而不是让大模型猜测、反复搜索或处理超长上下文。同时把工具费用与失败和模型节省一起计量。
按项目、客户、功能、环境、Key 和时间窗口设置限制,并在账单结算前,对每次成功成本、token 增长、重试飙升、缓存退化、路由变化和异常客户行为告警。
每项变化都需要离线评测集,以及质量、延迟、安全、工具成功和用户结果的生产护栏。通过影子流量和金丝雀发布,只有总结果成本改善时才保留更便宜路由。
Metrics that prevent false savings防止“假节省”的关键指标
Divide full model, gateway, tool, retry, and human-review cost by outputs that pass the business acceptance rule. This prevents low-quality cheap requests from looking efficient simply because their rework is recorded elsewhere.
Measure how often one route completes the task without repair prompts, another model, repeated tools, or human intervention. A small improvement in first-pass success can outweigh a large difference in advertised token price.
Break down planner, retrieval, model, tool, verifier, and formatter stages. Aggregate averages hide the exact stage creating long context, verbose output, repeated calls, or expensive tail latency.
Plot evaluation quality against total outcome cost for each model, prompt, route, and cache policy. Choose the lowest-cost configuration that clears the required quality threshold rather than the cheapest configuration overall.
用通过业务验收规则的输出数量,除完整的模型、网关、工具、重试与人工复核成本,避免低质量便宜请求因为返工记录在别处而显得高效。
衡量一条路由无需修复提示词、其他模型、重复工具或人工介入即可完成任务的比例。首次成功率的小幅提升,可能超过标称 token 价格的巨大差异。
拆分规划、检索、模型、工具、验证和格式化阶段。总体平均值会掩盖究竟哪个阶段造成长上下文、冗长输出、重复调用或昂贵尾延迟。
为每个模型、提示词、路由和缓存策略绘制评测质量与总结果成本。应选择达到所需质量阈值的最低成本配置,而不是总体最便宜配置。
Prove savings with quality-adjusted economics用质量调整后的经济性证明节省
Freeze a representative evaluation set and record model, prompt, route, tokens, latency, retries, tool calls, human review, and accepted outcomes before optimizing. Without a baseline, savings are anecdotes.
Compare cheaper routes on shadow traffic, then expose a small production slice with automatic rollback thresholds for quality, latency, safety, schema validity, tool success, and user outcomes.
Add repair prompts, fallback calls, repeated retrieval, duplicate tools, support tickets, and human correction to total task cost. A cheap first request can create the most expensive completed outcome.
Plot accepted quality against complete outcome cost for every route and workload. Retain the lowest-cost configuration that clears the required threshold, and re-evaluate whenever models, prices, or traffic mix change.
在优化前固定代表性评测集,记录模型、提示词、路由、token、延迟、重试、工具调用、人工复核和可接受结果。没有基线,所谓节省只是个案。
先在影子流量上比较低成本路由,再用小比例生产流量验证,并为质量、延迟、安全、schema、工具成功率和用户结果设置自动回滚阈值。
把修复提示词、回退调用、重复检索、重复工具、支持工单和人工纠错加入总任务成本。最便宜的首次请求可能产生最昂贵的最终结果。
为每条路由和工作负载绘制可接受质量与完整结果成本,只保留达到要求阈值的最低成本配置,并在模型、价格或流量结构变化时重新评估。
Where QVeris fits: capability routing after model routingQVeris 的位置:模型路由之后的能力路由
A model gateway and QVeris solve adjacent problems. The gateway governs inference traffic: provider credentials, model selection, retries, budgets, rate limits, and logs. QVeris governs the next step when an agent needs a real capability: discovering a suitable tool or dataset, inspecting its contract, calling it, and keeping an auditable record.
For a financial research agent, the gateway might route a planning prompt to the right model. QVeris can then expose the market data, filings, fundamentals, news, or external tools required to complete the plan. This separation keeps model policy and capability policy understandable instead of forcing one gateway to pretend it owns every external action.
The recommended architecture is model gateway plus QVeris, not model gateway versus QVeris. Keep each layer responsible for the traffic it can govern well, then connect them with explicit identity, budget, trace, and audit metadata.
模型网关与 QVeris 解决相邻但不同的问题。网关治理推理流量,包括供应商凭证、模型选择、重试、预算、限流和日志。QVeris 则治理 Agent 需要真实能力后的下一步:发现合适工具或数据集、检查契约、执行调用并保留可审计记录。
以金融研究 Agent 为例,网关可以把规划提示词路由到合适模型;QVeris 再提供完成计划所需的市场数据、财报、基本面、新闻或外部工具。这样可以让模型策略和能力策略保持清晰,而不是让一个网关假装管理所有外部动作。
推荐架构是“模型网关 + QVeris”,而不是“模型网关 vs QVeris”。每一层只负责自己擅长治理的流量,再通过明确的身份、预算、追踪和审计元数据连接起来。
- Send inference requests through the selected gateway or aggregator.
- Attach project, customer, environment, and trace identity to every route.
- Use QVeris discovery and inspection before an agent calls a live capability.
- Measure model cost and capability cost separately, then report the complete task cost.
- 把推理请求发送到选定的网关或聚合器。
- 为每条路由附加项目、客户、环境和追踪身份。
- Agent 调用实时能力前,先使用 QVeris 发现与检查。
- 分别计量模型成本和能力成本,再报告完整任务成本。
FAQ
Remove repeated context, cap unnecessary output, fix retry loops, cache stable work, and route simple tasks to evaluated smaller models.
Savings depend on workload mix and quality thresholds. Measure cost per accepted outcome with your own traffic instead of relying on a universal percentage.
No. It helps when a substantial prefix repeats and the provider's cache rules, lifetime, and pricing match the workload.
No. Remove low-value repetition, but retain instructions, evidence, examples, and policies that improve first-pass success.
A gateway can centralize budgets, cost attribution, caching, model routing, fallback, limits, and anomaly detection across applications.
QVeris can give agents direct, auditable access to data and tools, reducing unsupported speculation and keeping capability calls separate from model routing.
删除重复上下文、限制不必要输出、修复重试循环、缓存稳定工作,并把简单任务路由到经过评测的小模型。
节省幅度取决于工作负载组合和质量阈值。应使用自己的流量测量每个可接受结果成本,而不是依赖统一百分比。
不能。只有当大量前缀重复,且供应商缓存规则、生命周期和价格匹配工作负载时才有帮助。
不应该。应删除低价值重复,但保留能提升首次成功率的指令、证据、示例与策略。
网关可跨应用集中管理预算、成本归因、缓存、模型路由、回退、限制和异常检测。
QVeris 为 Agent 提供直接、可审计的数据与工具访问,减少无依据猜测,并让能力调用与模型路由分层。
Sources, methodology, and update policy来源、方法与更新政策
This guide uses public product documentation and a workload-based decision framework. Product limits, pricing, supported models, and plan boundaries change frequently; verify current terms directly with each provider before procurement or production migration.
QVeris is the publisher of this guide and is described only in its intended complementary role. The comparisons distinguish model-inference routing from agent capability routing so the commercial relationship is visible rather than hidden inside a generic ranking.
本指南使用公开产品文档和基于工作负载的决策框架。产品限制、价格、支持模型和套餐边界会频繁变化;采购或生产迁移前,请直接向各供应商核对最新条款。
QVeris 是本指南的发布方,文中仅按其互补能力层定位进行说明。对比明确区分模型推理路由与 Agent 能力路由,使商业关系保持透明,而不是隐藏在泛化排名中。
