这是一个创建于 314 天前的主题，其中的信息可能已经有所发展或是发生改变。
设备配置
- 显卡：8x4090 ，单张 24564MIB--约 24G 显存（单张可用 60%左右）
- CentOS 7.6 ，已有 cuda 、python 、docker 环境
需求
- 暂时采用量化模型，Qwen2.5 32B q6 或者 q8 （ q4km 效果太差了）
- 多卡部署，想充分利用多卡 gpu 简易离线部署（优先级小于多卡部署），最好类似 docker 镜像直接保存的方式，也可以使用 python 离线依赖安装的方式，主打一个一次导入，导入太麻烦了。
- 最终需要一个类似
open_webui的 web 方案
方案
- 当前单卡
ollama+open_webui效果差，想堪比 gpt 4o （当然没必要太强）能用的程度。 - llama.cpp 多卡好像支持不太好？
- vllm 多卡部署好像不支持量化模型，不是很满足需求。
- TGI 好像可以（ Int4 、Int8 、AWQ ）但是不太了解。
- 官方还提供 SkyPilot 、OpenLLM 但都不太了解
有没有一种好的方式快速部署
第 1 条附言 312 天前
致谢
感谢 @Leon6868 @Azure99 提供的lmdeploy工具，使用conda-pack成功迁移离线部署。 感谢 @Leon6868 @GPLer @mythabc @kenvix @oldfans 提到的72B模型，当前尝试是官方Qwen2.5-72B-Instruct-AWQ模型，可惜官方没有8bit AWQ量化。
方案
采用conda-pack离线部署lmdeploy。
原因：支持多卡，性能高
采用Qwen2.5-72B-Instruct-AWQ模型（4 bit）
原因：与GPTQ相比，AWQ可以显著提高推理速度，同时保持类似甚至更好的性能。
体验
- 短token很顺滑，几乎秒出答案；长token等个10s左右也能出答案，完全没有32B_q4那样混乱的答案，结果很清晰。
- 单人使用时，8x4090，单张GPU占用78%-90%左右，可以了
需求
- 暂时没有其他需求了，可能就是更少的内存更优的体验？不过感觉已经能充分利用显卡了，爽
 | 1 qiniu2025 314 天前 拿个 32B 开源想跟现在行业龙头 gpt 4o 比,你要给用户提供什么服务? 这种聊天机器人满大街都是 |
 | 3 Leon6868 314 天前  1 8x4090 跑 ollama ，不如借给我用（）（感兴趣可以联系 cXRiYm9zajVzQG1vem1haWwuY29t ，我可以帮你配置环境） 我个人的推荐是 lmdeploy + Qwen2.5 72B awq int8 ，响应速度很快，支持多卡，在 4xV100 上实跑 72B gptq int4 比 vllm 好用 |
 | 4 mmjy 314 天前 vllm 文档是有量化实验特性支持的，可以试试好不好用： https://docs.vllm.ai/en/latest/quantization/auto_awq.html |
 | 5 GPLer 314 天前 via Android 8x24GB 为什么不上 72B ，是要考虑多用户使用的情况吗。 |
 |
 | 11 Azure99 314 天前 1 lmdeploy≈sglang>vllm ，个人偏好是这样 |
 | 12 Fanhz 314 天前 可以试下 sglang |
 | 13 mythabc 314 天前  1 1. 为什么单张可用 60%？ 把其他任务都集中到 4 张显卡上，剩余 4 张用于跑 72b-awq 。多卡不建议超过 4 张，因为通信成本。 2. vllm 支持量化模型的。生产上用的最多的就是 vllm ，然后是 sglang （但是个人体感 sglang 比 vllm 稳定一些，因为版本都在不断迭代，所以仅是时效性的使用感受）。ollama 基于 llama.cpp ，这个项目最初就是用于在资源有限环境把模型 offload 到内存里跑起来的，一般就是个人玩具使用。 3. 喜欢一键的话，可以试一下 xinference ，有 docker 镜像，挺好用。 4. web 方案其实是各种 web client + openai style api ，各个推理引擎以 openai style api 将接口提供出来，兼容各类应用。 |
 | 14 kenvix 314 天前 2 用 32B Q8 远不如 72B Q4 。参数量带来的提升远大于提升精度 |
 | 15 oldfans 313 天前 Ollama 是 llama.cpp 的一个前端。 llama.cpp 支持多 GPU ，但不支持张量并行，单一并发同时只有一张卡在跑，多卡还有通信的开销，所以会比单卡还慢（前提是单卡的显存足够放模型）。 vLLM 支持在多卡上推理量化模型。 4-bit 的 Qwen2.5 72B 应该比未量化的 Qwen2.5 32B 要好。 Qwen2.5 可以试试用同系列的小参数量模型做推测解码（ Speculative decoding ），应该会快不少。 |
 | 16 DreamingCTW 313 天前 我 8 张 3080 的跑 qwen2.5:72b-instruct-q8_0 都没问题呀 |
| 17 DreamingCTW 313 天前 @DreamingCTW #16 我用的就是 ollama+open_webui 的方案 |
 | 18 wantstark 313 天前 学习了几个月下来，ray server 或者 kuberay 蚂蚁字节都在用，万卡级别部署 |
 | 19 woscaizi 313 天前 |
 | 20 Les1ie 313 天前 目前多卡用的 ollama+open_webui 的方案（以前用的 lobe-chat ，现在替换成了 open_webui ）。 使用的 ollama.com 提供的量化后的 qwen2.5 72b q4km ，针对常规的提示词工程的任务，对比询问了同样的问题，72b 相比于单卡就能带动的 qwen2.5 32b q4km 有明显的效果提升。不过多卡明显感觉有特别高的通信成本，远没有单卡响应速度快（显卡是几年前的，实际使用的 PCIe3 ）。 之前常用 qwen2.5 32b q4km ，最近几天切换成了 qwen 的 qwq:32b q4km 模型，感觉推理能力有稍微加强。（以上体验都是主观评价，没跑过 benchmark ，仅作参考） 建议： 1. 试试 qwen2.5 72b q4km ，内存占用大概 59GB ，体验提升明显，可能比精度带来的提升来的更快更直接 2. 如果 8 张 4090 资源只能分出来一小部分使用，试试 qwq:32b 3. 你这 8 张都能用上的话，可以试试 deepseek-v2.5:236b 4. 如果本地化部署不是任务的必要条件，那么 chatgpt/claude 仍然是目前的最优解, 4o 免费的目前已经有自我反思能力,能够回答问题过程中发现错误打断自己重新回答，而这些我是在其他模型中没有体验到的 |
 | 22 fid OP |
| 25 fid OP @DreamingCTW #17 ollama 多卡不太行吧 |
| 27 fid OP @Les1ie #20 1. q4km 量化多卡不太合适，目前尝试 72B awq 量化+LMdeploy ，参数级提升应该大于精度提升 2. 我协调一下显卡使用，应该能合理分配，毕竟多卡通信存在速度损失 3. qwen2.5 优于 deepseek 吧 4. 本地部署必要，100%无法联网，4o 还是太成熟了 |
 | 29 liu731 PRO 礼貌请问 OP 内存（ RAM ）多大，学习下。 |
| 31 DreamingCTW 313 天前 @fid #25 还行吧，还得看你硬件的融合方案 |
 | 32 lixile 313 天前 一样的配置 近似版本的系统 32B 对我来说 也几乎没办法使用 内网下还是太弱 楼主 72B 部署成功的话 记得反馈一下方案 和实际效果 我就对照着部署一下 |
 | 33 kennylam777 312 天前 的直接用 ExLlama2 呀, 量化有 2/3/4/5/6/8 bit, 支援多卡, 自或手整 VRAM 分配, 用 text-generation-webui, 生境用 TabbyAPI 即可有 OpenAI compatible API, Concurrent inference with asyncio 能同理多求增加吞吐量。 我就在用配 3090 跑 Qwen2.5 32B 8bit 量化, 32K context window 全也足了, 8 4090 能直接跑 72B 不量化吧, 但 PCIe 有。 |
| 34 kennylam777 312 天前 一提, 我用 4090 已能跑 Qwen2.5 72B 的 ExLlamav2 量化程式(convert), 4/5/6bits 等等模型在本地便生成, Huggingface 上也有很多已量化好的 exl2 模型 |
| 36 fid OP @kennylam777 #33 目前方案是 8x4090+Qwen2.5-72B-Instruct-AWQ+lmdeploy ，体验良好，占用低 |
| 38 fid OP |
Select Language