模型调用审计：后端要知道每一分钱花在哪个请求上

📅 2026/7/4 5:09:42 👁️ 次浏览

模型调用审计后端要知道每一分钱花在哪个请求上大模型应用上线后成本很快会变成架构问题。模型调用不是普通 RPC它按 token、模型等级、上下文长度和并发消耗资源。如果后端只记录“调用成功”不知道哪个租户、哪个功能、哪个请求花了多少 token成本治理就无从谈起。模型调用审计的目标是让每一分钱都能追到请求、用户、租户和功能。一、审计字段要完整flowchart TD A[Request] -- B[Model Gateway] B -- C[Usage Meter] C -- D[Audit Store] D -- E[Cost Report]模型网关是最适合做审计的位置。所有调用统一经过这里才能保证口径一致。二、记录 token 和模型{ trace_id: tr_0703_001, tenant_id: t_01, feature: doc_summary, model: large, prompt_tokens: 4096, completion_tokens: 800, cost_cent: 12 }不要只记录总 token。prompt 和 completion 分开看才能知道是上下文太长还是输出太啰嗦。三、成本要按功能聚合SELECT feature, SUM(cost_cent) FROM model_usage WHERE created_at current_date - interval 7 days GROUP BY feature;独立看租户也重要但功能维度更能指导产品优化。某个功能消耗高但留存低就要重新评估。四、异常成本要告警如果某个租户或功能成本突然升高要告警。可能是用户批量导入也可能是循环调用 bug。cost_alert: tenant_daily_cost_growth: 200% feature_hourly_cost: threshold single_request_tokens: 100k成本异常也是生产异常。只是它不一定表现为 500 错误而是账单爆炸。审计数据还可以反向驱动优化。比如某个功能 prompt token 长期很高可以考虑摘要压缩、上下文裁剪或缓存中间结果某个租户输出 token 异常高可能需要限制最大输出长度。cost_optimization: long_prompt: compress_context repeated_query: cache_response_or_evidence verbose_output: cap_completion_tokens成本治理不是财务月底才看的报表而是后端日常优化输入。五、总结模型调用审计要记录 trace、租户、功能、模型、prompt token、completion token 和成本并支持按租户和功能聚合。后端要知道每一分钱花在哪个请求上。成本可见架构优化才有方向。如果成本只能按供应商账单看那已经太晚。真正有用的成本数据应该在请求完成时就被记录下来。另外成本审计要和质量指标一起看。某个优化让成本下降 40%但用户重试率翻倍真实成本可能没有下降。要同时观察成功率、重试率、满意度或人工接管率。cost_quality_pair: cost_per_successful_task retry_rate fallback_rate user_acceptance_rate只看花了多少钱会把系统优化带偏。真正应该优化的是完成一个有效任务的成本。

相关新闻