原贴链接

由于很难在一个地方找到所有大语言模型的最大上下文窗口信息，我创建了一个表格 - 欢迎大家贡献信息！ 相关链接：https://github.com/taylorwilsdon/llm-context-limits

讨论总结

这个讨论是由创建LLM上下文限制表格的帖子引发的。其中包括对表格内容本身的探讨，如Gemini未被列入表格的疑问，有建议添加更多模型信息（原生上下文长度、扩展后的长度），也有指出表格缺少R1提供商相关信息的；还涉及到在相关技术使用过程中的问题，像搭建open - webui实例时配置困难，OWUI存在上下文限制被质疑等；同时包含对一些相关基准测试的看法，以及关于表格适用范围等内容，整体氛围较为理性和平和。

主要观点

  1. 👍 质疑表格创建者未将Gemini加入列表的原因
    • 支持理由：Gemini可能在相关领域有独特地位，与其他内容相比具有特殊性。
    • 反对声音：原作者表明只是因为没使用所以未加入。
  2. 🔥 搭建open - webui实例时配置最大上下文长度信息难查找
    • 正方观点：创建者自身经历，在谷歌或针对性搜索都难找到信息。
    • 反方观点：无（未提及）
  3. 💡 建议在列表中补充原生上下文长度和扩展技术后的最大长度相关内容
    • 支持理由：特定模型原生和扩展后的上下文窗口长度区别虽细微但很重要。
    • 反对声音：无（未提及）
  4. 💡 认为RULER基准测试更准确
    • 支持理由：可列出许多模型真正的原生上下文长度，避免夸大说法导致的性能下降。
    • 反对声音：无（未提及）
  5. 👍 对OWUI存在上下文限制表示不解
    • 支持理由：OWUI是UI不做推理不应有此限制。
    • 反对声音：无（未提及）

金句与有趣评论

  1. “😂 Are you too afraid to add Gemini on that list because it’s in a league of it’s own?”
    • 亮点：以一种诙谐的方式质疑表格创建者未将Gemini加入的原因。
  2. “🤔 Was standing up a new open - webui instance and had to go through one by one not just configuring the maximum context length for each of my dozen or so local and hosted models, I realized how absurdly hard it is to find the info all in one place whether on Google or even a more targeted search like perplexity.”
    • 亮点：生动描述了在搭建open - webui实例时配置最大上下文长度信息查找的困难程度。
  3. “👀 The distinction is subtle but important.”
    • 亮点：简洁地强调了补充表格内容（原生和扩展后的上下文长度区别）的重要性。
  4. “😂 lol you do all this and no one says thanks. Thanks”
    • 亮点：幽默地指出原帖作者工作未得到关注并表达感谢。
  5. “🤔 How does it not?”
    • 亮点：以反问的方式回应关于表格与LocalLLaMA无关的观点。

情感分析

总体情感倾向比较中立。主要分歧点在于表格内容相关，如Gemini未被列入表格的疑问、表格是否应补充更多信息等。可能的原因是大家从不同角度（使用体验、信息完整性等）对表格内容提出自己的看法。

趋势与预测

  • 新兴话题：可能会有更多关于如何完善LLM上下文限制表格内容（如补充R1提供商信息、不同模型的更多参数等）的讨论。
  • 潜在影响：如果表格不断完善，将有助于人们更好地了解LLM的上下文限制相关信息，在进行本地设置、模型选择等操作时能有更准确的参考。

详细内容：

标题：关于模型上下文窗口信息整合的热门讨论

最近，Reddit 上一个题为“Since it’s so hard to find max context windows all in one place, I started a table - contributions welcome!”的帖子引发了广泛关注。该帖子提供了一个链接 https://github.com/taylorwilsdon/llm-context-limits ，并收获了众多讨论。

讨论的焦点主要集中在模型上下文窗口的相关问题。有人提出是否应在列表中添加 Gemini，因为它与众不同；也有人对默认上下文窗口为 2048 令牌这一说法表示怀疑，称自己从未遇到过提交大消息被截断的情况。还有人建议将 RoPE 扩展技术下的原生上下文长度和最大长度纳入列表。

有人认为，如果未在 Open WebUI 中设置值，调用 API 时不会发送最大上下文值，由后端决定默认值。也有人疑惑为何 Open WebUI 会有上下文限制，原帖作者解释称这是为了控制成本，并且由于当前无法进行最大检测。

有用户提到 RULER 基准测试能更准确地测试许多模型的真实原生上下文长度。还有人感谢作者的工作，认为其回答了自己关于输出令牌限制的疑问。

文章将要探讨的核心问题是如何准确获取和设置模型的上下文窗口信息，以及不同模型在这方面的差异和限制。

在讨论中，有用户分享道：“我从未在 Open WebUI 的任何模型或设置页面上调整过最大上下文长度，但从未在提交大量消息时遇到问题（我经常粘贴大量代码和其他文档）。并且我知道它没有被截断，因为 LLM 能够清晰处理所有内容，而且我可以在 OpenRouter 中看到令牌使用情况，它报告说收到了完整的消息。”

也有用户表示：“我相信这完全取决于你所使用的 API。如果是 Ollama 本地主机且未覆盖，就是 2048。如果是 LiteLLM，则在代理处可自定义是否采用直通上下文或在那里设置。其他中间件提供商，如 OpenRouter，可能会有自己的处理方式，我不用它们。”

总之，这次讨论展示了模型上下文窗口这一话题的复杂性和多样性，大家对于如何获取准确信息和进行合理设置存在不同的看法和经验。