4 X L20 部署本地模型，求大神指点

terry

@Foster-Xu 大哥你4卡上VLLM干嘛啊，既然让AI干了，让AI上SG-Lang，它有Radix缓存，你问下AI就知道了，这才能发挥战力。

Foster Xu

昨天我让AI给我分析了一下，他说vLLM更加合适。。。我就没有动了

Foster Xu

我做了一下测试，好像数据很垃圾啊

terry

@Foster-Xu 好吧确实如此，SG-Lang Bug较多，版本地狱。你折腾VLLM也对，你的主板PCIE再差，也不至于这个速度，肯定是配置有问题。但是我们没环境，没办法帮你分析。你要实在搞不定，就用4卡单独跑4个实例。按理说你的卡是数据中心卡，支持NVLINK的，试试看？

Foster Xu

刚才部署了单卡的情况，请参考。

INT8 单卡部署成功了！关键数据：

模型权重：18.06 GiB（从 54 GB 量化到 18 GB）
KV cache 可用：20.78 GiB
KV cache 容量：332,662 tokens
最大并发：2.54x（128K 请求）
enforce-eager 模式（无 CUDA graph）

INT8 + CUDA graph: 33.41 tok/s。比 enforce-eager 的 23 tok/s 快了很多，但和 TP=4 BF16 的 34 tok/s 差不多。单卡没快多少，原因是 CUDA graph 部分 capture 失败，回退到了 eager 模式的那些层变慢了。

现在清理 INT8，试 INT4 (AWQ)。但 vLLM 的在线 AWQ 量化不太稳定，让我改试 --quantization fp8——FP8 量化更轻量，精度损失极小，且 L20 支持 FP8 计算。

Foster Xu

kop wang

这个只能围观了。没打过这么富裕的仗……

说正经的，单卡,8比特量化，33.41 tok/s这个数据从他的显存位宽来看也差不多合理。但是多卡*4就完全不是我能理解的领域了……
我更好奇的是prefill性能如何。

Foster Xu

太复杂了，都是GLM 5.1 + ClaudeCode在干，我也是围观的人... -_-!

kop wang

按理说这么大的显存，而且多卡并行，应该是无脑FP16+256K上下文的。但是因为完全没经验，所以就不班门弄斧了。
期待楼主的成果。

williamlouis

直接生成一套方案：参考即可。
其中夹杂了，AI长期学习我产生的记忆。会按我的习惯做出部署。可以直接忽略。
这套 4×L20（184GB 显存） 的配置，最适合的定位是：本地大模型推理 API 节点，跑 32B–70B 级别 Dense 模型 或 量化版 MoE 模型，对外提供 OpenAI 兼容接口。

terry

大佬，你的卡算力比4090弱一点，带宽稍差一点，但是也足够了，显存很大，如果没有NVLink，我建议直接跑Qwen3.6 27b q4km量化模型，上LLamal.cpp，每个卡跑一个实例，不要跑什么INT8之类的。Q4量化足够了，推理时会返回BF16计算，这是目前最成熟的生态，KV量化方案你是N卡，建议上Turoquant Turbo3，既然是AI在操作，可以和它说明你的需求，AI不是一直很聪明的，你要坚持自己的意见，否则无限制折腾。记得把MTP加上，一步到位。VLLM的AQW量化模型没有不稳定的说法，我亲测过，完全没问题。你的单卡跑AI视频或者任何其他应用都够，大模型你可以选择2张卡，3张卡，空出一张卡做ComfyUI。我认为这样比较有性价比，调度也自由，不用考虑互联带宽问题。

易先生

L20单卡，我用SGLANG部署的qwen3.6-27B(FP8),MTP设置为3，速度大概45，开130K上下文，但只能2个
并发

Foster Xu

GPU: 4× NVIDIA L20 (48GB each, Ada Lovelace, sm_89)
CPU: 4× L20 = 192GB 总显存 (用了 33GB / 18%)
RAM: 251GB
存储: /home 2.5TB 可用
驱动: NVIDIA 550.54.14
OS: CentOS 7.9

Model: Qwen3.6-27B-FP8 (基础架构 qwen3_5_text, hybrid GatedDeltaNet)
架构: 64 层, 5120 hidden, 24 attention heads, 4 KV heads
注意力: 16 × (3× GatedDeltaNet + 1× Gated Attention) (3:1 比例)
MTP: 1 个 MTP 头 (multi-token prediction)
训练 ctx: 262,144 (256K)
量化: Q5_K_XL (Unsloth Dynamic 2.0)
文件: /home/models/qwen3-27b-mtp-gguf/Qwen3.6-27B-UD-Q5_K_XL.gguf
大小: 19.0 GB
GGUF源: unsloth/Qwen3.6-27B-MTP-GGUF

主机

mkdir -p /tmp/llama-build/host-out
cd /tmp/llama-build && git clone --depth 1 https://github.com/ggml-org/llama.cpp.git

构建脚本（必须放在源码树内，容器才能看到）

cat > /tmp/llama-build/llama.cpp/build-wrapper.sh <<'EOF'
#!/bin/bash
exec >/tmp/build-out/build.log 2>&1
set -e
apt-get update -qq
apt-get install -y -qq cmake build-essential git ninja-build
cd /src/llama.cpp
rm -rf build
cmake -B build -G Ninja
-DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release
-DCMAKE_CUDA_ARCHITECTURES='89'
-DGGML_NATIVE=OFF -DGGML_CUDA_F16=ON
-DGGML_RPC=OFF -DBUILD_SHARED_LIBS=OFF
cmake --build build -j$(nproc) --target llama-server llama-cli llama-quantize
EOF
chmod +x /tmp/llama-build/llama.cpp/build-wrapper.sh

docker run -d --name llama-cpp-build
-v /tmp/llama-build/llama.cpp:/src/llama.cpp
-v /tmp/llama-build/host-out:/tmp/build-out
-w /src/llama.cpp
nvidia/cuda:12.4.0-devel-ubuntu22.04
bash /src/llama.cpp/build-wrapper.sh

mkdir -p /home/models/qwen3-27b-mtp-gguf
nohup bash -c '
curl -L --fail --retry 5
-o /home/models/qwen3-27b-mtp-gguf/Qwen3.6-27B-UD-Q5_K_XL.gguf
"https://hf-mirror.com/unsloth/Qwen3.6-27B-MTP-GGUF/resolve/main/Qwen3.6-27B-UD-Q5_K_XL.gguf"
' > /tmp/gguf-dl.log 2>&1 &

=== 模型 ===

-m /models/Qwen3.6-27B-UD-Q5_K_XL.gguf

=== 服务 ===

--host 0.0.0.0
--port 8003
--api-key 7cd5aace-734d-4223-813c-2406506c4b0a

=== 上下文（256K 完整原生）===

-c 262144
-ngl 999 # 所有层上 GPU

=== 多 GPU 切分（2×L20）===

--split-mode layer # 按层切分
--tensor-split 0.5,0.5 # GPU 2+3 各 50%
--main-gpu 0 # 主 GPU（相对 0 = 物理 GPU 2）

=== 并发 ===

--parallel 2 # 2 路并发
--kv-unified # ️ 关键：共享 KV 池
--cont-batching # 连续批处理

=== KV 量化（节省 50% 显存）===

--cache-type-k q8_0
--cache-type-v q8_0

=== MTP 投机解码（1.7-2× 加速）===

--spec-type draft-mtp # ️ 关键
--spec-draft-n-max 3 # 草稿 3 token
--draft-p-min 0.85 # 接受阈值

=== 性能优化 ===

--flash-attn auto # Flash Attention
--no-mmap --mlock # 不 mmap，锁内存
--batch-size 512
--ubatch-size 128

=== 采样 ===

--top-p 0.95 --top-k 20 --temp 0.7 --repeat-penalty 1.0

=== 模板 ===

--jinja
--chat-template-kwargs '{"enable_thinking":false}'
--reasoning off

结论

vLLM 7.5 TPS 是 L20 + Qwen3-27B-FP8 物理上限（之前我们认为无法突破）。

llama.cpp + MTP 投机解码在相同硬件上达到 50 TPS（平均）/ 80 TPS（峰值），6.7-10.7× 加速，且能跑 256K 完整原生上下文 + 2 路并发，显存只用 33GB。

关键启示：vLLM 框架本身在 hybrid Mamba/GDN 模型上有性能瓶颈（vLLM 0.5.x 测速 7.5 TPS，0.20.1 测速 7.45 TPS，几乎一样）。要突破必须换底层框架 — llama.cpp + MTP speculative decoding 是当前唯一现实路径。

抡锤者

4 X L20 部署本地模型 ，求大神指点

主机