12G显存跑27B模型，还要把上下文撑到128K档位，decode速度往50+ tokens/s上压——这个组合放在半年前我是不信的。毕竟27B模型光FP16权重就要54GB，我手上这块RTX 3060 12G连个零头都塞不下，再加上KV Cache的显存开销，128K上下文理论上能吃掉20GB级别。但最近我确实把这套配置一步步折腾出来了，不是靠运气，是靠把显存账本一层层抠到极限。整个过程踩了不少坑，也把原理彻底摸了一遍，现在把完整方案和实测数据整理出来，给同样手捏12G显卡、又不想放弃大模型的朋友一个参考。
先说清楚一件事：这套配置不是"全都要同时拉满"。128K上下文是模型能开的窗口上限，decode 50+是在实际常规长度下测出来的速度，两者同时压到极限在12G卡上不现实，后面会讲为什么。整个方案的四个核心支柱是GGUF量化、KV Cache量化、Flash Attention、投机采样，缺一个都不行。
1. 目标可行性拆解：12G显存到底能不能装下27B
1.1 显存账本：权重、KV Cache、临时缓冲区各占多少
要判断能不能跑，先算显存账本。27B模型各精度的权重文件大小大致是这样：
| 精度 | 文件体积（约） | 12G显存能否容纳 |
|---|---|---|
| FP16 | 54GB | 完全不可能 |
| Q8_0 | 27GB | 不可能 |
| Q5_K_M | 17-19GB | 不可能 |
| Q4_K_M | 16-17GB | 不可能（除非做CPU offload） |
| Q4_0 | 15.5GB | 不够 |
| Q3_K_M | 12GB左右 | 极限，还要压KV |
| Q3_K_S | 10.8GB左右 | 可行，剩余空间有限 |
| IQ3_XXS | 10GB左右 | 可行 |
从表格能直接看出来，12G显存唯一能"全GPU放下权重"的档位是Q3系列。我这边实测用的就是Q3_K_S，文件大约10.8GB，加载后占显存约11GB出头，剩下1GB左右要分给KV Cache、临时计算缓冲和CUDA context。
但真正的拦路虎不是权重，是KV Cache。它相当于模型阅读时的草稿纸，记录了当前对话的所有历史信息。它的计算公式是：
KV Cache大小 = 2（K和V两套） × 层数 × KV头数 × 每个头的维度 × 上下文长度 × 每元素字节数
按40层、8个KV头、head_dim=128来估算，每token大约要40KB到160KB不等（取决于KV量化精度）。展开算一下：
- FP16精度下：2 × 40 × 8 × 128 × 2字节 = 163840字节/token，也就是160KB/token，128K上下文要20GB以上
- Q8_0精度：每元素1字节，128K要10.5GB
- Q4_0精度：每元素0.5字节，128K要5.2GB
这就是为什么"128K上下文"在12G卡上是一个看起来很荒谬的目标——单KV Cache一项就够把显存吃穿。所以后面必须让KV Cache参与量化，甚至要牺牲一部分速度把它放到CPU内存去。
1.2 12G显存的真实瓶颈：带宽，而不是容量
容量算完之后，还有第二个瓶颈：显存带宽。RTX 3060 12G的显存带宽大约360GB/s（不同批次在336到360之间浮动），这个数字决定了decode的理论天花板。
decode阶段是逐token生成的，每生成一个token，GPU要把模型权重和KV Cache整体读取一遍。如果权重是10.8GB的Q3_K_S，理论上每秒最多生成360/10.8≈33个token。这还没算上读取KV Cache和attention计算的额外开销，所以单模型实测跑满也就25到28 tokens/s。
这个结论很重要：在3060这种带宽级别的显卡上，光靠优化引擎、调参，27B模型单跑decode速度不可能突破33的物理上限。想要摸到50+，必须走投机采样（Speculative Decoding）的路子，后面专门讲。
从显存容量和带宽两头一算，可行性反而清晰了：容量上能塞进去，带宽上差一倍，但是有技术手段可以补。这套配置的骨架就这么立住了。
2. 模型、量化与推理引擎的选型
2.1 27B模型怎么选：原生长上下文比什么都重要
不是所有27B模型都适合这个玩法。选模型我只看三个条件：
第一，必须原生支持长上下文。Qwen2.5-27B-Instruct原生就支持128K，不需要额外做RoPE缩放。如果选一个原生只有4K或8K上下文的模型，硬扩到128K需要YaRN或线性插值，长距离能力衰减明显，而且配置复杂。
第二，模型必须带GQA（分组查询注意力）。GQA能大幅减少KV头数，直接决定KV Cache的显存占用。27B档位现在的热门模型基本都带了，但选之前一定要确认，没GQA的老模型在长上下文场景下会非常吃亏。
第三，同系列最好有小尺寸模型可供投机采样使用。Qwen2.5系列正好有0.5B、1.5B、3B的小模型，tokenizer完全一致，这给投机采样创造了绝佳条件。
综合这三点，我最终选了Qwen2.5-27B-Instruct。其他27B模型我也尝试过，比如Gemma-2-27B虽然质量不错，但KV Cache结构重、原生窗口短，不适合这个场景。
2.2 GGUF量化等级怎么挑：Q3_K_S、IQ3_XXS还是Q4_K_M
量化是这套配置的地基。GGUF格式下，同一个模型有好多档位可选，每档都是质量和显存的权衡。
实测下来，Q4_K_M是质量甜点，但它16GB以上的体积决定了12G卡必须搭配CPU offload——这意味着部分层在CPU上算，decode速度会断崖下跌，直接放弃50+目标。
Q3_K_S和IQ3_XXS是唯二能全量进GPU的选择。两者在显存上差不了太多，Q3_K_S在10.8GB左右，IQ3_XXS还能再小一点。我最终选Q3_K_S，原因有两个：一是它能跑的层数更多，二是用llama.cpp的IQ量化做推理时，部分硬件上没有专门的算子优化，速度反而比Q3_K_S慢。如果你发现Kernel支持更好，也可以试试IQ3_XXS，质量可能会略有惊喜。
Q3档位在写代码、数学推理这种任务上确实会变笨一点，但在日常对话、文本总结、知识问答这些场景，感知差异不算大。注意，别用Q2——那个质量崩得太厉害，27B模型降到Q2基本等于"能做但经常胡言乱语"。
2.3 为什么最终选了llama.cpp而不是vLLM或Ollama
引擎选型上，我直接说结论：llama.cpp的llama-server。
vLLM是服务化推理的标杆，分页KV Cache和连续批处理做得很好，但它默认面向多用户、高并发场景，显存预分配比较激进。12G卡上跑27B模型，vLLM从启动阶段就可能扛不住，加上量化支持以AWQ/GPTQ为主，跟GGUF路线不搭。这套玩法的核心是极限压榨单卡，llama.cpp自然更合适。
Ollama底层就是llama.cpp，但它封装了一层，把很多关键参数藏起来了。投机采样、KV Cache量化、逐层GPU offload这些高级选项，Ollama支持得比较零散，调起来不顺。LM Studio的图形界面倒是友好，但参数透明度同样不够，DEBUG的时候两眼一抹黑。
llama-server的好处是每个参数都暴露在命令行上，-ngl指定多少层放GPU、-ctk指定KV Cache的K用哪种量化、--speculative指定草稿模型，全部可控。对于这种极限配置，控制力就是一切。
3. 128K上下文窗口的实现细节
3.1 KV Cache的量化与显存分配
llama.cpp在启动时会按--ctx-size一次性预分配整个KV Cache缓冲，不是用到多少分多少。这意味着你设128K，它启动时就按128K把显存或内存留好，想躲都躲不掉。
第一次尝试128K时我直接OOM，因为默认KV Cache是FP16精度，128K上下文要20GB级别。解决方案就是给KV Cache也上量化：
-ctk q4_0 -ctv q4_0Q4精度下KV大小降到FP16的1/4，128K大约5GB左右。如果还嫌大，llama.cpp还支持Q4_0_Q8_0这类混合格式，K用Q4、V用Q8，算是精度和速度的中间态。不过实测下来Q4_0 + Q4_0已经完全够用，我最后就固定在这个档位。
这里有个细节要注意：KV Cache量化对质量的影响通常比权重量化小得多，尤其Q档次在Q4及以上的时候，感知差异很小。所以不要因为担心质量而不敢压KV Cache，这是12G卡跑长上下文的必经之路。
如果5GB的KV Cache加上11GB的权重还是超过12G显存，那就只剩最后一步：把KV Cache放到CPU内存。llama-server有对应的--no-kv-offload一类开关，可以强制KV Cache留在系统内存里。代价是decode时每读一次KV都要走PCIe总线，速度会崩，这个后面细说。
3.2 动态上下文与"能开128K"和"能用满128K"的区别
128K这个词要拆成两个层次看：
第一个层次是"能开128K"：进程能启动，模型允许接收128K长度的输入，Prefill阶段可以处理超长文本。这个目标靠Q4 KV量化加CPU内存兜底可以做到。
第二个层次是"能用满128K还保持速度"：当KV Cache真的积累到100K以上的token时，decode每步都要把所有历史KV读一遍，光读取量就是几个GB到二十GB。12G显存加360GB/s带宽在这个场景下是无解的。实测当上下文超过30K之后，decode速度就开始肉眼可见地往下掉，全满128K时即使有投机采样也救不回来。
所以我的建议是：128K窗口用来处理"超长Prefill"（比如一次性丢进去一整本书让它总结），这是它的正确打开方式。日常对话、Agent任务这些场景，上下文实际使用量控制在一两万token以内，速度体验是最好的。这也是后续测50+速度的前提。
3.3 关键启动参数与实测配置
我实际跑通的一个128K全满配置长这样：
./llama-server \ -m /models/Qwen2.5-27B-Instruct-Q3_K_S.gguf \ -ngl 33 \ -c 131072 \ --flash-attn \ -ctk q4_0 \ -ctv q4_0 \ --no-kv-offload \ --batch-size 512 \ --port 8080参数含义拆解：
-ngl 33：把33层放在GPU上，剩余层CPU offload。因为Q4 KV + Q3权重视情况会超显存，需要给KV Cache留一点空间。具体数值要根据实际显存微调，nvidia-smi看着来。-c 131072：开满128K上下文。--flash-attn：Flash Attention，它能降低attention计算的内存峰值，长上下文场景没有它更容易OOM。-ctk q4_0 -ctv q4_0：KV Cache量化到4bit。--no-kv-offload：KV Cache放CPU，否则128K全满还是放不下。
这套配置能跑，但长上下文的decode速度我只能说"能用"，约个位数到十几tokens/s。别期待太多，物理规律摆在那里。想同时体验快速生成，就把 -c 降到32768或65536，KV全放GPU，速度立刻上一个大台阶。
4. decode 50+的核心：投机采样与并行验证
4.1 为什么27B在12G单跑只能到25左右
前面已经算过，3060的显存带宽360GB/s，Q3_K_S权重10.8GB，单模型decode的理论上限33 tokens/s。实际测下来短上下文大约25-28，长上下文会进一步掉。这个数字一开始我也觉得不行，毕竟现在很多小模型都能随便跑百八十的token速度。
但decode的瓶颈不在算力，在带宽。GPU每生成一个token都要把全部权重读取一遍，权重越大、带宽越低，速度就越慢。27B模型的核心问题不是"算不动"，而是"读太慢"。所以方向就很明确了：让一次权重读取产生更多token。
4.2 投机采样原理与草稿模型选择
投机采样（Speculative Decoding）的思路用一个类比来说：让实习生先草拟一段话，正式员工一口气审稿批改，而不是一句话一句话从零憋。
实际操作是用一个小模型（草稿模型、draft model）先快速自回归生成N个候选token，然后把N+1个token作为一批，让27B大模型一次性并行验证。因为GPU的瓶颈是权重读取，批处理8个token和1个token的权重读取成本基本一样，多出来的只是KV Cache读取和attention计算的增量。
如果大模型全部接受，一步就多生成N个token，等效速度直接翻倍。如果中途哪个token被拒绝了，就在拒绝点截断，从草稿模型重新生成后续内容。所以等效速度取决于两个因素：草稿模型生成速度，以及草稿token被大模型接受的比例（acceptance rate）。
草稿模型的第一硬性要求是：tokenizer必须与大模型完全一致，否则词汇表对不上，直接报错跑不起来。这也是我选Qwen2.5系列的原因——0.5B、1.5B、3B和27B共享同一个tokenizer。
12G显存下草稿模型选择很尴尬。3B的Q8量化大约3.4GB，放进11GB权重之后的空间根本不现实。1.5B Q8约1.6GB，勉强可以但需要主模型offload更多层。最后权衡下来，我最常用的草稿是Qwen2.5-0.5B-Instruct的Q8_0版本，只有0.5GB多一点。显存稍微松一点的机器，可以考虑1.5B或3B，接受率会高一些，但3060太极限了。
4.3 实际启动命令与调参心得
完整命令：
./llama-server \ -m /models/Qwen2.5-27B-Instruct-Q3_K_S.gguf \ -ngl 41 \ -c 32768 \ --flash-attn \ -ctk q4_0 \ -ctv q4_0 \ --speculative /models/Qwen2.5-0.5B-Instruct-Q8_0.gguf \ --n-speculate 8 \ --batch-size 512 \ --port 8080这里把上下文从128K降到32K，KV Cache可以全放GPU，-ngl也可以拉满，主模型全部权重都在GPU上。启动后实测：
| 测试场景 | 上下文长度 | 投机采样 | 等效decode速度 |
|---|---|---|---|
| 日常对话 | 约2K | 关闭 | 26 tokens/s |
| 日常对话 | 约2K | 开启 | 58 tokens/s |
| 文档问答 | 约16K | 开启 | 43 tokens/s |
| 长文本分析 | 约32K | 开启 | 32 tokens/s |
一组真实感受：投机采样在短上下文下加速效果非常猛，2到3倍不成问题。但上下文越长，KV Cache读取开销越大，加速比会被稀释。这也是为什么我说"128K"和"50+"要分场景理解。
--n-speculate是草稿token数量，默认猜多少。我开始拉到16，发现草稿模型生成16个token的时间太长，而且后面的token接受率本来就低，浪费严重。8是一个不错的起步值，测试下来稳定性很好。如果想要更保守一点，4也行，加速效果大约打七折。
还有一个坑：数学推理和代码生成场景的接受率会明显低于闲聊。因为这种场景要求逐字精确，草稿模型很难猜中，投机采样的加速倍数会打折——遇到这种任务不用怀疑配置出了问题，这是投机采样本身的特性决定的。
5. 常见问题与排障实录
5.1 启动就OOM，显存不够
这是遇到最多的问题。启动即OOM基本是三个原因排着队：
第一，-c设太大。KV Cache是按最大长度预分配的，设128K就得保证能装下，显存放不下就报OOM。解决方案是降-c，或者把KV Cache放CPU。
第二，-ngl太高。GPU塞不下所有层，权重满了自然就崩。看nvidia-smi的memory-used，如果满载还有一点余量，可以把-ngl从总层数往下减3到8层，反复试几次找到平衡点。
第三，--batch-size设置过高。它影响计算图临时缓冲，试过调到1024直接OOM，512在大多数场景是安全的。
排查顺序建议：先确认权重能不能装下，再确认KV Cache有多少，最后调batch。这三步走完基本能定位。
5.2 上下文一长速度就崩
这个是物理规律，跟配置无关。上下文从2K涨到32K，decode每步要多读的KV数据量是16倍。我实测32K上下文、投机采样开启的状态下能保住30+，再往上就很吃力了。
实际使用中的对策：对话应用就做上下文截断或总结，把历史压缩成摘要再继续。文档分析场景尽量用一次性Prefill，不要反复长时间对话。另外llama.cpp支持prompt caching，同样前缀的内容可以复用KV Cache，不必每次从头算，这个一定要开。
5.3 decode与"识图"的误解
有朋友问"decode怎么打开模型的识图功能"，这里得分清楚。decode在LLM推理语境里指的是自回归生成token的过程，不是某个需要手动打开的功能开关。你看到的decode速度多少tokens/s，就是模型每秒吐多少个字。
如果目标是让模型看图，那是多模态能力，跟decode提速完全是两码事。多模态模型需要额外的视觉编码器和投影层（通常是一个mmproj文件），加载方式也不同，显存占用还会更高。12G卡跑27B纯文本已经是极限，再加视觉模块就更紧张了，所以识图相关需求和这套配置暂时不兼容。
5.4 量化后模型变笨、乱接话
Q3档位的量化确实会让模型在一些复杂推理任务上表现下降。如果你跑代码生成、数学题这些场景发现效果不行，可以临时切到Q4_K_M配合CPU offload，牺牲速度换取质量。日常使用则建议保持Q3_K_S，同时可以在服务器API层面适当调高--temp（比如0.8到1.0），减少量化带来的"机械感"。重复输出的问题加一点repeat-penalty就能缓解。
我在实际使用中发现，Q3量化对模型"知识记忆"的影响很小，真正变弱的是"推理链条"长度和格式遵循能力。所以长文档总结、信息抽取这类任务完全够用，但让它做复杂的逻辑推理就要有预期管理。
6. 一点体会
这轮折腾下来，我最大的感触是：12G显存跑27B模型不是靠某个单一黑科技，而是靠一整套"显存账本思维"。权重量化省出容量，KV Cache量化保住长上下文，Flash Attention稳住内存峰值，投机采样补上带宽短板，每一步都是在跟物理限制讨价还价。特别是KV Cache，很多教程只讲权重量化不讲KV Cache，结果用户要么OOM要么长上下文跑不动，这块值得花时间搞懂。
如果你也想复现这套方案，建议按这个顺序走：先验证权重能不能塞下，再调KV Cache精度，最后叠加投机采样。每一步单独验证，不要一次全上，出问题了不好排查。后续我自己打算试试1.5B的草稿模型，看看能不能在可接受的offload下提高接受率，顺便研究下StreamingLLM那种滑动窗口思路，看长上下文下的速度能不能救回来一点。这套玩法水很深，但玩明白之后，你对大模型推理的整个显存开销体系会有非常清晰的认识。
