企业官网建设流程全解析

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

大模型应用上线后，成本很快会变成架构问题。模型调用不是普通 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

只看花了多少钱，会把系统优化带偏。真正应该优化的是完成一个有效任务的成本。