Token、上下文预算与 Prompt Caching

• 理解四类 token 的计价规则差异
• 理解对账与成本归集的影响
• 能设计按 token 类型的计费与披露

差异：输入 token 与输出 token 单价不同（通常输出更贵）；缓存读写有独立计价——缓存命中（cache read）比普通输入便宜，缓存写入（cache write）可能比普通输入贵，且不同 Provider 缓存价格与 TTL 不同；reasoning/thinking token 单独计费，且可能不参与缓存或按不同规则计费。影响：账单核对时若把"缓存命中"当"普通输入"会高估成本，把"缓存写入"当"普通输入"会低估成本；thinking token 若未单独计量会低估推理模型成本。租户计费应区分 token 类型（input/output/cache-read/cache-write/thinking）分别计价，并在账单中透明披露，对账时按类型分别比对，避免把不同类型混算导致偏差。

计量差异直接决定"成本是否准确"。对账与计费都要按 token 类型细分，否则缓存命中带来的成本下降、thinking 带来的成本上升都会被掩盖。设计上按类型计价 + 按类型对账 + 透明披露。

• 理解 reasoning token 的计费与展示规则
• 理解前端展示的隐私与口径问题
• 能设计面向用户的成本展示

计费：大型推理模型会把思考过程生成为 reasoning tokens，这些 token 单独计费（策略上可能比普通输出更贵或按输出计价），OpenAI 的 o 系列与 Anthropic 的 extended thinking 都在 usage 中单独暴露 reasoning/completion tokens 字段。展示：这些字段在 API usage 中可读，但前端不应直接回显"思考了 X 个 token"或原始思考链——一是思考内容属于敏感、可能被用于推理榨取（prompt extraction attack），很多 Provider 不暴露完整思考文本；二是原始 token 数对用户无意义且口径混乱（不同 Provider 定义不同）；三是回显可能泄露内部成本或引发对比误解。正确做法：前端展示"本次回答的 token 用量"按用户可理解的单位（如字符/约多少字），后端聚合成本但前端只给简化口径，思考 token 的明细仅用于内部对账与审计。

前端不应回显原始 thinking token 的原因：安全（避免泄露思考链）、口径（不同 Provider 定义不一致）、体验（原始 token 无意义）。计费上 thinking 单独计量，展示上只给聚合简化口径。

• 理解两种缓存 TTL 与失效条件差异
• 理解缓存前缀稳定的要求
• 能设计跨 Provider 缓存利用策略

失效条件：Anthropic 的 prompt caching 默认 5 分钟 TTL，缓存命中后 5 分钟内同前缀复用有效，超过 5 分钟未命中则失效，需重新写入；OpenAI 的缓存是"长保留"（如 5 分钟到一小时，且按固定前缀自动命中），失效主要由前缀字节变化、模型版本、组织/项目配置变化触发。两者共同点：都要"前缀稳定"——从消息开头到变化点的字节一致才命中，任何在前缀内的字节变化都会使后续缓存失效。应用层同时利用：把"稳定前缀"（system 指令、工具 schema、固定上下文）放在最前，最大化命中；把"变动字段"（时间戳、用户名、动态内容）后置到缓存点之后；对 Anthropic 设置缓存点（cache_control）并在 5 分钟内复用，对 OpenAI 依靠自动前缀缓存；两者都不依赖对方，session 内复用同一稳定前缀。核心是"前缀稳定 + 变动后置 + 按 TTL 复用"。

两种缓存机制不同（TTL + 显式缓存点 vs 自动前缀），但都要求"前缀稳定"。同时利用的关键是稳定前缀最大化 + 变动后置，并理解各自失效条件。

• 理解四种策略的信息丢失特征
• 理解上下文管理与任务质量的关系
• 能设计评估驱动的策略选择

信息丢失：截断（硬裁剪）——剪掉超出窗口的内容，可能丢失关键信息与上下文连贯性；滚动窗口——只保留最近 N 条消息，丢失早期历史与全局事实；摘要——把历史压缩成摘要，丢失细节、精确数据与原文引用，摘要本身可能失真；按需检索——只注入与当前查询相关的片段，丢失未检索到的上下文，依赖检索质量。选择策略：用任务评估——定义任务级指标（回答准确率、引用完整性、多轮一致性），对每个策略在同一评估集上测指标，结合延迟与成本（检索有额外开销、摘要有生成成本）选最优。原则：对"需要精确事实/全局"的任务少用摘要，对"只需近期上下文"的任务用滚动窗口，对"知识密集"用按需检索，截断作为兜底。

没有"万金油"策略，每种都以丢失为代价。用任务评估量化"丢了什么"对质量的影响，再结合成本选型。这是"上下文管理"的工程化方法。

• 理解三类问题的成因
• 理解来源优先级（source prioritization）与信息布局
• 能设计缓解与验证

识别：上下文污染——无关或误导信息进入上下文，导致模型偏离；事实冲突——上下文中存在相互矛盾的事实，模型可能采信错误一方；Lost-in-the-Middle——模型对长上下文中间部分信息利用弱于头尾。缓解：来源优先级——给每段信息标注来源与可信度（如 RAG 证据 > 用户描述 > 模型猜测），在 Prompt 中显式声明"优先采信高优先级来源"，并在冲突时让模型说明依据；信息布局——把关键指令放最前、最关键证据放最前或最后，避免埋在中段；检索排序——把最相关的证据排前；冲突检测——对多来源结果做一致性校验，显著冲突时拒答或要求澄清。核心是"来源优先级 + 关键信息布局 + 冲突校验"。

三类问题都源于"上下文组织不当"。来源优先级解决"信谁"，信息布局解决"关键信息被埋没"，冲突校验解决"自相矛盾"。三者结合缓解。

• 理解前缀缓存对"前缀稳定"的要求
• 理解高变动字段的位置影响
• 能设计消息顺序优化

前缀缓存要求"从消息开头到某位置字节稳定才能命中"。高变动字段（动态时间戳、当前用户名、每次变化的 id）若放在前缀，会导致每次请求前缀都不同，缓存全部失效。优化：把"稳定内容"放在最前——system 指令、工具 Schema（固定）、固定系统提示、静态上下文；把"高变动字段"尽量后置——时间戳、用户名、动态参数放到缓存点之后、远离前缀起点。工具 Schema 若固定则放前缀（稳定可命中），若部分工具定义会随请求变化则把固定工具放前、变动工具放后。动态时间戳等应放到 user 最新消息或缓存断点之后。通过"稳定前置、变动后置"最大化可缓存前缀长度，从而提升命中率与成本收益。

前缀缓存命中的前提是"前缀稳定"。高变动字段放前缀会破坏稳定性。把稳定内容前置、变动内容后置，是最大化缓存命中的通用原则。

• 理解 TPM/RPM 与并发的区别
• 理解两维约束的协同
• 能设计不误伤突发流量的限流

TPM/RPM 是"速率"约束（单位时间内 token/请求数），Concurrency 是"同时在途"约束（同时活跃的请求数）。两者独立且需协同：TPM/RPM 限制"吞吐上限"，Concurrency 限制"同时占用连接数"。建模：用令牌桶做 TPM/RPM 限流，用信号量/连接池做并发限流；突发流量时，若只限 TPM 会拒绝突发，若只限并发会让每个请求都等 token 配额。协同：先检查并发槽位（是否可发起），再检查速率令牌（是否有配额）；给突发留"令牌桶容量"（允许短时突发），给并发设"排队而不是直接拒绝"以吸收突发；区分"硬限流"（超配额拒绝）与"软限流"（突发允许后排队），并设置 Retry-After 与优先级。核心是"速率 + 并发双维建模，桶容量吸收突发，排队替代拒绝"。

突发流量的"误伤"源于只做硬限流。令牌桶容量允许突发、并发队列吸收突发、双维协同（先并发后速率）能既保护配额又不误伤。

• 理解工具调用对上下文结构的敏感
• 理解摘要/剪枝破坏引用导致的问题
• 能设计保护工具语义的压缩

工具调用上下文含"函数名、参数结构、返回值、tool_use 与 tool_result 的配对 id"。压缩时若把工具相关消息摘要化或剪枝，会破坏：函数名对齐（模型后续调用需要一致的函数名）、id 配对（tool_use 与 tool_result 成对，id 丢失则无法回填）、结构（参数为 JSON，摘要会破坏 schema）。避免手段：一是对工具相关消息"不压缩"——工具往返必须原样保留，只压缩纯文本对话；二是若必须压缩，压缩单元是"完整工具调用对"而非片段，且保留函数名与 id 映射；三是抽取时保留工具调用的 schema/签名，只压缩工具结果的大文本内容；四是压缩后做契约校验——确保仍满足"tool_use 后紧跟对应 tool_result"的不变量。核心是"工具消息原样保留，压缩只作用于纯文本，并校验结构完整"。

工具调用是结构化约束，摘要/剪枝用"语义化"处理会破坏其"精确结构"。因此工具消息必须保护，压缩只针对非工具文本，且压缩后校验配对与签名。

• 理解 usage 与实际计费的差异来源
• 理解可观测性链路与成本归因
• 能设计 usage 埋点与对账

做法：一是把每次响应的 usage 字段（input/output/cache/thinking 明细）作为结构化结构写入日志/追踪（span），与请求 id、租户、任务、模型、Provider 关联；二是成本归因——在可观测性平台按 usage 计算"预估成本"，与 Provider 实际账单对比，对偏差（缓存命中、计费单价变化、thinking 差异）告警；三是建立"usage 口径"——记录客户端的预估 token 与 Provider 实际 usage 的差，用于校准客户端的估算模型；四是把 usage 写入 trace 的 tags/metrics，供按租户/任务维度聚合成本；五是对账——定期把 Provider 账单与可观测性里的 usage 聚合比对，定位差异归因。核心是"usage 随请求结构化落库 + 关联计费元数据 + 对账归因"。

客户端预估与 Provider 实际计费不一致是常态。把 usage 写回可观测性链路，可使成本归因可追溯、可对账，并校准客户端估算。关键是把 usage 与请求/租户/任务关联。

• 理解上下文窗口是动态能力
• 理解写死窗口的风险
• 能设计基于能力契约的迁移

原因：上下文窗口是模型能力属性，会随模型版本、Provider 策略变化（如上下文窗口扩大、缩小、tokenizer 变更导致有效 token 数变化）。若业务规则写死"窗口为 128K"，模型升级后窗口变化会导致：超限截断、缓存失效、行为不一致。正确做法：把上下文窗口作为"能力元数据"从能力契约/配置读取，而非硬编码；迁移时——引入能力契约驱动，窗口变化时自动调整截断/压缩策略；用 tokenizer 估算实际用量，按"可用窗口"动态计算预留；灰度验证——窗口变化的模型先用影子流量验证行为，再切生产；设"预留安全区"（如只用到 90% 窗口）避免突增超限。核心是"窗口是能力而非常量，用能力契约 + 动态预留 + 灰度迁移"。

写死上下文窗口是把"动态能力"当"常量"，模型升级即失效。应把窗口作为能力元数据读取，用动态预留与灰度迁移应对变化。

• 理解估算与实际的偏差来源
• 理解偏差监控与告警
• 能设计异常检测

采集：每次请求记录"客户端估算 token"（tokenizer 估算）与"Provider 实际 usage"，计算偏差率，按模型/内容类型/租户聚合。告警维度：一是异常用量——单请求 token 远超基线、某租户 token 突增、输出 token 异常膨胀；二是缓存失效——缓存命中率骤降（如前缀被破坏、协议变更），导致成本上升；三是账单漂移——实际账单与 usage 预估成本持续偏离超阈值。检测方法：对偏差率设基线 + 阈值告警，用统计（如移动平均、异常检测）识别偏离；区分"正常波动"（内容长度差异）与"结构性漂移"（缓存失效、计费规则变化）。核心是"估算-实际双口径采集 + 多维偏差告警"。

估算与实际偏差是常态，关键是把偏差量化监控。偏差率基线、缓存命中率、账单回归三处告警，能及时发现缓存失效与计费变化。

• 理解累积 usage 与单次 usage 的差异
• 理解误解的来源
• 能设计报表区分

误解来源：长会话中每次请求都会携带全部历史，因此"单次请求 usage"（含历史输入的 token）与"会话累计 usage"（各次请求之和）不同——逐次请求会重复计算历史输入，累计 usage 远大于单次，且会话越长重复越多。团队若把"累计 usage"当"实际内容量"会高估，或把"单次 usage"当"会话总成本"会低估。应在报表中区分：会话级报表（累计 usage、会话总成本、含历史重复）与请求级报表（单次 usage、单次输入输出、不含历史重复）；再加"内容量报表"（去重后的实际 token 量，用于评估 prompt 长度设计）。用"去重后内容 token"评估上下文优化，用"累计 usage"做成本核算，避免口径混淆。

关键误解是"重复计算历史导致累计 >> 单次"。报表需分"请求级、会话级、内容级"三层，分别服务成本、优化、评估不同用途。

• 理解精确 token 与估算 token 的差异
• 理解复现评估的条件
• 能设计评估记录

原因：离线评估要复现"同 Prompt 的不同质量"，需要精确知道当时的 token 用量与上下文窗口占用。估算 token 与实际 token 有偏差（不同 tokenizer、内容特性），若用估算，两个看似相同的 Prompt 实际 token 数不同，导致上下文窗口占用不同、截断行为不同、缓存命中不同，进而质量不同——但记录里看不出来，无法归因。正确做法：评估时记录精确 usage（输入/输出/缓存/thinking 的精确 token）与模型版本、参数、tokenizer 版本，作为评估的"环境指纹"。这样重跑时能复现一致条件，或解释差异来源。核心是"精确 token 是评估复现与归因的必要条件"。

评估可复现依赖"精确环境"。token 估算误差会掩盖"上下文占用/截断/缓存"的差异，导致同 Prompt 不同质量却无法归因。记录精确 usage 是复现前提。

• 理解缓存命中的字节级条件
• 理解消息分层对命中率的影响
• 能设计分层策略

字节级稳定条件：缓存命中要求"从消息开头到某断点的字节序列完全一致"，任何字符差异（包括 JSON 字段顺序、空格、换行、Unicode 编码差异）都会使前缀不同步，导致后续缓存失效。分层：系统提示（静态、最稳定）放最前；工具定义（尽量固定，若个别工具变化则把固定工具放前、变动工具放后）其次；静态上下文（知识库固定内容）再前；动态用户消息（含时间戳、用户名、每次变动的输入）放最后、在缓存断点之后。层间用稳定分隔符，且保持序列化格式确定（字段顺序、缩进固定），避免"内容相同但字节不同"。核心是"稳定内容前置 + 动态内容后置 + 字节级一致序列化"。

缓存命中是"字节级"而非"语义级"，任何字节变化都失效。因此分层要按"稳定性"排序，且序列化格式必须确定，否则"语义相同字节不同"也命中不了。

• 理解缓存不解决所有延迟问题
• 理解上下文长度对延迟的影响
• 能设计延迟控制手段

原因：Prompt Caching 只降低"重复前缀的处理成本"，但不能解决：一是首 Token 延迟（TTFT）——模型对长上下文的预填充（prefill）仍是主要延迟来源，即使缓存命中，首次的上下文处理仍需时间；二是总处理时间——上下文越长，模型处理与生成的端到端延迟越高；三是缓存未命中场景（首次、前缀变化）——全量处理长上下文延迟很高。因此即使有缓存，用摘要、检索、压缩把"实际送入模型的上下文"控制在任务所需最小值，才能显著降低 TTFT 与总延迟。检索只注入相关片段、摘要压缩历史、压缩去掉冗余，都是"减少上下文长度 → 降低延迟"的手段。核心是"缓存优化重复，摘要/检索/压缩优化长度，两者互补"。

缓存解决"重复处理"，摘要/检索/压缩解决"长度本身"。即使缓存命中，长上下文仍带来高 prefill 与总延迟。控制进入模型的上下文长度是延迟优化关键。

• 理解不同内容类型的 token 密度
• 理解估算误差与截断
• 能设计含误差的截断策略

中文、代码、JSON 的 token 密度不同：中文通常按字切分，一个汉字可能占 1~2 个 token，token 密度高（字符数多）；代码按 token 化逻辑切分，关键词/标识符密度相对低；JSON 大量标点与空格，token 数取决于格式。用各模型的 tokenizer 做估算——对中文先估算"字数 × 系数"，代码/JSON 按实际 tokenizer 计数。估算误差纳入截断：截断判断不能用"估算值"直接用，要保留误差余量（如估算值 × 1.2 作为上限），避免因估算不足导致超限硬截断；对高密度中文内容预留更激进余量；截断前用精确 tokenizer 做最终校验。核心是"分类型估算 + 误差余量 + 截断前精确校验"。

token 密度因内容类型差异大，估算要分类。截断必须考虑误差，否则估算不足会超限硬截断丢内容。用"估算 + 余量 + 精确校验"三层。

• 理解缓存读写价格差异
• 理解命中率与复用长度的成本模型
• 能计算缓存收益

缓存收入模型：缓存写入（cache write）按全量 token 计费（可能比普通输入贵），缓存读取（cache read）按命中 token 打折（便宜）。收益取决于：命中率（复用请求占比）与复用长度（每次复用的前缀 token 数）。计算：单请求成本 = 新增部分（写入/未命中输入）+ 命中部分（读取折扣）。若命中率低或复用长度短，缓存写入的额外成本可能超过读取折扣，反而不划算。优化：按"命中率 × 复用长度"评估是否值得维护缓存前缀；对高复用稳定前缀（系统提示、工具）保留缓存，对低复用动态内容不缓存；用"写入成本 vs 读取节省"的收支平衡点决定缓存策略。核心是"把命中率与复用长度纳入成本模型，算清读写价差下的净收益"。

缓存不一定省钱：写入比读取贵，低命中/短复用会亏。要按"命中率 × 复用长度 × 读写价差"计算净收益，决定哪些前缀值得缓存。

• 理解统一 Token 预算的构成
• 理解各部分的优先级与降级
• 能设计预算控制

统一 Token 预算 = 系统指令 + 会话历史 + RAG 证据 + 工具结果 + 输出预留（为生成留出空间），合计 ≤ 上下文窗口。管理：给各部分分配配额与优先级——系统指令与工具定义（决定行为）最高优先级，RAG 证据与工具结果（最新事实）其次，会话历史（可用摘要替代）最低；超过预算时按优先级降级：先压缩/剪枝会话历史，再精简 RAG 片段，最后才动系统指令；输出预留保持固定（如 20% 窗口），避免生成到一半被截断。降级前用 tokenizer 估算实际用量，动态调整。核心是"统一预算 + 分层配额 + 按优先级降级 + 输出预留"。

上下文是共享有限资源，需统一预算。降级要"先牺牲可牺牲的"（历史、冗余证据），"保留不可牺牲的"（系统指令、输出空间）。输出预留防止生成截断。

• 理解各模态 token 计费差异
• 理解透明展示与对账
• 能设计多模态账单

图像、音频的 token 计费规则不同（图像按像素/tile、音频按时长/采样率），且不同 Provider 计价不同。透明展示：账单按模态拆分——文本/图像/音频分别列出 token 量与单价，注明计价规则（如"图像按 X 像素计费"）；给出每个模态的换算（音视频折算成等效 token 数），让客户理解成本结构。对账：本地记录按模态分类的 usage 明细，与 Provider 账单按模态比对；对差异按模态归因（如图像压缩导致 token 变化、音频采样率折算差异）。核心是"按模态拆分计费 + 注明计价规则 + 按模态对账"。

多模态计费天然异构，透明展示的关键是"按模态拆分 + 规则注明"。对账也按模态进行，否则无法定位差异来源。

• 理解三类 token 的计价差异
• 理解预算编制的维度
• 能设计预算分配

按三类分别编制：输入预算——控制送入模型的上下文（系统指令、历史、RAG）总量，与输出预留合计 ≤ 窗口；输出预算——为生成留出空间，防止截断，按任务长度设定 max_tokens；缓存命中预算——评估稳定前缀可复用的 token 量，作为成本优化项（命中越多成本越低）。预算编制：按窗口划分输入/输出，输入内再分稳定前缀（可缓存）与动态部分；输出按任务类型设上限；缓存命中作为"成本降低"指标而非占用指标。三者结合用于"成本估算"与"质量保障"：输入决定能看多少，输出决定能生成多少，缓存决定成本多低。核心是"输入/输出分窗口、缓存命中评估成本"。

输入预算管"看多少"，输出预算管"生成多少"，缓存命中管"成本多低"。三者维度不同，分列预算才能分别控制质量与成本。

• 理解 tokenizer 变更的影响
• 理解计费、窗口、缓存键的兼容
• 能设计治理策略

tokenizer 变更影响：同一文本的 token 数改变（计费变化）、上下文窗口的"有效 token 数"变化（窗口上限）、缓存键由 token 序列决定（前缀变化导致缓存失效）。治理：一是计费——历史记账按"当时 tokenizer"口径保留，新请求按新 tokenizer 计价，避免新旧混淆；二是窗口——用新 tokenizer 重新估算"实际 token 数"，动态调整截断/预留阈值，避免按旧窗口导致超限；三是缓存键——缓存键若含 token 序列，需含 tokenizer 版本作为键的一部分，tokenizer 变更后旧缓存自然失效，避免"用旧 tokenizer 的键命中新 tokenizer 的缓存"造成错位；四是灰度——tokenizer 变更通过灰度 + 影子验证，确认计费与行为稳定再全量。核心是"tokenizer 版本入键 + 计费口径区分 + 窗口动态校准 + 灰度迁移"。

tokenizer 是"计量单位"的根，变更牵动计费、窗口、缓存三处。治理关键是把 tokenizer 版本纳入缓存键与计费口径，并重新校准窗口。