LLM 服务的账单有一个特点:增长是平滑的,但归因是断裂的。财务看到的是一个月度总额,工程看到的是几个集群的利用率曲线,两者之间没有桥。本文的目标就是把这座桥搭起来:先把成本拆成可计费的单元,再把单元成本折算成业务指标,最后落到可执行的降本动作。
成本到底花在哪里
五类成本与计费口径
| 成本项 | 计费单位 | 自建典型占比 | API 典型占比 | 可优化性 |
|---|---|---|---|---|
| GPU 计算 | 卡时或 token | 55% 到 75% | 0% | 中,靠利用率与量化 |
| 模型 API | token | 0% | 70% 到 90% | 高,靠路由与缓存 |
| 存储 | GB 月 | 5% 到 12% | 2% 到 5% | 中,靠生命周期策略 |
| 网络出流量 | GB | 3% 到 10% | 1% 到 3% | 低 |
| 向量库 | GB 加查询数 | 5% 到 15% | 3% 到 10% | 高,靠索引与量化 |
这个表说明一件事:自建的成本重心在利用率,API 的成本重心在调用量。两者的优化手段完全不同,混用会浪费精力。关于量化对显存与吞吐的具体影响,见 量化与显存优化 。
一个真实的成本拆解
假设一个中等规模的客服 Agent 服务,日活 3 万用户,人均每天 6 次会话,每次会话 4 次模型调用,平均输入 2400 token、输出 350 token。
- 日调用量:3 万乘 6 乘 4 等于 72 万次模型调用
- 日输入 token:72 万乘 2400 约 17.3 亿
- 日输出 token:72 万乘 350 约 2.52 亿
- 月输入 token:约 519 亿
- 月输出 token:约 75.6 亿
如果全部走 GPT-4o 的公开价格(输入每百万 2.5 美元,输出每百万 10 美元),月成本约 51900 乘 2.5 加 756 乘 10,也就是 12.975 万加 0.756 万美元,约 13.7 万美元。注意输入 token 占了 94% 的成本,这是绝大多数 RAG 类应用的真实结构:钱花在"把上下文喂进去",而不是"把答案吐出来"。
容易被忽略的隐藏成本
- 重试成本:失败重试会重复计费输入 token。重试率 5% 意味着成本直接多 5%
- 空转成本:GPU 预留了但利用率只有 20%,剩下 80% 是纯浪费
- 向量库的查询成本:很多向量库按查询次数计费,Agent 一次会话可能查 10 次
- 评测成本:LLM-as-Judge 的调用量在评测期可能超过线上流量
- 数据出网:跨区调用模型 API 的出网流量在规模大时不便宜
- 可观测性成本:trace 全量存储与索引,年成本可能达到总成本的 3% 到 8%
单位经济模型
三个必须建立的指标
| 指标 | 计算方式 | 用途 | 健康值参考 |
|---|---|---|---|
| 每千次请求成本 | 月总成本除以月请求数乘 1000 | 衡量工程效率 | 随业务定 |
| 每活跃用户成本 | 月总成本除以月活 | 衡量商业模式 | 低于 ARPU 的 25% |
| 每会话成本 | 月总成本除以月会话数 | 定价与套餐设计 | 低于客单价的 20% |
| 毛利率 | 收入减成本再除以收入 | 判断可持续性 | 大于 60% |
| 成本弹性 | 成本增速除以请求增速 | 判断规模效应 | 小于 0.7 |
成本弹性小于 1 意味着有规模效应,大于 1 意味着每多做一单亏得更多。这是判断"要不要继续扩量"的关键信号,比单纯的绝对值更有指导意义。
单位经济的三个陷阱
第一个陷阱是分母不一致。成本按月统计,请求数按采样估算,两者口径不同,算出来的单位成本每周都在飘。解决办法是让成本数据与请求数来自同一个数据源,或者至少让采样率保持稳定。
第二个陷阱是把免费用户算进来。免费用户的成本结构完全不同,混在一起会掩盖付费用户的真实成本。正确做法是分群统计,付费用户的单位成本才是定价依据。
第三个陷阱是忽略固定成本的摊销。GPU 是预付的,按小时摊销到请求上时,低峰期单位成本会虚高。用月度总量除以月度请求总量,而不是用峰值小时去算。
每用户成本的分层
按用户分层后,通常会看到幂律分布:前 5% 的重度用户消耗 40% 到 60% 的 token。这意味着两件事:一是要识别并限制滥用,二是要思考定价是否对重度用户公平。常见做法是设 token 配额、对超出部分阶梯计价、或者对重度用户改用更小的模型。关于多模型路由如何实现这种分层,见 模型网关与多模型路由 。
自建与 API 的盈亏平衡
GPU 每小时成本
| GPU 型号 | 显存 | 按需价(美元每小时) | 一年预留价 | 典型吞吐(70B,4bit) |
|---|---|---|---|---|
| A100 80GB | 80 GB | 1.79 | 1.10 | 约 1800 token 每秒 |
| H100 80GB | 80 GB | 3.20 | 2.10 | 约 3400 token 每秒 |
| L40S 48GB | 48 GB | 1.25 | 0.85 | 约 900 token 每秒 |
| RTX 4090 | 24 GB | 0.42 | 0.30 | 约 700 token 每秒(8B) |
| 自购 A100 | 80 GB | 约 0.35(三年摊销) | 不适用 | 约 1800 token 每秒 |
自购的摊销算法是:单卡 1.5 万美元,三年 26280 小时,加上电费与机房约每小时 0.08 美元,合计约每小时 0.35 美元。这个数字只有在利用率超过 60% 时才成立,否则摊销价会低于实际成本。
模型 API 价格
| 模型 | 输入(美元每百万 token) | 输出(美元每百万 token) | 上下文上限 |
|---|---|---|---|
| GPT-4o | 2.50 | 10.00 | 128k |
| GPT-4o mini | 0.15 | 0.60 | 128k |
| Claude 3.5 Sonnet | 3.00 | 15.00 | 200k |
| Claude 3.5 Haiku | 0.80 | 4.00 | 200k |
| Llama 3.1 70B 托管 | 0.52 | 0.75 | 128k |
| Qwen2.5 72B 托管 | 0.38 | 0.60 | 128k |
盈亏平衡计算
自建与 API 的对比不能只看单价,必须把利用率作为变量。下面的脚本同时算 token 成本与自建盈亏平衡点。
"""cost_model.py 推理成本核算与自建盈亏平衡,Python 3.12"""
from dataclasses import dataclass
@dataclass(frozen=True)
class ApiPricing:
"""按每百万 token 计价"""
name: str
input_per_mtok: float
output_per_mtok: float
def cost(self, in_tokens: int, out_tokens: int) -> float:
return (in_tokens / 1_000_000) * self.input_per_mtok + \
(out_tokens / 1_000_000) * self.output_per_mtok
@dataclass(frozen=True)
class GpuPricing:
"""自建按小时计价"""
name: str
usd_per_hour: float
tokens_per_second: float # 实测吞吐,含批处理
utilization: float = 1.0 # 实际利用率
def effective_hourly(self) -> float:
# 利用率越低,等效每小时成本越高
return self.usd_per_hour / max(self.utilization, 1e-6)
def cost_per_mtok(self) -> float:
# 一小时能产出的 token 数
tokens_per_hour = self.tokens_per_second * 3600
return self.effective_hourly() / (tokens_per_hour / 1_000_000)
GPT4O = ApiPricing("gpt-4o", 2.50, 10.00)
GPT4O_MINI = ApiPricing("gpt-4o-mini", 0.15, 0.60)
LLAMA70B_API = ApiPricing("llama-3.1-70b-managed", 0.52, 0.75)
def breakeven_tokens(api: ApiPricing, gpu: GpuPricing,
in_out_ratio: float = 6.86) -> float:
"""返回每月 token 盈亏平衡点:超过此值自建更省
in_out_ratio 为输入 token 与输出 token 的比例,默认 6.86 对应
上文客服场景(输入 2400,输出 350)。
"""
in_share = in_out_ratio / (1 + in_out_ratio)
out_share = 1 - in_share
api_cost_per_mtok = (in_share * api.input_per_mtok +
out_share * api.output_per_mtok)
gpu_cost_per_mtok = gpu.cost_per_mtok()
if gpu_cost_per_mtok >= api_cost_per_mtok:
return float("inf") # 该 GPU 在任何规模下都不划算
# 固定成本(人力、运维、冗余容量)按每月 8000 美元估算
fixed_monthly = 8000.0
# 求 x 使 fixed + x * gpu < x * api
return fixed_monthly / (api_cost_per_mtok - gpu_cost_per_mtok) * 1_000_000
if __name__ == "__main__":
a100 = GpuPricing("a100-80g", 1.10, 1800, utilization=0.6)
h100 = GpuPricing("h100-80g", 2.10, 3400, utilization=0.6)
print(f"A100 有效每百万 token: {a100.cost_per_mtok():.3f} 美元")
print(f"H100 有效每百万 token: {h100.cost_per_mtok():.3f} 美元")
print(f"对比 GPT-4o 的混合单价: "
f"{GPT4O.cost(2_400_000, 350_000):.3f} 美元每百万混合 token")
print(f"对比 Llama 托管混合单价: "
f"{LLAMA70B_API.cost(2_400_000, 350_000):.3f} 美元每百万混合 token")
for api in (GPT4O, LLAMA70B_API):
for gpu in (a100, h100):
be = breakeven_tokens(api, gpu)
print(f"{api.name} vs {gpu.name}: 月盈亏平衡 {be / 1e9:.1f} B token")
在利用率 60% 的假设下,A100 的有效成本约每百万 token 0.34 美元,H100 约 0.34 美元,两者接近,说明吞吐提升被更高的时租抵消了。对比 Llama 托管 API 的混合单价约 0.60 美元,自建在单价上确实便宜,但算上每月 8000 美元的固定成本,盈亏平衡点通常在每月 30 到 60 B token 之间。低于这个量级,托管 API 更划算。
什么时候该自建
判断标准可以收敛成四条,同时满足再考虑自建:
- 月 token 量稳定超过盈亏平衡点,且有增长预期
- 数据合规要求不能出内网
- 有持续的模型定制需求,例如微调与蒸馏
- 团队里有能承担 GPU 运维与推理引擎调优的人
只满足前两条而缺后两条,是自建项目失败的主要原因。运维成本被严重低估:一次驱动升级、一次显存碎片导致的 OOM、一次 NCCL 通信退化,都可能吃掉几个月的成本差。多租户共享同一张卡时,还要额外考虑显存隔离与调度带来的碎片损耗,这部分损耗通常会让有效吞吐再降 10% 到 20%。
敏感性分析
盈亏平衡点对三个变量最敏感:利用率、吞吐、固定成本。下表给出在不同假设下平衡点的变化,用于快速判断结论是否稳健。
| 场景 | 利用率 | 每卡吞吐(token 每秒) | 月固定成本 | 平衡点(B token 每月) |
|---|---|---|---|---|
| 乐观 | 80% | 2200 | 6000 | 约 22 |
| 基准 | 60% | 1800 | 8000 | 约 43 |
| 悲观 | 35% | 1200 | 12000 | 约 168 |
| 灾难 | 20% | 900 | 15000 | 不划算 |
这张表最有价值的一行是悲观行。它说明只要利用率掉到 35%,平衡点就翻了四倍,从"半年内自建划算"变成"要等两年"。所以自建决策的真正问题不是"我们有多少 token",而是"我们能不能把利用率稳定在 60% 以上"。利用率取决于流量曲线的平滑程度,而流量曲线又取决于业务形态:面向企业的服务在工作时段集中,面向消费的服务在晚间集中,两者都需要靠弹性扩缩容来填谷。
混合策略
实践中很少有团队全自建或全 API,更常见的是混合:用自建承载基线流量,用 API 吸收峰值与突发。这种结构下,自建的利用率可以拉到 75% 以上,因为峰值由 API 兜底,而 API 的用量只占总量的一小部分,单价高但总量可控。混合策略的成本模型要分开算两个池子,不能简单取平均单价。
分场景的成本结构
不同产品的成本结构差异极大,用同一套优化顺序会事倍功半。下表给出三类常见场景的实测结构。
| 场景 | 输入输出比 | 成本大头 | 首选优化 | 次选优化 |
|---|---|---|---|---|
| RAG 问答 | 12 比 1 | 输入 token 与向量查询 | 上下文裁剪、前缀缓存 | 语义缓存、重排减量 |
| 代码助手 | 8 比 1 | 输入 token 与长上下文 | 前缀缓存、仓库索引裁剪 | 路由到小模型 |
| 内容生成 | 1 比 3 | 输出 token | 输出长度约束、流式截断 | 小模型草稿加校对 |
| 批处理抽取 | 20 比 1 | 输入 token 与吞吐 | 连续批处理、量化 | 自建替代 API |
| 实时对话 | 5 比 1 | 延迟约束下的算力冗余 | 分池、right-sizing | 量化 |
RAG 问答的成本结构最反直觉:钱主要花在检索回来的文档上,而不是生成答案。这意味着优化重排的 top_k、压缩注入文档的长度,比换模型有效得多。把 top_k 从 10 降到 5,同时用重排保证召回,实测能降 30% 以上的输入 token,质量分下降通常在 1 个点以内。
内容生成类正好相反,输出 token 是成本主体。约束最大输出长度、对长文分段生成并复用前缀、在草稿阶段用小模型,是三条主线。这类场景对量化最敏感,因为长文本生成的误差会累积。
批处理抽取类最容易被忽略,因为它不面向用户,没有体验约束。这类场景几乎必然应该自建,因为它的流量平滑、延迟容忍度高、批处理收益能完全兑现,是自建利用率最容易做到 80% 以上的场景。
成本归因
标签体系
| 标签维度 | 示例值 | 来源 | 归因用途 |
|---|---|---|---|
team | search、growth | 部署元数据 | 内部结算 |
application | support-bot、code-copilot | 服务名 | 产品毛利 |
tenant | t_8821 | 请求头 | 多租户计费 |
model | gpt-4o、llama-3.1-70b | 网关决策 | 模型性价比 |
prompt_version | v42 | 提示注册表 | 提示回归成本 |
cache_status | hit、miss | 缓存中间件 | 缓存收益核算 |
标签必须在请求进入网关时就打上,而不是在业务代码里补。网关是唯一能同时看到模型、租户、缓存状态的组件。提示版本也是一个重要的成本维度:同一个模型配不同提示,输入 token 可能相差一倍,因此 prompt_version 必须与 model 一起进入归因表。
从标签到账单
最小可行的归因流水线是:网关在响应里回填 usage 与标签,落一条结构化日志;日志按小时聚合到 cost_daily 表;BI 按标签维度出报表。关键在于日志必须包含 token 用量与缓存状态,否则只能算总账,算不出增量。
-- cost_daily.sql 按租户与模型聚合日成本(PostgreSQL 16.4)
CREATE TABLE cost_daily (
day date NOT NULL,
tenant_id text NOT NULL,
application text NOT NULL,
model text NOT NULL,
input_tokens bigint NOT NULL,
output_tokens bigint NOT NULL,
cache_hits bigint NOT NULL,
requests bigint NOT NULL,
cost_usd numeric(14,4) NOT NULL,
PRIMARY KEY (day, tenant_id, application, model)
);
INSERT INTO cost_daily
SELECT
date_trunc('day', ts)::date AS day,
tenant_id,
application,
model,
sum(input_tokens) AS input_tokens,
sum(output_tokens) AS output_tokens,
count(*) FILTER (WHERE cache_status = 'hit') AS cache_hits,
count(*) AS requests,
round(sum(
input_tokens / 1e6 * in_price +
output_tokens / 1e6 * out_price
), 4) AS cost_usd
FROM llm_request_log
WHERE ts >= now() - interval '1 day'
GROUP BY 1, 2, 3, 4
ON CONFLICT (day, tenant_id, application, model) DO UPDATE
SET input_tokens = EXCLUDED.input_tokens,
cost_usd = EXCLUDED.cost_usd;
价格要单独建一张 model_price 维表,并把生效日期带上。模型降价很频繁,把价格硬编码在查询里,历史账单会被追改,财务对不上账。
归因粒度的取舍
粒度越细,标签基数越高,存储与查询成本越高。经验规则是:高基数的 tenant 标签只保留在日聚合层,不进入逐请求的明细表;明细表里保留 application 与 model 即可。如果确实需要按租户逐请求归因,把明细按天分区并设 30 天保留期,更早的数据只保留聚合结果。
降本手段
手段与预期收益
| 手段 | 预期降幅 | 主要风险 | 实施成本 | 适用条件 |
|---|---|---|---|---|
| 提示瘦身与上下文裁剪 | 20% 到 40% | 质量下降 | 低 | 输入 token 占比高 |
| 前缀缓存 | 30% 到 70%(输入侧) | 前缀命中率低 | 中 | 系统提示固定且长 |
| 语义缓存 | 15% 到 50% | 错误命中 | 中 | 查询重复度高 |
| 模型路由到小模型 | 40% 到 80% | 质量分层不均 | 中 | 请求难度可分层 |
| 量化到 8bit 或 4bit | 30% 到 60%(自建) | 精度损失 | 低 | 自建推理 |
| 连续批处理 | 吞吐提升 2 到 5 倍 | 尾延迟上升 | 中 | 自建推理 |
| GPU right-sizing | 20% 到 50% | 容量不足 | 低 | 利用率低于 40% |
| 生命周期策略 | 5% 到 15% | 数据不可回溯 | 低 | 存储占比高 |
量化
自建场景下,把权重从 FP16 降到 INT8 通常能省一半显存、提升 1.3 到 1.8 倍吞吐;降到 INT4 能省四分之三显存,吞吐提升 2 到 3 倍,但复杂推理任务的质量损失会变得明显。判断标准是:如果你的评测集上 INT4 的质量分下降超过 2 个点,就不要上 INT4。
批处理与连续批处理
连续批处理把吞吐从每卡 400 token 每秒提升到 1800 token 每秒,是自建降本里收益最大的一项。代价是尾延迟上升:在 P99 上可能从 1.2 秒涨到 2.5 秒。如果业务对尾延迟敏感,用分池的方式解决,把延迟敏感流量单独放一个实例。批处理的收益还取决于请求长度的方差,长度差异越大,批内填充浪费越多,实际吞吐提升会低于理论值。
前缀缓存与语义缓存
前缀缓存对"系统提示很长且固定"的场景效果极好。一个 3000 token 的系统提示,如果每次都重新计算,成本占比很高;命中前缀缓存后,这部分输入按更低的费率计费。语义缓存则依赖查询重复度,客服场景的重复率常在 20% 到 40%,能直接砍掉对应比例的调用。
两者的共同前提是可观测:必须监控命中率,命中率低于 15% 时缓存收益覆盖不了它的复杂度与错误风险。
模型路由
把简单请求路由到小模型,是 API 场景下最直接的降本方式。一个可用的策略是先用小模型试,置信度不足再升级到大模型,实测能把 60% 到 75% 的请求留在小模型上。风险是升级判断本身的成本,以及分层不一致带来的体验波动。
right-sizing GPU
常见现象是给 8B 模型配了 A100 80GB,利用率常年低于 25%。正确做法是按显存与吞吐需求选卡:8B 模型用 L40S 或 4090 就够,70B 才需要 A100 或 H100。这一步不需要任何工程改动,收益却经常排在第二位。关于云上成本优化的通用方法,见 Kubernetes 成本优化 。
缓存收益的量化
缓存是少数能同时降成本与降延迟的手段,但收益需要算清楚才敢上。下面的脚本估算前缀缓存与语义缓存叠加后的成本曲线,用于确定投入顺序。
"""cache_savings.py 缓存收益核算,Python 3.12"""
from dataclasses import dataclass
@dataclass
class Workload:
requests_per_month: int
input_tokens: int # 平均输入 token
output_tokens: int # 平均输出 token
prefix_tokens: int # 可缓存的固定前缀长度
in_price: float # 每百万输入 token 价格
out_price: float # 每百万输出 token 价格
cached_discount: float = 0.10 # 缓存命中后输入侧的折扣系数
def monthly_cost(w: Workload, prefix_hit: float, sem_hit: float) -> dict:
"""prefix_hit 与 sem_hit 分别为前缀缓存、语义缓存的命中率"""
total_in = w.requests_per_month * w.input_tokens
total_out = w.requests_per_month * w.output_tokens
# 语义缓存命中:整次请求都不需要调用模型
effective_requests = w.requests_per_month * (1 - sem_hit)
# 前缀缓存命中:仅前缀部分按折扣计价
cached_prefix = effective_requests * w.prefix_tokens * prefix_hit
full_price_prefix = effective_requests * w.prefix_tokens * (1 - prefix_hit)
rest_in = effective_requests * (w.input_tokens - w.prefix_tokens)
in_cost = (
cached_prefix * w.cached_discount +
full_price_prefix +
rest_in
) / 1_000_000 * w.in_price
out_cost = effective_requests * w.output_tokens / 1_000_000 * w.out_price
return {
"input_usd": round(in_cost, 2),
"output_usd": round(out_cost, 2),
"total_usd": round(in_cost + out_cost, 2),
}
if __name__ == "__main__":
w = Workload(
requests_per_month=21_600_000,
input_tokens=2400,
output_tokens=350,
prefix_tokens=1500,
in_price=2.50,
out_price=10.00,
)
baseline = monthly_cost(w, 0.0, 0.0)["total_usd"]
for prefix_hit in (0.0, 0.4, 0.7, 0.9):
for sem_hit in (0.0, 0.2, 0.4):
cost = monthly_cost(w, prefix_hit, sem_hit)["total_usd"]
print(f"前缀命中 {prefix_hit:.0%} 语义命中 {sem_hit:.0%} "
f"月成本 {cost:,.0f} 美元 降幅 {(1 - cost / baseline):.1%}")
在这个负载下,仅开启前缀缓存(命中 70%)就能降约 22%;叠加 30% 的语义缓存命中,总降幅接近 48%。注意语义缓存的收益是乘性的,因为它直接减少请求数,而前缀缓存是线性的,只影响输入侧。因此当语义缓存命中率能稳定超过 20% 时,优先做语义缓存。
缓存的风险边界
语义缓存的核心风险是错误命中。两个语义相近但意图相反的问题,比如"如何启用双因素认证"和"如何关闭双因素认证",向量相似度可能高达 0.95。缓解方式有三条:提高相似度阈值(常用 0.93 到 0.97)、在缓存键里加入意图分类结果、对高风险领域直接禁用语义缓存。第三层防护是缓存命中后仍走一次轻量校验,用小模型判断缓存答案是否适配当前问题。
降本手段的排序原则
排序不应只看单点降幅,而要看"降幅除以实施成本"。经验顺序是:提示瘦身、缓存、路由、right-sizing、量化、批处理。前三项都在应用层,一两周能见效;后三项涉及推理栈或基础设施,周期以月计。把顺序做反,团队会在量化上花三个月,却发现输入 token 本来就能砍掉三成。
成本治理的组织方式
从月度对账到日常治理
FinOps 的成熟度分三级:第一级是月末对账,发现超支但为时已晚;第二级是日级看板,能在一周内纠偏;第三级是请求级预算,超预算的租户自动降级到小模型或返回限流。多数团队应该先做到第二级,再按需推进到第三级。
预算与告警
给每个应用设月度预算,并配置三条告警线:达到预算 70% 时通知负责人,达到 90% 时通知负责人加技术主管,达到 100% 时触发自动降级策略。自动降级要谨慎,错误的降级策略可能把付费用户也降掉,所以策略里必须带白名单。
谁负责成本
成本优化的最大障碍是责任不清。推荐的分工是:平台团队负责单位成本(每百万 token 的工程效率),业务团队负责总用量(请求数),财务负责定价与毛利。三者各自有明确的优化目标,避免"大家都觉得该省但没人动手"。
常见坑清单
只看 GPU 不看利用率
按卡时计费最容易骗自己:账单上 GPU 花了 4 万美元,看起来很多,但一算利用率只有 18%,实际有效算力成本是标价的 5.5 倍。任何自建成本报表的第一列都应该是利用率,而不是花费。
忽略空闲成本
预留实例、闲置的向量库、为峰值准备却常年空转的副本,这些空闲成本不会体现在请求级指标里,但会占账单的 20% 到 40%。做法是给每个资源打上 owner 与 purpose 标签,每月审查一次零请求的资源。
缓存命中率不监控
缓存是"上线容易、失效难察觉"的典型。命中率从 60% 掉到 8% 时,账单会涨,但接口成功率与延迟毫无变化,没有任何告警会触发。必须把命中率作为一等指标,与成本指标放在同一块看板上。
其余高频问题
- 用峰值小时的成本除以峰值请求数,得出偏低的单位成本,误导定价决策
- 模型降价后没有回填价格维表,历史报表与实际账单长期不一致
- 把评测、压测、开发环境的调用算进生产成本,掩盖真实单位成本
- 重试逻辑没有上限,失败风暴时重复计费输入 token,单次事故就能烧掉月度预算
- 只优化输出 token,而输入 token 占了 90% 以上成本
- 语义缓存阈值设得过松,命中错误答案,省了钱却丢了用户
- 没有把可观测性自身的存储成本纳入核算,trace 保留期过长导致隐性支出
- 自建时按理论吞吐算成本,忽略批处理失效、显存碎片、多卡通信带来的实际衰减
小结
推理成本治理的路径可以概括成三步:先把成本拆成 GPU、token、存储、网络、向量库五个可计费单元,并把每个单元的口径固定下来;再把单元成本折算成每千次请求成本、每用户成本与毛利率这三个业务指标,让工程决策与商业决策共用一套语言;最后按收益从高到低执行降本动作,通常是提示瘦身、模型路由、前缀缓存、量化、right-sizing 这个顺序。自建与 API 的选择不要凭直觉,用盈亏平衡点算一遍,把利用率与固定成本都算进去。最重要的习惯是让成本与用量来自同一个数据源,否则所有单位经济指标都只是估算。
继续阅读
探索更多技术文章
浏览归档,发现更多关于系统设计、工具链和工程实践的内容。