原贴链接

我想要部署一个本地基于大型语言模型（LLM）的光学字符识别（OCR）系统，用于读取我的文档，然后将其存入向量数据库。Mistral OCR有相关新闻，但我还无法在本地部署它。有什么推荐吗？我有48GB显存，很快会再增加48GB。我无法让它运行并连接到vllm。如果我能以某种方式将其转换为ollama模型，那我的工作就轻松多了。关于这个有任何帮助吗？我可以租用一个H100集群几个小时来转换它，或者我能否向别人请求转换？

讨论总结

原帖作者想要部署本地基于大型语言模型（LLM）的光学字符识别（OCR），将文档内容放入向量数据库，目前在Mistral OCR部署上遇到困难并希望能转换为ollama模型。评论者们纷纷给出不同的推荐，包括Qwen - VL 2.5、paddlerocr、olmOCR、Omnipage、Ovis2等，也有人提供了相关网址。同时，有评论者指出OCR问题复杂，不存在通用解决方案，还需考虑数据结构等因素。整体讨论氛围比较积极，大家都在为原帖作者出谋划策。

主要观点

  1. 👍 推荐Qwen - VL 2.5（在不卸载情况下用能适配的最大参数规模）
    • 支持理由：未提及具体理由，可能基于其在OCR方面的综合性能表现
    • 反对声音：无
  2. 🔥 建议使用tabbyAPI运行Qwen2.5 - VL
    • 正方观点：未提及具体正方观点，可能基于该API与Qwen2.5 - VL的适配性及运行优势
    • 反方观点：无
  3. 💡 推荐paddlerocr
    • 支持理由：速度快且准确
    • 反对声音：未按照原帖需求推荐基于LLM的OCR
  4. 🤔 推荐olmOCR作为本地部署基于LLM的OCR的选择
    • 支持理由：可能解决原帖作者Mistral OCR无法本地部署等问题
    • 反对声音：无
  5. 😎 推荐Omnipage用于OCR
    • 支持理由：在OCR方面表现非常出色
    • 反对声音：未涉及帖子中模型转换及硬件资源相关内容

金句与有趣评论

  1. “😂 推荐Qwen - VL 2.5 with the largest parameter size you can fit without offloading。”
    • 亮点：明确给出Qwen - VL 2.5的推荐使用方式
  2. “🤔 非LLM基于的paddlerocr是快速且准确的。”
    • 亮点：推荐了非基于LLM的OCR软件且强调其优点
  3. “👀 might be worth looking at olmOCR from AI2”
    • 亮点：为原帖作者提供了一个可能的解决方案
  4. “😏 just get omnipage. it does OCR very well.”
    • 亮点：简单直接地推荐Omnipage
  5. “🧐 Ovis2, even the 1b model is able to do ocr pretty well”
    • 亮点：指出Ovis2的1b模型在OCR方面的能力

情感分析

[总体情感倾向是积极的，大家都在积极为原帖作者提供解决方案。主要分歧点在于推荐的软件是否基于LLM以及是否考虑到原帖作者的硬件资源、模型转换等问题。可能的原因是大家从不同的角度出发，有的注重软件本身的性能，有的注重是否符合原帖作者的特定需求]

趋势与预测

  • 新兴话题：[可能会进一步讨论不同推荐软件在特定数据类型（如图像、表格、PPT等）上的OCR表现]
  • 潜在影响：[如果能确定一个较优的本地基于LLM的OCR方案，可能会影响到其他有类似需求的用户，提高他们处理文档并构建向量数据库的效率]

详细内容：

标题：探索最佳的基于 LLM 的 OCR 开源项目

在 Reddit 上，有一个引发热议的帖子，题为“ What is the best LLM based OCR open source available now? ”。此帖主要讨论了部署本地基于 LLM 的 OCR 来处理文档并将其放入向量数据库的问题。该帖子获得了众多关注，评论也十分热烈。

讨论的焦点主要集中在各种推荐的 OCR 模型和方法。有人推荐了 Qwen-VL 2.5 ，并详细介绍了如何运行它，比如“我建议运行它时使用tabbyAPI。例如，这是我运行 Qwen2.5-VL 的方法：cd ~/tabbyAPI/ &&./start.sh –vision True –model-name Qwen2.5-VL-72B-Instruct-8.0bpw-exl2 –cache-mode Q8 –autosplit-reserve 512 –max-seq-len 81920 。由于超过 64K 模型质量会明显下降，我预留了 16K 用于输出，64K + 18K = 80 （且 1024 * 80 = 81920）。由于自动内存分割的一个 bug ，需要添加--autospilt-reserve 512选项预留 512MB 。我在四个 3090 GPU 上运行 Qwen2.5-VL-72B ，但如果使用 4bpw EXL2 量化和 Q4 缓存，在两个 24GB 卡上运行应该也是可行的。”

也有人将不同模型进行对比，比如“有人问：你对比过 72b 模型和 7b 模型吗？我发现 7b 在做 OCR 时已经非常出色，很难想象 72b 是否值得运行。”

还有人提出其他的选择，比如“有人说：非 LLM 基于的 paddlerocr 快速且准确。”“有人问：还有什么其他选择。我的数据可能有图像、表格、PPT 等。准确性很重要。”

甚至有人表达了无奈，“有人说：我会在设置过程中崩溃的。”

也有不少具体的推荐，比如“有人说：可能值得看看 AI2 的 olmOCR 。”“有人说：直接用 omnipage ，它的 OCR 效果非常好。”“有人说：Ovis2 ，即使是 1b 模型也能够很好地进行 OCR ，如果能让 32b 模型运行，效果会更好。”还有人提供了网址“[zetaerre] https://olmocr.allenai.org ”

在这场讨论中，大家对于不同模型的适用性和效果存在不同看法。有人认为某些模型在特定场景下表现出色，而有人则更注重通用性和准确性。共识在于都在努力寻找最适合自己需求的 OCR 解决方案。一些独特的观点如“OCRing 是一个非常复杂的问题。不存在一种通用的方法。其效果很大程度上取决于数据的结构。比如，如果所有文档格式相同，可以使用 OCR 模板。如果不同，事情就会困难得多。所以，仅仅指向一个软件是不够的，需要更好地理解问题和解决方案的空间，才能做出最优选择。”丰富了讨论的深度和广度。

总的来说，这次关于基于 LLM 的 OCR 开源项目的讨论为有相关需求的人提供了丰富的参考和思考方向。