企业大模型资产盘点：评估各业务线的调用 ROI
去年年中，很多技术团队在 KPI 和技术创新的驱动下，纷纷在各类业务线中接入大模型能力：智能客服、知识库问答、营销文案生成、研发辅助 Code Review、运营数据报表总结等。
到了今年三季度做财务预算审计时，财务部门和运维总监把一份账单摔在架构组桌上：每月大模型 API 调用费用加上私有化 GPU 算力租金已突破六位数，但业务大盘的核心指标（如 GMV、用户留存、客服人效）却没有明显波动。
大模型落地已经走过了“尝鲜期”，进入了必须算清经济账的“资产盘点与 ROI 考核期”。本文从架构师视角，分享我们如何搭建一套大模型成本度量与业务 ROI 评估体系，以及如何通过架构手段实现大模型调用的精准降本。
为什么很多业务线的 AI 调用成了成本黑洞？
在对十多条业务线的大模型调用日志进行回溯后，我们发现了三个非常普遍的成本浪费现象：
- 杀鸡用牛刀，模型选型无分级：许多简单任务（如“从用户评论中提取手机号”、“判断用户情绪是正面还是负面”）直接调用了单价最高的大参数旗舰模型，而这些任务一个轻量级的 7B/14B 开源小模型甚至正则匹配就能以接近 0 成本完成。
- 长上下文 Prompt 的重复浪费：在客服和 RAG 知识库场景中，每次对话都会把长达上万 Token 的系统 Prompt、知识切片和历史对话全部重新打包发送，且没有任何上下文裁剪和缓存机制，导致 90% 的费用花在重复传输的静态上下文上。
- 低频伪需求占据高额算力池：某些业务线为了“讲故事”申请了独立的 A100/H800 GPU 算力实例，全天利用率不足 8%，但机器租赁成本每月照付不误。
大模型调用 ROI 评估模型
要衡量一条业务线是否值得继续投入大模型，我们建立了一套量化指标公式：
$$\text{ROI} = \frac{\text{业务增量价值} + \text{人力替代节约成本} - \text{AI 综合运行成本}}{\text{AI 综合运行成本}}$$
我们将评估维度拆解为可落地的三层指标：
+-------------------------------------------------------------+ | 大模型 ROI 综合评估体系 | +-------------------------------------------------------------+ | 1. 成本层 (Cost) | | - Token 直接费用 (Input / Output Token 费用归属) | | - 基础设施分摊 (GPU 卡时租金 / 向量数据库 / 网关带宽) | | - 运维与研发分摊 (Prompt 调优 / 数据标注 / 算法人力) | +-------------------------------------------------------------+ | 2. 效率与质量层 (Quality & Efficiency) | | - 平均处理时长缩短率 (AHT Reduction) | | - 一次性解决率 (First Contact Resolution, FCR) | | - 人工介入率 / 兜底率 (Fallback Rate) | +-------------------------------------------------------------+ | 3. 业务价值层 (Business Value) | | - 转化率提升 (Conversion Rate Lift) | | - 节约全职人力工时 (FTE Saved) | | - 客诉率与违规率下降 (Compliance & Risk Reduction) | +-------------------------------------------------------------+业务线四象限归类矩阵
通过以上指标，我们可以将企业内部所有接入 AI 的业务线划入四个象限，采取不同的资源倾斜策略：
| 象限 | 特征 | 典型业务场景 | 架构决策 |
|---|---|---|---|
| 第一象限（高价值·高收益） | Token 成本可控，业务指标显著提升 | 电商智能导购推荐、智能外呼挽单 | 持续加大资源投入，优化响应延迟 |
| 第二象限（高成本·可优化） | 业务有刚需，但 Token 消耗过大 | 智能客服知识库、合同法务审查 | 强制引入语义缓存与上下文压缩降本 |
| 第三象限（低价值·高浪费） | 调用频次低，人工接管率超 60% | 内部周报自动生成、冷门报表总结 | 立即下线或降级为纯端侧/开源小模型 |
| 第四象限（低成本·小工具） | 成本极低，辅助提升日常开发效率 | SQL 生成助手、单元测试自动补全 | 保持轻量化运行，限制调用配额 |
统一 AI 网关与成本计量架构
要算清每一分钱花在哪里，核心是在架构中建立统一 AI 流量接入网关。所有业务方不得私自直连云端大模型 API，必须统一经过内部 AI 网关。
+----------------+ +----------------+ +----------------+ | 客服业务线 | | 营销运营平台 | | 研发效能平台 | +-------+--------+ +-------+--------+ +-------+--------+ | | | +-----------------------+-----------------------+ | (带租户与业务标签 Tenant-Id) v +----------------------------------------------------------------+ | 企业统一 AI 接入网关 | | +---------------------+ +-----------------+ +-------------+ | | | 语义缓存 (Redis) | | 模型路由器(Rule)| | 预算硬限流 | | | +---------------------+ +-----------------+ +-------------+ | | +-----------------------------------------------------------+ | | | Token 计量与成本分摊过滤器 (Async Kafka Metric Producer) | | | +-----------------------------------------------------------+ | +-------------------------------+--------------------------------+ | +-----------------------+-----------------------+ v v +-------------------------------+ +----------------+ | 商业大模型 (按 Token 计费) | | 私有化算力集群 | | (DeepSeek / Qwen / Claude) | | (vLLM / 7B-32B)| +-------------------------------+ +----------------+1. Spring Cloud Gateway 计量过滤器实现
以下是我们在 API 网关中落地的核心 Token 采集与成本追踪 Filter：
package com.example.gateway.filter; import com.example.gateway.metric.AiCostMetricProducer; import com.example.gateway.model.AiUsageLog; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.cloud.gateway.filter.GatewayFilterChain; import org.springframework.cloud.gateway.filter.GlobalFilter; import org.springframework.core.Ordered; import org.springframework.stereotype.Component; import org.springframework.web.server.ServerWebExchange; import reactor.core.publisher.Mono; import java.time.Instant; @Component public class AiUsageMeteringFilter implements GlobalFilter, Ordered { private static final Logger log = LoggerFactory.getLogger(AiUsageMeteringFilter.class); private final AiCostMetricProducer metricProducer; public AiUsageMeteringFilter(AiCostMetricProducer metricProducer) { this.metricProducer = metricProducer; } @Override public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { long startTime = System.currentTimeMillis(); String tenantId = exchange.getRequest().getHeaders().getFirst("X-Tenant-Id"); String businessLine = exchange.getRequest().getHeaders().getFirst("X-Business-Line"); String requestedModel = exchange.getRequest().getHeaders().getFirst("X-Requested-Model"); if (tenantId == null || businessLine == null) { tenantId = "DEFAULT_TENANT"; businessLine = "UNKNOWN"; } final String finalTenantId = tenantId; final String finalBusinessLine = businessLine; return chain.filter(exchange).then(Mono.fromRunnable(() -> { long latencyMs = System.currentTimeMillis() - startTime; int statusCode = exchange.getResponse().getStatusCode() != null ? exchange.getResponse().getStatusCode().value() : 500; // 从响应头中提取大模型服务商返回的标准 Token 用量 String promptTokensStr = exchange.getResponse().getHeaders().getFirst("X-Prompt-Tokens"); String completionTokensStr = exchange.getResponse().getHeaders().getFirst("X-Completion-Tokens"); int promptTokens = promptTokensStr != null ? Integer.parseInt(promptTokensStr) : 0; int completionTokens = completionTokensStr != null ? Integer.parseInt(completionTokensStr) : 0; AiUsageLog usageLog = new AiUsageLog(); usageLog.setTenantId(finalTenantId); usageLog.setBusinessLine(finalBusinessLine); usageLog.setModel(requestedModel != null ? requestedModel : "unknown-model"); usageLog.setPromptTokens(promptTokens); usageLog.setCompletionTokens(completionTokens); usageLog.setTotalTokens(promptTokens + completionTokens); usageLog.setLatencyMs(latencyMs); usageLog.setStatusCode(statusCode); usageLog.setTimestamp(Instant.now()); // 异步投递到 Kafka 进行成本结算与实时看板统计 metricProducer.sendUsageMetric(usageLog); log.info("AI Request Metered: tenant={}, biz={}, model={}, promptTokens={}, completionTokens={}, costTime={}ms", finalTenantId, finalBusinessLine, requestedModel, promptTokens, completionTokens, latencyMs); })); } @Override public int getOrder() { return Ordered.LOWEST_PRECEDENCE; } }2. 成本实时核算 SQL 报表模型
网关采集的日志经 Flink 实时聚合后写入 ClickHouse 或 MySQL，支撑每周各业务线大模型消耗与 ROI 账单生成：
SELECT business_line AS 业务线, model AS 模型名称, COUNT(1) AS 调用总次数, SUM(prompt_tokens) AS 输入Token总数, SUM(completion_tokens) AS 输出Token总数, -- 假设商业模型单价：输入 0.002 元/k-token，输出 0.006 元/k-token ROUND(SUM(prompt_tokens) * 0.000002 + SUM(completion_tokens) * 0.000006, 2) AS 产生API成本_元, ROUND(AVG(latency_ms), 0) AS 平均耗时_毫秒, ROUND(SUM(CASE WHEN status_code = 200 THEN 1 ELSE 0 END) * 100.0 / COUNT(1), 2) AS 成功率_百分比 FROM ai_usage_log WHERE timestamp >= DATE_SUB(NOW(), INTERVAL 7 DAY) GROUP BY business_line, model ORDER BY 产生API成本_元 DESC;落地成效与降本关键实战
通过盘点与网关治理，我们在 3 个月内将大模型调用账单降低了 58%，核心动作包括：
- 引入精准语义缓存（Semantic Cache）：
在客服与知识库问答中，将历史高频提问在 Redis 向量库中构建索引。当新请求的语义相似度达到 0.95 以上时，直接返回缓存的回答结果，命中率达到 38%，这一项直接砍掉了近 40% 的 Token 采购成本。 - 多级模型路由（Tiered Routing）：
通过轻量规则引擎和 7B 开源小模型前置做意图识别。70% 的模板类、抽取类请求直接路由到私有化部署的小模型，只有深度长文本分析才放行给顶配旗舰模型。 - 强制业务部门承担账单（Showback / Chargeback）：
将 AI 网关统计出的月度账单直接计入各业务线部门成本中心。当大模型调用直接扣减业务线负责人的部门利润时，各类无序调用和低价值 Prompt 实验在两周内主动减少了 65%。
企业技术架构演进的终局永远是商业价值。大模型不是免费的魔法，只有建立清晰的成本账本和严格的 ROI 准入机制，才能让 AI 真正沉淀为驱动业务持续增长的核心数字资产。
