24G 显存跑本地 27B 模型最难的从来不是下载模型那一下而是把显存这张预算表算明白之后还能在“速度、上下文、并发、精度”里四选三甚至四选二。这段时间我把一张 24G 显存的卡专门用来跑 Qwen3 27B 这个档位的开源模型也就是社区里经常被提到的 Qwen 3.8 27b 这类本地部署需求折腾到后面发现能跑起来只是及格线真正能稳定用、回答不卡顿、不会跑两小时就爆显存的配置才是值得记录的东西。这篇文章直接给你我实测过的优化路径从显存开销的拆解到 llama-server 和 vLLM 的启动参数再到长上下文和缓存命中率的取舍。如果你手头也是 24G 显存想本地跑 27B 模型做问答、写代码或者接进自己的小项目这篇应该能帮你少走不少弯路。1. 显存账本先搞清楚 27B 模型把显存花到哪里去了很多人第一次跑崩不是模型文件太大而是压根没搞明白显存去向。24G 显存听起来不少可一张卡真正能自由支配的显存往往只有 22-23G 左右因为驱动、桌面环境、CUDA context 都会先占掉一部分。在这个基础上跑 27B 模型每一个字节都得有去处。1.1 模型权重、KV Cache 和临时激活值三笔开销怎么算模型运行时显存占用大致分成三块权重、KV Cache、临时激活值。最后还要留一点给 CUDA context 和推理框架自己吃掉的零头。先说权重。27B 参数量如果按照 BF16 全精度存放每一参数需要 2 字节算下来大约是 54GB这在 24G 单卡上直接出局。所以本地跑 27B 必然走量化路线。量化到 4bit 之后GGUF 格式的权重文件通常在 16-18GB 之间这才有了塞进 24G 显存的前提。再说 KV Cache。这是最容易让人误判的一项。自回归模型在生成每个 token 时需要把前面所有 token 的 Key 和 Value 缓存下来供后续注意力计算使用这部分显存会随着上下文长度线性增长。好在现在 27B 级别的模型普遍使用 GQA通过共享 KV head 把缓存体积压了下来。从我的实测经验看27B 模型在 4096 上下文时KV Cache 大概占 2-4GB开到 8192 就奔着 4-8GB 去了。如果框架实现里做了一些额外预留实际数值可能还要再高一点。临时激活值则是一个容易被忽略的“尖峰项”。模型在 prefill 阶段一次性处理大量输入 token 时中间激活值会短时间冲高。如果 batch 调得过大激活值甚至可能吃掉好几个 GB。好在推理框架通常会在解码阶段把 batch 降下来因此我们实际观察到的显存占用并不是一条直线而是一个有波峰的曲线。看到这里你应该已经明白24G 显存跑 27B 的真实预算大约是这样Q4 量化权重占 17GB 左右KV Cache 根据上下文长度占 2-8GB再留 1-2GB 给激活值和框架开销。极限情况下整个预算会被塞得满满当当这也是为什么后续每一个参数都要精打细算。1.2 量化档位怎么选Q4_K_M 是大多数人的甜点位GGUF 格式的量化档位非常多Q2 到 Q8 都有但真正适合 24G 卡跑 27B 的其实就那么几个。我实测过的组合放在下面这张表里量化档位权重占用约24G 卡上的实际表现我的建议Q4_K_M16-17GB还能给上下文留出 4-6GB适合日常使用默认优先选这个Q5_K_M18-19GB上下文超过 4K 时比较紧张8K 很可能 OOM想追求质量时可以试Q6_K约 20GB剩余显存太少KV Cache 稍大就爆不推荐在 24G 卡上常驻Q8_0/F16约 26-54GB24G 卡基本无望直接排除很多人会纠结 Q4_K_M 和 Q5_K_M 的质量差距。从我的实际使用感受来说Q5 在文本流畅度上确实比 Q4 好一点点但这个差距远没有“稳不稳定”重要。Q4_K_M 跑 8K 上下文还能留出余量遇到长文本请求不容易崩Q5_K_M 虽然权重更精细但可用的 KV 空间被压缩一旦上下文长度上来就可能被迫 offload 到 CPU速度瞬间掉到没法看。24G 卡跑 27BQ4_K_M 就是性价比最高的甜点位。顺便提一句下载模型时不要只看文件后缀写着 q4 就觉得万事大吉。同一个模型在不同量化方式下差异很大K_M 这类混合量化方案会对敏感层用更高精度实际效果要好于单纯的四位量化。如果你看到文件名里有 Q4_0 或者 Q4_1同等大小下优先选带 K_M 后缀的版本。1.3 24G 跑 27B 和跑 8B 的边界差异我在调优前先跑了一阵 Qwen3 8B发现 24G 卡跑 8B 是非常“奢侈”的体验模型全精度放进去都毫无压力上下文可以开到 16K 甚至 32K还能同时服务好几个并发请求。这给了人一种错觉好像 24G 显存非常宽裕。换成 27B 之后体验完全是另一回事。8B 模型让我习惯了“不用管资源”27B 则要求我时刻记得自己只有 24G。以前随手把 context window 设成 32K 很爽现在设成 32K 连权重都加载不完以前可以并行处理 4 个会话现在一个会话跑长文本都得掂量掂量。这个边界差异不是简单的大了三倍参数量而是从“资源冗余”变成了“资源刚好”所有使用习惯都要跟着改。所以我建议第一次上手 27B 的朋友先把预期调到“单用户、短到中等上下文、追求稳定输出”这个档位而不是想着榨干模型的所有能力。先跑通再谈优化。2. 推理引擎选择llama-server、vLLM、Ollama 三条路怎么选模型文件准备好了接下来面临的就是选哪个推理引擎来加载它。我在本地试过三条主流路线llama.cpp 的 llama-server、vLLM、Ollama。它们都能跑 27B 量化模型但各自的侧重点和使用姿势差别很大。推理引擎最佳场景显存开销特点灵活度llama-server本地单机、API 调用、精细控制相对省显存逐层控制 offload很高vLLM多轮 Agent、批量任务、高吞吐服务有显存预留机制连续请求友好中高Ollama不想折腾、开箱即用封装了 llama.cpp但隐藏参数较多较低如果你的目标是“我就要在本地稳定跑一个私有模型自己调用”那 llama-server 和 vLLM 是主要考虑对象如果只是想要一个聊天窗口随便玩玩Ollama 更省事。2.1 llama-server 的启动参数怎么给才不浪费显存llama.cpp 编译出来的 llama-server 是我用得最多的一套方案。它原生支持 GGUF不需要额外转换权重格式而且支持把模型逐层放到 GPU显存不足时可以自动把部分层留在 CPU 上。这个特性看起来是好事但在 24G 卡跑 27B 的场景里自动 offload 恰恰是最大的坑。我第一次就是直接跑了一个默认参数日志里显示 “offloaded 0/XX layers to GPU”意思是所有层都在 CPU 上计算生成速度直接跌到每秒几个 token。后来手动指定了-ngl 99让程序尽可能多地把层放到 GPU速度才恢复正常。注意-ngl 99并不是真的会加载 99 层而是表示“能放多少层就放多少层”具体加载多少层取决于剩余显存。除了层数几个核心参数我的配置思路是llama-server.exe -m D:\models\qwen3-27b-q4_k_m.gguf \ --host 127.0.0.1 \ --port 8080 \ -ngl 99 \ -c 8192 \ -b 512 \ -ub 256 \ --flash-attn \ --temp 0.7-c 8192表示上下文长度设为 8192 token这是我在 24G 卡上反复试出来的平衡点。再往上调到 12K 甚至 16K权重虽然能加载但 KV Cache 会明显膨胀一旦遇到长输入就很容易碰显存上限。-b 512是 prefill 阶段的 batch 大小-ub 256是微批大小。这两个值如果设得太大显存占用会出现尖峰设得太小第一批输入的处理速度又会变慢。在 24G 卡上512/256 这个组合是我试过比较稳的配置。--flash-attn会优化注意力计算不仅能稍微提速还能减少长上下文时的显存占用。现在新版 llama.cpp 里这个选项已经默认开启但我还是习惯显式写出来防止某些旧版本编译配置里没带上。启动之后可以用 OpenAI 兼容接口测试一下curl http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d {\model\:\qwen3-27b\,\messages\:[{\role\:\user\,\content\:\你好\}]}如果能看到正常的返回内容说明 llama-server 这条路已经通了。接下来才进入真正的调优阶段。2.2 vLLM 的缓存命中率优化在本地 Agent 场景价值更大vLLM 在数据中心里很常见单卡本地用的人相对少但它有一个突出的能力PagedAttention 加上自动前缀缓存能显著提高重复请求的缓存命中率。vLLM 官方启动命令大概是这个样子vllm serve /path/to/qwen3-27b-model \ --max-model-len 8192 \ --gpu-memory-utilization 0.92 \ --quantization awq \ --dtype float16 \ --enable-prefix-caching注意 vLLM 不像 llama-server 那样直接吃 GGUF它需要的是 Hugging Face 格式的权重量化方式也更偏好 AWQ、GPTQ 或者 FP8。所以如果你已经在 llama.cpp 生态里跑得很顺没必要为了 vLLM 专门转一套权重但如果要做 Agent 应用vLLM 值得认真考虑。vLLM 的缓存命中率提升逻辑很直观在 Agent 场景里每一轮调用都会携带相同的大段 system prompt、工具定义和前面的历史消息。如果不做缓存每次请求都要从头计算这些 token 的 KV开了--enable-prefix-caching之后相同的前缀会被直接复用第二轮开始的首 token 延迟会明显下降。我实际测过一个场景固定 system prompt 约 500 token连续进行多轮问答。关闭前缀缓存时每一轮都需要完整 prefill开启之后后续轮次的首 token 响应速度快了大概百分之六七十。这个提升并不改变单次推理的理论速度但用户体感会好非常多因为等待时间被大幅压缩了。2.3 Ollama 适合先跑通但不适合深调Ollama 是我最早用来试水的方案它把模型管理和启动封装得很好安装完执行一行命令就能跑起来。如果你只是想快速体验一下 Qwen3 27B 在本地是什么效果直接用 Ollama 拉一个 Q4 量化版本就行。但 Ollama 的问题在于它把很多底层参数藏起来了。比如 KV Cache 的具体分配策略、prefill 的 batch 大小、是否优先加载全部层到 GPU这些在 open webui 或者聊天场景下感知不明显一旦遇到长文档或者高并发请求Ollama 的内部默认策略可能不是为你 24G 显存定制的。想改一些关键参数也不是改不了但路径绕来绕去不如直接用 llama-server 来得透明。我的建议是Ollama 拿来验证模型文件没有问题先跑通整体流程。等你开始关心“为什么这个 context 长度下速度变慢”“为什么多轮对话后显存占用收不住”这类问题时就该切换到 llama-server 或者 vLLM 了。3. 影响体验的运行时参数上下文长度、缓存和并发权重选好了引擎也跑起来了接下来才是真正决定好不好用的部分。同样是 24G 卡、同样的模型文件参数设置不同体验可以天差地别。这一节我把上下文长度、缓存命中和并发这三个最影响体验的参数拆开讲。3.1 KV Cache 与上下文长度27B 在 24G 卡上的最大变量我在调优过程中反复吃过的亏都来自同一个源头一上来就把上下文长度设得特别大。被 8B 模型惯坏之后我习惯性把 context 调到 32K结果模型加载到一半直接 OOM。后来一算账才明白KV Cache 的开销会随上下文长度线性增长从 4K 开到 32K缓存占用不是翻一倍两倍的事而是直接吃掉几个 GB 到十几 GB。24G 卡跑 27B 的 KV Cache 预算是很有限的。Q4_K_M 权重约占 17GB扣掉激活值和框架开销留给 KV Cache 的实际空间也就 4-6GB。按这个预算倒推上下文长度在 4K-8K 之间是最稳的区间。我日常使用固定在 8192既能覆盖大部分代码文件和聊天历史又不会让显存经常报警。如果你确实需要处理超长文档优先考虑的不是把 context 开大而是把输入切块。把整篇文档拆成适当大小的段落用检索或摘要的方式把最相关内容放进 prompt而不是一股脑全部塞进去。这样做的好处不只是省显存模型对长上下文中无关信息的“忽略”能力其实有限塞太多不相关内容反而会影响回答质量。3.2 多轮重复请求要怎么省缓存命中率才是本地体验关键本地跑 27B单个 token 的生成速度通常已经固定在一个范围内真正能优化的其实是“减少重复计算”。这就是我在前面提到 vLLM 前缀缓存的原因。llama.cpp 本身也有缓存机制而且随着版本迭代也在不断完善只是在不同场景下的生效方式没有 vLLM 那么直观。缓存命中率这个概念在本地单用户场景下同样重要只是很多人没有意识到。你在和模型连续对话时每发一条新消息实际上都要把之前的对话历史重新作为输入传给模型。如果缓存没有命中哪怕只是新增了几个字前面几千个 token 也得全部重新算一遍。想要提高缓存命中率比较有效的做法是保持 prompt 结构稳定。系统提示词尽量固定不要每次都插入一些随机变化的内容工具定义和角色设定放在最前面最近几轮问答放中间真正要处理的新内容放最后。这样的结构不仅让缓存复用概率更高也让模型对“当前要做什么”的理解更清晰。如果你用 vLLM 做 Agent务必定时检查日志里的 prefix cache hit rate。当命中率偏低时多半是 prompt 前缀发生了变化可以从缓存设计的角度去调整请求结构。命中率高的时候你在用户侧能明显感受到一种“越聊越快”的体验因为后面每一轮都省掉了大段 prefill 时间。3.3 并发请求数和 batch 设置单卡本地不要贪多数据中心里跑大模型追求的是高吞吐因此会把多个请求拼在一起处理。但 24G 单卡跑 27B 模型显存本来就已经很紧再去开多并发请求就属于自己给自己找麻烦了。llama-server 里控制并发的参数是--parallel。默认值通常是 1也就是同一时间只处理一个请求。如果你设成 4KV Cache 的占用会在现有基础上乘以约 4 倍24G 显存根本接不住。我在调优时试过--parallel 2日常短对话没问题但只要有一个请求进入长文本处理显存占用就会逼近上限另一个请求很容易因为拿不到资源而报错。batch 参数同样要克制。前面给的-b 512 -ub 256是我在单用户场景下的经验值。如果你把 prefill batch 调到 1024 甚至 2048确实可能加快首 token 响应但代价是显存占用会出现很高的尖峰在长时间运行后更容易触发 OOM。稳定优先的话batch 宁可小一点也不要为了那一两秒的提首速去赌显存余量。4. 那些只有跑到一半才会发现的问题参数和引擎都准备好之后真正的坑才刚开始浮现。这一节我挑了三个最有代表性的问题每一个都是我自己实际遇到过并且花了不少时间才排查清楚的。4.1 显存没爆但速度暴跌检查日志里的 offload 层数有段时间我的模型运行速度突然从每秒二十几个 token 掉到每秒三四个但进程并没有崩溃也没有提示显存不足。一开始我怀疑是系统后台有程序在抢资源检查了一圈 CPU 和内存占用都很正常后来才想到去看启动日志。日志里明确写着 “offloaded 22/64 layers to GPU” 或者类似的字样。意思是模型一共有几十层但只有一部分被放到了 GPU 上剩下的层在 CPU 上算。CPU 算 transformer 层的速度远低于 GPU于是整体生成速度被拖垮了。出现这种情况的根本原因是显存不够放所有权重和 KV Cache。我今天把上下文从 8K 调到 12K 再重启就可能触发自动回退。排查方法不复杂启动时看日志输出确认它说加载了全部层而不是只加载了一部分。如果发现 offload 已经开始要么降低上下文长度、要么换更小的量化档位、要么就接受这个速度但千万不要假装没看见继续跑因为用户体验会差到让人怀疑模型坏了。4.2 速度忽快忽慢瓶颈往往不在 GPU 计算而在内存与带宽27B 模型每生成一个 token理论上都要把全部权重从显存里过一遍。这意味着解码速度的极限很大程度上取决于显存带宽而不是 GPU 的算力。RTX 3090 和 4090 这类 24G 卡显存带宽在 900GB/s 到 1000GB/s 左右跑 17GB 左右的 Q4 权重理论解码上限大约在 50 token/s 上下实际还要扣除注意力计算和框架调度开销能稳定跑到 25-35 token/s 就已经算不错了。如果你发现速度忽快忽慢而不是稳定在一个偏低的数值可以怀疑系统内存介入。当一部分权重被放在 CPU 内存里或者 mmap 的模型文件因为显存不足开始进行内存交换GPU 每算一层都要通过 PCIe 总线去 CPU 侧取数据速度自然就像过山车一样。特别提醒一下如果你是在老机器上用了 PCIe 转接卡或者外置显卡坞带宽受限的问题会被进一步放大。这种情况下本地跑 27B 的体验会比原生 PCIe 插槽差很多因为模型在 CPU 和 GPU 之间的通信会成为主要瓶颈。我后来的做法很简单确认权重完全落在显存里运行期间不要开太多吃内存的程序尽量让整个推理过程保持在“一张卡自己玩”的状态。4.3 Windows 环境下那三个绕不开的坑我长期在 Windows 上跑 llama-server和 Linux 相比Windows 多一些特有的问题这里单独拎出来说。第一个是显存残留。Windows 下如果上一个推理进程没有正常退出比如直接关掉了终端窗口显存有时候不会立刻释放。再启动新进程时系统告诉你显存不足但 nvidia-smi 里看不到任何可疑进程。解决办法比较直接打开任务管理器把所有带 Python、llama、vllm 字样的进程结束掉必要时重启一次系统再验证。第二个是--mlock参数。llama.cpp 文档里建议用--mlock把模型锁定在物理内存里防止运行时被换页到磁盘。但在 Windows 上这个参数偶尔会因为虚拟内存锁定失败导致进程启动不了。如果你加上这个参数后发现启动报错先去掉再试。Windows 下只要物理内存充足不开--mlock通常问题也不大。第三个是杀毒软件。模型文件动不动十几个 GB加载过程中杀毒软件实时扫描会占用大量磁盘和 CPU 资源导致加载时间明显变长甚至有可能误隔离部分文件。我的做法是把模型目录加入杀毒软件排除列表加载速度能快不少。这个细节很多教程不会提但实际影响比想象中大。5. 我这段时间调优下来的稳定配置与使用习惯讲了这么多理论最后给出一套我可以长期稳定使用的配置。如果你不想从零开始折腾可以直接照抄再根据自己的显卡型号和物理内存做小幅调整。5.1 一套可复制的 llama-server 启动模板这是我目前日常在用的完整启动命令llama-server.exe -m D:\models\qwen3-27b-q4_k_m.gguf \ --host 127.0.0.1 \ --port 8080 \ -ngl 99 \ -c 8192 \ -b 512 \ -ub 256 \ --flash-attn \ --temp 0.7 \ --seed 0对这套配置的解释已经在前文铺开这里只强调几个容易出现偏差的位置-ngl 99不等于“把模型塞进 24G 显存”而是“有多少放多少”。显存不够时依然会自动回退到 CPU。如果发现速度不对先看启动日志。-c 8192是我的日常平衡点。如果你只做短 QA可以设 4096这样余量更大、更不容易 OOM如果你经常贴长代码或整段文档先改成 4096 保稳再逐步往上加不要一上来就 12K。--temp 0.7和--seed 0是采样参数。--seed 0表示每次随机种子都不同如果你追求可复现的结果可以把这个值固定成一个具体数字。如果你想用 vLLM 那套方案跑 Agent同样只需要在gpu-memory-utilization上多注意。不要设置到 0.99单卡本地场景显存太满会导致连续请求时频繁触发显存整理反而影响稳定性。我建议从 0.90 开始观察一段时间没爆再慢慢调高。5.2 三个最容易被忽略但很管用的使用习惯配置稳定之后使用习惯对体验的影响会更加明显。这里写三个我踩过坑之后总结出来的习惯。第一个是别在浏览器开满标签页的状态下跑长文本生成。浏览器硬件加速会占用一定显存虽然单个页面可能只占几百 MB但多个视频标签加在一起就不容小觑了。你给 LLM 的 24G 显存里能被模型使用的部分本来就只有 22G 左右再被浏览器挤占一两 GB离 OOM 就更近了。第二个是多轮对话时适时用摘要代替完整历史。前面提到的缓存机制能省去重复计算但 27B 模型的历史输入越长每一轮 prefill 的压力就越大。我的习惯是当对话超过五六轮之后把前面的内容用模型自己生成一段简短摘要替换掉原始历史。这样既保留了上下文语义又不会让 KV Cache 无限膨胀。第三个是注意显卡温度。连续跑长文本生成时GPU 会长时间保持高负载温度一旦越过降频墙生成速度就会出现无规律的波动。我在持续跑任务时会把功耗墙限制到 300W 左右让温度稳定在一个安全区间。虽然极限吞吐稍微降了一点但速度曲线平滑很多不会出现那种忽快忽慢的难受体验。我把这套配置和方法跑了一周多中间处理过长度不等的代码生成、文档问答和多轮角色扮演对话整体稳定性和输出速度都符合预期。如果你手里也是 24G 显存卡想本地跑 Qwen3 27B可以从 Q4_K_M 权重加 llama-server 这条路线开始把基础流程跑通后再根据自己的场景切换 vLLM 或者调整上下文策略。至于那些动不动就让人“直接上 32K 上下文”的方案至少在这张卡上我劝你还是先拿计算器算算 KV Cache 的账。