NAS部署本地OCR，数据不出局域网，Hermes喜提免费文字识别能力

Hi，我是执着于持续分享NAS、AI、数码、家电、软件技巧相关知识，坚持创作有深度、高质量作品的博主 设计虱聊科技。期待您的关注。

上篇文章，咱们聊了怎么免费通过 Cloudflare 让 Hermes 拥有免费的 OCR 文字提取能力。还没有看过的小伙伴如果需要云端免费 OCR 方案，可以移步我的往期文章。

我本来以为大家都会倾向于云端的方案，没想到很多粉丝私信我，希望我也试试 NAS 本地部署的方案。

粉丝有要求，安排！

我尝试了好多镜像，终于找到一个适合 NAS 纯 CPU 推理的本地 OCR 方案，分享给大家。

✿ 本地 OCR 的核心价值

一句话：数据不出家门、完全免费。

我们用在线 OCR 工具，数据总会上传到别人的服务器。如果我们处理的是合同、发票、身份证、公司内部文档，用在线服务就真的不合适了。

而本地部署 OCR 工具，所有计算都在本地设备上完成，不离开我们的局域网，识别结果也不上传到任何地方。对于在意隐私的人来说，这个差别很大。

另外一个好处是免费。没有 API 调用次数限制，没有月费，想用多少用多少。

还有一点，中文识别能力会更好。因为这次我们要部署的，是国内某度的产品 PaddleOCR，有天然的中文语言优势。

PaddleOCR 针对中文排版、竖排、表格、手写体做了专门的优化，复杂排版、中英混排、低质量扫描件的识别效果，比通用云 OCR 好不少。如果日常处理的主要是中文内容，本地方案在准确率上是有优势的。

✿ 家用NAS的硬件能否满足要求

这是大家最关心的问题。

我这次是用绿联几年前的NAS DX4600 实测的，它搭载的 CPU 是 Intel N5105、8G 内存，没有GPU。我把它的内存升级到了 16G。如果你的设备配置比我的好，那就完全没问题了。

PaddleOCR 的 CPU 模式对硬件的要求不算高。DX4600 的 Intel N5105 支持 x86_64 架构（但不支持 AVX 指令集），4 核心满足最低要求。

8GB 内存加载模型后会比较满，但正常使用没问题。如果还部署有向量模型或其他比较消耗内存的 Docker 应用，最好和我一样，把内存升级至 16G。

没有 GPU 也不影响，PaddleOCR 支持纯 CPU 推理，只是速度会慢一些。一张普通截图大概 3-5 秒出结果，对于个人使用频率来说完全够用。

✿ 部署过程

我们通过 Docker 来部署 PaddleOCR。绿联 NAS 自带 Docker Compose 管理器，方便部署和管理。

因为绿联 DX 4600 的 CPU Intel N 5105 不支持 AVX 指令集，所以镜像我推荐用使用社区大佬 c403 为不支持AVX指令集的设备专门构建的 c403/paddleocr:2.2.2-noavx。

部署命令：

# docker-compose.yml version: '3' services: paddleocr-noavx: image: c403/paddleocr:2.2.2-noavx container_name: paddleocr-noavx restart: unless-stopped ports: - "5000:5000"

网络端口我设置的是 5000，你可以按自己喜好修改。

配置好后，点击开始部署。拉取比较慢，耐心等待。

大概 3-4 个小时，就下载完成了。如果一直超时，就想其他办法把镜像下载下来，通过镜像管理页面上传到本地镜像后，再去 Compose 部署。

部署成功界面：

✿ 测试效果

部署完之后，需要告诉 Hermes、OpenClaw 这种 AI 助手，直接让他们去对接：

我通过 Docker 在本地部署了 PaddleOCR，接口地址是 http://NAS的IP:5000 ，端点是/ocr，请求方式是 POST，字段名是 img，你测试一下能否正常使用。

剩下的交给 Hermes 就可以了。

我在测试的时候，专门去看了资源占用情况，CPU 占用会短时间达到 100%，但只持续了 1 秒左右，内存占用持续在 500 多 MB，整体表现稳定。

发一张语文阅读题作测试：

效果还不错。但是还可以继续优化。

还记得 Cloudflare 的 OCR 方案吗，Cloudflare 会调用一个 Workers AI 去做错别字和逻辑的最终整理，以确保准确率。

如果你对识别结果要求更高，也可以参照这个思路，调用 LLM 或者本地再部署一个小模型去达到同样的效果。

这一步的配置并不难，我也没这个需求。需要的小伙伴可以自行尝试。

✿ 这些问题要注意

○ 建议升级内存：

8GB 内存的 NAS 加载 PaddleOCR 模型后本身就比较满了，如果你同时还跑着好几个 Docker 服务、向量模型，大概率会卡。

所以建议有条件的话，还是升到 16 G 好一些。

○ 进行资源限制：

可以在 Compose 的命令中，设置资源限制，比如仅使用 2 个 CPU 核心和 4 GB 内存，避免高峰期卡顿。

○ 放低心理预期：

推理速度上，没有 GPU 的话肯定比不上云端，批量处理大量图片会比较吃力，但偶尔用一下，3-5 秒出一个结果，我个人觉得够了。

✿ 和云端方案怎么选

上一篇文章我也写了 Cloudflare Workers + OCR.space 的云端方案。两个方案各有优劣，选哪个取决于你的需求。

如果你主要是处理敏感文档、发票、合同之类的东西，本地方案肯定更放心。

但如果 NAS 配置比较低、不想折腾资源分配，或者只是偶尔扫一下非敏感的资料，云端反而省心。

其实并不矛盾，可以两个都部署。日常轻量用云端，敏感文档用本地。

✿ 我的感受

用了一段时间之后，我现在已经习惯了有什么识别需求就直接丢给 Hermes。它只是 NAS 上跑着的一个 Docker 容器，但每次帮我从图片里把文字扒出来的时候，我都会觉得当初折腾这一通确实值得。

坚持创作有深度、高质量的作品、致力于分享干货、抵制标题党和网络垃圾，是我的座右铭。

关注我，蹲后续。您的支持对我真的很重要O(∩_∩)O）。让我们共同打造互联网内容创作和知识分享的一股清流！ヾ(◍°∇°◍)ﾉﾞ