club-3090：为 RTX 3090 双卡用户整理 LLM 服务的实战配方

这个项目解决什么问题

RTX 3090 有 24GB 显存，但跑现代 LLM 并不轻松。模型量化、上下文长度、引擎选择都会影响能否跑起来，以及是否会在某个 token 处崩溃。club-3090 把社区验证过的配置收集起来，针对一张或两张 3090，给出可直接用的 docker compose 文件。它面向的人群很明确：在家用机器、homelab 或开发后端跑 LLM 的人。项目描述里说，它收集了可工作的配置、补丁和基准数据。对于不想自己从零调 vLLM 参数或试错 quant 的人，这省去了大量实验。

两条路线：吞吐优先还是稳健优先

项目把服务方式分成两条互补路线。vLLM dual 路线追求最大吞吐，文档称可达 127 TPS 代码生成，或 4 个并发流且上下文 262K。它支持视觉、工具调用、MTP 和流式输出。另一条是 llama.cpp 单卡路线，强调稳健性，能在单张 3090 上跑满 200K 上下文，且没有 prefill cliff。文档提到 91K needle 测试通过，25K token 的工具返回也能工作。速度上 llama.cpp 约 51 到 60 TPS，比 vLLM 双卡慢，但不会在处理真实工具调用代理时崩溃。这个取舍很实际：如果你跑的是长上下文 agent 任务，吞吐可能不是第一优先。

多引擎支持与模型无关的设计

项目支持三种引擎：vLLM 提供完整功能，llama.cpp 提供最大上下文和稳健性，ik_llama 提供最佳 GGUF 量化。设计上模型无关，目前预置了 Qwen3.6-27B 等模型的配置，但结构可以扩展。它还评估过 SGLang，但被 Ampere 架构阻塞，相关说明在 docs/engines/SGLANG.md。这种多引擎策略让用户根据工作负载选择，而不是绑定单一实现。不过这也意味着你需要理解不同引擎的差异，项目提供了 docs/INFERENCE_ENGINES.md 来帮助决策。

启动与操作：脚本和终端界面

快速开始需要克隆仓库，然后运行 bash scripts/setup.sh。这个脚本是交互式的，会问你选哪个模型、把权重放在哪里，默认是仓库内目录、~/models 或自定义路径。如果想跳过交互，可以设置环境变量 MODEL_DIR 并传入模型名。启动服务用 launch.sh，它会先调用 switch.sh 切换容器，再运行 verify-full.sh 验证服务正常。项目还提供了一个叫 c3 的终端界面，类似 lazydocker，可以用键盘浏览模型目录、启动服务、查看 GPU 状态和运行健康检查。安装方式是用 uv pip install -e tools/serve-cockpit。首次运行按 S 设置模型目录和 HuggingFace token，按 r 浏览目录并服务模型。

已知的坑：单卡长上下文问题

项目文档明确列出了一个未解决的问题：在单张 24GB 3090 上，vLLM 在单提示超过约 50K token 时会出现 prefill OOM。文档称这是 open 状态。解决办法是用双卡 TP=2 绕开。另一个变化是，之前作为单卡逃逸路线的 llamacpp/default 已在 2026-08-12 退役，只能用 --force 参数强制使用。这意味着单卡用户现在没有完全免疫 cliff 的 Qwen 路径。这个信息很重要，因为很多用户可能以为单卡能跑长上下文，但实际有限制。项目提供了 docs/CLIFFS.md 详细诊断，但采用前必须看。

通用 pull 流程：评估任意模型

除了预置模型，项目有一个通用 pull 流程，从 v0.8.0 开始支持。你可以用 pull 命令评估任何 safetensors 格式的 HuggingFace 仓库。它会基于 KV 缓存数学计算，给出诚实的适配性判断，用 --recommend 参数。如果硬阻塞，可以用 --submit-last 发送脱敏诊断信息。这个功能对想跑非支持列表模型的人有用，但文档也强调它只是评估，不是保证。它给出的结论是 one-line fit verdict，意味着精度有限。如果你对模型适配性有疑问，这个工具能给你一个起点，但最终还是要看实际测试。

维护成本与许可证

项目采用 Apache-2.0 许可证，允许商用和修改，但要注意这不是法律建议。维护上，项目最近更新频繁，v0.10.2 在 2026-07-13 发布，说明还在活跃开发。但这也意味着你需要跟上更新，因为配置可能随引擎版本变化。文档提到，在 git pull 之后需要重新运行安装命令来获取新的依赖和 UI 变化。这是明确的维护成本。另外，Windows 原生不支持，只有 WSL2 才能用完整工具链，原生 Windows 只能跑上游 llama.cpp 二进制。如果你在 Windows 上工作，需要先设置 WSL2。

替代方案与对比

一个直接的替代方案是自己手动配置 vLLM 或 llama.cpp，不使用任何配置集合。差异在于 club-3090 提供了经过验证的 docker compose 和针对 3090 显存限制的调优，而手动配置需要你自己处理 KV cache 大小、量化选择、引擎参数等。另一个替代是使用云 API，项目有 docs/COMPARISONS.md 讨论成本交叉点。对于有 3090 的用户，自托管可能更便宜，但你需要接受维护成本。如果是 3 张以上 GPU，项目也提供了多卡文档，但那是从 dual.yml 推导的，不是专门优化的。所以如果你有 4 张 3090，可能需要更多手动调整。

编辑结论

适合有一张或两张 RTX 3090，且想跑 Qwen3.6-27B 这类模型的个人或小团队。若你追求吞吐，vLLM dual 路线可到 127 TPS；若你需要长上下文和工具调用稳定性，llama.cpp 单卡路线更可靠。不适合只有一张卡且需要超过 50K 上下文的人，因为 vLLM 单卡有 prefill OOM 问题，而 llama.cpp 的旧路线已退役。在采用前，先验证你的模型是否在支持列表中，并检查 docs/CLIFFS.md 中列出的已知限制，尤其是单卡长上下文场景。

官方来源

1. Official README
2. Project repository
3. Release notes