Token 都花在哪了、Prompt 瘦身与缓存策略
一条以"Token 账本"为主线的成本归因方法论 · 从计费口径到工程落地
摘要
某天早上，你打开云厂商控制台，发现昨天的大模型 API 账单是平日的 7 倍，而线上 QPS 并没有明显变化。这类"账单暴涨但流量正常"的故障，是 LLM 应用进入生产环境后最典型、也最难定位的一类问题。本文以一次真实的排查过程为叙事骨架，提出一条贯穿全文的分析主线——Token 账本（Token Ledger）：把每一次 API 调用视为一笔可审计的账目，把输入 Token、输出 Token、缓存命中、重试放大、Agent 循环、上下文膨胀等全部纳入一本可对账的账本中。
全文围绕这条主线展开六个层面：计费口径的精确建模、Token 消耗的八大隐性来源、Prompt 瘦身的可量化方法、上下文压缩与 KV Cache 的工程权衡、语义缓存与路由降级的成本杠杆、以及成本可观测性体系的建设。文中给出可复用的排查清单、代码片段与决策表格，并对 Prefix Caching、语义缓存、推测解码等前沿方向给出笔者的独立判断。
本文所有公开数据均标注来源，涉及模拟或整合的部分已明确说明。目标读者是正在把 LLM 应用推向生产的后端工程师、SRE 与 AI 平台负责人。
目录
一、故障现场：账单暴涨的 48 小时
先把场景还原清楚。这是一个典型的 RAG（检索增强生成）客服系统：用户提问 → 向量检索 Top-K 文档 → 拼接 Prompt → 调用大模型 → 返回答案。系统上线三个月，日均调用约 12 万次，日均成本稳定在某个区间。然后某天，成本曲线突然抬升。
排查的第一反应通常是"是不是被刷了"。但监控显示：QPS 平稳、用户量平稳、平均响应时间甚至略有下降。这就排除了流量突增和外部攻击。第二个反应是"是不是换了模型"。查配置中心，模型版本没变。第三个反应是"是不是计费涨价"。查厂商公告，价格没动。
于是问题被逼到一个更本质的地方：单次调用的 Token 消耗变多了，或者调用次数被放大了。 这两句话，就是本文整条分析主线的起点。
1.1 三个"看起来正常"的假象
在真实排查中，最耗时间的不是找原因，而是排除假象。以下三个假象几乎每次都会出现：
- 假象一：QPS 正常 = 调用量正常。 实际上，一次用户请求可能触发多次模型调用（重试、Agent 多步、流式分片计费），QPS 统计的是入口请求，不是模型调用。
- 假象二：平均延迟下降 = 系统更健康。 延迟下降有时恰恰说明"输出变短了"或"缓存命中变多了"，但如果缓存策略配置错误，也可能意味着"该走缓存的没走，走了更贵的路径"。
- 假象三：Prompt 没改 = 输入没变。 Prompt 模板没改，但检索回来的文档变了、历史对话变长了、系统注入的上下文变多了，输入 Token 照样涨。
本文评述：账单故障与性能故障的根本区别在于——性能故障有明确的"坏"信号（超时、报错、抖动），而成本故障的"坏"信号是缺失的。系统一切正常，只是钱花多了。这意味着成本问题必须靠"账本"而非"告警"来发现，这是本文主张建立 Token 账本的第一层理由。
1.2 排查的正确顺序
经过多次实战，笔者总结出一个从粗到细的排查顺序，可以显著缩短定位时间：
在本次案例中，第 2 步就暴露了问题：输入 Token 总量涨了 5.8 倍，输出 Token 基本持平。继续下钻到第 6 步，发现检索模块的文档切分策略在前一天被"优化"过——chunk size 从 512 调到了 2048，Top-K 仍是 5，于是每次拼接进 Prompt 的上下文从约 2.5K Token 涨到约 10K Token。一次看似无关的检索参数调整，直接导致了账单暴涨。
这个结论听起来简单，但如果没有"输入/输出 Token 拆分"这一层账本，你永远只能看到"总成本涨了"，而无法定位到具体环节。这就是为什么本文要把"Token 账本"作为主线，而不是泛泛地谈"如何省钱"。
二、计费口径：先把账本的定义搞对
在讨论"Token 花在哪"之前，必须先搞清楚"Token 是怎么被计价的"。很多团队的成本失控，根源不在工程，而在对计费口径的理解偏差。
2.1 主流厂商的计费维度
截至本文撰写时，主流大模型 API 的计费维度大致可以归纳为以下几类。下表为笔者根据各厂商公开定价文档整理的对比（价格随时间和地区波动，此处仅列结构，不列具体数值）：
本文评述：上表最关键的一行是"推理/思考 Token"。推理模型（如各类 o 系列、R 系列）把内部思维链计入输出 Token，而输出单价又最高，这导致同一个问题的成本可能是普通模型的 5–20 倍。很多团队"为了效果更好"无脑切推理模型，结果账单直接失控。笔者的建议是：把推理模型当作"昂贵的手术刀"，只在真正需要多步推理的任务上使用，而不是当作默认引擎。
2.2 Token 与字符的换算关系
工程上做成本预估时，经常需要快速估算 Token 数。这里给出经验法则（注意：这是估算，精确值必须用对应模型的 tokenizer 计算）：
- 英文：约 1 Token ≈ 4 个字符 ≈ 0.75 个单词。这是 OpenAI 在其官方文档中给出的经典经验值。
- 中文：约 1 Token ≈ 1–1.5 个汉字，取决于 tokenizer。BPE 类 tokenizer 对中文的压缩率通常低于英文。
- 代码：约 1 Token ≈ 3–4 个字符，符号密集的代码 Token 密度更高。
- JSON：由于大量引号、括号、冒号，Token 密度极高，1 Token 可能只对应 2–3 个字符。
为什么 JSON 的 Token 密度值得单独强调？因为在 Function Call / Tool Use 场景中，工具 Schema 本身就是一大段 JSON，会被注入到每次请求的 Prompt 中。一个包含 10 个工具的 Schema，轻松占掉 1–2K Token，而这段内容在每次调用中都会重复计费。这是最容易被忽视的"固定成本"。
2.3 一个可复用的成本公式
把上述维度整合，可以得到一个工程上可用的成本估算公式：
单次调用成本 =
(输入Token - 缓存命中Token) × 输入单价
+ 缓存命中Token × 缓存读取单价
+ 缓存写入Token × 缓存写入单价
+ 输出Token × 输出单价
+ 推理Token × 推理单价
日成本 = Σ(单次调用成本) × 调用次数 × (1 + 重试率)
其中：
调用次数 = 入口请求数 × 平均每请求模型调用次数
平均每请求模型调用次数 = 1 + 重试次数 + Agent步数 + 分片数这个公式看起来朴素，但它把成本拆成了"单价 × 数量"两个可独立优化的维度。单价靠模型选型和缓存策略降，数量靠 Prompt 瘦身和调用链优化降。后文的所有方法，都可以归入这两个维度之一。
三、Token 账本：八大隐性消耗来源
这是全文的核心章节。笔者把生产环境中常见的 Token 隐性消耗归纳为八类，每一类都对应一个具体的排查动作和优化手段。建议读者把这八类做成一张检查表，在成本异常时逐项核对。
3.1 来源一：系统提示词的"沉默税"
System Prompt 是每次调用都会携带的固定内容。它包含角色设定、输出格式要求、安全规则、工具 Schema 等。一个"功能完整"的 System Prompt 很容易写到 2000 Token 以上。
假设 System Prompt 为 2000 Token，日调用 12 万次，那么仅 System Prompt 一项，每天就消耗 2.4 亿 Token 的输入。如果输入单价按每百万 Token 若干元计，这笔"沉默税"相当可观。而它的问题在于：它不随业务变化，所以最容易被忽略，也最容易被缓存优化。
本文评述：System Prompt 的优化空间往往被低估。很多团队把它当作"写一次就不动"的配置，但事实上，删掉一句冗余的礼貌用语、把冗长的 JSON Schema 换成精简描述、把重复的规则合并，都能带来 20%–40% 的输入 Token 下降。这不是"抠门"，而是工程纪律。
3.2 来源二：多轮对话的历史累积
对话类应用中，每一轮请求都需要把历史对话拼接进 Prompt。如果采用"全量历史"策略，第 N 轮的输入 Token 大致与 N 成正比。一个 20 轮的对话，最后一轮的输入可能是第一轮的 20 倍。
更隐蔽的是：很多框架默认保留全部历史，且不做摘要。用户聊得越久，单次成本越高，而用户往往感觉不到——他只是觉得"这个 AI 记得住上下文，挺好"。
优化方向有三条：滑动窗口（只保留最近 K 轮）、滚动摘要（把早期对话压缩成摘要）、以及基于重要性的选择性保留。三者的权衡在第五章展开。
3.3 来源三：RAG 检索文档的膨胀
回到开篇的案例，这正是本次故障的直接原因。RAG 的成本 = Top-K × 平均 chunk 长度。两个参数任何一个变大，成本都会线性上升。
（上表为模拟数据，用于说明参数与成本的线性关系，非真实业务数据。）
本文评述：chunk 长度不是越大越好，也不是越小越好。chunk 太大，检索精度下降、成本上升；chunk 太小，上下文碎片化、模型难以理解。笔者的经验是：先用 512 左右做基线，再根据召回质量微调，同时引入重排序（Rerank）把 Top-K 从 5 压到 3，往往能在质量不降的前提下省下 40% 的输入 Token。
3.4 来源四：重试与超时的放大效应
这是最容易被低估的一类。当模型返回超时、限流或格式错误时，很多客户端会盲目重试。如果重试策略是"指数退避 + 3 次重试"，那么一次失败请求最多产生 4 次计费调用。
更糟的是流式场景：如果流式响应中途断开，已经生成的部分 Token 通常仍会计费，而客户端重试会重新生成一遍。一次断流，成本翻倍。
排查动作：统计"重试率"和"流式中断率"两个指标。这两个指标在很多团队是缺失的，但它们对成本的影响可能超过 30%。
3.5 来源五：Agent 循环的步数失控
Agent 类应用（ReAct、Plan-and-Execute 等）会把"思考—行动—观察"循环多次执行。每一步都是一次完整的模型调用，且历史步骤会累积进上下文。
一个设计不佳的 Agent，可能因为工具返回格式不符预期而反复尝试，步数从预期的 3 步膨胀到 15 步。由于每步都携带前面所有步骤的历史，总 Token 消耗呈超线性增长。
工程上必须设置硬性上限：最大步数、最大总 Token、最大墙钟时间。三者任一触发即终止，并记录终止原因。这不仅是成本控制，也是防止 Agent "跑飞"的安全阀。
3.6 来源六：输出格式的冗长
输出 Token 单价通常是输入的 2–4 倍，因此输出的每一分浪费都被放大。常见问题包括：模型被要求输出 Markdown 表格而实际只需要纯文本、被要求"详细解释"而实际只需要结论、输出中包含大量重复的客套话。
一个实用技巧：在 Prompt 中明确约束输出长度，例如"用不超过 3 句话回答"、"只输出 JSON，不要任何解释"。这类约束对成本的影响立竿见影。
3.7 来源七：工具 Schema 的重复注入
如前所述，Function Call 的 Schema 是 JSON，Token 密度高。如果每次请求都注入全部工具的完整 Schema，而实际只用到其中一两个，就是纯粹的浪费。
优化思路：按意图动态选择工具子集、精简 Schema 描述、把长描述移到 System Prompt 的公共部分以便缓存。这三招组合，通常能把工具相关的输入 Token 降低 50% 以上。
3.8 来源八：Embedding 与 Rerank 的隐性成本
很多团队只盯着生成模型的账单，忽略了 Embedding 和 Rerank 模型的调用。在大规模 RAG 场景中，Embedding 的调用量可能是生成模型的数十倍（每次检索都要 embedding 查询、离线建库要 embedding 全量文档）。
Rerank 同样如此：它对每个候选文档打分，候选数 × 文档长度就是它的 Token 消耗。当 Top-K 从 5 调到 50 再做 Rerank 时，Rerank 的成本可能超过生成本身。
本文评述：把八类来源放在一起看，会发现一个规律——成本失控几乎从不来自单一原因，而是多个"小浪费"叠加。 System Prompt 多 500 Token、历史多 3 轮、chunk 大一倍、重试率 10%、Agent 多 2 步，每一项单独看都不致命，叠加起来就是 5–10 倍。这正是"账本"思维的价值：它强迫你逐项量化，而不是笼统地"优化一下"。
四、Prompt 瘦身：可量化的减法工程
Prompt 瘦身不是"把话说短"，而是一套有度量、有回归测试的工程流程。本章给出一套可落地的方法论。
4.1 第一步：建立 Prompt 基线度量
在动手改之前，先量化。建议对每条 Prompt 模板统计以下指标：
- 静态部分 Token 数（System Prompt、工具 Schema）
- 动态部分 Token 数（检索文档、历史对话、用户输入）
- P50 / P95 / P99 总输入 Token
- 输出 Token 分布
- 各部分占比（用于识别"大头"）
没有这组基线，任何优化都是盲目的。很多团队改了半天 Prompt，结果发现大头在检索文档上，白忙一场。
4.2 第二步：按"性价比"排序优化项
不是所有优化都值得做。笔者建议按"节省 Token / 改动成本"排序，优先做高收益低风险的项：
（上表为笔者基于多个项目经验的整合估算，非单一来源数据，实际效果因场景而异。）
4.3 第三步：Prompt 压缩的具体手法
以下是几种经过验证的 Prompt 压缩手法：
手法一：去冗余指令。 很多 Prompt 里堆砌了大量同义指令，例如"请仔细、认真、严谨地分析"。这类修饰词对模型行为影响有限，但会累积 Token。保留一条最明确的即可。
手法二：结构化替代自然语言。 用简短的标签式结构替代长句描述。例如把"你需要根据用户的问题，从提供的文档中找出最相关的信息，然后给出回答"压缩为"任务：基于文档回答问题"。
手法三：Schema 精简。 工具描述从"这个工具用于查询用户的订单信息，输入订单号，返回订单详情"压缩为"查询订单：入参 order_id"。模型对简短描述的理解能力通常足够。
手法四：Few-shot 示例裁剪。 Few-shot 示例对效果帮助大，但成本高。建议从 5 个示例减到 2–3 个高质量示例，或把示例放到可缓存的前缀中。
4.4 第四步：回归测试，防止"省了钱丢了效果"
任何 Prompt 改动都必须过回归测试。建议维护一个"黄金测试集"（Golden Set），包含 100–500 条带标注的真实请求，每次改动后跑一遍，对比：
- 任务准确率 / 召回率
- 输出格式合规率
- 平均输入/输出 Token
- 单次成本
只有当"效果不降、成本下降"时，改动才被合入。这套流程听起来繁琐，但它是把"省钱"从玄学变成工程的关键。
本文评述：Prompt 瘦身最大的误区是"一次性大改"。大改之后效果波动，你无法判断是哪一处改动导致的，只能整体回滚，前功尽弃。正确做法是小步快跑、单变量验证、每步留痕。 这与性能优化、数据库调优的方法论是一致的。
五、上下文压缩与 KV Cache 的权衡
如果说 Prompt 瘦身是"减少输入"，那么上下文压缩和缓存是"让同样的输入更便宜"。本章讨论这两个方向的工程权衡。
5.1 上下文压缩的三种范式
上下文压缩（Context Compression）在学术界已有大量研究。工程上可归纳为三种范式：
范式一：抽取式压缩。 从原文中抽取关键句或关键片段，丢弃其余部分。代表思路是句子级重要性打分。优点是保真度高、可解释；缺点是压缩率有限。
范式二：摘要式压缩。 用一个小模型把长文本改写成短摘要。压缩率高，但可能丢失细节，且摘要本身也要消耗 Token（虽然通常远小于原文）。
范式三：软提示压缩。 把长上下文编码成一组"软 Token"（soft prompt / gist tokens），直接喂给模型。压缩率最高，但需要模型侧支持，通用 API 场景难以落地。
本文评述：对绝大多数使用通用 API 的团队而言，抽取式 + 摘要式的混合策略是性价比最高的选择：先用检索和重排序筛掉大部分无关内容（抽取式），再对保留的长文档做摘要（摘要式）。软提示压缩虽然优雅，但受限于 API 能力，短期内难以工程化。
5.2 对话历史的压缩策略
对话历史是压缩收益最明显的场景。常见策略对比：
笔者推荐的默认策略是"摘要 + 窗口"：保留最近 K 轮原文，更早的对话压缩成一段摘要。这样既控制成本，又保留长期记忆。
5.3 KV Cache 与 Prefix Caching 的工程价值
KV Cache 是 Transformer 推理中的核心优化：缓存已计算的 Key/Value 矩阵，避免重复计算。在 API 场景中，与之相关的是 Prefix Caching（前缀缓存）——如果多次请求的 Prompt 前缀相同，服务端可以复用前缀的 KV Cache，从而降低计算成本，并把节省部分让利给用户。
这对工程实践的指导意义非常直接：把 Prompt 中稳定不变的部分放在最前面，把变化的部分放在最后。 这样前缀缓存的命中率最高。
推荐结构（前缀稳定，后缀变化）：
┌─────────────────────────────┐
│ 1. System Prompt（固定） │ ← 缓存命中区
│ 2. 工具 Schema（固定） │ ← 缓存命中区
│ 3. Few-shot 示例（固定） │ ← 缓存命中区
├─────────────────────────────┤
│ 4. 检索文档（每次变化） │ ← 需重新计算
│ 5. 对话历史（每次变化） │ ← 需重新计算
│ 6. 用户输入（每次变化） │ ← 需重新计算
└─────────────────────────────┘很多团队把动态内容（如时间戳、随机 ID、用户昵称）放在 Prompt 开头，这会直接击穿前缀缓存，让缓存命中率归零。这是一个非常常见、也非常昂贵的错误。
本文评述：Prefix Caching 的收益高度依赖"前缀稳定性"。笔者建议在代码层面强制约束 Prompt 的拼装顺序，并在 CI 中加入检查：任何把动态字段插入前缀区的改动都应被拦截。 把缓存友好性当作一种"接口契约"来维护，而不是靠开发者自觉。
5.4 压缩的边界：什么时候不该压
压缩不是无条件的。以下场景应谨慎：
- 法律、医疗、金融等高风险场景：细节丢失可能带来合规风险，压缩率应保守。
- 需要精确引用原文的任务：摘要会破坏可追溯性。
- 短上下文场景：压缩本身的调用成本可能超过节省。
换言之，压缩要算"净收益"：节省的 Token 成本减去压缩本身的成本，再减去效果损失带来的隐性成本。
六、缓存与路由：成本杠杆的乘数效应
前面几章是"节流"，本章讲"杠杆"——用缓存和路由把成本成倍地压下来。
6.1 语义缓存的原理与陷阱
语义缓存（Semantic Cache）的思路是：把用户查询向量化，如果在缓存中找到语义相似的查询，直接返回历史答案，跳过模型调用。这对 FAQ 类、客服类场景效果显著。
但它有两个陷阱：
陷阱一：相似度阈值难调。 阈值太高，命中率低；阈值太低，返回错误答案。而且"语义相似"不等于"答案相同"——"如何退款"和"如何取消订单"可能语义接近，但答案完全不同。
陷阱二：时效性。 缓存了昨天的答案，今天政策变了，就会返回过期信息。必须为缓存设置 TTL，并在数据更新时主动失效。
本文评述：语义缓存适合"高频、答案稳定、容错率高"的场景。笔者建议先做精确缓存（完全相同的查询直接命中），再做语义缓存，并且语义缓存必须配合人工审核的兜底策略。不要一上来就上语义缓存，否则可能省了钱、丢了信任。
6.2 模型路由：让合适的模型做合适的事
模型路由（Model Routing）是根据请求的难度动态选择模型。简单请求走小模型，复杂请求走大模型。这是成本优化中杠杆最大的一招。
级联路由（Cascade）尤其值得关注：它先用便宜模型生成，再用一个轻量判别器判断答案是否可靠，不可靠才升级到贵模型。学术界对这类"推测式级联"有持续研究，工程上也有成熟实践。
6.3 降级与限流的成本护栏
除了主动优化，还需要被动护栏。当成本异常时，系统应能自动降级：
- 预算熔断：当日成本超过阈值时，自动切换到更便宜的模型或返回缓存答案。
- 单用户限流：防止单个用户的高频调用拖垮整体预算。
- 输出长度硬限制：在 API 层设置 max_tokens，防止模型"话痨"。
- 重试上限：严格限制重试次数，并对重试请求打标监控。
这些护栏的价值在于：它们把"成本事故"从"第二天看账单才发现"变成"实时自动止损"。
七、成本可观测性：让账本自动对账
前面所有方法要落地，都依赖一个前提：你能看到 Token 花在哪。本章讲如何建设成本可观测性。
7.1 必须采集的指标
7.2 在调用层埋点
最有效的埋点位置是"模型调用网关"——所有请求都经过这里，可以统一采集。示例伪代码：
def call_llm(request, tenant_id, template_id):
start = now()
resp = client.chat.completions.create(...)
usage = resp.usage
metrics.emit({
"tenant_id": tenant_id,
"template_id": template_id,
"model": request.model,
"input_tokens": usage.prompt_tokens,
"output_tokens": usage.completion_tokens,
"cached_tokens": getattr(usage, "cached_tokens", 0),
"latency_ms": now() - start,
"cost": compute_cost(usage, request.model),
})
return resp关键点：把 tenant_id 和 template_id 作为标签带上。 没有这两个维度，你只能看到"总成本"，无法定位到"哪个租户、哪个模板"在烧钱。
7.3 成本归因看板
建议搭建三层看板：
- L1 总览：日/周/月成本趋势、同比环比、预算消耗进度。
- L2 归因：按租户、模板、模型、缓存状态拆分成本。
- L3 下钻：单个请求的 Token 明细，支持按 trace_id 追溯。
有了这三层，开篇那种"账单暴涨"的故障，可以在几分钟内定位到具体环节，而不是花 48 小时。
本文评述：成本可观测性的本质，是把"钱"变成"指标"。一旦成本成为可观测指标，它就能像延迟、错误率一样被 SLO 化、被告警、被优化。很多团队不是不会省钱，而是根本不知道钱花在哪。 先建账本，再谈优化，顺序不能反。
八、前沿预判与工程路线图
最后，笔者结合近年的研究趋势，给出几个值得关注的方向和一份可执行的路线图。
8.1 三个值得关注的技术方向
方向一：自动 Prompt 压缩。 学术界已有用小型语言模型自动改写、压缩 Prompt 的研究（如 LLMLingua 系列思路）。这类方法把压缩从"人工调参"变成"模型自动完成"，长期看有望成为标配。但其风险在于压缩过程本身可能引入语义漂移，需要严格的回归验证。
方向二：推测解码与级联推理。 用便宜模型"打草稿"、贵模型"审校"，在保证质量的前提下降低平均成本。这类方法在推理侧已有成熟实现，在 API 侧则体现为级联路由。
方向三：成本感知的调度。 把成本作为一等公民纳入调度决策，在延迟、质量、成本三者间做多目标优化。这需要把本文的"Token 账本"与调度系统打通。
本文评述：这三个方向的共同点是——成本优化正在从"事后审计"走向"实时决策"。 未来的 LLM 平台，成本会和延迟一样，成为调度器的输入变量，而不是月底才看的报表。谁能先把账本做细，谁就能先吃到这波红利。
8.2 一份 30 天落地路线图
这份路线图的核心逻辑是：先看见，再优化，最后自动化。 跳过第一步直接优化，往往事倍功半。
8.3 拓展学习资源
- OpenAI 官方 Tokenizer 工具与计费文档：platform.openai.com/tokenizer
- Anthropic Prompt Caching 文档：docs.anthropic.com
- LangChain 成本追踪与回调：python.langchain.com
- Hugging Face 关于 KV Cache 的技术博客：huggingface.co/blog
- LLMLingua 项目（Prompt 压缩研究）：github.com/microsoft/LLMLingua
九、主要参考文献
[1] Vaswani A, et al. Attention Is All You Need. NeurIPS, 2017.
[2] Pope R, et al. Efficiently Scaling Transformer Inference. MLSys, 2023.
[3] Jiang H, et al. LLMLingua: Compressing Prompts for Accelerated Inference. EMNLP, 2023.
[4] Jiang H, et al. LongLLMLingua: Accelerating and Enhancing LLMs in Long Context. ACL, 2024.
[5] Leviathan Y, et al. Fast Inference from Transformers via Speculative Decoding. ICML, 2023.
[6] Chen C, et al. FrugalGPT: How to Use Large Language Models While Reducing Cost. arXiv:2305.05176, 2023.
[7] Lewis P, et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP. NeurIPS, 2020.
[8] Gao Y, et al. Retrieval-Augmented Generation for Large Language Models: A Survey. arXiv:2312.10997, 2023.
[9] OpenAI. Pricing & Tokenizer Documentation. 2024.
[10] Anthropic. Prompt Caching Documentation. 2024.
[11] Kwon W, et al. Efficient Memory Management for LLM Serving with PagedAttention. SOSP, 2023.
[12] Zheng L, et al. Judging LLM-as-a-Judge. NeurIPS
微信扫一扫分享
打开微信「扫一扫」，扫描二维码后在微信中分享给好友或朋友圈。
💬 评论 (0)
评论功能已关闭
贵公网安备 52010302001819号
