Qwen3.6-27B 部署指南 - 256K 上下文下的最优配置

模型简介

Qwen3.6-27B 是通义千问推出的 27B 参数大语言模型，支持 262K 超长上下文。本文使用 UD-Q4_K_XL 量化版本（约 17 GB），在 AMD RX 395（96 GB 统一内存）上实现 256K 上下文 + 22 token/s 的推理速度，是目前实测最快的配置。

环境信息

1. 启动命令

思考模式

~/llama.cpp/vulkan/b10075/llama-server \
  -m ~/model-gguf/Qwen3.6-27B-UD-Q4_K_XL.gguf \
  --alias "qwen3.6-27B" \
  --api-key "sk-testing" \
  -ngl 99 -c 262144 \
  -ctk q8_0 -ctv q8_0 \
  -ctkd q8_0 -ctvd q8_0 \
  -fa on \
  --host 0.0.0.0 --port 8080 \
  --spec-type draft-mtp \
  --spec-draft-n-max 2 \
  -b 2048 \
  -ub 512 \
  -np 4 \
  --cache-ram 16384 \
  --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.00

非思考模式

~/llama.cpp/vulkan/b10075/llama-server \
  -m ~/model-gguf/Qwen3.6-27B-UD-Q4_K_XL.gguf \
  --alias "qwen3.6-27B" \
  --api-key "sk-testing" \
  -ngl 99 -c 262144 \
  -ctk q8_0 -ctv q8_0 \
  -ctkd q8_0 -ctvd q8_0 \
  -fa on \
  --host 0.0.0.0 --port 8080 \
  --spec-type draft-mtp \
  --spec-draft-n-max 2 \
  -b 2048 \
  -ub 512 \
  -np 4 \
  --cache-ram 16384 \
  --temp 0.6 --top-p 0.8 --top-k 20 \
  --presence-penalty 1.5 --min-p 0.00 \
  --reasoning off

实测速度：22 token/s，262144 上下文全开，是 AMD RX 395 上最快的配置。

--temp 推荐：无论思考还是非思考模式，--temp 0.6 都是最佳选择。思考模式的默认 --temp 1.0 输出更随机，但 0.6 在稳定性和质量上表现更好。

2. 参数详解

基础参数

GPU 与注意力

上下文与 KV 缓存

Q8_0 KV 缓存在精度和显存之间取得最佳平衡，每 token 约 32 KiB。相比 iq4_nl，q8_0 在 AMD RX 395 上兼容性更好、速度更快。--cache-ram 分配更多内存给模型缓存，减少磁盘 IO。

MTP 推测解码

Qwen3.6-27B 内置 MTP（Multi-Token Prediction）头，无需额外草稿模型文件。--spec-draft-n-max 2 表示每次推测 2 个未来 token，实测接受率良好。

生成参数

--temp 0.6 在两种模式下都是最佳选择，在稳定性和输出质量间取得平衡。非思考模式下 --presence-penalty 1.5 有效减少重复内容。

Batch 与并发

-np 4 允许同时处理 4 个请求，适合多用户场景。-b 2048 为最大 batch size，-ub 512 为 prompt 处理的 micro-batch size（需 ≤ -b），结合显存/内存带宽调优。

-cb Continuous Batching（什么时候才需要加？）

-cb 能大幅提高系统的总吞吐量，但有严格的前提条件。用错场景不仅不能提速，反而可能让单个用户的体验变差。

生效条件（必须同时满足）：

1. 多请求并发：2 个或更多请求同时/交错发给 llama-server（需配合 -np 2 或更多 slot）
2. 追求吞吐量而非单用户延迟：目标是单位时间内处理更多请求，而非让单个用户最快拿到回复

原理：大模型在生成下一个 Token（Decode）时，GPU/内存带宽利用率极低（单 Token 计算量太小）。-cb 把请求 A 和请求 B 的 Decode 阶段合成一个 Batch 送进 GPU，用同一趟内存读取同时计算多个人的 Token。

什么时候不加：

• 单用户 / 低并发场景（-np 1）：没有并发请求可以合并，-cb 无意义
• 追求单请求最低延迟：合并 Batch 会让每个请求等待其他请求完成，单用户体感反而变慢

3. 显存预算

262144 上下文显存计算

96 GB 显存跑满 262144 上下文仍有大量富余，这也是能保持 22 token/s 高速的关键。

KV 缓存大小参考

4. API 调用

curl -s http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-testing" \
  -d '{
    "messages": [{"role": "user", "content": "你好"}],
    "max_tokens": 100
  }'

5. 性能对比

Qwen3.6-27B 的 Q4_K_XL 量化在质量与速度之间取得了很好的平衡，配合 MTP 推测解码和 Q8_0 KV 缓存，在满上下文下仍能保持 22 token/s。

6. 注意事项

• AMD RX 395 兼容性：KV 缓存推荐使用 q8_0，避免 iq4_nl（兼容性不佳）
• --reasoning off：非思考模式，直接输出回答，适合日常对话和快速响应场景
• -np 4：支持 4 个并发请求，多用户场景下无需排队
• --cache-ram 16384：分配 16GB 给模型缓存，减少磁盘 IO，提升响应速度
• MTP --spec-draft-n-max 2：Qwen3.6 的 MTP 头设计为预测 2 个 token，不建议设更大
• 首次请求较慢：模型预热 + 编译缓存，后续请求提速
• --temp 推荐 0.6：无论思考还是非思考模式，0.6 都是最佳温度

7. GPU 驱动排查

如果 nvtop 看不到 GPU 信息，很可能是驱动没有正确安装。按以下步骤排查：

安装诊断工具

sudo apt install -y nvtop vulkan-tools

检查 GPU 信息

sudo lshw -C display

检查 Vulkan 设备

vulkaninfo --summary

关注输出中有几个 GPU 设备。如果看到 GPU0 = PHYSICAL_DEVICE_TYPE_CPU，说明当前走的是 CPU 软件渲染，GPU 驱动没有正确加载，Vulkan 无法使用硬件加速。

修复：将用户加入 GPU 用户组

sudo usermod -a -G video,render your_username

将 your_username 替换为实际用户名。加入组后需要让权限生效：

newgrp video
newgrp render

newgrp 只是让当前 shell 立即生效，建议直接重启以确保所有进程都拿到正确的组权限。

重启后再次运行 nvtop，应该可以看到 GPU 监控信息。如果 vulkaninfo --summary 中 GPU0 显示为实际的显卡型号而非 CPU，说明驱动已正常工作。