从单GPU升级到双GPU体验不错,但并非如我所料
摘要
作者分享,从单个24GB GPU升级到双24GB GPU后,LLM性能提升并非通过更大模型实现,而是通过并行性:使用一个主编排代理配合多个较小的子代理,从而提高了编码任务的整体吞吐量。
我原本以为,将显存从24GB翻倍到2x24GB后,我就能使用更高量化等级和更多上下文,从而获得更智能的LLM,但结果并非如此。至少对于编码任务来说,我发现从qwen 27B UD-Q4-XL升级到Q6或Q8,质量差异相当小。相反,至少在编码方面,我利用额外算力的方式是并行化。我没有追求更智能的LLM,而是使用带有大量上下文的qwen 27B作为编排器,将任务拆分成更小/更窄的子任务,然后传递给子代理——通常是qwen 35B-A3B,它在任务狭窄且定义明确时表现足够好。这些子代理通常能在115k上下文限制下执行任务,向主代理报告结果后结束,这样我就可以同时运行两个子代理。最终的整体吞吐量大大提高,因为我可以并行运行3个代理,而之前只能运行一个;我不需要为了运行探索或网络研究等次要任务而卸载模型来加载更快的模型;而且大多数情况下这些代理无需压缩即可完成任务。主代理最终仍会压缩,但频率低得多。子代理则很少压缩。我没看到很多拥有超过32GB显存的人讨论这一点,大多数人似乎痴迷于尝试运行100B+的模型,必要时甚至共享系统内存,但实际上,我从那些分而治之、互相审查的小模型中获得了更多价值,而不是试图以不充分的速度运行巨型模型来一次性完成任务。每隔一段时间,我会请一个真正的SOTA闭源模型审查整个项目并列出改进清单,就像偶尔请一位专家顾问做短期项目一样。但大部分工作已经不再需要这样做了。
相似文章
@analogalok:别再盲目信任本地 LLM 的默认多 GPU 设置了,你实际上正浪费 25% 的性能……
基准测试结果对比了 llama.cpp 中针对双 GPU 设置的层并行与张量并行:层模式在预填充(RAG 管道)中快 25%,而张量模式在解码(交互式聊天)中快 16%。
@no_stp_on_snek: 运行本地模型的好硬件发现:两块GPU作为独立实例,优于通过PCIe用Tensor-Parallel连接在一起的那两块……
运行本地AI模型的硬件提示:将两块GPU作为独立实例使用比通过PCIe用Tensor-Parallel连接起来更快,后者比单独一张卡慢了23%。Tensor-Parallel仅对一张GPU无法容纳的模型有益。
@analogalok: 买不起2000美元的GPU这个借口已经彻底失效了。昨天我展示了如何解锁一块企业级16GB……
关于如何使用Kaggle免费的双Tesla T4 GPU(32GB显存)来运行大语言模型并支持超大上下文窗口的指南,涵盖llama.cpp中的多GPU并行策略。
双GPU llama.cpp加速
llama.cpp的一个分支修复了量化KV缓存中的--split-mode tensor问题,在双GPU配置上实现高达40%的速度提升,且无质量损失。
再加一张GPU就获得近乎线性的扩展?有点奇怪
一位用户报告称,在使用Qwen模型进行推理时,添加第二张RTX 3090后实现了近乎线性的性能扩展,在没有NVLink的情况下,解码TPS提升了约1.8倍。