不要忽略旧硬件上的llama.cpp RPC。5070 Ti和1080 Ti通过千兆以太网的测试结果：实际上功能可用。

直接上结果：我必须在预填充和token生成之间做出选择——没有两全其美的方法。使用UD-Q4_K_XL、q8 kv缓存和96k最大上下文：专注于生成（MTP = 2）：在12k上下文下，预填充350 pp和生成36 tg；专注于预填充（禁用MTP）：在12k上下文下，预填充560 pp和生成19 tg。专注于质量：使用UD-Q5_K_XL、完整kv缓存、96k最大上下文且无MTP：在12k上下文下，预填充380 pp和生成15 tg。 目标：我真的很想试试新的Qwen 3.8 27B模型，但我不想在kv缓存或模型上妥协。这意味着q4 kv不在考虑范围内，任何低于4位量化模型也是如此。由于我的主GPU只有16GB显存，而将负载卸载到CPU上效果极差，我决定看看使用NAS中的GPU能做什么，而不涉及硬件改动。不需要实时聊天。论坛式的交互和异步工作符合我的预期和工作风格。 经验教训：启用MTP绝对会大幅降低预填充速度。比如，立即下降30%。据我了解，这本应是未来PR修复的内容，但我查看的最新ticket是3个月前的。可能不容易修复。显而易见但值得一提：MTP使用显存。因此，如果你需要更多上下文且不介意等待，就禁用MTP。为草稿MTP模型启用kv量化会降低你的可用上下文——这与预期完全相反。不，说真的，每次测试我都会得到这个结果。甚至有一个GitHub issue讨论这个，并解释说这是预期行为。请注意！(https://github.com/ggml-org/llama.cpp/discussions/24102) MTP应用于每个生成循环的末尾。这意味着，你实际上希望最强的GPU是RPC链中的最后一张卡，而不是第一张。这也意味着它会影响你的提示处理，因为传统观念会将强GPU放在前面以提高预填充速度，但现在你得移动它。当我将卡顺序设为CUDA0,RPC0时，最大文本生成速度约为22-25。设为RPC0,CUDA0时，我能够获得超过36个token每秒。通过让5070 Ti处理MTP步骤而不是1080 Ti，实现了巨大的提升。 无法平衡预填充和文本生成。任一方向的跳跃都很大且互斥。最佳选择是优化每个方面，让场景/用例决定使用什么。将功能图想象成U型。 在网络中启用巨型帧。你必须在整个链上执行此操作以避免分段（NIC、交换机、主机/虚拟机管理程序）。 批处理大小有很大影响（老生常谈，我知道）。仅专注于预填充时，最佳速度是512/64。但是，当GPU排列切换并启用MTP时，最佳批处理大小是1536/256。 当我专注于速度而不是输出质量时，我在5070 Ti上使用了超过14GB的显存，而在1080 Ti上只有7.2GB。因此，具有类似带宽的8GB显卡也能同样工作。 未来步骤：仍有很大调整空间。我在做所有这些时运行着KDE，所以如果llama.cpp以无头模式运行，我至少能在5070 Ti上再挤出1-1.5GB显存。 每次扫描只运行了4或5次，且仅在12k上下文下。这足以让我了解什么有效，而无需等待整个晚上。应该足以帮助其他人找到适合自己硬件组合的成功方法。 有许多方法可以增加上下文大小，如果这是期望的话。对我来说，速度下降太多，甚至不值得让它运行过夜。最好找到更高效的解决方案。目前，我将让模型继续将步骤分解为可管理的块。这也符合我自己计划/编写事物的方式。因此，这使我更容易审核/校对。 注意事项：llama.cpp b10362 n-gram推测始终启用（匹配16，最小32，最大64）但未优化；未使用拟合，因为我发现手动调整层分割效果更好；生成（RPC,CUDA为10,19）和预填充（CUDA,RPC为25,10）。5070 Ti在CUDA 13.3上运行，驱动610.57.04，在Fedora 44上使用KDE；1080 Ti在CUDA 12.9上运行，驱动580.126.18，在Proxmox 9.2的PCI直通无头Fedora 44 LXC中运行；Pascal卡，因此没有Tensor核心和糟糕的F16支持；千兆以太网，两台PC之间有一个托管交换机。我将在下面的评论中发布llama-swap配置条目：https://www.reddit.com/r/LocalLLaMA/comments/1vrkxdt/dont_ignore_llamacpp_rpc_with_old_hardware/p4e1fd4/