原贴链接

每个人都喜欢图表，对吧？如果不喜欢，表格是次优选择。|使用的软件|虚拟内存|常驻内存|模型量化|提示评估速率（令牌/秒）|评估速率（令牌/秒）|相对性能| |:-|:-|:-|:-|:-|:-|:-| |KTransformers|714GB|670GB|Q8_0|57.41|5.80|1.946| |KTransformers|426GB|380GB|Q4_K_M|83.02|8.66|1.986| |llama.cpp|976GB|970GB|Q8_0|24.40|2.98|1.000| |llama.cpp|716GB|682GB|Q4_K_M|25.58|4.36|1.000| 这是对llama.cpp和KTransformers在DeepSeek v3上8位和4位量化的一些对照测试和比较总结。测试的版本是在基准测试前几个小时从每个项目的main分支获取的最新版本。 #配置 硬件：

  • AMD EPYC 7773X CPU
  • Nvidia 3090 Ti GPU 软件：
  • Ubuntu 24.04.1
  • llama.cpp构建版本：4722（68ff663a）
  • KTransformers主版本/2.1
  • CUDA 12.8 框架特定设置：
  • KTransformers：使用单个3090 Ti GPU进行部分GPU加速。在2.1版本说明中声称支持8K上下文。
  • llama.cpp：仅使用CPU，64K上下文。 #基准测试设置 使用了一个稍长但不过长、略超过500个令牌的提示，以确保它在KTransformers的处理限制内。这个长度足以对预填充性能进行基准测试。
  • 使用KTransformers默认的300个令牌输出长度来进行生成的基准测试。
  • 为保持一致性，将llama.cpp的输出长度设置为300个令牌。 #调整 KTransformers：
  • 对模型提示两次以进行“预热”，因为它似乎不会锁定内存以防止CPU内存换出。让KTransformers闲置一段时间会导致提示评估速度降低约4倍，令牌评估速度降低约1.5倍。
  • 重新提示可恢复预期性能。
  • 其他设置保持默认值。
  • 根据文档建议设置CPU线程数，而非手动调整确定。 llama.cpp：
  • 在提示前使用默认的“预热”设置。
  • 将块和用户块大小优化为1024，以在预填充和生成性能之间达到最佳平衡。
  • 通过实验确定线程数，并将其设置为测试系统的最佳值。 #观察 #内存需求和上下文处理 DeepSeek V3/R1模型很大，需要大量内存。即使是8位量化，一个671B参数的模型也无法在512GB内存的系统上运行。
  • llama.cpp处理65K上下文需要300GB的内存，这是相当多的。
  • 如果内存可用，llama.cpp能够处理的上下文长度是KTransformers的8倍以上。
  • 在4位量化下，llama.cpp能够处理多达128K的上下文。
  • 由于KTransformers还不支持更大的上下文，其内存扩展效率尚不清楚。 #性能
  • KTransformers在预填充和生成方面都显著优于llama.cpp，这得益于GPU加速。
  • 然而，观察到的2倍性能提升低于KTransformers声称的预期。
  • 这表明KTransformers可能针对特定硬件进行了过度优化，而非整体性能的提升。
  • llama.cpp未针对混合专家（MoE）模型进行优化，这影响了它在本次测试中的性能。 #特性
  • llama.cpp是一个成熟、功能丰富的项目，具有强大的参数控制和稳定的网络API。
  • KTransformers缺少很多参数控制，但有独特的以MoE为重点的特性，包括：
    • 能够减少生成中使用的专家数量。
    • 用于在CPU和GPU资源间放置不同层的详细MoE配置。 #使用和API支持
  • 两个框架都使用它们的命令行“聊天”界面进行了测试。
  • 两者都提供Python API。
  • llama.cpp有一个稳定、完全兼容的网络API。
  • KTransformers的网络界面由于未明确的错误目前不可用。
  • 之前尝试将KTransformers与开放网络用户界面（Open WebUI）一起使用时发现缺少API支持，导致不兼容。 #最终想法 DeepSeek V3/R1的日益流行可能会促使llama.cpp更好地支持MoE模型。在llama.cpp中实施KTransformers的创新可能会显著提高性能。 然而，KTransformers是为类似DeepSeek的模型从头设计的，其性能优势也反映了这一点。但是，在上下文长度、稳定性和可配置性方面的限制使得它对需要更大灵活性的用户缺乏吸引力。 目前，KTransformers更像是一个技术演示，而不是llama.cpp的完全替代品。 两个项目都发展迅速，性能和特性可能在短短几个月内发生巨大变化。

讨论总结

原帖对KTransformers 2.1和llama.cpp在DeepSeek V3上的多方面情况进行了比较。评论者们的态度大多积极，有人称赞项目很棒，有人对原帖内容表示感谢。同时也有不少建设性的意见，如对比较方式的质疑，希望在基准测试中加入新的项目等，还推荐了一些相关的软件工具。

主要观点

  1. 👍 项目很棒
    • 支持理由：无（直接表达赞赏）
    • 反对声音：无
  2. 🔥 对原帖比较KTransformers和llama.cpp的方式提出质疑
    • 正方观点：KTransformers的GPU部分运行模式特殊，影响量化比较的合理性
    • 反方观点：原帖未提及此情况，可能导致比较不准确
  3. 💡 希望原帖的基准测试能加入vLLM
    • 支持理由：丰富基准测试内容
    • 反对声音：无
  4. 👍 推荐ik_llama.cpp
    • 支持理由：在特定CPU上有性能优势
    • 反对声音：无
  5. 🔥 建议尝试SGlang、vllm和TGI
    • 正方观点：可能有更好的效果
    • 反方观点：可能受硬件或软件缺乏的限制

金句与有趣评论

  1. “😂 This project is awesome!”
    • 亮点：简洁直接地表达对项目的喜爱。
  2. “🤔 I really don’t think you can directly compare KTransformers’ Q8_0 quantization with llama.cpp in this case.”
    • 亮点：对原帖比较方式提出理性的质疑。
  3. “👀 You can also try ik_llama.cpp, it has my MLA path already merged, 2x faster prompt processing (at least on my Epyc Genoa CPU), tg is also faster compared to regular llama.cpp.”
    • 亮点：详细介绍推荐项目的优势。
  4. “🤔 Excelent! Thanks a lot but would mind to try SGlang, vllm and TGI too?”
    • 亮点：在肯定原帖的基础上提出新的尝试建议。
  5. “😂 Your thorough post and information is very much appreciated - thank you.”
    • 亮点：表达对原帖内容的感激。

情感分析

总体情感倾向积极，大部分评论者对原帖内容表示肯定、赞赏或者感谢。主要分歧点在于原帖对KTransformers和llama.cpp的比较方式是否合理，可能的原因是原帖未全面考虑KTransformers的GPU运行模式对量化比较的影响。

趋势与预测

  • 新兴话题：在基准测试中加入更多项目（如vLLM）以及对新推荐软件工具（如ik_llama.cpp）的进一步探索。
  • 潜在影响：有助于相关软件在性能优化、功能扩展方面的发展，为用户提供更多选择。

详细内容：

标题：KTransformers 2.1 与 llama.cpp 在 DeepSeek V3 上的比较引发热议

在 Reddit 上，一则关于“KTransformers 2.1 与 llama.cpp 在 DeepSeek V3 上的比较”的帖子吸引了众多目光。此帖详细罗列了一系列对比数据，并对多个方面进行了深入探讨，获得了大量的关注和众多评论。

帖子主要对比了 KTransformers 和 llama.cpp 在虚拟内存、常驻内存、模型量化、提示评估速率和评估速率等方面的表现，还介绍了硬件和软件的配置、基准测试的设置、调优和调整情况以及最终的观察结果，包括内存需求、性能表现、特色功能、使用和 API 支持等。

讨论焦点主要集中在以下几个方面： 有人称赞这个项目很棒，并探讨了关于获取特定量化版本以及使用 mmap 解决系统内存不足的问题。也有用户表示自己只是普通用户，对于一些数据的来源不太清楚。还有人提到了 ik_llama.cpp 的优势，比如更快的提示处理速度，以及不同的量化类型等。

有人分享了个人经历和案例，比如“对于参考，这里是我在 ik_llama.cpp 中分配 64K 和 128K 上下文时的数字。n_ctx = 128000，CPU KV 缓冲区大小 = 16203.13 MiB，CPU 计算缓冲区大小 = 64468.01 MiB，n_ctx = 64000，CPU KV 缓冲区大小 = 8101.57 MiB，CPU 计算缓冲区大小 = 32343.01 MiB”。

有趣或引发思考的观点如“不幸的是，ik_llama.cpp 似乎是从一个相当过时的 llama.cpp 版本分叉出来的，并且此后差异很大。不知道是否仍然有可能将两者合并成一个‘科学怪人’，保留 ik_llama.cpp 的原始数字处理能力（至少对于 CPU 而言），但保留 vanilla llama.cpp 的网络界面，更重要的是 OpenAI API 兼容的工具调用”。

讨论中的共识在于认可这个对比测试的价值和意义，同时也指出了两个框架各自的优势和不足。特别有见地的观点是关于如何进一步优化和改进两个框架，以满足不同用户的需求和硬件条件。

总之，这次关于 KTransformers 和 llama.cpp 的讨论为相关技术的发展和应用提供了丰富的参考和思考方向。但目前，两个框架都还有改进和提升的空间，未来的发展值得持续关注。