原贴链接

已解决！问题在于必须在HTTP请求JSON中将cache_prompt设置为true，以便llama.cpp缓存提示。默认情况下它是关闭的，而我的客户端https://jan.ai不支持设置cache_prompt。最终我修改了llama.cpp以默认启用cache_prompt，但由于TabbyAPI更快的推理速度，我仍将转向它作为日常使用。

讨论总结

本次讨论主要集中在llama.cpp服务器在处理长上下文（超过8000个tokens）时的性能问题。用户发现问题在于cache_prompt参数未在HTTP请求JSON中设置为true，导致无法缓存提示，从而影响处理速度。通过修改llama.cpp代码默认启用cache_prompt，用户解决了处理速度慢的问题，但仍计划转向使用TabbyAPI以获得更快的推理速度。讨论中还涉及了其他技术细节，如缓存机制、客户端支持、替代方案等。

主要观点

  1. 👍 cache_prompt设置为true可以提高处理速度，但可能导致结果的不确定性。
    • 支持理由：通过缓存提示，避免重复处理相同的提示前缀，只处理不同的后缀，显著提高处理速度。
    • 反对声音：可能导致结果的不确定性，影响结果的一致性。
  2. 🔥 客户端不支持设置cache_prompt，需要手动修改服务器代码。
    • 正方观点：通过修改llama.cpp服务器代码，默认启用cache_prompt，解决了处理速度慢的问题。
    • 反方观点：客户端应提供设置cache_prompt的选项，减少用户手动修改代码的负担。
  3. 💡 计划转向使用TabbyAPI以获得更快的推理速度。
    • 解释：TabbyAPI的推理速度更快，适合日常使用，尽管llama.cpp通过修改代码提升了性能，但TabbyAPI的性能优势更明显。

金句与有趣评论

  1. “😂 qnixsynapse：I send cache_prompt to True for every request which keeps the kvcache.”
    • 亮点：简洁明了地指出了提高处理速度的关键设置。
  2. “🤔 JockY：After rebuilding the issue goes away and prompt processing is as instant as ExllamaV2 / TabbyAPI.”
    • 亮点：展示了通过修改代码解决问题的实际效果。
  3. “👀 fish312：Maybe try koboldcpp, it handles all that automatically.”
    • 亮点：提出了一个自动处理问题的替代方案。

情感分析

讨论的总体情感倾向较为积极，用户通过技术手段解决了性能问题，并对未来的技术选择持开放态度。主要分歧点在于客户端是否应提供更多设置选项，以及是否应转向更高效的API。

趋势与预测

  • 新兴话题：可能会有更多关于自动处理长上下文问题的替代方案的讨论。
  • 潜在影响：对llama.cpp和相关API的性能优化将持续受到关注，用户可能会更倾向于选择性能更优的解决方案。