推理成本核算与 FinOps

本文解决 LLM 服务账单不可解释的问题:拆解 GPU 小时、token、存储、网络、向量库五类成本的计费口径与占比,给出自建与 API 的盈亏平衡计算方法与真实价格表,建立每千次请求成本、每用户成本、毛利率等单位经济指标。文中给出按团队、应用、租户打标签的归因方案,梳理量化、批处理、前缀缓存、路由、right-sizing 五类降本手段的降幅与风险,附可运行的 Python 核算脚本与常见坑。

LLM 服务的账单有一个特点:增长是平滑的,但归因是断裂的。财务看到的是一个月度总额,工程看到的是几个集群的利用率曲线,两者之间没有桥。本文的目标就是把这座桥搭起来:先把成本拆成可计费的单元,再把单元成本折算成业务指标,最后落到可执行的降本动作。

成本到底花在哪里

五类成本与计费口径

成本项计费单位自建典型占比API 典型占比可优化性
GPU 计算卡时或 token55% 到 75%0%中,靠利用率与量化
模型 APItoken0%70% 到 90%高,靠路由与缓存
存储GB 月5% 到 12%2% 到 5%中,靠生命周期策略
网络出流量GB3% 到 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 80GB80 GB1.791.10约 1800 token 每秒
H100 80GB80 GB3.202.10约 3400 token 每秒
L40S 48GB48 GB1.250.85约 900 token 每秒
RTX 409024 GB0.420.30约 700 token 每秒(8B)
自购 A10080 GB约 0.35(三年摊销)不适用约 1800 token 每秒

自购的摊销算法是:单卡 1.5 万美元,三年 26280 小时,加上电费与机房约每小时 0.08 美元,合计约每小时 0.35 美元。这个数字只有在利用率超过 60% 时才成立,否则摊销价会低于实际成本。

模型 API 价格

模型输入(美元每百万 token)输出(美元每百万 token)上下文上限
GPT-4o2.5010.00128k
GPT-4o mini0.150.60128k
Claude 3.5 Sonnet3.0015.00200k
Claude 3.5 Haiku0.804.00200k
Llama 3.1 70B 托管0.520.75128k
Qwen2.5 72B 托管0.380.60128k

盈亏平衡计算

自建与 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%22006000约 22
基准60%18008000约 43
悲观35%120012000约 168
灾难20%90015000不划算

这张表最有价值的一行是悲观行。它说明只要利用率掉到 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% 以上的场景。

成本归因

标签体系

标签维度示例值来源归因用途
teamsearch、growth部署元数据内部结算
applicationsupport-bot、code-copilot服务名产品毛利
tenantt_8821请求头多租户计费
modelgpt-4o、llama-3.1-70b网关决策模型性价比
prompt_versionv42提示注册表提示回归成本
cache_statushit、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 或 4bit30% 到 60%(自建)精度损失低自建推理
连续批处理吞吐提升 2 到 5 倍尾延迟上升中自建推理
GPU right-sizing20% 到 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 的选择不要凭直觉,用盈亏平衡点算一遍,把利用率与固定成本都算进去。最重要的习惯是让成本与用量来自同一个数据源,否则所有单位经济指标都只是估算。

继续阅读

探索更多技术文章

浏览归档,发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页

「LLMOps」更多文章

  1. 语义缓存与 Prompt 缓存
  2. 结构化输出与函数调用
  3. 多智能体编排与工作流引擎