我的公司打算为员工部署一个聊天机器人(由于安全问题要禁用ChatGPT)。我们有大约5000名员工,其中办公室员工大概3000名。目前,我正在8个A100(40GB)上运行Llama 3.1 405B AWQ,并使用Gradio前端为大约100人做试验。运行状况良好,但我担心它无法扩展。
Gradio不是最好的前端,但我们没钱构建更好的。它扩展到每天约40000个请求时会怎样?不管我用什么,它都得让没有前端经验的我能轻松编辑,还得允许自定义功能。我正在考虑huggingchat UI,如果需要的话,暂时忽略任何RAG或自定义功能。
我正在对一些保存的聊天历史进行吞吐量测试,看起来我们目前的设置每小时只能处理1000个请求。
我也在测试Llama 3.1 70B,根据我的配置,每小时能处理4000 - 6000个请求。
人们实际使用聊天机器人的频率是多少?现在,我估计如果我们为3000人部署,1000 - 1500人会实际使用并平均每天提交20个请求。即每天20000 - 30000个请求或者每小时2000 - 3000个请求。我的估计有多准确?
我是一个独立开发者,试图为同事提供一个替代方案,我利用业余时间做这个,因为我对这个项目充满热情(在公司这也有回报)。不幸的是,由于安全问题,我们的IT部门打算禁用ChatGPT,我想确保我的同事有一个可行的替代方案。我几乎没有预算可用,所以任何关于扩展我们聊天机器人解决方案的建议或指导都将非常感激!
讨论总结
原帖作者所在公司因安全问题要封禁ChatGPT,作者想为约3000名办公室员工部署聊天机器人,目前在试用Llama 3.1 405B AWQ,但担心无法扩展,且自己作为单人开发者预算有限。评论者们纷纷给出建议,涉及模型的选择(如推荐70B版本而非405B版本)、前端的更换(如推荐open - webui)、技术架构的调整(如使用vllm后端)等方面,总体氛围是积极提供解决方案的。
主要观点
- 👍 推荐vllm后端和librechat前端解决原帖需求
- 支持理由:几乎不需要做什么工作,是即拖即用的,唯一技术工作就是部署它
- 反对声音:无
- 🔥 不建议采用Llama 3.1 405B版本,推荐使用70B版本
- 正方观点:405B版本是过度使用,70B版本更适合原帖规模
- 反方观点:无
- 💡 可设置前端并发请求限制和负载均衡前端应对负载问题
- 解释:可有效解决原帖作者担心的负载问题
金句与有趣评论
- “😂 Theendangeredmoose: vllm backend, librechat frontend. Sweet fuck all work involved if you use those, they’re drag and drop ready to go. Only technical work would be deploying it”
- 亮点:形象地表达出使用这两者工作量极小
- “🤔 AlexByrth:Llama 3.1 405B is a total overkill. Just don’t do it.”
- 亮点:简洁明了地指出405B版本的不合适
- “👀 MachineZer0:We just started serving a 14B finetune. Running at bf16 on vLLM we run lots of batches at the moment and can crank out 10,800 requests per hour on a single A100 and 14,400 requests per hour on a single H100. Avg tokens 2000.”
- 亮点:分享了实际的14B微调模型处理能力数据
情感分析
总体情感倾向是积极的,大家都在为原帖作者出谋划策。主要分歧点较少,可能的原因是原帖是一个比较具体的技术问题寻求帮助的场景,大家更多是基于自己的经验提供解决方案而非争论。
趋势与预测
- 新兴话题:可能会有更多关于如何在有限预算下优化聊天机器人性能的讨论。
- 潜在影响:如果这些建议被采纳,可能会影响原帖作者公司内部聊天机器人的部署成功与否,也可能对其他面临类似情况的公司有借鉴意义。
详细内容:
《关于大规模 LLM 部署的热门讨论:挑战与解决方案》
近日,Reddit 上一则关于公司大规模部署 LLM(大型语言模型)的帖子引发了广泛关注。帖子作者所在公司计划为约 3000 名办公室员工部署聊天机器人,并禁止使用 ChatGPT 以规避安全问题。目前作者在 8 个 A100(40GB)上运行 Llama 3.1 405B AWQ 并以 Gradio 为前端进行了约 100 人的试用,但担心无法扩展规模。此帖获得了众多点赞和大量评论。
讨论焦点主要集中在以下几个方面: 有人推荐使用 vllm 后端和 librechat 前端,认为这样几乎无需费力就能搭建。还有人建议使用 Nvidia-NIMs 以实现更便捷的部署和自动扩展。
在模型选择上,不少观点认为 Llama 3.1 405B 有些过度,推荐使用 Llama 3.1 70B 并考虑开源解决方案。例如,有人提到 H2O - AI 的相关开源项目。
对于如何提高处理能力,有人提出设置并发请求限制和使用负载均衡器,也有人建议采用 Kubernetes 部署服务。
在前端选择上,OpenWebUI 被多次提及,有人认为其具有更好的功能和可定制性。
有人分享了自己使用 vLLM 服务 LLM 的经验,指出其速度快且容错性强。
但也有人提出反对意见,认为这对于个人而言是一项全职工作,需要高层支持和团队协作,否则可能面临诸多风险。
讨论中的共识在于,要确保模型选择和部署方案能够满足公司的需求和实际情况,同时要充分考虑安全、性能和成本等因素。
特别有见地的观点如有人详细阐述了通过缓存常见请求、选择合适模型大小、采用推测解码和请求批处理等方法来大幅提高处理能力。
总体而言,这次关于大规模 LLM 部署的讨论十分热烈,为面临类似问题的人们提供了丰富的思路和解决方案。但最终的选择仍需根据具体情况权衡利弊。
感谢您的耐心阅读!来选个表情,或者留个评论吧!