最近我一直在让我的3090全力运行,同时运行大语言模型(LLMs)以及各种照片和视频生成模型。今天,我有点恍然大悟:就原始吞吐量和效率而言,我可能最好将本地硬件用于照片生成,而依靠API来运行大语言模型。原因如下。
在大语言模型方面,我根据任务运行参数从140亿到320亿不等的模型。在我的设置下,平均每秒大约能得到18到20个标记(tkps)。如果我让GPU连续24小时满负荷运行,理论上一天能生成大约170万个标记。为保守起见,并考虑到预处理或其他低效因素等开销,我们把这个数字向下取整到每天150万个标记。
另一方面,在照片生成方面,我的设备每分钟能生成大约3张图片。如果不间断运行24小时,一天大约能生成4000张图片。
现在,关键来了:如果我使用像Open Router的QwQ 32这样的API来生成同样数量的标记,每天大约花费1美元。
照片生成API通常每张图片收费约0.04美元。按照这个价格,生成4000张图片每天将花费我160美元。这是巨大的差异,这就有力地证明了使用本地硬件进行照片生成,同时将大语言模型任务交给API是明智的。
如果有人知道比每张图片0.04美元更便宜的照片生成API,我很想听听!但就目前而言,这种成本分析让我重新思考如何分配我的资源。也就是让GPU专注于照片生成,并使用API来处理大语言模型。
讨论总结
原帖作者分享自己使用3090的经历,对比本地进行LLM任务和图像生成的效率与成本,认为使用API进行LLM任务、本地进行图像生成更具成本效益。评论者大多认同这一观点,有人补充了云端进行文本生成更便宜快速、只有私密内容适合本地处理等内容,也有人提及其他工具、不同的模型运行情况等。此外,还有一些针对图像生成相关的询问、推荐和好奇。
主要观点
- 👍 认同原帖关于成本效益的观点
- 支持理由:原帖详细计算了本地进行LLM任务和图像生成的理论成果与成本,评论者认为从成本效益角度这样的资源分配是合理的。
- 反对声音:无。
- 🔥 云端文本生成更便宜快速
- 正方观点:与本地硬件运行LLM相比,使用云端API成本更低速度更快。
- 反方观点:无。
- 💡 单批次LLM使用计算资源占比低
- 解释:评论者指出在特定的计算情况下,单批次的大型语言模型仅使用一小部分计算资源。
- 💡 3090在特定的模型推理下可达到2000 t/s的速度
- 解释:如果以特定的模型推理方式(批次为200的8B FP16模型推理),3090能达到约2000 tokens/秒的速度。
- 💡 推荐Flux Schnell模型用于图像生成
- 解释:评论者推荐该模型,称其虽然被大多数人忽视,但足以胜任绝大多数图像生成任务。
金句与有趣评论
- “😂 Yep. For cost efficient that is totally it.”
- 亮点:简洁地表达对原帖成本效益观点的认同。
- “🤔 Text generation is so much cheaper and faster on the cloud, only makes sense for very private stuff, like second brain processing”
- 亮点:明确指出云端文本生成在成本和速度上的优势以及本地处理的特殊情况。
- “👀 3090 can do around 2000 t/s with batch 200 8B FP16 model inference.”
- 亮点:提供了3090在特定模型推理下的速度数据。
- “😎 如果您追求真正快速的图像生成,我强烈推荐Flux Schnell。”
- 亮点:强烈推荐被忽视但好用的图像生成模型。
- “🤨 你说的应该是“images”,而不是“photos”。”
- 亮点:指出原帖用词错误。
情感分析
总体情感倾向是积极正面的。主要分歧点较少,大多数评论者都认同原帖的成本效益观点。可能的原因是原帖通过详细的数据计算,比较有说服力地阐述了自己的观点,且话题比较聚焦于技术资源分配的理性探讨。
趋势与预测
- 新兴话题:可能会有更多关于Flux Schnell模型在图像生成中的实际表现与应用的讨论。
- 潜在影响:对于那些使用类似硬件进行多任务处理的用户,可能会促使他们重新思考资源分配的方式以达到成本效益最大化。
详细内容:
标题:关于高效利用硬件与 API 进行 LLM 和图片生成的热门讨论
最近,在 Reddit 上有一个引发热烈讨论的帖子,题为“Realized I should use API’s for LLMs and do photos locally with my 3090”。该帖子获得了众多关注,点赞数和评论数都颇为可观。
原帖作者表示,自己一直在用 3090 显卡运行大型语言模型(LLMs)和各种图片、视频生成模型,最近有了新的发现。作者指出,就原始吞吐量和效率而言,或许将本地硬件用于图片生成,而依靠 API 来处理 LLM 任务会更好。
在 LLM 方面,作者运行的模型参数在 140 亿到 320 亿之间,平均每秒能生成 18 到 20 个 token,若 GPU 连续运行 24 小时,理论上一天可生成约 170 万个 token,保守估计并考虑到预处理等开销,约为 150 万个 token 每天。而在图片生成方面,作者的设备每分钟能生成约 3 张图片,连续运行 24 小时约可生成 4000 张图片。
有人提到,使用像 QwQ 32 通过 Open Router 这样的 API 生成相同数量的 token,每天成本约为 1 美元。图片生成的 API 通常每张图片收费约 0.04 美元,生成 4000 张图片每天则要花费 160 美元。这一巨大的成本差异,使得利用本地硬件进行图片生成,并将 LLM 任务交给 API 成为一个有力的选择。
讨论焦点与观点分析:
有人认为,从成本效益来看,这样的选择完全合理,还提到了音频生成和 OCR 方面的类似情况。
有人表示,单批 LLM 仅使用了少量的计算资源,3090 显卡在批处理 200 个 8B FP16 模型推理时能达到约 2000 t/s,并给出了相关建议。
有人分享自己的经历,询问应从何处开始,希望了解更多。
有人建议部署像 Aphrodite 或 vLLM 这样的引擎,并遵循相关说明。
有人提出疑问,这样是否需要 200 倍以上的 kv - cache 存储。
有人给出了一些有趣或引发思考的观点,提供了相关链接,如“什么是多轮射击”的介绍链接和关于 llama.cpp 的相关链接。
有人推荐了 Flux Schnell 模型用于快速图片生成,并分享了自己的使用体验。
有人好奇作者通常生成什么样的图片。
有人指出应该用“images”而非“photos”。
有人好奇为何一天要生成 4000 张图片,是否用于 SaaS。
这场讨论中的共识在于,对于如何更高效地利用资源,大家都在积极思考和探讨。特别有见地的观点如对于不同模型和技术的具体分析,丰富了讨论内容,为参与者提供了更多的思路和参考。
感谢您的耐心阅读!来选个表情,或者留个评论吧!