RTX 3090 部署 Qwen3.8 27B:模型选择、参数建议与性能实测
RTX 3090 拥有 24GB 显存,仍然是本地部署大模型性价比较高的显卡之一。但运行 27B 模型时,24GB 显存已经接近临界范围:模型能否装入显存、上下文能开多大、速度是否可接受,都会受到量化版本、KV 缓存和推理引擎的直接影响。
本文记录一次使用 llama-server 在 RTX 3090 上部署 Qwen3.8 27B GGUF 模型的实践,为同样使用 24GB 显卡的用户提供参数参考。
本文中的 qwen3.8:27b 是 API 模型别名,实际使用的模型文件为:
Qwen3.8-27B-MTP-IQ4_KS.gguf
一、部署环境
核心硬件与软件配置如下:
- GPU:NVIDIA RTX 3090 24GB
- 系统内存:64GB
- 推理引擎:支持 MTP 的
ik_llama.cpp - 服务程序:
llama-server - 模型格式:GGUF
- 并发数:1
- API:OpenAI 兼容接口
如果使用标准 llama.cpp、Ollama 或其他推理引擎,参数名称和实际速度可能有所不同,但模型选择、显存估算和 KV 缓存配置的思路基本一致。
二、模型版本选择
本次先后测试了两个 Qwen3.8 27B 量化版本。
| 模型版本 | 文件大小 | 最低生成速度 | 平均生成速度 | 结论 |
|---|---|---|---|---|
| Q4_K_M | 约 17.1GB | 38.11 t/s | 41.61 t/s | 未采用 |
| MTP-IQ4_KS | 约 16.9GB | 58.38 t/s | 61.48 t/s | 最终采用 |
两个模型参数量相同,文件大小也非常接近,但速度差异明显。
通用 Q4_K_M 可以正常加载,输出质量也没有明显问题,但在当前推理引擎下没有充分发挥 MTP 推测解码的优势。换成 MTP-IQ4_KS 后,最低生成速度从 38 tokens/s 提高到了 58 tokens/s 以上。
这说明选择 GGUF 模型时,不能只看“都是 4 位量化”。还要考虑:
- 具体量化算法
- 推理引擎是否针对该量化优化
- 是否包含或适配 MTP
- 模型张量布局
- CUDA 内核兼容性
- 模型制作者使用的转换工具
对于本次使用的 ik_llama.cpp,MTP-IQ4_KS 是更合适的版本。
三、最终推荐配置
最终采用的核心参数如下:
--model Qwen3.8-27B-MTP-IQ4_KS.gguf
--alias qwen3.8:27b
--ctx-size 120000
--parallel 1
--gpu-layers 999
--flash-attn on
--cache-type-k q5_1
--cache-type-v q5_1
--cache-type-k-draft q5_1
--cache-type-v-draft q5_1
--batch-size 2048
--ubatch-size 512
--threads 8
--threads-batch 12
--cont-batching
--jinja
--reasoning off
--metrics
--no-context-shift
--cache-ram 8192
--ctx-checkpoints 32
--merge-qkv
--merge-up-gate-experts
--spec-type mtp:n_max=4,p_min=0.0
--recurrent-ckpt-mode auto
如果只需要普通聊天或编程辅助,可以将上下文降低到 80K 或 100K,并继续使用 Q8 KV,以换取更好的 KV 缓存精度。
如果确实需要处理长文档、代码库或长时间保存对话历史,120K 搭配 Q5_1 KV 更适合 RTX 3090。
四、为什么选择 120K 和 Q5_1 KV
模型元数据显示,其原生训练上下文长度为:
262144
因此模型本身能够支持 120K,真正的限制主要来自显存。
在 81,920 上下文、Q8 KV 缓存下,显存分配大致为:
- 模型权重:约 15,142MiB
- 主模型 KV 缓存:约 3,040MiB
- MTP KV 缓存:约 170MiB
- 主模型计算缓存:约 505MiB
- MTP 计算缓存:约 505MiB
- CUDA 及其他运行开销:约 2~3GB
整卡占用约 22GB,只剩约 2GB 显存。
KV 缓存占用基本随上下文长度线性增长。如果保持 Q8 KV 直接提高到 120K,预计显存占用将接近 23.6GB,剩余空间不足 1GB。虽然有机会启动,但不适合作为稳定配置。
最终改为 Q5_1:
--cache-type-k q5_1
--cache-type-v q5_1
启用 MTP 后,还需要同步设置 Draft 缓存:
--cache-type-k-draft q5_1
--cache-type-v-draft q5_1
120K 下实测:
- 主模型 KV 缓存:3,139.5MiB
- MTP KV 缓存:175.88MiB
- 总显存占用:约 21.6~22.6GB
- 剩余显存:约 1.7~2.7GB
Q5_1 比 Q4 KV 更保守地保留缓存精度,同时又比 Q8 显著节省显存,是 120K 上下文下较平衡的选择。
五、性能实测
在 120K/Q5_1 配置下,使用三组不同中文提示词,每次生成 384~512 tokens。
| 测试 | 生成速度 |
|---|---|
| 第一轮 | 53.59 t/s |
| 第二轮 | 59.76 t/s |
| 第三轮 | 52.69 t/s |
汇总结果:
- 最低:52.69 tokens/s
- 中位数:53.59 tokens/s
- 平均:55.34 tokens/s
对于 RTX 3090 上的 27B 模型,这个速度足以满足单用户聊天、文档分析、代码辅助和办公应用。
需要注意,这些数字是短上下文生成速度。上下文变长后,生成速度会下降。
实际测试中:
- 约 67K tokens 上下文:生成速度约 36 tokens/s
- 67K~82K 范围:约 29~49 tokens/s
- 66,704 tokens 首次提示词处理:约 87 秒
因此,“支持 120K 上下文”并不代表装入 120K 内容后仍能维持 55 tokens/s。
六、RTX 3090 部署中容易踩的坑
1. 认为模型文件能装下就代表可以运行
模型文件约 16.9GB,而显卡有 24GB,看起来还剩 7GB。但运行时还要分配:
- KV 缓存
- 计算缓存
- CUDA 上下文
- 推测解码缓存
- 临时工作区
不能简单地用 24GB 减去模型文件大小来计算可用上下文。
对于 27B 模型,建议至少预留 1.5~2GB 显存余量。
2. 只看“4 位量化”,不看具体版本
Q4_K_M、IQ4_KS、IQ4_XS 等都属于 4 位附近的量化,但实际表现可能不同。
量化版本会同时影响:
- 模型文件大小
- CUDA 计算效率
- 输出质量
- 长上下文稳定性
- 推测解码兼容性
在选定推理引擎后,最好实际测试两到三个量化版本,而不是仅根据文件名判断。
3. 上下文调高后仍然沿用 Q8 KV
Q8 KV 质量较好,但在 120K 或 150K 上下文下非常占显存。
RTX 3090 上可以参考:
| 上下文 | KV 建议 | 说明 |
|---|---|---|
| 32K~64K | Q8_0 | 显存相对充足 |
| 80K | Q8_0 或 Q5_1 | 根据模型占用选择 |
| 100K~120K | Q5_1 | 质量和显存较平衡 |
| 150K | Q4_0 或更激进配置 | 能运行,但速度和质量代价较大 |
如果追求稳定性,不建议在 RTX 3090 上将 27B 模型默认配置为 150K。
4. 启用 MTP 却忽略 Draft KV 缓存
MTP 会创建额外的推测解码上下文。
只设置:
--cache-type-k q5_1
--cache-type-v q5_1
可能还不够,应同时设置:
--cache-type-k-draft q5_1
--cache-type-v-draft q5_1
否则显存占用可能与预期不一致。
5. 将上下文参数的内部对齐当成错误
本次配置:
--ctx-size 120000
实际运行时引擎返回:
120064
这是 KV 缓存按照内部块大小对齐的正常结果,不影响对外提供 120K 上下文。
自动化验收脚本不应要求实际值与配置值完全相等,应允许几十到几百 tokens 的内部对齐。
6. 只测试短提示词
短提示词主要反映模型解码速度,无法验证长上下文性能。
一个相对完整的验收应包括:
- 短提示词生成速度
- 10K~20K 文档读取
- 50K 以上提示词预处理
- 长上下文中的信息召回
- 接近最大长度时的稳定性
- 长对话连续生成
- 服务重启后重新加载
长上下文部署既要看“能否加载”,也要看“是否真的可用”。
7. 只跑一次性能测试
第一次运行可能包含 CUDA 内核初始化和缓存预热,结果不够稳定。
建议:
- 先执行一次短生成预热。
- 准备至少三组不同提示词。
- 每组生成 384~512 tokens。
- 记录最低、中位数和平均速度。
- 使用最低速度作为验收依据。
对于本次配置,将 45 tokens/s 设为短上下文最低验收线。
8. 在 24GB 显卡上盲目增加并发
本次使用:
--parallel 1
120K 上下文本身已经占用了大量显存。增加并发槽位会进一步挤压上下文空间和运行余量,而且多个请求同时生成时速度会明显下降。
RTX 3090 运行 27B 模型更适合:
- 单用户使用
- 多用户排队
- 应用层限制并发
- 短请求优先处理
如果需要稳定的多用户并发,应降低上下文、改用更小模型,或者使用更大显存的 GPU。
七、推荐方案
对于 RTX 3090 用户,可以根据用途选择以下配置。
日常聊天和代码辅助
模型:Qwen3.8-27B-MTP-IQ4_KS
上下文:64K~80K
KV:Q8_0
并发:1
优点是速度更快、KV 精度更高、显存压力更低。
长文档和长对话
模型:Qwen3.8-27B-MTP-IQ4_KS
上下文:100K~120K
KV:Q5_1
并发:1
这是本次采用的配置,容量、速度和显存余量相对均衡。
追求更大上下文
上下文:150K
KV:Q4_0
并发:1
这种配置理论上可以装入 24GB 显存,但满上下文速度会明显下降,KV 量化也可能影响长距离信息召回,不建议作为默认方案。
八、结论
RTX 3090 可以较好地运行 Qwen3.8 27B,但必须精细控制模型量化、KV 缓存和上下文长度。
本次验证较为平衡的组合是:
Qwen3.8-27B-MTP-IQ4_KS
120K 上下文
Q5_1 KV 缓存
单并发
全层 GPU 加载
Flash Attention
MTP 推测解码
最终实测:
- 对外上下文:120,000
- 内部上下文:120,064
- 显存占用:约 21.6~22.6GB
- 显存余量:约 1.7~2.7GB
- 短上下文平均速度:55.34 tokens/s
- 短上下文最低速度:52.69 tokens/s
- OpenAI 兼容接口运行正常
如果主要追求速度,建议选择 80K 上下文和 Q8 KV;如果需要长文档能力,120K/Q5_1 是 RTX 3090 运行 Qwen3.8 27B 更值得参考的配置。