Prompt/响应缓存、批处理 API 与异步化降本

• 理解 Prompt 缓存的三要素（写入成本、命中折扣、命中率）
• 掌握缓存投入产出的计算
• 理解显式配置缓存断点的业务量级门槛

Prompt 缓存投入产出 = 命中部分节省的成本 - 写入/维护成本。三要素：写入成本（首次写入缓存有成本，或缓存写入消耗存储）、命中折扣（命中缓存时输入价格大幅降低，如缓存输入是普通输入的 1/10）、命中率（稳定前缀被复用的比例）。计算：假设命中率 h，输入 token 为 I，普通输入价 p，缓存价 p_c，则每次请求输入成本 = (1-h)×I×p + h×I×p_c。缓存值得的条件：命中节省（h×I×(p-p_c)）> 写入/维护成本。业务量级门槛：只有当"请求量足够大、前缀足够稳定（命中率足够高）"时，显式配置缓存断点（精心设计系统提示/前缀的稳定分段）才值得投入；若请求量小、命中率低，Provider 自动缓存即可，显式配置成本反而高。量级判断：高频、前缀稳定、重复度高的业务（客服、客服批量、同类任务）值得显式配置；低频、变化大的业务不值得。

缓存的价值 = 命中率 × 命中折扣 × 请求量。显式配置缓存断点（把稳定前缀与动态内容分开）能提升命中率，但需要投入（设计、维护、调优）。只有当"请求量大 + 命中率高"时，显式配置的收益才覆盖投入，否则依赖 Provider 自动缓存即可。

• 理解适合 Batch 的任务特征（延迟不敏感、量大）
• 掌握结果过期、失败重试、在线 SLA 的口径
• 理解 Batch 与在线 SLA 的区分

适合 Batch 的任务：延迟不敏感（无需实时返回）、量大（批量提交）、结果可异步领取（报表、批量摘要、数据清洗、批量生成、离线处理）。不适合：实时交互、在线问答、需要即时响应的任务。Batch 迁移后的口径设计：结果过期——Batch 结果有"时效"，设定任务截止时间，超时未完成则结果作废或标记过期；失败部分重试——Batch 中部分任务失败，需"部分重试"机制（只重试失败的子项，而非整批重跑），并设置重试上限；在线 SLA——Batch 与在线分不同的 SLA 口径，Batch 用"任务完成时间"（如 24 小时内完成、P95 完成时间），在线用"P95 响应延迟"，两者不混淆。Batch 任务要记录"提交时间、完成时间、结果有效期"，对过期结果通知重跑。

Batch 迁移的核心是"延迟换折扣"，前提是任务"等得起"。结果过期、失败重试、SLA 口径是 Batch 的工程细节——过期要有机制、失败要部分重试（别整批重跑）、SLA 要按任务完成而非响应延迟。设计好这些，Batch 才可靠。

• 理解异步化的成本核算（任务成本 vs 轮询成本）
• 掌握防止轮询导致成本上升
• 理解异步化的降本本质

同步转异步（任务队列 + 通知）本身能降本（批处理、控制并发、复用结果），但若用户反复轮询，轮询本身可能产生额外请求成本（每次轮询都调 LLM 或产生请求），导致成本不降反升。核算：异步化成本 = 任务处理成本 + 轮询/通知成本。防止轮询成本上升：优先用"通知/回调"替代"轮询"（任务完成推送结果，用户不主动轮询）；若必须轮询，轮询用"状态查询"（轻量、不调 LLM），只有状态变为"完成"才拉取结果，避免每次轮询都触发重算；对轮询做限流（间隔控制、次数上限）。降本本质：异步化让"结果复用"（相同任务只算一次）、"批量处理"（多个任务合并）、"并发控制"（不用为每个交互预留资源），从而降本。关键是把"轮询"与"重算"解耦——轮询只查状态，不重算。

异步化的降本依赖"结果复用 + 防轮询重算"。若轮询每次触发重算，就白异步化了。通知优先、轮询只查状态、限流轮询，是防止"成本不降反升"的关键。核算要含轮询/通知成本，别只看任务成本。

• 理解批任务结果更新与缓存的交互
• 掌握缓存失效策略（主动失效、版本号、TTL）
• 理解防止在线读到过期答案

批处理结果更新后，若缓存未失效，在线请求会读到过期批次的结果。处理：主动失效——批任务完成时，主动删除/失效相关缓存键（按任务 ID、业务键），让在线请求重新生成或取新结果；版本号——缓存带版本号，批任务更新后 bump 版本，在线读时校验版本，不匹配则失效重取；TTL——给缓存设过期时间，批任务更新周期内 TTL 覆盖，避免长期过期。防止"读到过期答案"的关键是"缓存与数据源的一致性"：批结果落库时，同步触发缓存失效（写后失效），或缓存带"数据版本"。对时效敏感的缓存，用"短 TTL + 主动失效"双保险；对不敏感的，用 TTL 兜底。线上请求读到过期答案的风险在于"批结果更新了但缓存还是旧的"，所以要确保"更新→失效"的原子性。

读写缓存的一致性问题是"缓存失效"的经典难题。批处理更新 + 缓存若不联动，在线会读到旧批次。主动失效 + 版本号 + TTL 的组合，保证"数据更新必反映到缓存"，防止过期答案。写后失效要保证原子，避免更新与失效之间有窗口。

• 理解不引入缓存的隐性成本（重复提问）
• 掌握从日志采样估算重复/长尾比例
• 理解估算成本差驱动缓存决策

不引入缓存的隐性成本是"重复提问"——相同/相似问题每次都重新生成，浪费 token。评估：从请求日志采样，分析重复度——按归一化/嵌入相似度聚类，估算"重复提问占比"（相同/相似问题占总请求的比例）与"长尾提问占比"（唯一问题占比）。成本差估算：若重复提问占比为 r，则引入缓存可省的成本 ≈ r ×（每请求成本 - 缓存命中成本）。即：不引入缓存时，重复提问全按全价生成，引入缓存后命中部分按低价。用这个成本差判断"要不要引入缓存"。长尾提问（唯一、低频）是缓存帮不上忙的部分（命中率低），但重复提问（高频、相似）是缓存价值所在。从日志采样比全量分析省资源，且能给出"重复 vs 长尾"的比例，支撑缓存 ROI 判断。

缓存的隐性价值是"消灭重复提问的重复成本"。评估用"重复提问占比"估算——占比高则缓存价值大、占比低则价值小。日志采样估算比全量分析省力，且能支撑"要不要缓存"的决策。长尾提问命中率低，不能指望缓存覆盖。

• 理解 Batch 折扣差的产生与归属
• 掌握折扣在租户账单中的体现
• 理解节省部分是否让利

Batch 折扣（相对在线便宜 50%）是平台通过"延迟换取折扣"获得的成本优势。体现方式：折扣应反映到租户账单——Batch 请求按"批量折扣价"计费，租户账单中明确标注"Batch 折扣"一行，让租户看到"走 Batch 省了多少"。是否让利：策略有两种——全让利（Batch 按折扣价计费，租户直接受益，鼓励租户用 Batch，平台获稳定批量）、部分让利（平台保留部分折扣作为利润，租户也享受部分折扣）。建议"让利"：因为让利给租户能激励租户把延迟不敏感任务迁移到 Batch，既帮平台降低峰值压力与成本，又让租户得实惠，形成双赢。但要让利的程度与规则透明（如"Batch 请求按 X 折计费"），并支持租户在账单中查看 Batch 与在线各自成本。关键是"折扣透明 + 让利激励"，而非把折扣全吞掉。

Batch 折扣是"平台通过延迟换来的成本优势"，让利与否是"激励与利润"的平衡。透明折扣 + 让利激励，能引导租户主动用 Batch，对平台是"降本 + 降峰值"，对租户是"省钱"，双赢。全吞折扣会失去租户用 Batch 的动机。

• 理解异步化对延迟与用户体验的影响
• 掌握用成本与留存双指标衡量
• 理解避免只看节省金额

异步化能降本（批量、并发控制），但会引入延迟，可能伤害用户体验（用户等待）与留存。只用"节省金额"衡量会误导——省了钱但用户流失，损失更大。因此要用"成本 + 留存"双指标评估：成本（节省金额、单位成本）与留存（用户等待时长、会话完成率、次日留存、用户满意度）。取舍：对"延迟敏感"任务（实时交互），异步化带来的延迟会显著伤留存，该任务不宜异步化（即使省钱）；对"延迟不敏感"任务（报表、批量），异步化对留存影响小，可放心异步化。判断方法：A/B 测试——对照组在线、实验组异步化，同时测成本与留存，看"省下的钱"是否值得"留存的损失"。若留存下降导致的损失 > 节省的成本，则不该异步化。关键是"成本与留存的联合权衡"，而非单看省钱。

异步化的本质是"用延迟换成本"，但延迟有代价（留存）。只看省钱会低估异步化的隐性损失。成本 + 留存双指标，用 A/B 测"省的钱 vs 流失的用户"，才能判断异步化是否真划算。延迟敏感任务优先保留存。

• 理解缓存命中降本与流量自然下降的区分
• 掌握看板中单独呈现缓存降本
• 理解成本下降的归因

缓存命中带来的成本下降要单独呈现，否则会被误当作"流量下降"。区分方法：看板同时展示"流量（请求量）"与"成本"两个维度——若请求量不变而成本下降，说明是缓存命中（单位成本下降）；若请求量下降而成本下降，说明是流量自然下降。单独呈现：把"缓存命中率"作为独立指标，展示"缓存命中节省的成本"（= 命中 token × 全价与命中价差），与"流量下降节省的成本"分开两张图。归因：成本下降 = 流量下降贡献 + 缓存命中贡献 + 单位成本优化贡献，分别展现。这样能看到"成本降是因为缓存变好"还是"流量没了"，避免误判。缓存命中率与命中节省成本要趋势监控，命中率下降说明缓存失效或前缀变化，需及时优化。

成本下降的归因要"多因素分解"，不能只看总成本。缓存命中（单位成本降）与流量下降（总量降）是不同原因，分开呈现才能正确评估"缓存优化的效果"。缓存命中率是前导指标，命中成本是结果指标。

• 理解三种缓存粒度（整段、分段、语义）
• 掌握命中率与失效成本的权衡
• 理解缓存粒度选型

响应缓存粒度分三种，命中率与失效成本不同。整段缓存：把完整 Prompt+响应缓存，命中率最低（要求完全相同的输入），但失效成本低（命中即全省）；失效简单（按完整 key 失效）。分段缓存：把响应的稳定部分（如系统提示、固定结构）与动态部分分开缓存，命中率中等（稳定段可复用），失效成本中等（需按段失效）。语义缓存：按语义相似度匹配（不同措辞同意图），命中率最高（相似即命中），但失效成本高（语义匹配可能误命中、失效需按语义范围，且误命中可能返回不准确答案）。评估：命中率（整段<分段<语义）、失效成本（整段最低、语义最高）、误命中风险（语义最高）。选型：如果请求高度重复（完全相同的输入多），用整段或分段；如果请求相似但措辞多变，用语义缓存（但需设相似度阈值控制误命中）。评估用"命中率 vs 失效/误命中成本"权衡，选粒度。

缓存粒度是"命中率与失效成本"的权衡。整段命中率低但安全，语义命中率高但有误命中风险，分段居中。粒度选择取决于"请求重复度"与"对准确性的要求"。语义缓存需阈值校准防误命中。

• 理解批任务的多优先级队列与公平性
• 掌握批任务与在线请求的隔离（配额、背压）
• 理解调度设计

批处理任务调度要解决"优先级、公平性、与在线隔离"。优先级队列：批任务按优先级（业务重要性、截止时间）分多级队列，高优先级批任务先处理，低优先级靠后；队列用加权轮询/优先级调度保证"高优优先、低优不饿死"。公平性：多租户/多业务线的批任务要公平调度（按配额/权重分配处理资源），避免大任务独占、小任务饿死；用"每租户队列 + 按配额调度"。与在线隔离：批任务与在线请求不能互相挤占——在线用独立配额/资源池（优先保障在线延迟），批任务用独立配额（可被背压）；背压：当批任务队列或处理资源过载时，通过背压（暂停入队、限速、降低批处理并发）保护在线与系统，而非盲目处理。核心是"在线优先、批任务按优先级与公平调度、过载用背压保护"。

批处理的调度本质是"资源共享与隔离"。在线请求延迟敏感，必须优先保障；批任务延迟不敏感，可排队、可背压。多优先级队列 + 按配额公平调度 + 在线/批独立配额与背压，保证在线稳定、批任务有序。

• 理解共享配额下批任务挤占在线的风险
• 掌握配额隔离与优先级设置
• 理解防止挤占在线

共享配额时，批任务可能挤占在线——批任务量大、可重试，若与在线共用配额，会吃掉在线请求的配额，导致在线延迟变差或 429。防止方法：配额隔离——在线与批任务分配各自的配额（如在线 70%、批 30%），互不挤占；或在线优先——在线配额不足时，批任务让出配额（批任务可延迟、可重试，在线不能）。优先级：在线请求设置更高优先级，批任务在配额竞争时让位；批任务用"可抢占"配额（在线紧张时被抢占）。落地：单一配额池用"优先级 + 抢占"——在线优先获得配额，批任务在在线空闲时才用；或分池隔离。核心是"在线优先、批任务可让可延迟"，防止批任务挤占在线导致在线体验受损。

共享配额挤占的根源是"批任务能等、在线不能等"。因此在线优先 + 批任务可让位/可延迟，是合理的隔离策略。分池隔离或优先级抢占都能实现，关键是"在线服务质量不被批任务拖累"。

• 理解 Batch 的降本幅度与延迟取舍
• 掌握截止时间设置
• 理解结果领取设计

Batch 以降本（折扣）换取延迟，离线任务要平衡"折扣幅度"与"交付延迟"。折扣幅度：Batch 通常比在线便宜 50%，但越便宜（更深折扣）通常延迟越长。取舍：对每个离线任务，设"截止时间"（如 2 小时、24 小时），在截止时间内用 Batch 最便宜的方式跑；若 Batch 无法在截止时间前完成，则改用在线或提高优先级。结果领取设计：任务提交后，用"轮询 + 回调"组合领取——优先回调（完成通知），轮询兜底（间隔查询）；结果领取要幂等（避免重复领取）；结果有过期（在截止时间后未取即作废或重跑）。关键是"截止时间约束 Batch 的延迟上限"，结果领取要可靠、幂等、有超时处理。

Batch 的取舍是"价格 vs 时间"。截止时间是"时间约束"，在此约束内选最便宜的 Batch 策略；结果领取的可靠与幂等保证"钱花了结果能拿到"。设计好截止时间与领取协议，Batch 降本才可靠。

• 理解队列深度与并发控制的关系
• 掌握控制峰值资源成本
• 理解不牺牲吞吐的并发设置

异步化的降本之一是"削峰填谷"——把高峰期的请求入队，用恒定并发处理，避免按峰值预留资源。队列深度与并发控制：队列深度——设定上限，防止无限积压导致延迟无限增长；超限时用背压（拒绝新请求/限速）或扩容。并发控制——用"吞吐目标"确定并发：并发 = 目标吞吐 / 单任务处理速率。设置原则：不按峰值并发预留资源（否则峰值资源成本高），而是按"平均吞吐 + 缓冲"设置并发，高峰靠队列吸收、低峰充分利用资源。落地：用限流器（令牌桶）控制入队速率，用并发池（semaphore/size）控制处理并发，监控队列深度与处理延迟，动态调整。目标是"用固定并发支撑波动流量，资源成本稳定而非随峰值波动"。

异步化的降本本质是"用队列平滑流量，用恒定并发替代峰值并发"。这避免了"按峰值预留资源"的浪费。队列深度是"缓冲上限"，并发是"吞吐决定"，两者配合在保吞吐的同时削峰，降低峰值资源成本。

• 理解影响缓存命中率的因素（前缀稳定性）
• 掌握三项优化手段（稳定提示、字段规范化、动态内容后置）
• 理解落地方法

缓存命中率取决于"前缀的稳定性"——前缀越稳定，命中率越高。三项优化：系统提示稳定化——把系统提示（Instructions、角色设定）做成固定、排版一致的文本，避免每次拼接导致前缀变化（如加空格、换行、无关信息），让前缀字节级一致；请求字段规范化——把请求字段（时间戳、用户 ID、随机参数、URL 中的动态值）规范化/去除，避免"每次不同的字段"破坏前缀稳定（如把时间戳放后、随机数剔除）；动态内容后置——把每次变化的动态内容（用户输入、时间、动态数据）放在 Prompt 的后部，让稳定前缀在前，命中缓存的前缀部分。落地：统一 Prompt 模板，稳定部分固定在前，动态内容追加在后，并确保格式一致。这样缓存能命中"稳定前缀"，提升命中率。

缓存命中率优化的核心是"让前缀稳定"。稳定化提示、规范化字段、动态内容后置，都是"把稳定部分前置、把变化部分后置"，让缓存能命中稳定前缀。这直接提升命中率、降低输入成本。

• 理解适合 Batch 的非实时场景
• 掌握等待时长透明化
• 理解用户预期管理

适合 Batch API 的非实时场景：报表生成（定时报表、数据仪表盘）、批量摘要（批量文档/会议摘要）、数据清洗（批量数据标准化、去重）、批量生成（群发内容）、离线分析（大规模推理）。共同特征：量大、延迟不敏感、结果异步可领取、不需要实时返回。等待时长透明化：在提交任务时明确告知用户"预计完成时间"（如"约 30 分钟后可在通知/结果页查看"）；用进度状态（排队中、处理中、完成）让用户了解进度；完成后通过通知/邮件/结果页推送结果，避免用户盲等。透明化让用户理解"批量处理需要时间但更省"，从而接受等待。关键是把"等待预期"说清楚，避免用户以为系统卡死。

适合 Batch 的场景是"量大不急"。等待时长透明化是"管理用户预期"——用户接受等待的前提是"知道要等多久、有进度可看、完成后有通知"。透明化避免用户困惑，也引导用户选择 Batch（更省）。

• 理解语义缓存的相似度匹配机制
• 掌握相似度阈值设置
• 理解误命中控制

语义缓存用嵌入相似度判断"查询是否与缓存条目语义相同"，相似度超过阈值则命中返回缓存答案。相似度阈值设置：阈值过高→命中率低（省不了多少）；阈值过低→误命中多（相似但不同的问题返回错误答案，质量崩）。校准：用带标注的样本（哪些应命中、哪些不应命中）测不同阈值下的命中率与误命中率，选"误命中率可接受的前提下命中率最高"的阈值。误命中控制：阈值校准 + 白名单/黑名单（对高误命中风险的查询类型禁用语义缓存）+ 误命中回退（命中结果若置信度低则重新生成）。

语义缓存的难点是"误命中"——相似但语义不同的问题若命中缓存，会返回错误答案。阈值是"命中率与误命中率"的平衡点，需用数据校准。误命中控制（阈值、名单、回退）保证语义缓存"既省又不瞎答"。

• 理解缓存折扣与批量折扣的叠加
• 掌握叠加后的成本核算
• 理解折扣归属与对账

缓存与批处理同时使用时，两个折扣叠加：批量折扣（Batch 便宜 50%）+ 缓存折扣（命中输入更便宜）。叠加核算：Batch 请求的命中缓存部分，其成本 = 批量折扣价 × 缓存命中价，即"双重折扣"。归属：折扣要分别归属与追踪——缓存折扣归属"缓存命中"（归因于缓存优化），批量折扣归属"Batch 使用"（归因于批量迁移），两者在账单中分别列示，便于评估各自优化效果。对账：成本核算要按"原价 - 缓存折扣 - 批量折扣"计算，且记录各折扣的明细（原价、缓存折扣额、批量折扣额、实付），保证与 Provider 账单对得上。关键是"折扣叠加要算准、折扣归属要分清"，避免对重复计算或归属错乱导致账目不符。

双折扣叠加的核算要"逐层计算、分别归属"。缓存折扣与批量折扣是不同优化手段的成果，分开归属才能分别评估 ROI。对账要保留折扣明细，保证"原价减折扣=实付"与 Provider 账单一致。