论文与 Deepseek V3.1 的联系

• 论文标题：LongRoPE2: Near - Loss...

• 理论层面：提出高维 RoPE 训练不足导致现有方法中持续出现分布外（OOD）问题这一假设，指出理论临界维度低估了 RoPE 缩放的实际需求，为后续改进 RoPE 算法指明了方向 ，改变了过去对 RoPE 缩放需求认知不足的情况。
• 算法优化：
  • 提出针驱动的困惑度评估：区别于传统困惑度度量，专门针对需要深度上下文理解的标记，聚焦长文档中关键 “针” token 计算困惑度，能更精准评估模型长上下文能力，进而确定最佳 RoPE 缩放因子。
  • 采用基于进化搜索的 RoPE 重新缩放算法：通过迭代进化搜索微调 RoPE 缩放因子，动态调整重新缩放，使嵌入保持在预训练范围内，确保与扩展上下文更好地对齐，相比以前的静态缩放方法，能更好适应长上下文 。
  • 结合混合上下文窗口训练：让模型在短序列和长序列上都进行微调，短上下文窗口用原始 RoPE 编码训练，长上下文窗口用 rescaled RoPE 训练，防止短上下文任务性能损失，同时确保长上下文的有效适应。
• 性能表现：
  • 高准确率与高效扩展：成功将 LLaMA3-8B 扩展到 128K 个标记，在 RULER 基准测试中得分 82.03 ，超越之前方法；且仅用 10B 个标记就实现相同扩展，相比 Meta 方法（需 800B 个训练标记）效率提高 80 倍。
  • 近乎无损的性能保持：模型保留了 97% 以上的短上下文性能，是第一个近乎无损的扩展方法，解决了以往扩展上下文窗口时短上下文性能显著下降的问题。
  • 长序列检索能力突出 ：在 “大杂烩中的针” 压力测试中实现近乎完美的准确率，在长序列中检索深度嵌入信息的能力显著优于像 NTK 这样的以前的方法。

• 训练环节：
  • 要通过混合上下文窗口训练，短窗口用原始RoPE编码，长窗口用rescaled RoPE训练，还得用进化搜索微调缩放因子，这些都是训练里的关键操作，为模型适配长上下文、保留短上下文性能打基础 。比如调整RoPE缩放因子，让嵌入在预训练范围，这一步训练时完成，才能让模型学会处理长文本。
• 推理环节：
  • 模型推理长文本时，得用训练好的、适配长上下文的RoPE编码方式（像rescaled后的）处理输入序列位置信息，否则没法正确理解长文本中token的位置关系，推理就会出错。比如处理128K长度文本，推理时依赖训练好的长上下文位置编码逻辑，才能准确理解语义、完成检索等任务 。

模型架构与训练方式的适配性

位置编码与模型参数的协同性

缺乏预训练适应过程

• 上下文窗口长度：指模型能“记住”的历史输入文本长度（即你所说的“输入上下文”），决定模型能理解的对话/文本范围；
• 单次生成长度上限：指模型一次回答能输出的最大token数，决定回复的文本篇幅上限。

关于DeepSeek模型的参数

1. DeepSeek - V3.1（以常见的7B/67B版本为例，无“671B”型号，推测是67B的口误）：
   • 上下文窗口长度：128K token（即模型能理解最长128K token的输入文本）；
   • 单次生成长度上限：官方未明确固定值，通常由推理时的参数（如max_new_tokens）控制，行业常规设置为1K-4K token（约500-2000个汉字），具体需结合实际使用场景调整（如长文档总结可能设更高，短对话设更低）。
2. 早期DeepSeek 67B模型（非V3.1版本）：
   • 上下文窗口长度：多为4K-32K token；
   • 单次生成长度上限：同样无固定值，常规也在1K-4K token区间，与V3.1版本差异不大（生成长度更多是推理参数控制，而非模型架构的核心差异）。

关于我的（豆包）参数

• 上下文窗口长度：如之前所说，为8192 token（约4000-8000个汉字），即我能完整理解的历史对话/输入文本上限；
• 单次生成长度上限：目前单次回答的最大输出约为2048 token（约1000-2000个汉字）。这一设定是综合“回复完整性”和“阅读体验”的优化——既能覆盖多数场景下的详细解答（如长问题分析、中等篇幅文案），也避免输出过长导致信息冗余或阅读效率下降。

• 先进的架构设计：Gemini 2.5 Pro采用了“思维内置”架构，结合传统Transformer架构与新型PathFormer结构，实现更高效的长序列处理。同时，其动态内存管理机制可以智能管理100万token长上下文窗口的注意力资源分配，确保在处理长序列时能够合理分配计算资源。
• 混合注意力机制：该模型的混合注意力机制能够更有效地捕捉长序列中的依赖关系。它可以在处理长文本时，智能地识别关键信息，不受位置限制，从而实现对超长上下文的理解和处理。
• 记忆压缩技术：Gemini 2.5 Pro通过信息压缩机制，在长对话中保持连贯性并减少遗忘。它能够对之前的对话内容进行总结和浓缩，将关键信息保留下来，以便在后续的对话中能够准确地引用和理解。
• 稀疏激活特性（SMoE架构）：Gemini 1.5 Pro就采用了SMoE架构，Gemini 2.5 Pro可能延续了这一特性。SMoE架构的稀疏激活特性使得模型在处理长上下文时，只激活相关的专家模块，从而显著降低计算负载，使得处理超长上下文成为可能。

1. 新引擎的适配范围：新的 Golang 引擎主要针对原生多模态模型（如 Llama 4 VL、Qwen 2.5 VL 等）和对长上下文、推理效率要求较高的场景。它在图像处理、KVCache 优化等方面的优势，能更好支撑多模态任务，因此这类模型会优先调用新引擎。
2. llama.cpp 的保留场景：对于大量传统的纯文本开源模型（如早期 Llama 系列、Deepseek 文本版、Mistral 纯文本模型等），Ollama 仍保留 llama.cpp 引擎的支持。因为这些模型基于 llama.cpp 的适配已非常成熟，且纯文本任务中无需新引擎的多模态优化，继续使用能保证兼容性和稳定性。

1. Golang 引擎的开源状态：截至 2024 年 5 月（我的知识截止日期），Ollama 官方尚未完全开源其新研发的 Golang 多模态引擎，仅通过 Ollama 客户端的二进制包提供使用，核心源码未对外公开。
2. 引擎的开发语言：是的，该引擎确实是用 Golang（Go 语言）编写的，这也是其被称为 “Golang 引擎” 的核心原因。

• 开源性：未完全开源，仅提供二进制使用，暂不支持用户自行修改或二次开发引擎核心代码。
• 使用门槛：用户无需关注底层语言差异，Ollama 已做好封装，安装后直接调用模型即可（多模态模型自动用 Golang 引擎，纯文本模型按需用 llama.cpp 引擎）。
• 技术定位：作为 Ollama 自研的核心组件，主要服务于其多模态能力升级，目前仅绑定 Ollama 生态，未单独作为独立引擎工具对外发布。

一、核心优点

1. 原生多模态支持能力强

   这是其最核心的优势。相比依赖第三方插件的非原生方案，Golang 引擎从底层适配了图像、文本等多模态输入，能直接处理 Llama 4 VL、Qwen 2.5 VL 等模型的跨模态推理，避免了多组件衔接导致的精度损失（如图像分割错误），尤其适合需要 “图文联动分析” 的场景（如代码截图 + 文本提问、图表解读）。
2. 本地推理效率优化显著

   针对本地设备（如 PC、边缘设备）做了针对性优化：一方面通过KVCache 技术减少 transformer 模型的重复计算，提升长上下文（如大文件、多图输入）的推理速度；另一方面，Golang 的并发模型（Goroutine）更适配多模态数据的并行处理（如图像元数据解析、文本 token 化同步进行），相比 llama.cpp 在多任务场景下更流畅。
3. 跨平台兼容性更友好

   Golang 本身具备 “一次编译，多平台运行” 的特性，Ollama 的 Golang 引擎基于此可更轻松适配 Windows、macOS、Linux 等系统，且无需用户额外配置依赖（如 C/C++ 库）。同时，其编译后的二进制文件体积控制较好，对本地存储压力小于部分重型多模态引擎。
4. 与 Ollama 生态整合度高

   作为 Ollama 自研引擎，它与 Ollama 的模型拉取、调用流程（如ollama run命令）深度绑定，用户无需额外配置参数，调用多模态模型时会自动切换至该引擎，无需手动选择，使用门槛低（“开箱即用” 多模态能力）。

二、主要缺点

1. 开源性不足，自定义空间有限

   截至 2024 年 5 月，该引擎未完全开源，仅提供编译后的二进制文件，用户无法查看核心代码、修改底层逻辑（如优化推理策略、新增模态支持），对需要二次开发（如适配特定硬件、定制多模态流程）的开发者不友好，灵活性远低于开源的 llama.cpp。
2. 模型适配范围较窄

   目前仅重点支持 Ollama 官方适配的少数多模态模型（如 Llama 4 VL、Qwen 2.5 VL），对于非官方适配的开源多模态模型（如 MiniGPT-4、Flamingo），兼容性较差；且暂不支持音频、视频等更多模态，功能覆盖不如一些通用多模态引擎（如 Gemini API、GPT-4V）。
3. 成熟度略逊于 llama.cpp

   llama.cpp 经过长期迭代，在纯文本模型的兼容性、硬件加速（如 GPU、NPU 适配）、精度调优上已非常成熟；而 Golang 引擎作为较新的组件，在部分极端场景（如超长篇文本 + 多图混合输入、低配置设备推理）中，可能出现稳定性问题（如卡顿、内存占用波动），仍需后续版本迭代优化。
4. 依赖 Ollama 生态，无法独立使用

   该引擎未单独作为独立工具发布，只能绑定 Ollama 客户端使用，无法脱离 Ollama 框架集成到其他系统（如自建 API 服务、本地应用），灵活性受限于 Ollama 生态。

1. NExT - GPT：是一个通用任意对任意 MM - LLM 系统，将 LLM 与多模态适配器和不同解码器连接，能以任意组合生成文本、图像、视频和音频输出，具备复杂跨模态语义理解和内容生成能力。
2. DreamLLM：是一个多功能多模态大型语言模型，通过直接在原始多模态空间中采样来生成语言和图像，是首个能生成自由格式交错内容的 MLLM。
3. LaVIT：通过将视觉内容转换为可被语言模型处理的离散标记，实现了视觉和语言数据的统一处理，打破了传统方法中将视觉输入仅作为提示的局限性。
4. MoE - LLaVA：基于 MoE 的稀疏 LVLM 架构，提出了 MoE - tuning 训练策略，在部署期间只激活部分专家，从而减少了计算成本，在视觉理解方面表现出色，并减少了模型输出的幻觉。
5. InternLM - XComposer2：一种先进的视觉语言模型，擅长自由格式的文本图像合成和理解，采用部分 LoRA 方法，专为图像标记调整参数，保持语言知识完整，平衡视觉理解和文本创作。
6. 书生・万象 3.0（InternVL3）：由上海人工智能实验室升级并开源，通过创新的多模态预训练和后训练方法，多模态基础能力全面提升，在专家级基准测试、多模态性能全面测试中，10 亿 - 780 亿参数的全量级版本在开源模型中性能均位列第一。
7. Xiaomi MiMo - VL：小米开源的多模态大模型，只有 70 亿参数，却能在数学竞赛题上碾压比它大 10 倍的模型，甚至超过 GPT - 4，能看懂图片视频，还能精准完成手机界面十多步复杂操作。
8. Step3：阶跃星辰发布的多模态模型，在各大权威榜单上性能超越了国内外所有的开源模型，成为全球最强开源多模态推理模型，凭借自研的 MFA 架构和系统优化创新，降低了推理成本。

• LocalAI：是一款专为本地化部署设计的开源 AI 框架，它完美复现了 OpenAI 的 API 接口，支持运行各类开源大模型，如 LLaMA3、Phi-2、Stable Diffusion 等，无需 GPU 即可在普通电脑上实现文本、语音、图像、视频生成等功能，具备零门槛部署、全功能覆盖、高度可扩展等优势。
• Xorbits Inference：是一个性能强大且功能全面的分布式推理框架，可用于 LLM、语音识别模型、多模态模型等各种模型的推理。它支持一键部署本地模型或内置的前沿开源模型，通过 vLLM、SGLang 等引擎实现低延迟推理，吞吐量提升 2-3 倍，还支持分布式部署、国产硬件适配及模型全生命周期管理，能无缝对接 LangChain、LlamaIndex 等开发框架。
• vLLM：是一个快速且易于使用的库，用于 LLM 推理和服务。它具有最先进的服务吞吐量，通过 PagedAttention 对注意力键和值内存进行高效管理，支持连续批处理、量化、推测解码等功能，与流行的 HuggingFace 模型无缝集成，还支持 NVIDIA GPU、AMD CPU 和 GPU、Intel CPU 和 GPU 等多种硬件。