当企业级应用接入 DeepSeek 等大模型时，成本核算往往陷入黑箱状态。一个看似简单的问答请求，背后可能同时触发：

1. 基础模型推理（按 token 计费）
2. RAG 环节的向量检索与重排（按调用次数计费）
3. 外部工具调用如代码执行（按 API 次数计费）

成本拆解的三层挑战

日志字段缺失：多数 LLM 网关仅记录总耗时和总 token 数，不区分生成 token 与提示词 token。例如 DeepSeek API 返回的 usage.prompt_tokens 实际包含：

• 用户原始输入
• 系统提示模板
• RAG 插入的文档片段
• 工具调用的参数序列化

资源耦合：当采用流式响应时，推理、检索和工具调用可能并行执行。某金融客户案例显示，其工单分析请求中 38% 的延迟来自并行执行的 PDF 解析工具，但成本全被计入模型推理。

间接消耗：向量数据库的搜索开销通常按节点计费，但实际消耗与以下强相关：

• 查询时触发的索引类型（HNSW 比 IVF 更耗 CPU）
• 返回的候选数（top_k 从 5 增至 50 时成本非线性上升）

可落地的审计方案

阶段一：日志增强

# 在 FastAPI 中间件注入审计字段
@app.middleware("http")
async def audit_log(request: Request, call_next):
    start_time = time.time()
    response = await call_next(request)

    # 从响应头提取 DeepSeek 原生指标
    model_usage = json.loads(response.headers.get("X-LLM-Usage", "{}"))

    # 自定义审计字段
    audit_data = {
        "rag_stages": request.state.rag_ops,  # 记录各阶段耗时
        "tool_calls": request.state.tool_invocations,
        "real_prompt_tokens": calculate_real_prompt_tokens(request)
    }

    # 写入时序数据库
    await influxdb.write("llm_cost", {**model_usage, **audit_data})
    return response

阶段二：资源标签化

• 推理环节：通过 X-Request-ID 关联到具体模型版本和量化精度（FP16 比 INT8 成本高 1.7 倍）
• 检索环节：记录向量库的 index_type 和 top_k 参数
• 工具环节：标记工具类型（代码解释器/网络搜索等）和执行耗时

阶段三：成本分配公式

某电商客户采用的分配逻辑：

$$ \text{推理成本} = \frac{\text{生成token数}}{\text{总token数}} \times \text{模型单价} $$

$$ \text{RAG成本} = \sum (\text{检索耗时} \times \text{向量库单价}) + \frac{\text{文档token数}}{\text{总token数}} \times \text{模型单价} $$

避坑指南

1. 不要依赖单一计费指标：当发现 DeepSeek 账单中 prompt token 占比异常高时，可能是工具调用参数序列化未被过滤
2. 警惕流式响应的成本漂移：在长会话中，后期消息可能因上下文积累消耗更多 token，需按消息拆分统计
3. 测试环境的成本泄漏：预发环境使用的向量库若与生产共享集群，其开销可能被错误归因

边界情况处理

• 混合检索场景：当同时使用关键词搜索和向量搜索时，建议按 7:3 拆分两者对最终结果的贡献度
• 缓存命中：若从 Redis 获取了历史搜索结果，需标记为 cached_rag 避免重复计费
• 失败请求：即使 HTTP 500 也可能消耗计算资源，需捕获并记录到 failed_requests 成本池

成本优化实战案例

某在线教育平台通过精细化的成本归因发现：

• 其「题目解析」功能中，41% 的成本来自 LaTeX 公式渲染工具调用，而非模型推理
• 通过将公式预处理为文本描述，单题解析成本下降 63%
• 在 RAG 环节，将 top_k 从默认的 20 调整为动态值（根据 query 复杂度在 5-15 间浮动），月度向量库支出减少 ¥8,200

监控看板关键指标

建议在 Grafana 中配置以下核心指标：

实施路线图

1. 第 1 周：部署增强版日志中间件，收集原始数据
2. 第 2-3 周：建立成本分配模型，验证数据准确性
3. 第 4 周：优化工具链配置，首批试点 API 成本下降 15-30%
4. 持续迭代：每月分析成本构成变化，识别新的优化机会

通过这套方法，某物流企业将其 LLM 成本核算精度从「项目级」提升到「API 调用级」，发现 19% 的消耗实际来自未被监控的表格解析工具链。后续通过工具链优化，季度总成本降低 27%，同时保持了 99% 的 SLA 达标率。