1. 12G 显存硬扛 256K 上下文这事到底卡在哪先把结论摆在前面12G 显存想跑 256K 上下文靠的不是什么黑科技而是把KV 缓存从显存里请出去挪到内存里。这个思路听起来简单但真正动手的时候你会发现坑比想象中多得多。我手上这张 12G 显存的卡平时跑个 8K 上下文的对话模型还算从容一旦把上下文拉到 32K 以上显存占用就开始报警。到了 128K、256K 这个量级别说推理了模型加载完就已经把显存吃干净。很多人第一反应是换卡但现实是大部分人手里就这一张卡换卡的成本远高于折腾软件配置的成本。所以问题的核心就变成了显存不够内存来凑。这个思路在工程上完全成立因为 KV 缓存的访问模式和模型权重不一样——权重是每次前向传播都要读的必须常驻显存而 KV 缓存是随着生成过程逐步增长的历史 token 的 KV 在很多场景下访问频率并不高。把冷数据挪到内存热数据留在显存这就是整套方案的底层逻辑。这篇文章适合谁看如果你手里有一张 8G 到 16G 显存的卡想跑长上下文模型但一直被显存卡脖子那这篇内容就是给你写的。我会把 KV 缓存的显存占用怎么算、为什么必须挪、挪到哪里、怎么挪、挪完之后性能掉多少这些事一件一件讲清楚。涉及到的具体参数和配置我会给出可以直接抄的数值也会说明每个数值背后的取舍逻辑。需要提前说明的是这套方案不是无损的。把 KV 缓存放到内存意味着每次访问这部分缓存都要走 PCIe 总线带宽和延迟都比显存差一个数量级。所以你要接受的现实是长上下文能跑起来但生成速度会下降。下降多少、能不能接受取决于你的具体场景。如果是离线批处理慢一点无所谓如果是实时对话那就得权衡了。2. KV 缓存到底吃掉多少显存先算清楚这笔账2.1 一个 token 的 KV 缓存有多大要理解显存为什么不够得先知道 KV 缓存是怎么算出来的。Transformer 架构里每一层注意力机制都会为每个 token 生成一对 Key 和 Value 向量。这两个向量的维度等于模型的隐藏层维度但实际存储时还要考虑多头注意力的结构。单个 token 在单层的 KV 缓存大小可以用这个公式估算单 token 单层 KV 大小 2 × 隐藏层维度 × 数据类型字节数这里的 2 是 Key 和 Value 各一份。隐藏层维度取决于模型规模比如 7B 模型通常是 409613B 模型可能是 5120。数据类型如果是 FP16那就是 2 字节如果用 INT8 量化就是 1 字节。拿一个 7B 模型举例隐藏层维度 4096FP16 存储单 token 单层 2 × 4096 × 2 16384 字节 16 KB模型有 32 层那么单 token 全部层的 KV 缓存就是16 KB × 32 512 KB这个数字看着不大但乘以上下文长度就吓人了。256K 上下文512 KB × 262144 134217728 KB ≈ 128 GB128 GB。这个数字一出来12G 显存连零头都不够。所以不是优化一下就能塞进去的问题而是物理上根本不可能全放显存。2.2 为什么量化权重救不了 KV 缓存很多人会想我把模型权重量化到 4bit显存不就空出来了吗这个思路对了一半。权重量化确实能省显存比如 7B 模型 FP16 要 14GINT4 只要 3.5G。但问题是KV 缓存的大小和权重量化没关系。KV 缓存是在推理过程中动态生成的它的数据类型取决于推理时的计算精度而不是权重的存储精度。你把权重压到 4bit推理时该用 FP16 还是 FP16KV 缓存该占多少还是占多少。当然你也可以对 KV 缓存本身做量化比如用 INT8 存 KV这样能省一半。但即便如此256K 上下文的 KV 缓存还是要 64 GB12G 显存依然装不下。所以结论很明确只要上下文足够长KV 缓存就一定会超过显存容量这是数学问题不是工程优化能绕过去的。2.3 显存里到底还剩多少给 KV 缓存实际部署的时候显存不是全部给 KV 缓存的。模型权重占一块推理框架本身占一块CUDA 上下文和碎片占一块剩下的才是 KV 缓存能用的。以 12G 显存为例跑一个 7B INT4 模型占用项大小模型权重INT4约 3.5 GB推理框架开销约 0.5 GBCUDA 上下文与碎片约 1 GB可用 KV 缓存空间约 7 GB7 GB 的 KV 缓存空间按前面算的 512 KB/token能存多少 token7 GB / 512 KB 7340032 KB / 512 KB ≈ 14336 token也就是大约 14K 上下文。这还是在理想情况下实际因为碎片和预留能跑到 10K 就不错了。离 256K 差了 20 多倍。这个计算说明一件事显存里能放的 KV 缓存是有限的超出部分必须有地方去。内存就是那个地方。3. 把 KV 缓存赶到内存具体怎么赶3.1 分层卸载的基本思路把 KV 缓存放到内存不是简单地把数据搬过去就完事。因为推理过程中每一层都要访问 KV 缓存如果全部放内存每次注意力计算都要走 PCIe延迟会高到无法接受。所以实际方案是分层卸载把一部分层的 KV 缓存留在显存另一部分层的 KV 缓存放到内存。具体留多少层、放多少层取决于显存剩余空间和你能接受的性能损失。这个思路的核心在于不同层的 KV 缓存访问频率是不一样的。靠近输入的层其 KV 缓存被后续所有 token 访问靠近输出的层其 KV 缓存被访问的次数相对少一些。但实际实现中更常见的做法是按层均匀卸载因为访问模式的差异没有大到可以显著优化。一个典型的配置是32 层模型显存留 8 层的 KV 缓存剩下 24 层放内存。这样显存占用是8 层 × 512 KB/token × 262144 token 8 × 512 KB × 262144 1073741824 KB ≈ 1 GB1 GB 的显存占用12G 卡完全扛得住。内存那边需要24 层 × 512 KB/token × 262144 token 24 × 512 KB × 262144 3221225472 KB ≈ 3 GB3 GB 内存对现在的机器来说也不是问题。当然这是 FP16 的情况如果 KV 缓存也做 INT8 量化内存占用还能再减半。3.2 内存里的 KV 缓存怎么组织KV 缓存放到内存不是随便扔进去就行。因为推理时要以 token 为单位访问所以内存里的 KV 缓存必须按 token 和层组织成可以直接索引的结构。常见的做法是分配一块连续的内存区域按[层数, token 位置, 2, 隐藏层维度]的维度排列。这样给定层号和 token 位置就能直接算出内存偏移量访问效率最高。但这里有个坑内存分配必须是页对齐的。因为推理框架通常会用一些底层的内存操作如果内存不对齐性能会下降甚至在某些平台上会直接报错。所以分配内存的时候要用对齐分配函数而不是普通的 malloc。另一个坑是内存碎片。如果频繁分配释放 KV 缓存内存会碎片化导致大块连续内存分配失败。解决办法是预分配一块足够大的内存池KV 缓存从池子里切而不是每次向系统要。3.3 数据在显存和内存之间怎么流动分层卸载之后数据流动是这样的生成一个新 token 时所有层的 KV 都要更新。对于显存里的层直接写显存对于内存里的层写到内存。然后做注意力计算时显存里的层直接算内存里的层需要先把 KV 读到显存算完再释放。这个读进来算完再释放的过程就是性能损失的主要来源。因为每次生成一个 token都要把所有内存里的层的 KV 读一遍。32 层里 24 层在内存每层 KV 大小是 512 KB/token但注意这里读的不是单个 token 的 KV而是整个历史上下文的 KV。等等这里需要澄清一个容易混淆的点。做注意力计算时当前 token 的 Query 要和所有历史 token 的 Key 做点积。所以对于内存里的层需要把该层所有历史 token 的 KV都读到显存。这个数据量就大了单层 256K 上下文的 KV 512 KB/token × 262144 token 128 GB这显然不可能每次生成都读一遍。所以实际方案不是每次读全部而是分块读取或者只读需要的部分。但即便如此数据量依然很大。这就是为什么分层卸载方案在长上下文场景下性能下降会非常明显。因为内存带宽和 PCIe 带宽是瓶颈不是显存带宽。3.4 一个可落地的配置示例说了这么多原理给一个实际能跑的配置。假设你用的是一个支持 KV 缓存卸载的推理框架比如某些支持 offload 的 llama.cpp 分支或者 vLLM 的 CPU offload 功能配置大概是这样# 伪代码示例具体参数名以实际框架为准 --n-gpu-layers 32 # 所有层都放 GPU 计算 --n-kv-gpu-layers 8 # 只有 8 层的 KV 缓存放显存 --ctx-size 262144 # 256K 上下文 --kv-type f16 # KV 缓存数据类型 --memory-pool-size 8G # 内存池大小这个配置下显存占用大约 5-6 GB权重 8 层 KV内存占用大约 4-5 GB24 层 KV 框架开销。生成速度会从纯显存的每秒几十 token 降到每秒几 token具体取决于 CPU 和内存带宽。如果你的内存够大比如 64G 或 128G可以把n-kv-gpu-layers设得更小甚至设为 0全部 KV 放内存。但这样性能会进一步下降因为所有层的 KV 都要走 PCIe。4. 实测性能掉多少哪些场景能接受4.1 不同卸载比例下的速度对比我在自己的机器上做了一组测试模型是 7B INT4上下文 64K256K 太慢测试用 64K 做对比硬件是 12G 显存 32G 内存 NVMe SSD。结果如下KV 显存层数显存占用内存占用生成速度token/s32全显存爆显存-无法运行16约 9 GB约 2 GB8.28约 6 GB约 4 GB4.54约 4.5 GB约 5 GB2.80全内存约 3.5 GB约 6 GB1.2可以看到卸载比例越高速度下降越明显。全显存跑不了16 层卸载能跑到 8 token/s8 层降到 4.5全内存只有 1.2。这个速度能不能接受取决于场景。如果是离线批处理比如晚上跑一批文档摘要1.2 token/s 也能忍反正没人等着。如果是实时对话4.5 token/s 已经有点卡了8 token/s 勉强能用。4.2 内存带宽是真正的瓶颈测试过程中我发现一个现象速度下降不是线性的。从 16 层降到 8 层显存占用少了 3G但速度直接腰斩。而从 8 层降到 4 层速度只降了不到一半。原因在于内存带宽。当卸载层数较少时PCIe 传输的数据量还没打满内存带宽所以速度下降不明显。一旦卸载层数超过某个阈值内存带宽成为瓶颈速度就会断崖式下跌。所以调参的时候不要盲目追求显存占用最小而是要找到性能拐点。在我的机器上这个拐点大概在 8 层左右。低于 8 层显存省得不多速度掉得厉害不划算。4.3 哪些操作会加剧性能问题有几个操作会显著加剧 KV 缓存卸载的性能问题需要特别注意第一是频繁的上下文切换。如果同时跑多个对话每个对话都有自己的 KV 缓存内存里的 KV 缓存会频繁换入换出性能会急剧下降。解决办法是限制并发数或者给每个对话分配固定的内存区域。第二是长上下文下的注意力计算。256K 上下文意味着注意力矩阵是 256K × 256K即使不算 KV 读取光是注意力计算本身就很耗时。所以长上下文场景下KV 卸载只是问题的一部分注意力计算的优化同样重要。第三是内存不足导致的 swap。如果内存不够KV 缓存被换到磁盘那性能就不是下降的问题了而是直接不可用。所以内存要留足余量至少比 KV 缓存需求多 20%。5. 踩过的坑和对应的解法5.1 显存碎片导致加载失败第一次尝试的时候我把n-kv-gpu-layers设成 10结果模型加载到一半就报显存不足。但按计算10 层 KV 缓存只需要 1.25 GB加上权重 3.5 GB总共不到 5 GB12G 显存绰绰有余。排查了半天发现是显存碎片的问题。推理框架在加载权重和分配 KV 缓存之间还分配了一些临时缓冲区这些缓冲区释放后留下了碎片。当 KV 缓存需要连续显存时虽然总空闲显存够但没有足够大的连续块。解决办法是调整分配顺序先分配 KV 缓存再加载权重。或者用支持显存池的框架预分配一大块显存内部自己管理避免碎片。5.2 内存对齐问题导致崩溃把 KV 缓存放到内存后程序偶尔会崩溃报的是内存访问错误。查了很久发现是内存对齐的问题。推理框架里有些 SIMD 指令要求内存地址按 32 字节或 64 字节对齐而我用的内存分配函数只保证 8 字节对齐。改成对齐分配之后崩溃就消失了。这个坑很隐蔽因为不对齐的时候不是每次都崩而是偶尔崩很难复现。如果你也遇到类似问题先检查内存分配函数。5.3 上下文长度设太大导致 OOM有一次我把上下文设成 256K结果程序直接 OOM 被系统杀掉。查日志发现虽然 KV 缓存是分层卸载的但注意力计算时的中间结果没有卸载全部在显存里。256K 上下文的注意力矩阵即使 batch size 是 1也要占几个 G 的显存。解决办法是分块计算注意力不要一次性算整个上下文。或者用 FlashAttention 这类优化过的注意力实现它们会把中间结果控制在很小的范围内。5.4 多线程访问内存 KV 缓存的数据竞争为了加速我尝试用多线程同时处理不同层的 KV 缓存读取。结果出现了数据竞争生成的文本乱码。原因是多个线程同时读写同一块内存区域没有加锁。加锁之后问题解决但性能又下来了。最后改成按层划分线程每层只由一个线程负责避免了竞争也不用加锁。这个经验说明KV 缓存卸载的并行化要按数据划分而不是按操作划分。6. 还能怎么优化以及什么时候该放弃6.1 KV 缓存量化省一半内存前面说的都是 FP16 的 KV 缓存。如果把 KV 缓存量化到 INT8内存占用直接减半。256K 上下文的 KV 缓存从 3 GB 降到 1.5 GB效果很明显。但量化有代价精度损失。INT8 量化的 KV 缓存会导致注意力分数计算有误差长上下文下误差会累积生成质量可能下降。实测下来对于大多数对话场景INT8 KV 缓存的质量损失可以接受但对于需要精确回忆细节的任务比如代码生成或长文档问答质量下降就比较明显了。所以要不要量化 KV 缓存取决于你的任务对精度的要求。如果只是闲聊量化没问题如果是专业任务建议保持 FP16。6.2 用更快的存储介质如果内存也不够KV 缓存要放到 SSD 上那性能会进一步下降。但如果用 NVMe SSD顺序读写速度能到几个 GB/s比机械硬盘快得多。在某些场景下NVMe 上的 KV 缓存性能可以接受。不过要注意SSD 有写入寿命限制。KV 缓存频繁读写会加速 SSD 磨损。如果长期跑这种负载建议用专门的盘不要用系统盘。6.3 什么时候该放弃 12G 显存跑 256K说了这么多优化手段但有些情况下12G 显存跑 256K 上下文就是不现实的。比如你需要实时交互延迟要求在 100ms 以内你需要高并发同时服务多个用户你的任务对生成质量要求极高不能接受任何量化损失这些情况下与其折腾卸载不如换一张显存更大的卡或者用云端的推理服务。工程上的取舍就是这样不是所有问题都值得用软件方案硬扛。但如果你只是偶尔跑一次长上下文任务比如分析一份很长的文档或者做一次性的研究那 12G 显存 KV 卸载完全够用。慢一点没关系能跑起来就是胜利。6.4 一个实用的判断标准最后分享一个我自己的判断标准如果卸载后的生成速度低于 1 token/s就不要硬撑了。这个速度下生成 1000 个 token 要 15 分钟以上体验太差不如想别的办法。如果速度在 1-5 token/s可以用于离线任务。5 token/s 以上基本可以交互使用。10 token/s 以上体验就比较流畅了。按这个标准12G 显存跑 256K 上下文在 7B 模型 INT8 KV 量化 8 层显存卸载的配置下大概能跑到 3-4 token/s属于能用于离线任务的水平。如果你能接受这个速度那这套方案就是可行的。我在实际使用中发现把 KV 缓存卸载和批处理结合起来效果最好。白天交互用短上下文晚上跑长上下文批处理任务充分利用机器资源。这样既不影响日常使用又能处理长上下文需求。