单卡4090部署27B大模型：量化、推理框架与显存优化实战

1. 为什么要在单卡4090上跑27B级别的模型

先说结论：单张RTX 4090的24GB显存，跑一个270亿参数级别的模型，在FP16精度下是绝对放不下的。这不是调参能解决的问题，是物理层面的硬约束。很多人第一次尝试本地部署大模型时，看到"27B"这个数字觉得"应该还行"，结果加载到一半就爆显存，然后开始怀疑是不是驱动有问题、CUDA版本不对、框架有bug——其实都不是，就是显存不够。

那为什么还要选这个组合？因为量化。把模型权重从FP16压缩到4bit或8bit，显存占用能降到原来的四分之一到一半。27B模型在4bit量化下，权重部分大约需要14-15GB显存，加上KV Cache和推理框架本身的开销，24GB刚好能兜住。这就是单卡4090跑27B模型的可行性基础。

但"能跑"和"跑得好"是两回事。我见过太多人量化完之后发现输出质量断崖式下跌，或者推理速度慢到没法用，又或者上下文一长就OOM。这些问题背后都有具体的技术原因，不是玄学。

选择本地部署而不是调用云端API，核心动机通常有三个：数据不出本地、推理成本可控、可定制化程度高。对于科研和工程场景来说，第一个尤其关键。实验数据、代码资产、内部文档这些东西，很多时候是不允许上传到外部服务的。本地部署意味着从模型权重到推理过程全部在自己的机器上完成，没有任何数据外流的风险。

注意：本地部署的"保密"是相对的。模型本身如果是开源权重，那权重来源是公开的；但你的输入数据、推理日志、微调数据这些，确实可以做到完全本地化。这一点在选型时要想清楚。

单卡4090的另一个优势是成本。一张4090的价格在消费级显卡里算高的，但对比专业级推理卡，性价比非常突出。对于个人研究者或小团队来说，用一张4090搭建一个能跑27B级别模型的推理环境，总投入是可控的。而且4090的FP16算力（约165 TFLOPS）和显存带宽（约1008 GB/s）在消费级卡里属于第一梯队，推理速度不会太难看。

但这里有个常见的误区：很多人以为显存够大就行，忽略了显存带宽对推理速度的影响。大模型推理是典型的memory-bound任务，每生成一个token都需要把整个模型权重读一遍。4090的带宽虽然不错，但和A100/H100那种服务器级卡比还是有差距。所以单卡4090跑27B模型，速度上要有合理预期——大概在每秒十几个token到几十个token之间，取决于量化精度、上下文长度和推理框架的优化程度。

2. 量化方案的选择：4bit还是8bit，GPTQ还是AWQ

量化是单卡4090跑27B模型的关键技术环节，选错了量化方案，后面所有优化都是白费力气。目前主流的量化方案有几种，各有各的适用场景。

2.1 精度选择：4bit和8bit的取舍

8bit量化（如LLM.int8()）的显存占用大约是FP16的一半，27B模型大概需要14GB左右。听起来很美好，但实际用下来有几个问题：一是推理速度提升不明显，因为8bit的计算需要额外的反量化操作；二是部分实现（如bitsandbytes的8bit）在某些层上仍然会用FP16计算，实际显存占用比理论值高。

4bit量化是目前单卡跑大模型的主流选择。27B模型在4bit下权重占用约14-15GB，留给KV Cache和框架开销的空间大约有8-9GB。这个空间够不够用，取决于你的上下文长度和并发数。如果只是单用户、上下文控制在4K以内，完全够用；如果要跑8K以上的长上下文，就需要仔细调KV Cache的分配策略。

实操心得：4bit量化的质量损失在大多数任务上是可以接受的，但在需要精确数值推理或代码生成的任务上，偶尔会出现"降智"现象。如果发现模型在某个特定任务上表现异常，可以先试试切换到8bit对比一下，确认是不是量化导致的。

2.2 量化算法：GPTQ、AWQ和GGUF的差异

GPTQ和AWQ是目前最主流的两种4bit量化算法。GPTQ出现得早，生态成熟，几乎所有推理框架都支持；AWQ是后来者，核心思路是"激活感知"——在量化时考虑激活值的分布，对重要通道保留更高精度。实测下来，AWQ在相同bit数下的输出质量通常略好于GPTQ，尤其是在小模型上差异更明显。

GGUF是llama.cpp生态的格式，优势是CPU/GPU混合推理和极低的内存占用，但纯GPU推理场景下性能不如GPTQ/AWQ。如果你的场景是"偶尔跑一下，不追求极致速度"，GGUF是个省心的选择；如果追求推理吞吐，还是选GPTQ或AWQ。

2.3 量化校准集的坑

自己做量化的时候，校准集的选择非常关键。校准集是用来估计权重和激活值分布的数据集，如果校准集和实际使用场景的分布差异太大，量化后的模型在你的任务上表现会明显下降。

我踩过的一个坑：用英文通用语料做校准，然后拿去做中文代码生成任务，结果模型在代码补全时经常出现奇怪的符号和语法错误。后来换成中英文混合的代码语料做校准，问题就消失了。所以校准集一定要贴近实际使用场景，宁可小一点、精一点，也不要大而泛。

3. 推理框架的选型与配置细节

量化方案定了之后，下一步是选推理框架。目前单卡4090跑27B模型，主流选择有vLLM、TGI（Text Generation Inference）、llama.cpp和ExLlamaV2。每个框架的定位不同，配置方式差异也很大。

3.1 vLLM：吞吐优先的选择

vLLM的核心优势是PagedAttention，这个技术把KV Cache分成固定大小的块来管理，大幅减少了显存碎片，提升了并发吞吐。如果你需要同时服务多个请求，vLLM基本是首选。

但vLLM对显存的"胃口"比较大。它默认会预分配大部分显存给KV Cache，如果模型权重已经占了15GB，剩下的9GB里vLLM可能直接拿走8GB做缓存。这在单用户场景下是浪费，但可以通过--gpu-memory-utilization参数控制。我一般设成0.85到0.9，留一点余量给系统。

python -m vllm.entrypoints.openai.api_server \ --model /path/to/qwen-27b-awq \ --quantization awq \ --dtype float16 \ --gpu-memory-utilization 0.88 \ --max-model-len 8192 \ --port 8000

这里有几个参数需要解释：--quantization awq告诉vLLM用AWQ反量化；--dtype float16指定计算精度，虽然权重是4bit，但计算时还是用FP16；--max-model-len控制最大上下文长度，设得越大KV Cache占用越多。

注意：vLLM启动时会做一次显存预分配，如果--gpu-memory-utilization设得太高，启动阶段就可能OOM。建议从0.8开始试，稳定后再往上调。

3.2 TGI：生产环境的稳健选择

TGI是HuggingFace推出的推理服务框架，特点是稳定、功能全、和HF生态集成好。它支持连续批处理、token流式输出、多种量化格式，配置项比vLLM更细。

TGI的显存管理策略和vLLM不同，它不会一次性预分配所有显存，而是按需分配。这在单卡场景下更友好，但并发高的时候可能出现显存碎片。TGI的启动命令通常用Docker，配置通过环境变量传入：

docker run --gpus all \ -e MODEL_ID=/models/qwen-27b-awq \ -e QUANTIZE=awq \ -e MAX_INPUT_LENGTH=4096 \ -e MAX_TOTAL_TOKENS=8192 \ -p 8080:80 \ tgi-image

TGI的一个隐藏优势是对量化模型的支持更成熟。AWQ和GPTQ在TGI上的表现通常比vLLM更稳定，尤其是长上下文场景下。

3.3 llama.cpp：灵活但速度妥协

llama.cpp的优势是极致的灵活性——支持CPU+GPU混合推理，GGUF格式的量化选项非常多（从Q2到Q8），而且可以在显存不足时自动把部分层放到CPU上。但纯GPU推理时，llama.cpp的速度通常不如vLLM和TGI，因为它对GPU的优化程度相对低一些。

如果你的场景是"偶尔跑一下，不追求高并发"，llama.cpp的简单直接很有吸引力。启动一个server只需要一行命令：

./llama-server -m /path/to/model.Q4_K_M.gguf \ -ngl 99 \ -c 8192 \ --host 0.0.0.0 --port 8080

-ngl 99表示把所有层都放到GPU上，-c 8192是上下文长度。如果显存不够，把-ngl调小，让部分层跑在CPU上。

3.4 框架选型的决策逻辑

选哪个框架，取决于你的核心需求：

• 要高并发、多用户：vLLM，PagedAttention的吞吐优势明显
• 要稳定、生产级：TGI，配置细、容错好
• 要灵活、低资源：llama.cpp，CPU/GPU混合是独门绝技
• 要极致单请求速度：ExLlamaV2，但生态相对小

我自己的做法是：日常实验用vLLM，因为启动快、API兼容OpenAI格式；对外提供服务用TGI，因为稳定性经过更多验证；应急场景用llama.cpp，因为几乎不会启动失败。

4. 显存精打细算：KV Cache与上下文长度的博弈

单卡4090跑27B模型，显存是稀缺资源。模型权重占了14-15GB之后，剩下的8-9GB要同时容纳KV Cache、推理框架开销和系统预留。KV Cache的大小和上下文长度、批大小、模型层数、注意力头数都有关，算不清楚就很容易OOM。

4.1 KV Cache的显存计算公式

KV Cache的显存占用可以用这个公式估算：

KV Cache大小 = 2 × 层数 × 注意力头数 × 头维度 × 上下文长度 × 批大小 × 精度字节数

以Qwen3.6-27B为例，假设层数约48层，注意力头数约40个，头维度128，FP16精度（2字节）：

• 单token的KV Cache = 2 × 48 × 40 × 128 × 2 = 983,040字节 ≈ 0.94MB
• 4K上下文、批大小1：0.94MB × 4096 ≈ 3.8GB
• 8K上下文、批大小1：0.94MB × 8192 ≈ 7.7GB

看到问题了吗？8K上下文下，KV Cache就要吃掉7.7GB，加上模型权重的15GB，已经22.7GB了，离24GB的红线非常近。这时候任何额外的开销都可能导致OOM。

4.2 降低KV Cache占用的实操手段

有几个手段可以压缩KV Cache：

第一，量化KV Cache。把KV Cache从FP16降到INT8，显存直接减半。vLLM支持--kv-cache-dtype fp8，TGI也有类似选项。代价是长上下文下的注意力精度会下降，但在大多数任务上感知不明显。

第二，使用GQA（分组查询注意力）。如果模型本身支持GQA，KV Cache的占用会大幅降低。Qwen系列的部分模型用了GQA，注意力头数被分组共享，KV Cache能降到原来的几分之一。选模型的时候可以留意这一点。

第三，控制上下文长度。这是最直接的手段。如果任务不需要8K上下文，就设成4K甚至2K。很多科研场景（如单篇论文分析、单个函数生成）根本用不到超长上下文，设大了纯属浪费。

第四，滑动窗口注意力。部分模型支持滑动窗口，只保留最近N个token的KV Cache，老的直接丢弃。这对流式对话场景很有效，但会丢失远距离依赖。

实操心得：我一般会先按最大上下文长度启动，然后观察实际运行时的显存占用。如果发现KV Cache用不满，就把--max-model-len调小，把省下来的显存留给批处理。反过来，如果经常OOM，就先把上下文砍一半试试。

4.3 显存监控与动态调整

跑起来之后，显存监控是必须的。nvidia-smi是最基本的工具，但它的刷新频率有限，看不到瞬时峰值。更细粒度的监控可以用nvidia-smi dmon或者Python的pynvml库。

import pynvml pynvml.nvmlInit() handle = pynvml.nvmlDeviceGetHandleByIndex(0) info = pynvml.nvmlDeviceGetMemoryInfo(handle) print(f"已用: {info.used/1024**3:.2f}GB, 剩余: {info.free/1024**3:.2f}GB")

如果发现显存占用在推理过程中持续上涨，大概率是KV Cache没有正确释放。这在长对话场景下很常见——每轮对话都往KV Cache里追加，但从不清理。解决办法是设置会话超时，或者用支持KV Cache淘汰策略的框架。

5. 从零搭建：环境准备与模型部署的完整链路

前面讲的都是原理和选型，这一节把整个搭建过程串起来。假设你有一张4090，系统是Ubuntu 22.04，目标是跑起来一个能用的27B模型推理服务。

5.1 驱动与CUDA环境

4090需要NVIDIA驱动版本525以上，CUDA版本11.8以上。推荐用CUDA 12.x，对新卡的支持更好。安装驱动最省事的方式是用系统包管理器：

sudo apt update sudo apt install nvidia-driver-535 sudo reboot

重启后验证：

nvidia-smi

看到4090的信息和CUDA版本就说明驱动OK了。注意这里显示的CUDA版本是驱动支持的最高版本，实际用的CUDA Toolkit版本可以不同。

Python环境建议用conda或venv隔离，避免和系统Python冲突。PyTorch要装CUDA版本，不要装CPU版本：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

5.2 模型下载与量化文件准备

如果直接用别人量化好的模型，下载下来就能用。HuggingFace上有很多社区量化版本，AWQ和GPTQ都有。下载的时候注意确认量化配置和推理框架匹配——vLLM用的AWQ和llama.cpp用的GGUF是两套东西，不能混用。

如果自己量化，需要先下载FP16的原始权重，然后用AutoAWQ或GPTQ-for-LLaMa做量化。这个过程比较吃显存，27B模型量化时峰值显存可能超过24GB，建议在显存更大的机器上做，或者用CPU offload。

from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path = "Qwen/Qwen3.6-27B" quant_path = "qwen-27b-awq" model = AutoAWQForCausalLM.from_pretrained(model_path) tokenizer = AutoTokenizer.from_pretrained(model_path) model.quantize(tokenizer, quant_config={"zero_point": True, "q_group_size": 128, "w_bit": 4}) model.save_quantized(quant_path)

q_group_size=128是分组大小，越小量化越精细但文件越大；w_bit=4是4bit量化。这两个参数是AWQ的标配，一般不用改。

5.3 启动推理服务并验证

以vLLM为例，启动服务后先用curl测一下：

curl http://localhost:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen-27b-awq", "prompt": "用Python写一个快速排序", "max_tokens": 256, "temperature": 0.7 }'

如果返回了合理的代码，说明服务正常。然后测一下长上下文：

curl http://localhost:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen-27b-awq", "prompt": "'"$(python -c 'print("测试上下文。" * 2000)')"'总结上面这段话", "max_tokens": 128 }'

这个测试会往上下文里塞大约4000个token，如果显存不够会直接报错。能跑通说明KV Cache的配置是合理的。

5.4 常见启动失败原因排查

启动失败的原因五花八门，但高频的就那么几个：

我遇到最多的是量化格式不匹配。比如下载了一个GPTQ模型，但vLLM启动时没指定--quantization gptq，框架会按FP16加载，直接爆显存。这种问题看日志就能发现，日志里会写"loading model in fp16"之类的信息。

6. 科研与工程场景下的Agent能力调优

模型跑起来只是第一步，真正要用于科研和工程，还需要在Agent能力上做调优。所谓Agent能力，核心是工具调用、多步推理和上下文管理这三件事。

6.1 工具调用的格式约束

让27B模型稳定地输出结构化的工具调用请求，需要明确的格式约束。最可靠的方式是用JSON Schema定义工具，然后在prompt里给出严格的输出格式要求。Qwen系列对JSON格式的支持比较好，但4bit量化后偶尔会输出格式错误的JSON。

我的做法是在推理框架外面套一层解析和重试逻辑：先尝试解析模型输出，如果JSON解析失败，就把错误信息拼回prompt里让模型重新生成。通常重试一两次就能得到合法输出。

import json def call_with_retry(model, prompt, max_retries=3): for i in range(max_retries): output = model.generate(prompt) try: return json.loads(output) except json.JSONDecodeError as e: prompt += f"\n上次输出格式错误：{e}，请重新输出合法JSON。" raise ValueError("重试次数耗尽")

6.2 多步推理的上下文管理

科研和工程任务往往需要多步推理——先查资料，再分析，再计算，最后总结。每一步的输出都要作为下一步的输入，上下文会快速膨胀。这时候KV Cache的管理就非常关键。

一个实用的策略是分层上下文：把上下文分成"系统指令"、"历史摘要"和"当前任务"三层。系统指令固定不变；历史摘要用模型自己压缩，只保留关键信息；当前任务放完整的细节。这样既能保持长程一致性，又不会让KV Cache无限增长。

注意：让模型自己压缩历史是有风险的，可能丢失关键细节。我的做法是保留最近N轮完整对话，更早的才做摘要压缩，N一般设成3到5。

6.3 代码生成任务的特殊处理

工程场景下代码生成是高频需求。4bit量化模型在代码生成上的表现和FP16有差距，主要体现在长代码的连贯性和边界条件处理上。几个改善手段：

• 用代码校准集重新量化：如果主要用途是代码生成，量化时的校准集应该以代码为主
• 降低temperature：代码生成建议temperature设0.2到0.4，减少随机性
• 提供few-shot示例：在prompt里给一两个相关代码示例，能显著提升输出质量
• 分步生成：复杂函数拆成多个简单函数分别生成，再组合

实测下来，27B模型在4bit量化后，写单文件级别的代码（200行以内）基本可用，但跨文件的大型重构还是力不从心。这个预期要建立好。

7. 性能实测与调优经验

最后分享一些实测数据和调优经验。测试环境是单卡4090 24GB，Qwen3.6-27B AWQ 4bit，vLLM 0.4.x，Ubuntu 22.04。

7.1 不同上下文长度下的速度表现

可以看到，上下文越长，生成速度下降越明显。这是因为每生成一个token都要对越来越长的KV Cache做注意力计算。8K上下文下速度降到20 token/s，对于交互式使用还能接受，但批量处理就偏慢了。

7.2 批处理对吞吐的影响

单请求速度是一回事，吞吐是另一回事。开启动态批处理后，多个请求可以共享模型权重的读取，吞吐能提升好几倍。但批处理会成倍增加KV Cache占用，所以批大小和上下文长度要权衡。

我的经验是：4K上下文下，批大小设4比较稳；8K上下文下，批大小只能设1到2。再大就OOM了。

7.3 几个容易被忽略的调优点

第一，关闭不必要的日志。vLLM和TGI默认会打大量日志，在高频推理时日志IO会成为瓶颈。生产环境把日志级别调到WARNING以上。

第二，用SSD而不是HDD存模型。模型加载时要从磁盘读几十GB的数据，SSD能把加载时间从几分钟降到几十秒。

第三，注意GPU温度。4090长时间高负载运行温度会到80度以上，触发降频后速度明显下降。机箱风道要做好，必要时手动调风扇曲线。

第四，预留系统显存。不要把所有显存都给推理框架，留500MB到1GB给系统和显示输出。尤其是用桌面环境的时候，显存被吃满会导致界面卡死。

7.4 什么情况下该考虑升级硬件

单卡4090跑27B模型是有天花板的。如果你发现以下情况频繁出现，就该考虑升级了：

• 需要16K以上的上下文，且不能接受速度下降
• 需要同时服务5个以上的并发用户
• 需要跑FP16精度做质量对比实验
• 需要微调模型而不是只做推理

升级方向有两个：加一张4090做张量并行，或者换专业级卡。前者成本低但需要框架支持多卡；后者成本高但省心。对于大多数个人研究者来说，双4090是性价比最高的方案。

踩过几次坑之后，我的体会是：单卡4090跑27B模型是一个"刚好够用"的方案，它在显存、速度、质量三者之间找到了一个平衡点。但这个平衡很脆弱，任何一个参数设错都可能导致不可用。所以搭建的时候要有耐心，一个参数一个参数地调，把每个参数的作用和影响搞清楚，比盲目抄配置要靠谱得多。