PagedAttention & RadixAttention ✍ prasanna🕐 2026-07-28📦 14.4 KB 🟢 已读 𝕏 文章列表 本文深入探讨了 PagedAttention 和 RadixAttention 两种技术。PagedAttention 通过类似操作系统的分页机制管理 GPU 内存，解决 KV Cache 的内部和外部碎片问题，显著提升并发处理能力。RadixAttention 则利用基数树索引缓存的前缀状态，实现跨请求的计算和内存复用，进一步优化推理性能。 vLLMSGLangPagedAttentionRadixAttentionKV Cache内存管理推理优化LLM # PagedAttention & RadixAttention **作者**: prasanna **日期**: 2026-07-27T09:49:49.000Z **来源**: [https://x.com/jaga_prasanna/status/2081678437698408899](https://x.com/jaga_prasanna/status/2081678437698408899) ---  today we look at how two techniques solve memory and compute bottlenecks from two complementary angles virtual memory paging for intra-request memory allocation and prefix tree caching for inter-request compute reuse! 1. PagedAttention in vLLM 2. RadixAttention in SGLang # PagedAttention (vLLM) PagedAttention is primarily a Key-Value cache memory-management technique, not a completely new mathematical attention algorithm. the underlying attention math stays standard, every query token still computes dot-product attention against past key and value vectors. what changes is how those KV vectors are stored and gathered in physical GPU VRAM! 1. why the KV cache becomes a massive memory problem ? imagine renting apartments in a building where tenants arrive dynamically and stay for unpredictable amounts of time. if you assign every tenant a 10 bedroom suite on day one just in case they decide to bring nine friends later, almost all of your rooms sit completely empty while new tenants are turned away at the door! that is precisely how naive LLM serving handles the Key-Value (KV) cache in GPU memory, during inference, the Key-Value cache creates a massive, dynamically growing footprint: - dynamic memory growth: during the decode phase, every newly generated token appends a new Key vector and Value vector across every layer and attention head in the model. - unpredictable sequence lifespan: one user request might finish in 20 tokens while another runs for 2,000 tokens. - naive continuous allocation: to avoid running out of VRAM mid-generation, standard PyTorch implementations reserve a contiguous chunk of GPU memory sized to max_sequence_length (e.g. 4,096 tokens) for every active request up front! allocating continuous memory regions per request causes two severe forms of memory waste: 1. internal fragmentation: if a user request finishes after generating 100 tokens, the remaining 3,996 reserved token slots sit empty. up to 80% of reserved VRAM is wasted on memory that is never written to. 2. external fragmentation: as requests start and finish at different times, freed memory chunks get scattered across VRAM in different sizes. even if total free VRAM is large enough for a new request, memory allocation fails because there is no single contiguous block big enough to fit max_sequence_length because of this memory fragmentation waste, traditional servers could only fit tiny batch sizes (often 2 to 4 concurrent requests per GPU) before running out of VRAM, leaving powerful GPU compute units idling while waiting for memory operations! > we call it compute starvation paying dollar for an H100 GPU only to let its CUDA cores sit idle waiting at the VRAM memory! ## The Solution: Fixed-size blocks PagedAttention solves this by bringing virtual memory paging from operating systems into GPU VRAM management. instead of requiring one continuous memory region for every request, PagedAttention splits the KV cache of a sequence into small, fixed-size physical blocks (typically 16 or 32 tokens per block). we distinguish between two concepts: - logical blocks: logical block 0 stores tokens 0 to 15, logical block 1 stores tokens 16 to 31, and so on. - physical GPU-memory blocks: actual 16-token VRAM memory pages allocated anywhere in GPU memory from a global free block pool. a sequence no longer needs to occupy contiguous physical memory instead vLLM maintains a block table for each active sequence: - block table lookup: the block table maps each logical block index of a sequence to a specific non-contiguous physical block ID in VRAM. - dynamic allocation on demand: when a request arrives, vLLM allocates only one physical block (16 tokens). as generation proceeds and fills token slot 15, the engine claims a new physical block from the free pool and appends it to the request's block table for token 16. - instant memory release: as soon as a request finishes or reaches `EOS`, all its assigned physical blocks are immediately freed and returned to the global free block pool for other requests to use. Lets see how the pagedAttention execute at step by step I refered the vLLM paper showing a request growing across physical GPU memory blocks (using a block size of 4 tokens): 1. prompt prefill: prompt "Four score and seven years ago our" (7 tokens) fills logical block 0 (mapped to physical block 7) and 3 slots of logical block 1 (mapped to physical block 1). 2. generating "fathers":output token "fathers" fills the 4th and final slot of logical block 1 (physical block 1). 3. generating "brought": logical block 1 is full, so the engine claims physical block 3 from the free pool for logical block 2. 4. completion & cleanup: upon reaching <EOS>, physical blocks 7, 1, and 3 are unmapped and returned immediately to the global VRAM pool.  block table mapping architecture as shown in the architectural request flow diagram above: - Request A arrives with prompt `"Four score and seven years ago our"` and generates output tokens `"fathers" -> "brought"`. - logical blocks 0, 1, and 2 are mapped via the vLLM block table to physical blocks 7, 1, and 3 scattered across GPU DRAM. - unallocated physical blocks (0, 2, 4, 5, 6, 8) remain completely free in VRAM for other concurrent requests. by managing KV memory through paged blocks, external fragmentation drops to zero because physical pages do not need to be contiguous in VRAM because memory waste is virtually eliminated, better memory usage allows larger batch sizes on the same GPU hardware, higher batch concurrency keeps GPU memory bandwidth and CUDA cores fully utilized during decode steps, significantly increasing overall serving throughput. In simple terms, fitting more active sequences into VRAM means your GPU spend goes directly toward useful token generation rather than holding empty memory slots. the biggest advantage of PagedAttention is that it virtually eliminates memory waste, keeping memory fragmentation under 4% and letting you fit 2x to 4x more concurrent requests into GPU VRAM. the main trade-off is control-plane and kernel complexity. managing block tables on the CPU introduces lookup overhead, and gathering non-contiguous physical memory blocks requires custom CUDA kernels instead of standard PyTorch memory operations. > this is also why we call PagedAttention an intra-request memory allocation technique (intra meaning within). > it focuses entirely on how blocks and pages are dynamically assigned inside a single sequence as its tokens grow, without caring about what other requests are doing. ## RadixAttention (SGLang) while PagedAttention optimizes memory allocation within individual requests, RadixAttention addresses redundant compute and memory across multiple requests. RadixAttention and PagedAttention are compatible, but the SGLang paper does not describe RadixAttention as simply building on top of vLLM's PagedAttention though I thought that be the case here! RadixAttention stores KV cache tensors in a non-contiguous, paged layout where each page holds one token. so the physical KV memory is paged, while the radix tree adds a separate idea on top: it indexes cached token prefixes so their KV states can be found and reused. instead of discarding a request's KV cache as soon as processing finishes, RadixAttention retains the cached prompt and generation states so later requests can reuse them. those states stay in the shared memory pool until SGLang needs to evict them. it organizes token sequences in a CPU-managed Radix Tree that maps token sequences to their corresponding KV cache tensors. this turns the shared KV memory pool into a dynamic, tree-structured LRU cache across multiple requests. the distinction matters here: - paged layout describes how KV tensors live in physical GPU memory. - radix tree describes how SGLang finds shared token prefixes and the KV tensors that belong to them. - LRU eviction helps with removing unused cached leaf when the shared memory pool needs space. it is important to note that RadixAttention is mainly about reusing cached Key-Value states across requests with shared prefixes. mathematically, attention computation remains standard, what changes is that prefill computation for repeated prompt prefixes is skipped by reusing pre-computed KV states directly from memory. ## How requests reuse prompt prefixes ? think about reading a 500 page technical textbook where every chapter begins with the exact same 50 page historical background. if three different readers ask you to summarize three different chapters, re-reading the identical 50 page background from scratch for every single reader wastes immense time. in real-world LLM applications, incoming requests frequently reuse the exact same prompt prefixes: - system prompts: long role instructions, guidelines, and safety framing appended to every user message. - multi-turn chat history: past conversation turns re-sent with every follow-up question in a chat session. - few-shot prompt: examples identical demonstration pairs included across many distinct user queries. - tool definitions & agent instructions: JSON schemas, API specs, and agent loop trajectories. in naive engines, every new request forces the GPU to recompute Key-Value states for the exact same prefix tokens over and over again, wasting GPU FLOPs and increasing Time to First Token (TTFT) RadixAttention solves this by storing cached Key-Value states in a radix tree. a radix tree is a space-efficient tree data structure where each edge represents a sequence of tokens, and the tree maps those sequences directly to their pre-computed Key-Value cache tensors by structuring the cache this way, shared token prefixes naturally become common ancestor nodes near the root of the tree, allowing multiple child branches to share them. when a new request arrives, SGLang simply traverses the radix tree to find the longest matching cached prefix. ## Rradix-tree state transition flow  when your first chat request arrives, SGLang processes the entire prompt and saves your system instructions, user message, and its own reply as a single continuous path in the tree. when you send a follow-up message in that exact same chat, SGLang matches the prefix. it reuses the entire cached memory block from turn one and only computes the brand new message, appending it to the end of the branch. now imagine a completely different user starts a new chat but uses the exact same system prompt "You are helpful assistant". it notices this and splits the original branch. both chat sessions now share the same physical memory for the system prompt, branching off only where the specific user messages differ. as more requests comes in with same system promtps like multi shot benchmarks or parallel sampling, the GPU memory eventually fills up, when a new request needs space but the memory pool is full, SGLang simply finds the oldest, unused leaf at the edge of the tree and evicts it to free up physical blocks. this makes the tree a highly elastic, self-managing memory pool that balances heavy prefix cache reuse with stability under high concurrent workloads. the biggest win of this tree structure is how it automatically speeds up generation and saves compute power. by keeping chat histories, system prompts, and few-shot examples cached in memory, it skips the heavy math required to process them again. the key benefits are: - faster TTFT: skips redundant prefill math for shared prompts. - cheap parallel sampling: multiple branches reuse the same cached prefix. - elastic memory: safely locks active requests, evicts the oldest unused leaves when VRAM is full. > this is why we call RadixAttention an inter-request compute reuse technique (inter meaning between or across). > while PagedAttention manages page blocks within a single request, RadixAttention shares cached prefix blocks across multiple completely independent requests. ## PagedAttention vs RadixAttention  ## When to choose who, which engine should you actually run in production? PagedAttention and RadixAttention are not direct competitors, they solve entirely different bottlenecks. PagedAttention focuses purely on squeezing memory waste to zero, while RadixAttention focuses on skipping redundant prefill computation. if you look at the throughput comparison below, you can see exactly where SGLang pulls ahead:  this performance gap tells a clear story based on your workload. if your application relies heavily on shared context like long multi-turn agent conversations, structured JSON generation with massive schemas, or complex few-shot tool loops SGLang is the absolute winner. it leverages the radix tree to reuse all that shared history across requests, which drastically cuts your latency and shoots your TTFT fast! on the other hand, if you are building a general-purpose API serving completely unique, randomized traffic (like text summarization across thousands of unrelated documents), that radix tree will not help you. if there are no shared prefixes to cache, managing the tree just adds unnecessary CPU overhead. for these random-traffic workloads, vLLM remains the gold standard, giving you rock solid, low-overhead memory paging to maximize continuous batching throughput! Sources & references: the concepts and benchmarks presented in this article are derived from the following core research papers: - PagedAttention / vLLM paper paper - RadixAttention / SGLang paper paper ## 相关链接 - [prasanna](https://x.com/jaga_prasanna) - [@jaga_prasanna](https://x.com/jaga_prasanna) - [22K](https://x.com/jaga_prasanna/status/2081678437698408899/analytics) - [paper](https://arxiv.org/abs/2309.06180) - [paper](https://arxiv.org/abs/2312.07104) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [5:49 PM · Jul 27, 2026](https://x.com/jaga_prasanna/status/2081678437698408899) - [22.3K Views](https://x.com/jaga_prasanna/status/2081678437698408899/analytics) - [View quotes](https://x.com/jaga_prasanna/status/2081678437698408899/quotes) --- *导出时间: 2026/7/28 12:29:25* --- ## 中文翻译 # PagedAttention & RadixAttention **作者**: prasanna **日期**: 2026-07-27T09:49:49.000Z **来源**: [https://x.com/jaga_prasanna/status/2081678437698408899](https://x.com/jaga_prasanna/status/2081678437698408899) ---  今天我们来看看这两种技术如何从两个互补的角度解决内存和计算瓶颈：用于请求内内存分配的虚拟内存分页，以及用于请求间计算重用的前缀树缓存！ 1. vLLM 中的 PagedAttention 2. SGLang 中的 RadixAttention # PagedAttention (vLLM) PagedAttention 主要是一种键值缓存内存管理技术，而不是一种全新的数学注意力算法。 底层的注意力数学计算保持标准，每个查询 token 仍然根据过去的键和值向量计算点积注意力。 改变之处在于这些 KV 向量如何在物理 GPU 显存中存储和收集！ 1. 为什么 KV 缓存会变成巨大的内存问题？ 想象一下在一栋大楼里出租公寓，房客是动态到达的，并且停留的时间不可预测。如果你在第一天就给每个房客分配一套 10 居室的套房，以防他们以后决定带 9 个朋友来，那么几乎所有的房间都会完全空置，而新房客却会被拒之门外！ 这正是朴素的 LLM 服务在 GPU 内存中处理键值缓存的方式。在推理过程中，键值缓存会产生一个巨大的、动态增长的内存占用： - 动态内存增长：在解码阶段，每个新生成的 token 都会在模型的每一层和每个注意力头中追加一个新的键向量和一个值向量。 - 不可预测的序列寿命：一个用户请求可能在 20 个 token 后结束，而另一个则可能运行 2,000 个 token。 - 朴素的连续分配：为了避免在生成过程中用尽显存，标准的 PyTorch 实现会为每个活动请求预先保留一块大小为 `max_sequence_length`（例如 4,096 个 token）的连续 GPU 内存块！ 为每个请求分配连续内存区域会导致两种严重的内存浪费： 1. 内部碎片：如果一个用户请求在生成 100 个 token 后结束，剩余的 3,996 个预留 token 位将空置。高达 80% 的预留显存被浪费在从未写入的内存上。 2. 外部碎片：由于请求在不同时间开始和结束，释放的内存块会以不同的大小散落在显存各处。 即使总空闲显存足以容纳一个新请求，内存分配也会失败，因为没有足够大的单个连续块来容纳 `max_sequence_length`。由于这种内存碎片浪费，传统服务器在耗尽显存之前通常只能容纳极小的批次大小（通常每个 GPU 2 到 4 个并发请求），导致强大的 GPU 计算单元闲置，等待内存操作！ > 我们称之为计算饥饿——花钱租用 H100 GPU，却让其 CUDA 核心闲置在显存内存旁等待！ ## 解决方案：固定大小的块 PagedAttention 通过将操作系统的虚拟内存分页引入到 GPU 显存管理中来解决这个问题。 PagedAttention 不再要求每个请求占用一个连续的内存区域，而是将序列的 KV 缓存分割成小的、固定大小的物理块（通常每个块包含 16 或 32 个 token）。 我们区分两个概念： - 逻辑块：逻辑块 0 存储第 0 到 15 个 token，逻辑块 1 存储第 16 到 31 个 token，依此类推。 - 物理 GPU 内存块：从全局空闲块池中分配在 GPU 内存任意位置的实际 16-token 显存内存页。 一个序列不再需要占用连续的物理内存，相反 vLLM 为每个活动序列维护一个块表： - 块表查找：块表将序列的每个逻辑块索引映射到显存中特定的非连续物理块 ID。 - 按需动态分配：当一个请求到达时，vLLM 只分配一个物理块（16 个 token）。随着生成的进行并填满第 15 个 token 位，引擎会从空闲池中索取一个新的物理块，并将其附加到该请求用于第 16 个 token 的块表中。 - 即时内存释放：一旦请求完成或达到 `EOS`（结束符），其所有分配的物理块都会立即被释放并返回到全局空闲块池，供其他请求使用。 让我们看看 pagedAttention 是如何一步步执行的。 我参考了 vLLM 论文中展示的一个请求跨越物理 GPU 内存块生长的示例（使用 4 个 token 的块大小）： 1. 提示预填充：提示词 "Four score and seven years ago our"（7 个 token）填满了逻辑块 0（映射到物理块 7）和逻辑块 1 的 3 个位（映射到物理块 1）。 2. 生成 "fathers"：输出 token "fathers" 填满了逻辑块 1 的第 4 个也是最后一个位（物理块 1）。 3. 生成 "brought"：逻辑块 1 已满，因此引擎从空闲池中索取物理块 3 用于逻辑块 2。 4. 完成与清理：一旦达到 `<EOS>`，物理块 7、1 和 3 将被解除映射并立即返回到全局显存池。  块表映射架构 如上面的架构请求流程图所示： - 请求 A 带着提示词 `"Four score and seven years ago our"` 到达，并生成输出 token `"fathers" -> "brought"`。 - 逻辑块 0、1 和 2 通过 vLLM 块表映射到分散在 GPU DRAM 中的物理块 7、1 和 3。 - 未分配的物理块（0, 2, 4, 5, 6, 8）在显存中保持完全空闲状态，供其他并发请求使用。 通过分页块管理 KV 内存，外部碎片降至零，因为物理页不需要在显存中连续。由于内存浪费几乎被消除，更好的内存利用率允许在相同的 GPU 硬件上使用更大的批次大小。更高的批次并发性使得 GPU 内存带宽和 CUDA 核心在解码步骤中得到充分利用，从而显著提高了整体服务吞吐量。 简而言之，在显存中容纳更多活动序列意味着你的 GPU 支出直接用于有用的 token 生成，而不是用于持有空的内存位。 PagedAttention 最大的优势在于它几乎消除了内存浪费，将内存碎片控制在 4% 以下，并使你能在 GPU 显存中容纳 2 倍到 4 倍的并发请求。 主要的代价在于控制平面和内核的复杂性。在 CPU 上管理块表会引入查找开销，并且收集非连续物理内存块需要自定义的 CUDA 内核，而不是标准的 PyTorch 内存操作。 > 这也是为什么我们将 PagedAttention 称为请求内内存分配技术（intra 意为“内部”）。 > 它完全专注于如何在单个序列的 token 增长过程中动态分配块和页，而不关心其他请求在做什么。 ## RadixAttention (SGLang) 虽然 PagedAttention 优化了单个请求内的内存分配，但 RadixAttention 解决了多个请求之间的冗余计算和内存问题。 RadixAttention 和 PagedAttention 是兼容的，但 SGLang 论文并没有将 RadixAttention 描述为仅仅建立在 vLLM 的 PagedAttention 之上，尽管我原本是这么认为的！ RadixAttention 将 KV 缓存张量存储在非连续的、分页的布局中，其中每个页容纳一个 token。因此物理 KV 内存是分页的，而基数树在此基础上增加了一个单独的概念：它对缓存的 token 前缀进行索引，以便找到并重用它们的 KV 状态。 RadixAttention 不会在处理完成后立即丢弃请求的 KV 缓存，而是保留缓存的提示词和生成状态，以便后续请求可以重用它们。这些状态会保留在共享内存池中，直到 SGLang 需要将它们驱逐出去。 它利用 CPU 管理的基数树来组织 token 序列，该树将 token 序列映射到其对应的 KV 缓存张量。这将共享 KV 内存池转变为跨多个请求的动态的、树形结构的 LRU 缓存。 这里的区别很重要： - 分页布局描述了 KV 张量如何存在于物理 GPU 内存中。 - 基数树描述了 SGLang 如何找到共享的 token 前缀以及属于它们的 KV 张量。 - LRU 驱逐有助于在共享内存池需要空间时移除未使用的缓存叶子节点。 值得注意的是，RadixAttention 主要关于在具有共享前缀的请求之间重用缓存的键值状态。在数学上，注意力计算保持标准，改变的是通过直接从内存重用预计算的 KV 状态，跳过了重复提示词前缀的预填充计算。 ## 请求如何重用提示词前缀？ 想象一下阅读一本 500 页的技术教科书，每一章都以完全相同的 50 页历史背景开头。如果有三个不同的读者要求你总结三个不同的章节，为每个读者从头开始重读那相同的 50 页背景会浪费大量时间。 在现实的 LLM 应用中，传入的请求经常重用完全相同的提示词前缀： - 系统提示词：附加到每条用户消息的长角色指令、指南和安全框架。 - 多轮对话历史：在聊天会话中每次后续提问时都会重新发送的过往对话轮次。 - 少样本提示词：包含在许多不同用户查询中的相同演示对示例。 - 工具定义和代理指令：JSON 模式、API 规范和代理循环轨迹。 在朴素的引擎中，每个新请求都迫使 GPU 一次又一次地重新计算完全相同的前缀 token 的键值状态，浪费了 GPU FLOPs 并增加了首字延迟。 RadixAttention 通过将缓存的键值状态存储在基数树中来解决这个问题。基数树是一种节省空间的树形数据结构，其中每条边代表一个 token 序列，并且该树将这些序列直接映射到其预计算的键值缓存张量。通过这种结构化缓存方式，共享的 token 前缀自然成为靠近树根的共同祖先节点，允许多个子分支共享它们。 当新请求到达时，SGLang 只需遍历基数树以找到最长的匹配缓存前缀。 ## 基数树状态转换流程  当你的第一个聊天请求到达时，SGLang 处理整个提示词，并将你的系统指令、用户消息及其自己的回复保存为树中的一条连续路径。 当你在同一个聊天中发送后续消息时，SGLang 会匹配前缀。它重用第一轮的整个缓存内存块，只计算全新的消息，并将其附加到分支的末尾。 现在想象一个完全不同的用户开始了一个新的聊天，但使用了完全相同的系统提示词 "You are helpful assistant"。 它会注意到这一点并分裂原始分支。两个聊天会话现在共享系统提示词的相同物理内存，仅在特定用户消息不同的地方分叉。 随着更多具有相同系统提示词的请求（如多镜头基准测试或并行采样）进来，GPU 内存最终会被填满。当一个新请求需要空间但内存池已满时，SGLang 只需找到树边缘最古老、未使用的叶子节点并将其驱逐，以释放物理块。 这使得该树成为一个高度弹性、自我管理的内存池，在重负载并发工作负载下平衡了大量前缀缓存重用与稳定性。 这种树结构最大的胜利在于它如何自动加速生成并节省算力。通过将聊天历史、系统提示词和少样本示例缓存在内存中，它跳过了再次处理它们所需的大量数学运算。 主要好处包括： - 更快的 TTFT（首字延迟）：跳过共享提示词的冗余预填充数学运算。 - 低成本的并行采样：多个分支重用相同的缓存前缀。 - 弹性内存：安全地锁定活动请求，当显存已满时驱逐最古老的未使用叶子节点。 > 这就是为什么我们将 RadixAttention 称为请求间计算重用技术（inter 意为“之间”或“跨越”）。 > 当 PagedAttention 管理单个请求内的页块时，RadixAttention 在多个完全独立的请求之间共享缓存的前缀块。 ## PagedAttention vs RadixAttention  ## 何时选择谁，你在生产环境中应该运行哪个引擎？ PagedAttention 和 RadixAttention 并不是直接的竞争对手，它们解决完全不同的瓶颈。PagedAttention 专注于将内存浪费降至零，而 RadixAttention 专注于跳过冗余的预填充计算。 如果你看下面的吞吐量对比，你可以清楚地看到 SGLang 领先的地方：  根据你的工作负载，这个性能差距讲述了一个清晰的故事。 如果你的应用程序严重依赖共享上下文——如长多轮代理对话、具有巨大模式的 JSON 结构化生成，或复杂的少样本工具循环——SGLang 是绝对的赢家。 它利用基数树在请求之间重用所有共享的历史记录，这极大地降低了延迟，并使你的 TTFT 飙升！ 另一方面，如果你正在构建一个通用 API 来服务完全独特、随机的流量（例如跨数千个不相关文档的文本摘要），那个基数树对你没有帮助。 如果没有共享的前缀可以缓存，管理树只会增加不必要的 CPU 开销。对于这些随机流量工作负载，vLLM 仍然是黄金标准，为你提供可靠、低开销的内存分页，以最大化连续批处理的吞吐量！ 来源与参考： 本文中提出的概念和基准测试源自以下核心研究论文： - PagedAttention / vLLM 论文 [论文](https://arxiv.org/abs/2309.06180) - RadixAttention / SGLang 论文 [论文](https://arxiv.org/abs/2312.07104) ## 相关链接 - [prasanna](https://x.com/jaga_prasanna) - [@jaga_prasanna](https://x.com/jaga_prasanna) - [22K](https://x.com/jaga_prasanna/status/2081678437698408899/analytics) - [paper](https://arxiv.org/abs/2309.06180) - [paper](https://arxiv.org/abs/2312.07104) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [5:49 PM · Jul 27, 2026](https://x.com/jaga_prasanna/status/2081678437698408899) - [22.3K Views](https://x.com/jaga_prasanna/status/2081678437698408899/analytics) - [View quotes](https://x.com/jaga_prasanna/status/2081678437698408899/quotes) --- *导出时间: 2026/7/28 12:29:25*
人 人工智能的工程全景（中）：推理，后训练，对齐和安全 本文是AI工程全景的中篇，深入探讨了模型训练完成后的工程化路径。首先详述了推理优化的核心手段，包括模型瘦身（量化、蒸馏、剪枝、MoE）、投机解码以及主流推理引擎（vLLM, TensorRT-LLM, SGLang）的生态格局。文章分析了成本、延迟与吞吐的“不可能三角”，并重点介绍了“测试时计算”这一范式转变，即通过在推理阶段增加计算量来动态提升模型智能。 技术 › LLM ✍ snowboat🕐 2026-07-03 LLM推理优化量化投机解码测试时计算MoEvLLMAI工程
C CAG：缓存增强生成，RAG的替代方案 文章介绍了缓存增强生成（CAG）作为一种替代经典RAG流水线的新方案。CAG通过将全部知识预加载到模型上下文并缓存KV Cache，显著提升响应速度，解决检索延迟和召回缺失问题。适用于中短篇幅静态文档，但对大规模或频繁变动数据仍需传统RAG或混合架构。 技术 › LLM ✍ Amto🕐 2026-07-29 CAGRAG缓存增强生成LLM私有知识向量化KV Cache开源
F From GPT2 to Kimi3, Explained 文章回顾了从 GPT-2 (2019) 到 KimiK3 (2026) 的大语言模型架构演进，重点对比了参数规模从 1.24 亿到 2.8 万亿的巨大跨越。深入解析了 GPT-2 的 Transformer 解码器结构、KV 缓存机制，并探讨了线性注意力机制在降低计算复杂度方面的原理与权衡。 技术 › LLM ✍ ali🕐 2026-07-28 LLMTransformerKimiK3GPT-2AttentionKV Cache架构演进线性注意力
L LLM 推理原理详解：从 Prefill 到 Decode 本文深入解析了大语言模型（LLM）推理的计算流程。文章指出，LLM 推理主要包含 Prefill（处理提示词，计算密集型）和 Decode（逐词生成，显存带宽密集型）两个阶段。作者详细阐述了分词、Embedding、Transformer 层及 KV Cache 的工作原理，并分析了 KV Cache 带来的内存挑战及 vLLM 的优化方案。最后，探讨了 DeepSeek-V4 等新架构通过重新设计注意力机制来从根本上压缩 KV Cache 的创新思路。 技术 › LLM ✍ Avi Chawla🕐 2026-06-29 LLM推理KV CachePrefillDecodeDeepSeekTransformer性能优化
L LLM 原理与实践指南 (2026 版) 这是一份关于大语言模型（LLM）的实践指南。文章从基础循环机制出发，详细解释了文本如何转化为 Token，以及 Transformer、注意力机制、KV Cache 和 RoPE 等核心概念的工作原理。作者强调理解模型内部的推理机制（如 Prefill 和 Decode 阶段）对于硬件选型、显存估算和本地部署的重要性。文章涵盖了 Token 化、上下文窗口、量化、模型服务及本地 AI 硬件数学计算等关键主题，旨在为深入理解 LLM 提供直观的基础。 技术 › LLM ✍ Ahmad🕐 2026-05-23 LLMTransformer本地部署Tokenization推理Attention硬件教程KV Cache
N No .md files until Series B：为何生产级 Agent 需要真正的内存层 文章以一个垂直 Agent 创业公司因使用 Markdown 文件管理内存而导致架构崩溃的真实案例为引子，深入探讨了在构建生产级、多用户、多 Agent 系统时，简单文件存储无法解决的五大核心难题：细粒度权限控制、并发写入冲突、时态查询准确性、可追溯的自我改进机制，以及海量数据的检索效率。作者指出，虽然 MD 文件适合早期原型，但一旦系统规模扩大，开发者往往会不自觉地重新发明数据库，这实际上是倒退。 技术 › Agent ✍ Vasilije🕐 2026-05-21 Agent架构内存管理系统设计LLM工程化权限控制向量检索ScalingAI应用
C Codex CLI 内存机制详解 文章深入解析了 OpenAI Codex CLI 的内存架构，该工具通过本地 Markdown 文件异步生成和汇总记忆。文章详细介绍了记忆的写入与加载流程，指出其缺乏向量数据库、仅依赖关键词匹配及受限于本地文件系统等局限。最后，文章引入 Mem0 作为解决方案，通过 MCP 协议提供跨机器、跨工具的持久化智能记忆层，解决原生功能在扩展性和同步方面的不足。 技术 › OpenAI ✍ mem0🕐 2026-05-14 CodexCli内存管理MCPAgentMem0架构设计开发工具OpenAILLM
T Top Companies Are Secretly Working on This (It Will Replace LLMs) 文章探讨了顶级科技公司正在秘密研发的架构转变——状态空间模型（SSM）。旨在解决 Transformer 架构在长序列处理中的计算成本高和内存消耗大的问题。文章详细解析了 SSM 的工作原理、相比 LLM 的优势（线性时间复杂度、恒定内存），并展示了 NVIDIA、IBM 和 Microsoft 等公司在 Nemotron、Bamba 和 SambaY 等混合架构上的实际应用进展。 技术 › LLM ✍ Siddharth🕐 2026-05-06 SSMTransformerMamba架构NvidiaDeep Learning推理优化LLMInferenceState Space Models
大 大厂正在秘密开发的下一代架构：状态空间模型 SSM 本文探讨了科技巨头如 NVIDIA、Meta 和 Microsoft 正在秘密研发的状态空间模型（SSM），旨在解决 Transformer 架构在长序列处理中的计算和内存瓶颈。文章详细介绍了 SSM 的线性复杂度优势，并列举了 NVIDIA Nemotron-H 和 IBM Bamba-9B 等混合模型如何通过替换 Attention 层来提升推理速度和降低内存消耗。此外，文中还回顾了 S4 和 Mamba 等 SSM 架构的演变，展示了 SSM 在大模型未来的巨大潜力。 技术 › LLM ✍ Siddharth🕐 2026-05-06 SSMMambaTransformerLLM架构Nvidia推理优化人工智能深度学习
L LLM 优化面试笔记：训练与推理核心技术 这是一份针对 AI 实验室面试准备的笔记，涵盖了高效训练和部署大语言模型（LLM）的核心优化策略。内容主要分为三部分：内存优化（如 Flash Attention、MQA/GQA、激活检查点）、计算优化（序列打包、高效变体 Transformer）以及推理优化（KV 缓存、投机解码、量化技术）。文章旨在总结在大规模模型开发中应对算力和内存瓶颈的关键技术。 技术 › LLM ✍ Gauri Gupta🕐 2026-05-06 LLM优化推理训练Flash AttentionKV Cache量化面试Transformer性能优化
推 推理侧AI Infra的战略价值：为什么新云正在成为推理时代的核心战场 文章指出AI竞争已从模型本身转向基础设施，尤其是推理优化。作者分析了为何推理Infra是模型商业化的生命线，以及“新云”如何通过提供专用AI算力成为行业关键，并强调未来的AI竞争将一半在模型，一半在Infra。 技术 › LLM ✍ Yiran🕐 2026-05-03 AI Infra推理优化新云Nebius商业化算力模型服务vLLMDeepSeek
A AI 的记忆机制：从 KV Cache 到智能压缩 文章深入探讨了 AI Agent 遗忘信息的根本原因。作者指出，问题通常不在于检索，而在于 KV Cache 在上下文过长时的处理机制。文章对比了 StreamingLLM（仅保留近期信息）与 SnapKV（基于注意力分数保留关键信息）的区别，并解释了模型如何通过“注意力权重”来决定哪些 Token 值得被记忆，从而实现 92% 的压缩比且不丢失关键信息。 技术 › LLM ✍ Siddharth🕐 2026-04-29 LLMKV CacheAgent记忆机制模型推理上下文压缩StreamingLLMSnapKVAI 架构长文本处理