前段时间我一直在折腾 24G 显存单机跑 Qwen 3.8 27b 这件事配置是 RTX 3090 24G、64G 内存、Ubuntu 22.04。实话实说作为一个开源免费、适合单机本地运行的模型27B 这个体量非常讨喜能力明显强过 7B/14B又没到 70B 那种必须双卡、大内存才能碰的地步。但 24G 显存放在 27B 模型面前刚上手是非常难受的模型加载一次 OOM 一次改参数调到吐最后才跑得相对顺手。这篇文章就是把我的优化经验完整落下来重点不是“装一个模型”而是告诉你每一步为什么要这么选、参数为什么这么调适合手里已经有 24G 卡、准备把本地大模型当主力工具用的人。先说结论24G 显存跑 27B绝不是把模型下载下来双击加载就行。你真正要解决的问题有三个权重怎么量化、上下文开多大、显存不够时让 CPU 和内存分担多少。这三个问题如果只盯着某一个其他两个迟早给你埋雷。1. 先算显存账27B 模型到底吃多少显存1.1 权重的三个档位FP16、INT8、INT4很多人第一次下载模型直接选了默认的 FP16/BF16 权重然后加载就报显存不足心里还在想“我不是 24G 吗怎么一个 27B 都放不下”。这里要明确一个最基本的计算逻辑27B 表示参数数量约 270 亿FP16 精度下每个参数占 2 字节那你可以在显存里跑起来仅权重就需要 54GB。一张 24G 卡连一半都装不进去。所以量化不是可选项是必选项。量化就是把模型参数用更低精度表示27B 参数量在 INT8 下是约 27GBINT4 下大约是 13.5GB 到 16GB 之间视量化方法不同浮动。只有降到 INT424G 显存才能真正有余量去放其他东西。这一步想明白后后续所有配置都是围绕“如何让 INT4 权重和运行时缓存都塞进 24G”来展开的。不过很多人会在这里产生一个误解觉得量化越低效果越差。实际情况是27B 模型量化到 INT4 之后语言理解、代码生成、普通问答的能力损失远没有想象中明显除非你拿非常精确的数学推理或者复杂逻辑测试去硬刚。如果你追求的是“能本地跑起来、能日常用”INT4 是性价比最高的起点。1.2 除了权重还有三块你没注意到的显存开销权重只是显存的大头不是全部。很多人在模型加载完后发现显存占用已经很高了但一发起对话又 OOM原因就是忽略了三块额外开销。第一块是 KV Cache。每一次对话模型都要把历史 token 的 Key 和 Value 缓存下来供后续注意力计算使用这部分显存占用随上下文长度线性增长。对于 27B 量级的模型即便是带 GQA 优化的版本在几千 token 上下文的场景下KV Cache 也可能吃掉 2GB 到 5GB 甚至更多。你要是一直把上下文长度拉到 32KKV Cache 本身就能把显存吃得只剩零头。第二块是中间激活值。推理时每一层计算都会产生临时张量占用大小和 batch size、序列长度强相关。虽然量化模型通常会在 GPU 里做反量化后计算临时占用单 batch 可能不是特别夸张但一旦你并发多个请求或者单条消息包含超长输入这部分就会像餐后甜点一样在你以为显存还很够的时候悄悄顶到上限。第三块是框架预留。比如 vLLM 在启动时会根据gpu-memory-utilization和max-model-len预先申请大量显存作为 KV Cache 池。你明明只是简单聊天它也会把能申请的都申请走这属于正常现象但如果你不懂它的逻辑就很容易被表面数字吓到或者反过来胡乱调参导致真正 OOM。1.3 24G 卡的安全线大概在哪里我自己在实际测试中总结了一个简单判断24G 显卡上模型加载完并进入待命状态后nvidia-smi里显示的占用如果超过 22GB就非常危险。因为你不知道什么时候用户会突然发一段长文本或者多轮对话累积起来让 KV Cache 二次膨胀。建议把安全线压在 21GB 以内留出至少 2GB 到 3GB 的动态余量。基于这条安全线我对普通用户推荐的起步配置就很明确了INT4 量化模型初始上下文长度控制在 8192 左右。如果显存占用还有富余再考虑拉长上下文如果已经快到 22GB优先降上下文而不是继续往显存里塞东西。2. 量化方案与加载选型GGUF、GPTQ、AWQ 到底怎么选2.1 先搞清楚你属于哪类用户针对本地部署目前主流方案基本是 GGUF 系和 GPTQ/AWQ 系两条路线两者不冲突但适用场景差异明显。GGUF 是 llama.cpp 生态的格式优势是灵活、能非常精细地控制多少层放在 GPU、多少层放 CPU甚至可以把整个模型跑在 CPU 内存里只要有耐心。Ollama 底层也基本是这套体系适合想快速搭一个能用的本地服务、不想折腾基础设施的人。GPTQ 和 AWQ 则更偏服务化推理它们早期就是给 GPU 推理框架设计的vLLM、SGLang 这些对 GPTQ 支持比较成熟适合要做并发、要做高吞吐、可能还要接 API 的场景。如果你只是想自己对话玩这两个方案也能用但前置处理明显比 GGUF 麻烦。2.2 一张表把常见配置说清楚我在 24G 显卡上把几种常见加载方式的显存占用和体验列成了表方便你对着选加载方式权重体积预估24G 显存上的实际难度推荐用途FP16/BF16约 54GB完全不可行至少需要 64G 显存的服务器INT8约 27GB权重已经接近 24G几乎没有余量不建议在 24G 卡上尝试GPTQ/AWQ INT4约 14-16GB可行需要控制上下文服务化部署、并发请求首选GGUF Q4_K_M约 14-16GB可行且可 CPU/GPU 灵活分配个人本地使用首选GGUF Q5/Q6约 17-20GB可行但上下文稍长就紧张对质量敏感、上下文需求低从这张表能看出真正在 24G 卡上体验好的区域就是 INT4 那一条。我自己最终留在本地的默认模型也是 GGUF Q4_K_M而不是 Q5 或 Q6原因很简单Q5/Q6 虽然质量略好但在 24G 卡上需要挤压上下文空间最后换来的一点质量提升远不如 KV Cache 不足导致的长文本崩坏问题来得影响大。2.3 不要盲目追求“更好的量化精度”有一个误区我觉得必须单独拿出来说。很多人觉得量化越低越烂于是死守 Q8、Q6然后发现上下文只能开 2048稍微多聊几句就忘事。这种“精度执念”在 24G 显卡上是反效果。你可以换个角度想27B 模型本来就是为了处理复杂任务而存在的如果因为显存限制只能保留 2048 上下文那模型根本没机会容纳足够的历史信息这个损失远大于 INT4 本身带来的几个百分点精度下降。在实际使用中Q4_K_M 8K 上下文的综合体验明显优于 Q6 2K 上下文。量化丢的是参数精度上下文不够丢的是功能完整性两者不可同日而语。另外如果你是跑 vLLM 服务化部署现在很多量化版模型直接标注了 GPTQ-Int4 或 AWQ下载对应版本后框架会自动识别量化格式不需要你额外准备什么。别下个 FP16 原版然后指望 vLLM 在加载时实时量化那不是它的工作方式内存和显存照样会爆。3. 两条主流落地路线llama.cpp 灵活换层vLLM 服务化提速3.1 llama.cpp 系GPU 层数怎么调才算准走 GGUF 路线的朋友几乎都会遇到一个参数叫-ngl或者--n-gpu-layers中文社区常叫“GPU 层数”。它代表把模型的前多少层放在 GPU 上计算剩下的层放在 CPU 上。理论上层数越高用 GPU 越多速度越快但在显存不够时你不能盲目设成 999。我自己测试的经验是24G 卡 27B Q4_K_M 8K 上下文如果 CPU 内存足够可以尝试把全部层都放到 GPU也就是-ngl 99。加载成功后显存大概在 18GB 到 21GB 之间日常推理速度可以跑到 13 到 20 token/s这个速度对个人对话来说已经很舒服了。如果加载时报 CUDA out of memory说明剩余显存不够这时候不要急着把上下文砍成 1024而是先把层数往下调。具体调多少取决于你模型的总层数比如 64 层的模型可以先试-ngl 56再不行就降到-ngl 48。每降一层大约能释放几百 MB 显存但代价是推理速度会下降具体下降幅度取决于 CPU 内存带宽。有人用 DDR4 内存跑 CPU offload速度会从 15 token/s 掉到 5 token/s 以下这个体验差距需要提前有心理准备。我实际建议初学者别直接上手裸 llama.cpp先用 Ollama 这类封装好的工具跑起来再说。Ollama 会自动检测显存使用情况并决定多少层放在 GPU适合快速验证。等你真需要精细调参了再回到 llama.cpp 命令行。下面是我在 llama.cpp 环境下的一个启动示例./llama-server \ -m ./models/Qwen3-27B-Q4_K_M.gguf \ -ngl 60 \ --ctx-size 8192 \ --host 0.0.0.0 \ --port 8080日志里如果显示类似offloaded 60/64 layers to GPU说明有 60 层真正跑在显卡上。启动后建议马上打开另一个终端执行nvidia-smi看显存占用如果数字长期贴着 22GB还是建议你往下微调层数给自己留点缓冲。注意-ngl设得过高但只要没触发 OOM不代表万事大吉。它只表示模型加载成功运行时的 KV Cache 和激活值仍可能让显存继续上涨。所以我在调整时从来不看“能不能加载”而是看“加载完只剩几个 GB”。3.2 vLLM 系别被大的上下文选项“骗”了如果你打算把模型跑成一个 OpenAI 兼容接口供多个人或上层应用调用vLLM 是很合适的选择。它的吞吐能力、连续批处理、前缀缓存都很成熟但 24G 显卡跑 27B 需要更严格地管理参数。我用 vLLM 时的参考启动命令大概是python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen3-27B-GPTQ-Int4 \ --quantization gptq \ --gpu-memory-utilization 0.95 \ --max-model-len 8192 \ --max-num-seqs 4 \ --enable-prefix-caching这里最容易被忽略的是gpu-memory-utilization和max-model-len的联动关系。vLLM 启动时会根据这个比例预留显存作为 KV Cache 池你设了 0.95它就可能把 24G 中的几乎所有显存都纳入管理。但如果这时候max-model-len设得很大比如 32768它可能会预留一个巨大但暂时用不满的 KV Cache 池导致系统为了安全而拒绝加载或是在启动之后稍微并几个请求就触顶。所以我的习惯是方案上先定一个你真正需要的最大上下文长度比如日常聊天 8192 足够了那么max-model-len就设 8192。不要给 vLLM 超过需求的上下文预算。max-num-seqs同理如果只是自己用4 个并发已经很多设成 16 反而会放大 KV Cache 池的总需求。GPTQ/AWQ 模型在 vLLM 下能发挥接近原版的推理速度实测单请求生成速度不比 llama.cpp 慢但在连续请求压力下优势明显。如果你后续想把本地模型接进自动化脚本或者做 RAG 应用vLLM 的 OpenAI 兼容接口会省很多事情。3.3 显存不足时的兜底逻辑CPU 内存和 offload即便做了 INT4 量化如果你的目标是长上下文或多轮复杂对话显存照样会不够。这时候最实在的兜底方案就是把部分权重和 KV Cache 放到系统内存里也就是 offload。专业一点叫 CPU offload 或异构推理。不过这里要泼一盆冷水offload 不是越多越好。GPU 和 CPU 之间的数据搬运带宽远低于 GPU 显存带宽一旦大量权重放在系统内存里每生成一个 token 都可能要跨 PCIe 搬运速度会瞬间拉垮。我自己测试过如果 24G 卡把全部权重塞进去后只 offload 10% 到 20% 的层速度损失可能在 20% 左右还能接受如果 offload 一半以上的层生成速度能掉到 2 到 5 token/s基本上就只能接受“让它慢慢算”的现实了。所以我对 offload 的建议优先级是先量化再压上下文最后才考虑 offload。只有在上下文长度确实不能降、而且你能忍受速度下降的时候才去配置 GPU 和 CPU 的分层比例。系统内存至少要有 32GB最好 64GB 以上否则 offload 过程中会出现新的内存瓶颈。4. 现场实操从启动到接口测试完整走一遍4.1 我的实际运行环境先说我的硬件软件配置方便你对照参考GPUNVIDIA RTX 3090 24GCPUAMD Ryzen 9 5900X内存64GB DDR4 3200MHz系统Ubuntu 22.04 LTSCUDA 驱动12.2推理框架llama.cpp 最新 release vLLM两套都试过RTX 3090 和 RTX 4090 同为 24G 显存但在推理速度上 4090 会明显更强因为显存带宽更高、Tensor Core 更强。不过两者在显存占用和 OOM 边界上基本一致所以本文的参数在 4090 上同样适用。4.2 用 GGUF 跑通第一轮对话我下载好 Qwen3-27B-Q4_K_M.gguf 后第一步并不是直接启动服务而是先看一眼文件大小确认它是 14-16GB 左右。如果下载下来的是 50GB 以上那说明文件选错了后续所有优化都无法生效。确认没问题后我先用比较保守的参数启动./llama-server \ -m ./models/Qwen3-27B-Q4_K_M.gguf \ -ngl 99 \ --ctx-size 8192 \ --host 0.0.0.0 \ --port 8080启动日志如果正常会输出类似“模型加载完成、显存占用多少、KV Cache 大小”的信息。我第一次跑的时候显存占用在 20GB 左右GPU 利用率平时很低只有生成 token 时才会跳起来。用 8K 上下文连续对话几轮后显存也没出现明显爆涨说明这套配置确实站得住。为了排除运气因素我还对模型做了一个最小烟雾测试让它写一段 Redis 实现排行榜的代码然后逐步追问缓存策略、持久化方案、并发安全问题。一连串追问下来上下文长度从 1000 涨到 4000 多显存依然稳定在 21GB 以内说明我的安全线没有白留。4.3 用 OpenAI 兼容接口做验证llama.cpp 启动后默认会提供一个 OpenAI 兼容的 HTTP 接口可以非常方便地用 Python 调用验证。我的测试脚本大概是这样的from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8080/v1, api_keyEMPTY, ) resp client.chat.completions.create( modelqwen3.8-27b, messages[ {role: system, content: 你是一个严谨的技术助手。}, {role: user, content: 解释一下什么是 KV Cache以及它为什么影响显存。}, ], max_tokens512, temperature0.7, ) print(resp.choices[0].message.content)第一次调用时我特意设置了max_tokens512没有给太大因为我想先确认生成过程中显存会不会出现剧烈波动。实测输出非常流畅单 token 生成速度在 15 到 18 token/s 左右已经足够拿来做日常问答工具。如果你不想写 Python直接用 curl 也能测curl http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen3.8-27b, messages: [{role: user, content: 你好用一句话说明你是谁。}], max_tokens: 200 }4.4 显存观测和动态调整跑起来之后我习惯每隔一段时间就执行一次nvidia-smi重点看“已用显存”和“GPU 利用率”两列。如果已用显存长期超过 22GB我会选择重启服务把上下文从 8192 降到 4096或者把-ngl往下调几层而不是放任它继续运行。因为本地推理不像云服务那样有完善的自动扩容机制OOM 后进程直接崩溃所有会话就断了。对于 vLLM 版本我更关注的是启动时输出的 KV Cache 预留量。如果它告诉我预留了 6GB而权重和 CUDA context 已经把显存顶到 23GB那就马上调低max-model-len这是最直接的止血手段。5. 各种坑的记录与解决思路5.1 现象一模型加载直接报 CUDA out of memory这个是最常见的坑原因多半不是 GPU 不够“好”而是你给的上下文预算太大或者显存被其他进程吃了。排查顺序我建议是先看nvidia-smi确认有没有残留的 Python 进程、其他推理服务占用显存。然后看自己的启动参数有没有把上下文长度设到 16K 甚至 32K。最后再考虑是不是-ngl太高。如果只是自己玩没必要追求一次加载后生成一万个 token。我把同一个人日常聊天用的模型上下文调到 8192 或 4096几乎不会再碰到加载即崩的情况。5.2 现象二速度慢到像假死CPU 却满占用出现这种情况大概率是权重被大量 offload 到了系统内存推理时 CPU 在做大量计算而 GPU 反而在空等。你可以看看 llama.cpp 日志里的层数分配如果 GPU 上只有二三十层那速度肯定快不了。解决方式是提高-ngl值让更多层回到 GPU。但如果你已经把能放的层都放了还这么慢那就只能从模型侧下手换更低的量化版本比如从 Q6 换到 Q4_K_M或者把上下文长度继续压低给模型权重腾出更多 GPU 空间。还有一个小技巧是使用--batch-size 512这类参数让 prompt 处理阶段更快但对生成阶段的速度帮助有限。5.3 现象三显存看起来够用一段时间后突然 OOM这种最典型的原因是长对话累积的 KV Cache 超过预期。很多本地推理框架虽然会根据显存动态管理 KV Cache但如果你的上下文从 3000 涨到 7000而显存又只留了 1GB 余量那就会在某个临界点爆掉。我的破法是主动限制上下文而不是指望框架自动清理。在 llama.cpp 里我设置--ctx-size 8192同时在应用层控制对话历史不要无限增长比如用截断策略只保留最近十轮消息。对采用 vLLM 的朋友建议打开--enable-prefix-caching它可以缓存系统提示词等重复前缀减少不必要的重复计算和显存占用。5.4 一张速查表帮我快速定位问题现象最可能原因第一推荐解法备选解法启动即 OOM上下文设太大或权重非量化把 max-model-len / ctx-size 降到 4096换 INT4 量化模型显存持续偏高-ngl 拉满导致余量过少往下调 4 到 8 层降低上下文生成速度很慢大量层在 CPU 上计算提高 -ngl限制 offload升级内存带宽用一段时间后 OOMKV Cache 涨超显存限制对话历史轮数重启服务释放缓存vLLM 启动报显存不够gpu-memory-utilization 太高降到 0.92 左右减小 max-model-len输出重复或乱码温度过高或量化过度把 temperature 降到 0.7换 Q4_K_M 或更高量化5.5 我的个人教训踩了这么多坑之后我现在给本地 24G 显卡跑 27B 模型定了一个很朴素的基线基本上遇到新问题都会先回到这个基线上排查模型用 GGUF Q4_K_M 或者 GPTQ-Int4上下文长度默认 8192加载后显存占用控制在 20GB 到 21GB 之间速度低于 8 token/s 就认为配置有问题。这套基线不一定适合所有人但它能帮你快速区分是模型问题、框架问题还是硬件资源问题不会在稀里糊涂的调参中浪费一晚上。如果你也想在 24G 显卡上跑 Qwen 3.8 27b我建议你先不要抄任何花哨配置顺着这个流程走一遍确认权重是 INT4 量化版本设置上下文 8192先让模型成功跑一轮对话再根据nvidia-smi的数据去微调层数和并发参数。只要它能在 20GB 到 21GB 的水平稳定运行你已经超过了 90% 第一次尝试就放弃卡在 OOM 里的人。后面如果你还想进一步优化再考虑 RAG、函数调用、多轮会话管理这些进阶玩法那又是另一个值得深入的话题了。 24G显存跑27B大模型：量化、上下文与显存分配实战优化指南
前段时间我一直在折腾 24G 显存单机跑 Qwen 3.8 27b 这件事配置是 RTX 3090 24G、64G 内存、Ubuntu 22.04。实话实说作为一个开源免费、适合单机本地运行的模型27B 这个体量非常讨喜能力明显强过 7B/14B又没到 70B 那种必须双卡、大内存才能碰的地步。但 24G 显存放在 27B 模型面前刚上手是非常难受的模型加载一次 OOM 一次改参数调到吐最后才跑得相对顺手。这篇文章就是把我的优化经验完整落下来重点不是“装一个模型”而是告诉你每一步为什么要这么选、参数为什么这么调适合手里已经有 24G 卡、准备把本地大模型当主力工具用的人。先说结论24G 显存跑 27B绝不是把模型下载下来双击加载就行。你真正要解决的问题有三个权重怎么量化、上下文开多大、显存不够时让 CPU 和内存分担多少。这三个问题如果只盯着某一个其他两个迟早给你埋雷。1. 先算显存账27B 模型到底吃多少显存1.1 权重的三个档位FP16、INT8、INT4很多人第一次下载模型直接选了默认的 FP16/BF16 权重然后加载就报显存不足心里还在想“我不是 24G 吗怎么一个 27B 都放不下”。这里要明确一个最基本的计算逻辑27B 表示参数数量约 270 亿FP16 精度下每个参数占 2 字节那你可以在显存里跑起来仅权重就需要 54GB。一张 24G 卡连一半都装不进去。所以量化不是可选项是必选项。量化就是把模型参数用更低精度表示27B 参数量在 INT8 下是约 27GBINT4 下大约是 13.5GB 到 16GB 之间视量化方法不同浮动。只有降到 INT424G 显存才能真正有余量去放其他东西。这一步想明白后后续所有配置都是围绕“如何让 INT4 权重和运行时缓存都塞进 24G”来展开的。不过很多人会在这里产生一个误解觉得量化越低效果越差。实际情况是27B 模型量化到 INT4 之后语言理解、代码生成、普通问答的能力损失远没有想象中明显除非你拿非常精确的数学推理或者复杂逻辑测试去硬刚。如果你追求的是“能本地跑起来、能日常用”INT4 是性价比最高的起点。1.2 除了权重还有三块你没注意到的显存开销权重只是显存的大头不是全部。很多人在模型加载完后发现显存占用已经很高了但一发起对话又 OOM原因就是忽略了三块额外开销。第一块是 KV Cache。每一次对话模型都要把历史 token 的 Key 和 Value 缓存下来供后续注意力计算使用这部分显存占用随上下文长度线性增长。对于 27B 量级的模型即便是带 GQA 优化的版本在几千 token 上下文的场景下KV Cache 也可能吃掉 2GB 到 5GB 甚至更多。你要是一直把上下文长度拉到 32KKV Cache 本身就能把显存吃得只剩零头。第二块是中间激活值。推理时每一层计算都会产生临时张量占用大小和 batch size、序列长度强相关。虽然量化模型通常会在 GPU 里做反量化后计算临时占用单 batch 可能不是特别夸张但一旦你并发多个请求或者单条消息包含超长输入这部分就会像餐后甜点一样在你以为显存还很够的时候悄悄顶到上限。第三块是框架预留。比如 vLLM 在启动时会根据gpu-memory-utilization和max-model-len预先申请大量显存作为 KV Cache 池。你明明只是简单聊天它也会把能申请的都申请走这属于正常现象但如果你不懂它的逻辑就很容易被表面数字吓到或者反过来胡乱调参导致真正 OOM。1.3 24G 卡的安全线大概在哪里我自己在实际测试中总结了一个简单判断24G 显卡上模型加载完并进入待命状态后nvidia-smi里显示的占用如果超过 22GB就非常危险。因为你不知道什么时候用户会突然发一段长文本或者多轮对话累积起来让 KV Cache 二次膨胀。建议把安全线压在 21GB 以内留出至少 2GB 到 3GB 的动态余量。基于这条安全线我对普通用户推荐的起步配置就很明确了INT4 量化模型初始上下文长度控制在 8192 左右。如果显存占用还有富余再考虑拉长上下文如果已经快到 22GB优先降上下文而不是继续往显存里塞东西。2. 量化方案与加载选型GGUF、GPTQ、AWQ 到底怎么选2.1 先搞清楚你属于哪类用户针对本地部署目前主流方案基本是 GGUF 系和 GPTQ/AWQ 系两条路线两者不冲突但适用场景差异明显。GGUF 是 llama.cpp 生态的格式优势是灵活、能非常精细地控制多少层放在 GPU、多少层放 CPU甚至可以把整个模型跑在 CPU 内存里只要有耐心。Ollama 底层也基本是这套体系适合想快速搭一个能用的本地服务、不想折腾基础设施的人。GPTQ 和 AWQ 则更偏服务化推理它们早期就是给 GPU 推理框架设计的vLLM、SGLang 这些对 GPTQ 支持比较成熟适合要做并发、要做高吞吐、可能还要接 API 的场景。如果你只是想自己对话玩这两个方案也能用但前置处理明显比 GGUF 麻烦。2.2 一张表把常见配置说清楚我在 24G 显卡上把几种常见加载方式的显存占用和体验列成了表方便你对着选加载方式权重体积预估24G 显存上的实际难度推荐用途FP16/BF16约 54GB完全不可行至少需要 64G 显存的服务器INT8约 27GB权重已经接近 24G几乎没有余量不建议在 24G 卡上尝试GPTQ/AWQ INT4约 14-16GB可行需要控制上下文服务化部署、并发请求首选GGUF Q4_K_M约 14-16GB可行且可 CPU/GPU 灵活分配个人本地使用首选GGUF Q5/Q6约 17-20GB可行但上下文稍长就紧张对质量敏感、上下文需求低从这张表能看出真正在 24G 卡上体验好的区域就是 INT4 那一条。我自己最终留在本地的默认模型也是 GGUF Q4_K_M而不是 Q5 或 Q6原因很简单Q5/Q6 虽然质量略好但在 24G 卡上需要挤压上下文空间最后换来的一点质量提升远不如 KV Cache 不足导致的长文本崩坏问题来得影响大。2.3 不要盲目追求“更好的量化精度”有一个误区我觉得必须单独拿出来说。很多人觉得量化越低越烂于是死守 Q8、Q6然后发现上下文只能开 2048稍微多聊几句就忘事。这种“精度执念”在 24G 显卡上是反效果。你可以换个角度想27B 模型本来就是为了处理复杂任务而存在的如果因为显存限制只能保留 2048 上下文那模型根本没机会容纳足够的历史信息这个损失远大于 INT4 本身带来的几个百分点精度下降。在实际使用中Q4_K_M 8K 上下文的综合体验明显优于 Q6 2K 上下文。量化丢的是参数精度上下文不够丢的是功能完整性两者不可同日而语。另外如果你是跑 vLLM 服务化部署现在很多量化版模型直接标注了 GPTQ-Int4 或 AWQ下载对应版本后框架会自动识别量化格式不需要你额外准备什么。别下个 FP16 原版然后指望 vLLM 在加载时实时量化那不是它的工作方式内存和显存照样会爆。3. 两条主流落地路线llama.cpp 灵活换层vLLM 服务化提速3.1 llama.cpp 系GPU 层数怎么调才算准走 GGUF 路线的朋友几乎都会遇到一个参数叫-ngl或者--n-gpu-layers中文社区常叫“GPU 层数”。它代表把模型的前多少层放在 GPU 上计算剩下的层放在 CPU 上。理论上层数越高用 GPU 越多速度越快但在显存不够时你不能盲目设成 999。我自己测试的经验是24G 卡 27B Q4_K_M 8K 上下文如果 CPU 内存足够可以尝试把全部层都放到 GPU也就是-ngl 99。加载成功后显存大概在 18GB 到 21GB 之间日常推理速度可以跑到 13 到 20 token/s这个速度对个人对话来说已经很舒服了。如果加载时报 CUDA out of memory说明剩余显存不够这时候不要急着把上下文砍成 1024而是先把层数往下调。具体调多少取决于你模型的总层数比如 64 层的模型可以先试-ngl 56再不行就降到-ngl 48。每降一层大约能释放几百 MB 显存但代价是推理速度会下降具体下降幅度取决于 CPU 内存带宽。有人用 DDR4 内存跑 CPU offload速度会从 15 token/s 掉到 5 token/s 以下这个体验差距需要提前有心理准备。我实际建议初学者别直接上手裸 llama.cpp先用 Ollama 这类封装好的工具跑起来再说。Ollama 会自动检测显存使用情况并决定多少层放在 GPU适合快速验证。等你真需要精细调参了再回到 llama.cpp 命令行。下面是我在 llama.cpp 环境下的一个启动示例./llama-server \ -m ./models/Qwen3-27B-Q4_K_M.gguf \ -ngl 60 \ --ctx-size 8192 \ --host 0.0.0.0 \ --port 8080日志里如果显示类似offloaded 60/64 layers to GPU说明有 60 层真正跑在显卡上。启动后建议马上打开另一个终端执行nvidia-smi看显存占用如果数字长期贴着 22GB还是建议你往下微调层数给自己留点缓冲。注意-ngl设得过高但只要没触发 OOM不代表万事大吉。它只表示模型加载成功运行时的 KV Cache 和激活值仍可能让显存继续上涨。所以我在调整时从来不看“能不能加载”而是看“加载完只剩几个 GB”。3.2 vLLM 系别被大的上下文选项“骗”了如果你打算把模型跑成一个 OpenAI 兼容接口供多个人或上层应用调用vLLM 是很合适的选择。它的吞吐能力、连续批处理、前缀缓存都很成熟但 24G 显卡跑 27B 需要更严格地管理参数。我用 vLLM 时的参考启动命令大概是python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen3-27B-GPTQ-Int4 \ --quantization gptq \ --gpu-memory-utilization 0.95 \ --max-model-len 8192 \ --max-num-seqs 4 \ --enable-prefix-caching这里最容易被忽略的是gpu-memory-utilization和max-model-len的联动关系。vLLM 启动时会根据这个比例预留显存作为 KV Cache 池你设了 0.95它就可能把 24G 中的几乎所有显存都纳入管理。但如果这时候max-model-len设得很大比如 32768它可能会预留一个巨大但暂时用不满的 KV Cache 池导致系统为了安全而拒绝加载或是在启动之后稍微并几个请求就触顶。所以我的习惯是方案上先定一个你真正需要的最大上下文长度比如日常聊天 8192 足够了那么max-model-len就设 8192。不要给 vLLM 超过需求的上下文预算。max-num-seqs同理如果只是自己用4 个并发已经很多设成 16 反而会放大 KV Cache 池的总需求。GPTQ/AWQ 模型在 vLLM 下能发挥接近原版的推理速度实测单请求生成速度不比 llama.cpp 慢但在连续请求压力下优势明显。如果你后续想把本地模型接进自动化脚本或者做 RAG 应用vLLM 的 OpenAI 兼容接口会省很多事情。3.3 显存不足时的兜底逻辑CPU 内存和 offload即便做了 INT4 量化如果你的目标是长上下文或多轮复杂对话显存照样会不够。这时候最实在的兜底方案就是把部分权重和 KV Cache 放到系统内存里也就是 offload。专业一点叫 CPU offload 或异构推理。不过这里要泼一盆冷水offload 不是越多越好。GPU 和 CPU 之间的数据搬运带宽远低于 GPU 显存带宽一旦大量权重放在系统内存里每生成一个 token 都可能要跨 PCIe 搬运速度会瞬间拉垮。我自己测试过如果 24G 卡把全部权重塞进去后只 offload 10% 到 20% 的层速度损失可能在 20% 左右还能接受如果 offload 一半以上的层生成速度能掉到 2 到 5 token/s基本上就只能接受“让它慢慢算”的现实了。所以我对 offload 的建议优先级是先量化再压上下文最后才考虑 offload。只有在上下文长度确实不能降、而且你能忍受速度下降的时候才去配置 GPU 和 CPU 的分层比例。系统内存至少要有 32GB最好 64GB 以上否则 offload 过程中会出现新的内存瓶颈。4. 现场实操从启动到接口测试完整走一遍4.1 我的实际运行环境先说我的硬件软件配置方便你对照参考GPUNVIDIA RTX 3090 24GCPUAMD Ryzen 9 5900X内存64GB DDR4 3200MHz系统Ubuntu 22.04 LTSCUDA 驱动12.2推理框架llama.cpp 最新 release vLLM两套都试过RTX 3090 和 RTX 4090 同为 24G 显存但在推理速度上 4090 会明显更强因为显存带宽更高、Tensor Core 更强。不过两者在显存占用和 OOM 边界上基本一致所以本文的参数在 4090 上同样适用。4.2 用 GGUF 跑通第一轮对话我下载好 Qwen3-27B-Q4_K_M.gguf 后第一步并不是直接启动服务而是先看一眼文件大小确认它是 14-16GB 左右。如果下载下来的是 50GB 以上那说明文件选错了后续所有优化都无法生效。确认没问题后我先用比较保守的参数启动./llama-server \ -m ./models/Qwen3-27B-Q4_K_M.gguf \ -ngl 99 \ --ctx-size 8192 \ --host 0.0.0.0 \ --port 8080启动日志如果正常会输出类似“模型加载完成、显存占用多少、KV Cache 大小”的信息。我第一次跑的时候显存占用在 20GB 左右GPU 利用率平时很低只有生成 token 时才会跳起来。用 8K 上下文连续对话几轮后显存也没出现明显爆涨说明这套配置确实站得住。为了排除运气因素我还对模型做了一个最小烟雾测试让它写一段 Redis 实现排行榜的代码然后逐步追问缓存策略、持久化方案、并发安全问题。一连串追问下来上下文长度从 1000 涨到 4000 多显存依然稳定在 21GB 以内说明我的安全线没有白留。4.3 用 OpenAI 兼容接口做验证llama.cpp 启动后默认会提供一个 OpenAI 兼容的 HTTP 接口可以非常方便地用 Python 调用验证。我的测试脚本大概是这样的from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8080/v1, api_keyEMPTY, ) resp client.chat.completions.create( modelqwen3.8-27b, messages[ {role: system, content: 你是一个严谨的技术助手。}, {role: user, content: 解释一下什么是 KV Cache以及它为什么影响显存。}, ], max_tokens512, temperature0.7, ) print(resp.choices[0].message.content)第一次调用时我特意设置了max_tokens512没有给太大因为我想先确认生成过程中显存会不会出现剧烈波动。实测输出非常流畅单 token 生成速度在 15 到 18 token/s 左右已经足够拿来做日常问答工具。如果你不想写 Python直接用 curl 也能测curl http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen3.8-27b, messages: [{role: user, content: 你好用一句话说明你是谁。}], max_tokens: 200 }4.4 显存观测和动态调整跑起来之后我习惯每隔一段时间就执行一次nvidia-smi重点看“已用显存”和“GPU 利用率”两列。如果已用显存长期超过 22GB我会选择重启服务把上下文从 8192 降到 4096或者把-ngl往下调几层而不是放任它继续运行。因为本地推理不像云服务那样有完善的自动扩容机制OOM 后进程直接崩溃所有会话就断了。对于 vLLM 版本我更关注的是启动时输出的 KV Cache 预留量。如果它告诉我预留了 6GB而权重和 CUDA context 已经把显存顶到 23GB那就马上调低max-model-len这是最直接的止血手段。5. 各种坑的记录与解决思路5.1 现象一模型加载直接报 CUDA out of memory这个是最常见的坑原因多半不是 GPU 不够“好”而是你给的上下文预算太大或者显存被其他进程吃了。排查顺序我建议是先看nvidia-smi确认有没有残留的 Python 进程、其他推理服务占用显存。然后看自己的启动参数有没有把上下文长度设到 16K 甚至 32K。最后再考虑是不是-ngl太高。如果只是自己玩没必要追求一次加载后生成一万个 token。我把同一个人日常聊天用的模型上下文调到 8192 或 4096几乎不会再碰到加载即崩的情况。5.2 现象二速度慢到像假死CPU 却满占用出现这种情况大概率是权重被大量 offload 到了系统内存推理时 CPU 在做大量计算而 GPU 反而在空等。你可以看看 llama.cpp 日志里的层数分配如果 GPU 上只有二三十层那速度肯定快不了。解决方式是提高-ngl值让更多层回到 GPU。但如果你已经把能放的层都放了还这么慢那就只能从模型侧下手换更低的量化版本比如从 Q6 换到 Q4_K_M或者把上下文长度继续压低给模型权重腾出更多 GPU 空间。还有一个小技巧是使用--batch-size 512这类参数让 prompt 处理阶段更快但对生成阶段的速度帮助有限。5.3 现象三显存看起来够用一段时间后突然 OOM这种最典型的原因是长对话累积的 KV Cache 超过预期。很多本地推理框架虽然会根据显存动态管理 KV Cache但如果你的上下文从 3000 涨到 7000而显存又只留了 1GB 余量那就会在某个临界点爆掉。我的破法是主动限制上下文而不是指望框架自动清理。在 llama.cpp 里我设置--ctx-size 8192同时在应用层控制对话历史不要无限增长比如用截断策略只保留最近十轮消息。对采用 vLLM 的朋友建议打开--enable-prefix-caching它可以缓存系统提示词等重复前缀减少不必要的重复计算和显存占用。5.4 一张速查表帮我快速定位问题现象最可能原因第一推荐解法备选解法启动即 OOM上下文设太大或权重非量化把 max-model-len / ctx-size 降到 4096换 INT4 量化模型显存持续偏高-ngl 拉满导致余量过少往下调 4 到 8 层降低上下文生成速度很慢大量层在 CPU 上计算提高 -ngl限制 offload升级内存带宽用一段时间后 OOMKV Cache 涨超显存限制对话历史轮数重启服务释放缓存vLLM 启动报显存不够gpu-memory-utilization 太高降到 0.92 左右减小 max-model-len输出重复或乱码温度过高或量化过度把 temperature 降到 0.7换 Q4_K_M 或更高量化5.5 我的个人教训踩了这么多坑之后我现在给本地 24G 显卡跑 27B 模型定了一个很朴素的基线基本上遇到新问题都会先回到这个基线上排查模型用 GGUF Q4_K_M 或者 GPTQ-Int4上下文长度默认 8192加载后显存占用控制在 20GB 到 21GB 之间速度低于 8 token/s 就认为配置有问题。这套基线不一定适合所有人但它能帮你快速区分是模型问题、框架问题还是硬件资源问题不会在稀里糊涂的调参中浪费一晚上。如果你也想在 24G 显卡上跑 Qwen 3.8 27b我建议你先不要抄任何花哨配置顺着这个流程走一遍确认权重是 INT4 量化版本设置上下文 8192先让模型成功跑一轮对话再根据nvidia-smi的数据去微调层数和并发参数。只要它能在 20GB 到 21GB 的水平稳定运行你已经超过了 90% 第一次尝试就放弃卡在 OOM 里的人。后面如果你还想进一步优化再考虑 RAG、函数调用、多轮会话管理这些进阶玩法那又是另一个值得深入的话题了。