原贴链接

我进行了一项测试，看能否通过升级存储设置来提升Unsloth 1.58位量化的DeepSeek R1 671B的性能。剧透：成功了！我的令牌生成率几乎提高了三倍，而且在此过程中学到了很多。硬件设置：CPU：Ryzen 5900X（4.5GHz，12核）；GPU：XFX AMD Radeon 7900 XTX Black（24GB GDDR6）；RAM：96GB DDR4 3600MHz（4根不匹配，不理想）；主板：MSI X570 Tomahawk MAX WIFI；操作系统：EndeavourOS（Arch Linux）。存储：单NVMe（BTRFS，主板上）：XPG 4TB GAMMIX S70 Blade PCIe Gen4；四NVMe RAID 0（XFS，通过ASUS Hyper M.2 x16 Gen5卡）：4×2TB Silicon Power US75；关键优化：调度器设置为kyber；read_ahead_kb设置为128以提高随机读取性能；文件系统测试了F2FS、BTRFS和XFS，XFS在RAID阵列上表现最佳。发现与局限：这个结果仅对低上下文大小（约2048）有效，更高上下文会大幅增加内存和显存使用（打算针对更高上下文大小进行更多测试，但怀疑会耗尽内存）；无法充分利用RAID 0速度，在Linux上限为16GB/s，可能是由于PCIe通道限制（主板上的NVMe插槽已满且7900 XTX占用带宽）；最大影响？read_ahead_kb效果最明显，mmap严重依赖随机读取吞吐量，此设置对其影响很大（在一定程度上越低似乎越好）；如果重新做一次？（或者如果从头开始而不仅仅是升级我的主电脑）我会选择Threadripper以获得更多PCIe通道，并且会尝试更快的内存。统计数据：4TB NVME单驱动器和4x2TB NVME Raid - 0的相关测试数据（包含模型、大小、参数、后端、测试类型、每秒处理事务数等数据）。

讨论总结

原帖作者通过升级存储设置来提升Unsloth 1.58 - bit - quantized DeepSeek R1 671B的性能，并分享了硬件、存储、优化关键、结果与限制等内容。评论者在肯定原帖测试结果的基础上，围绕硬件升级（如SSD速度提升、RAM升级、PCI - E线路等）、技术细节（如RAID阵列和XFS参数、Vulkan与ROCm的选择）、动态量化等方面展开讨论，整体氛围比较理性、技术向。

主要观点

  1. 👍 对原帖测试结果表示肯定
    • 支持理由：认可原帖提升性能的测试结果是不错的进展
    • 反对声音：无
  2. 🔥 原测试中的SSD速度可能有提升空间
    • 正方观点：认为使用4个PCIe5.0 SSD组成RAID可能会提升速度
    • 反方观点：无
  3. 💡 质疑在性能测试中使用Vulkan而非ROCm
    • 正方观点：Vulkan允许VRAM溢出到系统内存在此测试不适用，ROCm可能更快
    • 反方观点：无
  4. 💡 特定量化是动态的，2.51位动态量化比unsloth标准q4结果更好
    • 支持理由：有相关测试结果表明2.51位动态量化效果更好，且有文章可查
    • 反对声音：无
  5. 💡 1.58位量化结果较差但也有自身价值
    • 支持理由：原帖中的1.58位量化虽结果差些但也能维持原模型部分能力
    • 反对声音：无

金句与有趣评论

  1. “😂 6T/s for prompt processing and 3T/s for generation! Now we’re slowly getting somewhere!”
    • 亮点：以直观的数据体现了处理速度，表达出积极的态度
  2. “🤔 So there might be (much) room for improvement with a setup with a RAID of 4 PCIe5.0 SSD’s.”
    • 亮点：提出了一种可能提升原测试中SSD速度的方法
  3. “👀 anyone have any idea the T/s you could get with a i7 gen 15 and 192gb of ddr5 memory with 3090, wonder if its worth upgrading my memory to max”
    • 亮点：反映出在硬件升级时对性价比的考量

情感分析

总体情感倾向是积极的，大家对原帖提升性能的测试结果表示肯定。主要分歧点较少，更多是在技术探讨方面，如Vulkan和ROCm的选择、不同量化方式的效果等，这可能是因为讨论者大多是对技术感兴趣的人，关注如何更好地提升性能。

趋势与预测

  • 新兴话题：在不同硬件配置下的性能优化方向。
  • 潜在影响：可能为相关技术爱好者提供更多性能优化的思路，推动类似技术在实际应用中的性能提升。

详细内容：

标题：通过升级存储提升 Unsloth 1.58 性能，速度提升近三倍！

最近，Reddit 上有一篇关于通过升级存储来提高 Unsloth 1.58-bit-quantized DeepSeek R1 671B 性能的帖子引发了热烈讨论。该帖子获得了众多关注，点赞数和评论数不断攀升。

原帖作者进行了一项测试，通过升级存储设置来提升性能，结果令人惊喜，token 生成率几乎提高了三倍，还分享了许多过程中的经验。

讨论的焦点集中在以下几个方面： 有人称赞这一成果，称“6T/s 用于 prompt 处理和 3T/s 用于生成！现在我们慢慢有了进展！” 还有人询问能否用 IQ2XXS 进行基准测试。

原帖作者回应，虽然有更快的 NVME SSD，但这在其预算范围内。对于较大的上下文尺寸，作者还想先尝试，因为 2048 的上下文不太实用，作者希望至少达到 32K 上下文。作者认为在模型加载阶段，原始吞吐量似乎很重要，但运行时可能受 CPU 限制，怀疑是延迟而非其他因素在起作用，随机读取而非顺序读取更关键。

有人好奇如何监控资源，有人给出建议“首先停止使用 Ollama 并切换到 Linux + llama.cpp”。

关于硬件配置，有人询问 RAID 阵列和 XFS 的参数，特别是条带大小，作者进行了详细说明。

有人考虑 i7 第 15 代和 192GB 的 DDR5 内存以及 3090 显卡能达到的速度，也有人分享了自己的配置和性能。

还有人询问为何使用 Vulkan 而非 ROCm，作者解释称 Vulkan 允许 VRAM 溢出到系统内存，而 ROCm 似乎不能，且速度上 ROCm 稍快。

有人比较不同量化方式的效果，称 2.51bit 动态量化比 Unsloth 的标准 q4 效果更好，1.58 稍差但仍有一定表现。

讨论中的共识在于大家对提升性能的探索和交流的热情，不同的观点和经验分享丰富了讨论，为相关领域的爱好者和从业者提供了有价值的参考。

总的来说，这次关于 Unsloth 1.58 性能提升的讨论，展现了大家在技术探索方面的积极性和创造力。