LLM

在日常的 Agent 开发中，开发者很难直接接触到服务端的 KV Cache。然而，无论是编写 Prompt、控制对话历史的长度，还是设计 Agent 的长程反思循环，其本质都在操纵 KV Cache 的计算与复用。本文旨在系统化拆解 KV Cache 与 Prompt Cache 的工作机制，分析其在多轮对话与 Agent 架构中的应用设计原则，并深入探讨在百万级用户规模下，分布式推理系统在安全性、多级存储管理、以及调度计费上面临的工程权衡。 1. 核心概念：Prompt Cache 与 KV Cache 1.1 Prompt Cache 与 KV Cache 的区别 要理解大模型推理的成本与时延，首先必须厘清两层性质完全不同的“缓存”概念。它们处于不同的生命周期，服务于不同的系统目的： 维度 运行时 KV Cache 前缀复用缓存 (Prompt Cache / Prefix Cache) 主体对象 某个正在进行的单次生成请求，独占该内存块 已结束请求留下的、可供后续跨请求复用的前缀 KV 块 存活周期 即时焚毁：随请求开始而创建，随生成结束（吐出 EOS）而彻底释放 持久留存：请求结束后不丢弃，在内存/硬盘中留存一段时间（TTL） 系统目的 维持 Self-Attention 机制的多轮解码，让当前的 Token 生成得以持续 跳过后续相同前缀请求的 Prefill 阶段，直接加载计算结果 核心效益 将自注意力计算复杂度从 O(N^2) 降低到 O(1) 极端优化首字延迟（TTFT）与算力成本 1.2 Prompt Cache 缓存了什么 在 Prefill 阶段，推理引擎将 Prompt 中的每个 Token 转换为 K, V 向量填入缓存。Prompt Cache 做的事情，是在当前请求结束后，将这段已经算好的 KV Cache 留在服务端。下次请求若 Prompt 前缀相同，则直接加载这块 KV，跳过对这段前缀的 prefill。 ...

1. 自回归生成 LLM 本质上就是一个 next-token predictor：给定一段 prompt，预测下一个 token。所有长篇回答，都是 token by token 生成的。初学者需要注意，token 与词/字符之间并不完全等价，模型的处理单位是 token，即模型的输入输出都是 token，而不是一个词或一个字符。（注：若仅关注原理部分，不关注 tokenization 的内部实现机制，粗糙地将 token ≈ 词，关系也不大） 模型在预测下一个 token 时，不是直接吐出一个确定的词，而是输出全词表的概率分布。比如，用户输入"今天天气真"，模型经过一系列计算得到全词表的概率分布，再经过采样得到一个 token： 1 2 3 4 5 6 7 8 输入："今天天气真" "好" → 0.62 "不错" → 0.15 "热" → 0.08 ...(其余 token 瓜分剩余概率) ==》 next token: "好" 模型一次只产出一个 token，把第 i 步的输出作为第 i+1 步的输入，用伪代码表示，大致如下： 1 2 3 4 5 while not finished: logits = model.forward(tokens) # ① 前向: 算出词表上 N 个分数 probs = softmax(logits) # ② 变概率 next_token = sample(probs) # ③ 采样选一个 tokens.append(next_token) # ④ 拼上去 示例： ...