1.2 成本最高的10类请求画像

1.2 找出成本最高的 10 类请求：给优化排个优先级

读完这一节，你应该能回答：「我手里有限的工程精力，该先砸在哪些请求上？」答案不是「最频繁的那类」，而是「频率和单价乘积最高、且最容易被缓存或降级的那类」。

Day 1 我们建立了成本公式，这一节要做的第一件实事，就是把公式落到你自己的系统上：不看直觉，看账单。90% 的团队在这里会犯一个错——凭感觉觉得「客服问答最费钱」，结果一拉数据发现真正烧钱的是「每天被定时任务反复触发的批量摘要」。本节带你用一套可复用的画像方法，把「成本最高的 10 类请求」挖出来，并给出每一类的处置策略。

一、为什么是「10 类」而不是「全部」

工程资源永远有限。一个中等规模的 AI 应用，请求类型可能上百种，但你不需要、也不应该一上来就全部优化。帕累托法则在这里依然成立：通常前 10 类请求就贡献了 70%~90% 的 Token 成本。把这一小撮打透，收益最大、风险最小。

更重要的是，「10 类」是一个「既能看清结构、又不至于淹没在细节里」的粒度。太少（比如只盯 3 类）会漏掉重要长尾；太多（50 类）则失去聚焦意义。下面这张图说明了聚焦逻辑。

二、给请求「画像」需要哪些字段

要从日志里还原出「类成本」，你需要至少这些字段（上一节建议打的标签正好用上）：

• 请求指纹（request signature）：用于聚类的稳定标识。可以是「路由路径 + 模板名」，例如 chatbot/faq、summary/daily_news。注意要用「意图」而非「原始文本」做聚类，否则每个用户的不同问法都会变成不同类，无法聚合。
• 调用次数（count）：该类在统计窗口内的总次数。
• 平均输入 Token / 平均输出 Token：建议同时记录 P50 和 P95，因为长尾会扭曲平均值。
• 使用的模型（model）：不同模型单价不同。
• 是否命中缓存（cache_hit）：这是后续衡量优化效果的关键基线，现在可能是 0，但要先埋点。
• 来源（source）：是真实用户流量，还是内部定时任务、测试脚本、爬虫。

说明：上表用 Mermaid 的 table 语法示意「画像字段卡」，实际你在数据仓库里就是一张宽表。核心是「每个类一行，行内有频次、Token、单价、模型、缓存命中率」这几列。

三、计算「类成本」并排序：一个最小可用的 SQL 思路

假设你的请求日志在表 llm_requests 中，字段如上。一条最朴素的聚合查询长这样（伪 SQL，具体语法随你的数仓而定）：

SELECT
    request_signature,
    COUNT(*)                         AS call_count,
    AVG(input_tokens)               AS avg_in,
    AVG(output_tokens)              AS avg_out,
    AVG(reasoning_tokens)           AS avg_reason,
    ANY_VALUE(model)                AS model,
    SUM(input_tokens  * input_price
      + output_tokens * output_price
      + reasoning_tokens * reason_price) AS class_cost
FROM llm_requests
WHERE ts BETWEEN :start AND :end
GROUP BY request_signature
ORDER BY class_cost DESC
LIMIT 10;
​

跑完这条查询，你得到的就是「成本 Top 10 类请求」。但光看金额排序还不够，因为处置策略取决于「这类请求能不能被优化」。所以下一步要给每一类打上「可优化性标签」。

四、十类请求的「典型画像」与处置策略

为了让你有体感，下面列出真实业务里最常见的十类高成本请求，以及对应的首选策略。你可以把它们当作「对照表」，把自己的 Top10 对号入座。

1. FAQ / 标准问答（如「怎么退款」）：极高重复、答案稳定 → 语义缓存首选，命中率轻松过半。
2. 定时批量摘要（每日新闻/工单汇总）：频次中等但单次 Token 巨大 → 错峰用批处理低价、并加结果缓存避免重复跑。
3. RAG 检索问答：上下文动辄几千 Token → 缓存检索结果 + 压缩上下文，命中一次省一大笔。
4. 代码补全 / 生成：输出 Token 高 → 路由到专用代码小模型，贵模型只做复杂重构。
5. 长文档翻译 / 改写：输入输出都长 → 分块 + 缓存块结果，避免重试重算。
6. 意图识别 / 分类路由：极短输入输出却频繁调用 → 直接降级到小模型或本地规则，别用大模型。
7. 多轮客服对话：历史越滚越长 → 历史摘要化（用缓存的摘要替代原始历史）。
8. 内容安全审核：高频短文本 → 轻量模型或本地模型，大模型只兜底疑难样本。
9. 数据抽取 / 结构化：模板化强 → 缓存同类模板的 few-shot，减少每次重传示例。
10. 测试 / 压测流量：本不该计费却混在生产里 → 隔离到独立 key + 限流，先「止损」再「优化」。

五、一个反直觉的结论：先看「测试流量」和「重复流量」

经验告诉我，第一次做画像的团队，Top10 里往往混着两类「本不该存在」的成本：

• 测试/压测流量： developer 用生产 key 跑脚本，悄悄烧钱。这类不优化，直接「隔离 + 限流」就能立省一笔。
• 重复流量：同一个用户刷新三次、同一批数据被三个服务各算一遍。这类是缓存的「白送命中」，ROI 最高。

所以我的建议是：在动手写缓存和路由之前，先做一次「止损扫描」——把非生产流量和明显重复流量清掉。这比任何精巧算法都来得快。

六、把画像变成「优化路线图」

画像不是终点，是起点。拿到 Top10 后，画一张这样的优先级矩阵（纵轴=成本占比，横轴=优化难度），右上角（高成本+低难度）就是第一波要打的：

七、常见误区与自检

• 误区一：只看频次不看单价。某类调用一天 10 万次但每次 5 个 Token，可能不如一天 1 万次、每次 3000 Token 的类烧钱。永远用「频次×单价×Token」算总成本。
• 误区二：用原始文本聚类。不同用户问法千变万化，必须用语义/路由意图聚类，否则聚合失效。
• 误区三：画像一次就完事。流量结构会变，建议每周重算 Top10，作为成本治理的「仪表盘」。

八、怎么真正落地聚类：请求指纹的几种做法

画像的质量，取决于「请求指纹」怎么取。常见三种粒度：

• 路由路径指纹：直接用「服务名 + 接口/模板名」，最简单，适合内部系统已经按意图路由的场景。缺点是没路由信息的散请求聚不起来。
• 模板归一化指纹：把请求里的变量（用户 ID、订单号、时间戳）脱敏替换成占位符，再对结构做哈希。例如「用户 123 问订单 A 到哪了」归一为「用户 {id} 问订单 {oid} 到哪了」，同类问题就能聚合。这是性价比最高的做法。
• 语义聚类指纹：对请求做向量化，用聚类算法（如 KMeans 或近邻检索）自动归堆。适合完全无结构、无路由的自由文本。代价是需要额外跑聚类管线，且簇含义需要人工标注。

我的建议：先用「模板归一化」快速拿到 80% 的价值，等数据积累够了再用语义聚类补长尾。别一上来就上重模型，那是过度工程。

九、一个手算示例：算清某类的真实成本

以「定时批量摘要」为例。假设每天跑 1 次，每次读 50 篇新闻、每篇约 1500 Token，要求输出 800 Token 摘要，用单价较高的长上下文模型（输入 0.02、输出 0.06 元/千 Token 示意）：

单次输入 = 50×1500 = 75000 Token，输出 800 Token。
单次成本 ≈ 75000/1000×0.02 + 800/1000×0.06 = 1.5 + 0.048 ≈ 1.548 元。
月成本 ≈ 46.4 元，看似不大。但注意：如果这份摘要「当天被 10 个下游服务各重新生成一次」（重复计算），成本立刻变成 464 元/月。真正的浪费往往不在单次贵，而在被反复重算。 这也是为什么缓存对这类请求 ROI 极高——算一次，全公司复用。

十、长尾要不要管？何时该放手

Top10 之外还有 90 类长尾请求，它们合计可能占 20% 成本。要不要管？经验法则：

• 如果某长尾类「频次极低但单次极贵」（如偶发的超长文档分析），值得单独做提示词压缩或路由降级，因为它单次就能烧一笔。
• 如果某长尾类「既低频又便宜」，果断放手，把精力留给头部。过度优化长尾，边际收益为负。
• 设立一条红线：单类月成本超过 X 元才进入优化队列（X 按你预算定），其余默认不碰。

十一、把画像结果讲给老板听：从「技术债」到「预算案」

成本治理能不能拿到资源，往往取决于你能否把 Top10 画像翻译成「预算语言」。一个好用的叙事框架：

• 现状基线：本月 LLM 总成本 X 元，其中 Top10 类占 Y%（通常是 80%）。
• 根因：这 Y% 里，Z% 来自「重复计算」（可缓存），W% 来自「用贵模型干简单活」（可路由降级）。
• 目标：本季度把 Top10 类的单位成本降 30%，对应节省约 X×30% 元。
• 投入：约 N 人日搭缓存 + 路由，ROI = 节省 / 投入，通常一两个月回本。

当你用「省下的钱」而不是「技术先进」去申请资源时，通过率高得多。这也是为什么 1.1 的「成本公式」和 1.2 的「画像」是整套方法论的地基——没有数字，降本就是空谈。

十二、画像的常见数据陷阱

最后提醒几个会让画像失真的小坑：

• 窗口太短：只取一天数据，会错过「周末批量任务」这种周期性大户。建议至少取一个完整自然周，最好跨两周。
• 混入内部流量：员工调试、健康检查、压测脚本都会计入，不剔除会严重污染 Top10。先做 1.5 节的「止损扫描」再画像。
• 只看均值忽略分布：某类平均 200 Token，但 P95 是 8000（偶发超长文档），按均值优化会漏掉真正的大头。务必同时看 P95/P99。
• 汇率/单价写死：单价可能调价，画像脚本里单价最好从账单 API 实时拉，别硬编码。

十三、给新项目的「画像即代码」建议

如果你是从零搭一个新 AI 系统，别等账单爆了才做画像。建议把「成本画像」做成基础设施的一部分：

• 建表即埋点：服务上线第一天，请求日志就带齐第五节那张字段卡（指纹、Token、模型、命中率、来源）。
• 周级自动跑：把第八节的聚合查询固化成定时任务，每周自动产出 Top10，并和上周对比，异常波动自动告警（如某类成本突然翻倍）。
• 纳入 on-call：成本异常和延迟、错误率一样，成为值班要看的面板。

把画像从「一次性项目」变成「持续机制」，你就不会陷入「优化完又反弹」的循环。下一章我们就动手把这些机制落成真正的缓存层与路由模块。

小结：本节你带走了什么

• 聚焦「成本 Top10 类」，因为它们通常吃掉 80% 的预算，性价比最高。
• 画像需要字段：请求指纹、频次、输入/输出/推理 Token、模型、缓存命中率、来源。
• 类成本 = 频次 ×（输入×输入价 + 输出×输出价 + 推理×推理价），按此排序再判「可优化性」。
• 十类典型请求各有首选策略：FAQ 用语义缓存、批量用语义缓存+批处理、RAG 缓存检索结果、简单分类降级小模型。
• 先做「止损扫描」：隔离测试流量、清掉重复流量，往往比算法优化来得更猛。
• 用「成本×难度」矩阵排优先级，右上角先打。

下一节（1.3）我们上升到方法论：缓存与路由在整体降本里到底扮演什么角色、它们之间是什么关系、又有哪些你今天就该在架构里预埋的钩子。基础章到此收尾，后面两章进入真正的「动手搭」。