双RTX 3090实测：llama.cpp vs SGLang，哪个更适合你的场景？
我的工作站有两张RTX 3090，一开始只跑了一个llama.cpp服务（27B模型）。后来想试35B MoE模型，发现llama.cpp对MoE支持还不够完善，于是GPU1装上了SGLang。结果两个框架就这么一起跑了半个月。同一台机器、同一批模型，实测数据告诉你：没有万能框架，只有最匹配场景的工具。
为什么会有两个框架？
初衷很简单：llama.cpp 稳定、省心，但 MoE 优化不如 SGLang 深入。 SGLang 功能全、新模型快，但配置门槛高。既然各有短板，不如让它们各司其职——GPU0 跑 llama.cpp 做日常交互，GPU1 跑 SGLang 处理批量任务。两周跑下来，意外发现了很多细节差异。
部署体验：从“一行命令”到“两个补丁”
llama.cpp：开箱即用的快感
一条 docker 命令就能跑起来：
docker run ghcr.io/ggml-org/llama.cpp:server-cuda \
-m Qwen3.6-27B-UD-Q4_K_XL.gguf \
--ctx-size 65536 --flash-attn on
一个 .gguf 文件 + 一行命令，不需要装 Python、处理 transformers 版本、担心依赖冲突。 llama.cpp 的哲学是“一个可执行文件搞定一切”。我甚至把模型目录 models/ 下放了一堆 .gguf，想换模型直接改文件名重启容器——干净利落。
SGLang：强大但曲折
SGLang 的部署就曲折多了。模型是 safetensors 分片格式（9个文件），依赖 transformers 特定版本，还有两个运行时补丁要打。启动参数光是 CUDA Graph 就折腾了半天。但代价换来了丰富功能：FlashInfer attention、AWQ Marlin kernel、Breakable CUDA Graph、PD分离部署、LoRA热加载。
问题在于，这些功能不是都兼容你的模型，“参数越多坑越多”。 比如我踩过的坑：v0.5.14 升 v0.5.15 后 CUDA Graph 不兼容，不得不回退。
模型支持：GGUF 的方便 vs safetensors 的灵活
llama.cpp 的优势
- GGUF 格式：一个文件就是一个模型，管理极其方便。随便移动、复制、删除，没有目录结构烦恼。
- 量化格式丰富：Q2_K 到 Q8_0，还有 IQ1_S 到 IQ4_XS。想压多小压多小，总有一款适合你的显存。
- MoE 可以但不完美：能从 HF 权重转成 GGUF 跑 35B MoE 模型，但推理优化不如 SGLang 深入。
SGLang 的优势
- 原生多分片模型支持：直接从 HuggingFace 格式加载 safetensors，不需要转换。
- AWQ/GPTQ/Marlin 量化：4-bit AWQ 通过 Marlin kernel 加速，矩阵乘比普通 AWQ 快 2 倍。
- MoE 深度优化：FlashInfer MoE 调度 + Triton MoE kernel 编译，200 专家的模型也能跑到 130 t/s。
- 新模型首发快：Hunyuan 3、DeepSeek V4 等新模型通常在 SGLang 上最先可用。
结论：GGUF 更适合个人用户管理模型；safetensors 更适合需要最新模型的场景。
显存效率：KV 缓存量化是胜负手
在 24GB 的 RTX 3090 上，显存是最大的约束。以下是实测占用：
| 项目 | llama.cpp (27B Q4_K_XL) | SGLang (35B MoE AWQ) |
|---|---|---|
| 模型 | ~17 GB | 18.68 GB |
| KV Cache (64K) | ~2.5 GB (q8_0) | 1.60 GB (bf16) |
| MTP/Mamba Cache | ~0.5 GB | 1.10 GB |
| CUDA Graph 捕获 | 无 | 0.18 GB |
| 其他开销 | ~1 GB | ~1 GB |
| **合计** | **~21 GB** | **~22.9 GB** |
| 剩余 | ~3 GB | ~1.3 GB |
llama.cpp 的 KV cache 量化（--cache-type-k q8_0 --cache-type-v q8_0）把缓存从 bf16 压缩到 8-bit，节省了 50% 显存。 实测 65K 上下文完全无压力，还有 3GB 余量。
SGLang 的显存更紧张：一是 MoE 模型有额外 Mamba state 缓存；二是 RTX 3090 不支持 fp8 Tensor Core，无法使用 KV cache 量化（bf16 是唯一选项）；三是 CUDA Graph 捕获需要额外内存。虽然 65K 也能跑，但余量只有 1.3 GB，不能像 llama.cpp 那样游刃有余。
对于显存敏感的卡（如 24GB/16GB），llama.cpp 的 KV cache 量化几乎是必杀技。
推理速度：意料之外的悬殊
这是最让人意外的地方：
| 对比项 | llama.cpp (27B) | SGLang (35B MoE) |
|---|---|---|
| 模型参数量 | 27B dense | 35B MoE (~3B/token) |
| 量化 | Q4_K_XL (GGUF) | AWQ 4-bit (safetensors) |
| 速度 | ~65 t/s | **~130 t/s** |
| 首 token 延迟 | 较低 | 较高（prefill + CG） |
| 长上下文退化 | 轻微 | 较明显 |
35B MoE 比 27B dense 快 2 倍——因为 MoE 每 token 只激活约 3B 参数，而 dense 模型每 token 都要跑满 27B。 这是架构本身的胜利，和框架关系不大。但如果比较相同模型（比如都跑 Qwen 27B），llama.cpp 在单用户场景下的 decode 延迟控制得更好，因为调度简单、没有 CUDA Graph 等额外开销。
结论：想用 MoE 模型选 SGLang（高吞吐），用 dense 模型选 llama.cpp（低延迟）。
稳定性：一个让人放心，一个让人折腾
| 方面 | llama.cpp | SGLang |
|---|---|---|
| 启动成功率 | 接近 100% | 依赖 transformers 版本 |
| 长上下文稳定性 | ✅ 优秀 | ✅ 优秀（64K 内） |
| CUDA Graph | ✅ 一次成功 | ⚠️ 需要调参+等3分钟 |
| 版本兼容性 | ✅ 极少出问题 | ❌ 经常遇到 breaking change |
| 补丁需求 | 几乎为零 | 本项目打了2个补丁 |
llama.cpp 的稳定性令人放心。它就是一个 C++ 程序，没有 Python 依赖链，没有 transformers 版本地狱。 更新镜像、重启、完事。
SGLang 紧跟前沿模型和框架，更新频繁，但也意味着更容易踩坑。v0.5.14 升 v0.5.15 就经历了 CUDA Graph 不兼容的问题。 但对于需要最新模型支持的用户来说，这种“不稳定”是值得的——新模型首发通常比 llama.cpp 早一到两周。
我的最终方案：两个都跑
GPU0 用 llama.cpp 跑 Qwen3.6-27B，负责日常对话、代码生成、视觉问答。启动快、稳定、首 token 延迟低，适合交互式场景。
GPU1 用 SGLang 跑 Qwen3.6-35B MoE，负责批量推理、高吞吐任务。130 t/s 的吞吐对代码审查、文档分析等场景非常适用。
两台服务都是 OpenAI 兼容 API，上层应用不用关心背后是哪个框架。
场景选择指南
| 场景 | 推荐框架 | 理由 |
|---|---|---|
| 日常编码助手 | llama.cpp | 稳定、首 token 快、配置简单 |
| 代码/文档批量处理 | SGLang | 高吞吐、MoE 模型快 2 倍 |
| 超长上下文 (>100K) | llama.cpp | KV cache 量化+CPU offload |
| 最新模型尝鲜 | SGLang | 首发支持快 |
| 生产环境单一模型 | llama.cpp | 零依赖，故障率低 |
| 个人工作站双卡 | 两者都跑 | 互不干扰，各取所长 |
没有最好的框架，只有最适合你的场景。 如果你只需要跑一个模型、希望配置简单，llama.cpp 是不二之选。如果你需要最新模型、最高吞吐，SGLang 值得折腾。如果像我有双卡——那就不用选了，两个都装，各显神通。
你遇到过类似的框架选择困境吗？ 是追求极致的吞吐，还是更看重稳定省心？欢迎在评论区聊聊你的真实案例。