为什么 Immich 将 OCR 并发设为 2 也会崩？低性能 CPU 的救命稻草。

很多开发者在配置 Immich 的机器学习功能时，看到官方默认的 OCR_CONCURRENCY（文字识别并发数）只有 2，心里难免会想：我的 NAS 好歹也是个四核，区区 2 个并发难道还跑不动？于是直接维持原样甚至调高。

结果，当系统扫描到包含大量文字的照片（如笔记、书稿）时，你会发现 immich_machine_learning 容器的内存占用曲线像火箭一样直插云霄，紧接着就是整个系统的死机。作为一名处理过海量多媒体数据的架构师，我必须告诉你：在 OCR 面前，“并发 2”并不代表轻量，它极可能是压死你低功耗 CPU 的最后一根稻草。

💡 报错现象总结：当 OCR 任务开启后，后台日志显示 [Nest] 7 - DEBUG [Microservices:QueueService] 设置 OCR 并发数为 2。随后 CPU 占用率瞬间锁定在 100%，系统内存耗尽（OOM），后台抛出 worker pool error: process exited with code 137（典型的内存溢出退出）。

---

OCR 的算力黑洞：为什么 2 个并发能吃掉所有内存？

Immich 的 OCR 功能底层依赖于 Tesseract 或类似的深度学习库。与简单的图片缩略图生成不同，OCR 需要将图片转换成高维张量（Tensor），并调用 CPU 的神经网络指令集进行高密度的矩阵运算。

根据社区高赞 Issue 的技术复盘，每一路 OCR 并发不仅会占用一个物理核心，还会根据图片分辨率申请巨大的内存缓冲区。如果你在只有 4G 或 8G 内存的 NAS 上运行，两个并发的 OCR 任务再加上系统本身的微服务开销，足以触发 OOM 机制。

# 案发现场：典型的内存溢出崩溃日志
immich_machine_learning | [04/28 11:47:39] INFO: Loading OCR engine...
immich_machine_learning | [04/28 11:47:45] ERROR: Memory allocation failed for tensor processing.
immich_machine_learning | [04/28 11:47:46] CRITICAL: Worker lost! (OOM Killer triggered)

在不同档位的硬件上，OCR 并发的稳定性反馈如下：

CPU 类型	推荐并发数	预期表现	架构师底层诊断
ARM (树莓派/RK3588)	0 或外部调用	极易导致核心过热死机	浮点运算能力不足以支撑本地 OCR 并发
J4125 / N100	1	稳定但缓慢	缓存（L3 Cache）太小，双并发会产生严重的内存竞争
Intel i5 / i7 (12代后)	2	流畅	拥有足够的指令集带宽和多通道内存支持
企业级 Xeon / EPYC	5+	飞速	I/O 和算力完全匹配，适合百万级图库

---

给低功耗 CPU 降压的“原生态”方案

如果你手头是 N5105 或 J4125 这类常见的 NAS 神机，面对 OCR 导致的崩溃，你不得不进行以下手动干预：

1. 强行限制单并发：在 .env 中明确设置 IMMICH_OCR_CONCURRENCY=1。虽然速度减半，但至少系统不会在深夜悄悄重启。
2. 设置 Swap 交换分区：对于内存小于 8G 的设备，你需要手动给 Linux 挂载一个 4G 以上的 Swap 文件。这能作为 OCR 处理超大图片的“避风港”，防止应用直接被杀掉。
3. 禁用大图识别：如果你不依赖搜索照片里的文字，直接在管理后台的“机器学习设置”中关闭 OCR 选项。这能为相册浏览释放出大量的 CPU 余量。

这种“笨办法”虽然让 AI 功能看起来不再那么“全能”，但在硬件资源极其有限的 NAS 环境下，生存远比炫技重要。

---

获取“低功耗设备专用 OCR 配置文件”

与其让你的 NAS 在不断的崩溃与重启中折磨硬盘，不如直接接入社区优化后的“轻量级”配置。

我已经针对低功耗设备，在 GitCode 维护了一套**《Immich 低功耗硬件 OCR 专项优化包》**。这套配置包含了一组预设的内存限制参数和专门调优过的 Tesseract 运行时配置，能显著降低 OCR 过程中的峰值内存占用。

直接前往 GitCode 访问这个优化包。别让一个默认的“并发 2”参数毁了你的私有云体验，用最克制的配置，换取最稳健的服务。

[获取 GitCode 优化的低功耗设备专用 OCR 配置文件]