[BUG]: Consistent crash in bundled onnxruntime-node during document processing on macOS 27 beta (EXC_BREAKPOINT in BFCArena::Extend)

快速结论：在 AnythingLLM Desktop 中通过 API 批量上传文档时，负责嵌入的 Helper 进程会在 1-3 次真实处理请求内稳定崩溃，报错指向 onnxruntime 的内存分配器：EXC_BREAKPOINT in BFCArena::Extend。优先排查是否为 macOS 27 beta 上 onnxruntime 内存分配逻辑触发，以及系统可用内存是否在嵌入过程中被耗尽。

适用环境：AnythingLLM Desktop v1.15.0，macOS 27.0 beta（26A5388g），Apple M1 Max（10 核），64GB RAM。

最快修复方案：暂无确认的一步修复方案。Issue 关闭时未提供明确验证过的官方修复补丁或配置项，仅推测为内存分配边界问题，并提及可能将内存缩放逻辑改为可配置项。

注意事项：以下方法与结论均未在 Issue 中被明确验证，属于推测方向：降低 worker 数量、删除本地 ONNX 模型缓存、切换向量搜索模式等已被用户测试且无效；不要盲目相信“64GB 内存足够”的假设，崩溃发生在 onnxruntime 的 BFCArena::Extend 分配路径，可能与 macOS 27 beta 的进程内存管理变化有关。

问题场景

用户运行 AnythingLLM Desktop v1.15.0，在 macOS 27.0 beta 上通过 Developer API（/api/v1/document/upload）批量上传文档时，AnythingLLM Helper 进程稳定崩溃。崩溃与文件内容无关，即使 1KB 的小文件也会触发；GUI 上传器和主应用不受影响，仅处理嵌入的 Helper 进程退出。之前同机同系统曾成功处理 12,000+ 文档，次日开始持续失败。

报错原文

[BUG]: Consistent crash in bundled onnxruntime-node during document processing on macOS 27 beta (EXC_BREAKPOINT in BFCArena::Extend)

Crash signature: EXC_BREAKPOINT (SIGTRAP) in Electron Framework,
originating in onnxruntime::BFCArena::Extend -> CPUAllocator::Alloc
during a Tensor allocation inside an Add kernel execution
(onnxruntime::Add<float>::Compute).

原因分析

崩溃发生在 onnxruntime 的 BFCArena::Extend 调用 CPUAllocator::Alloc 进行 Tensor 分配时，属于 EXC_BREAKPOINT（SIGTRAP）类型的异常。可能原因包括：

onnxruntime-node 内置模块在 macOS 27 beta 上的内存分配行为与系统内存管理不兼容，触发了运行时断言。
嵌入模型（Xenova/all-MiniLM-L6-v2）在批量处理时内存占用超过某个阈值，导致 BFCArena 扩张失败；但用户物理内存为 64GB，且单 worker 时同样崩溃，因此单纯“内存不足”的假设证据不足。
该问题与 issue #5936 相似，但 #5936 在 48GB M4 上已确认修复；本机内存更高且依旧崩溃，说明可能不是简单的内存容量限制，而是 beta 系统下的另一回归。

环境排查

确认 AnythingLLM Desktop 版本为最新（Issue 时为 v1.15.0）。
确认操作系统版本为 macOS 27.0 beta（26A5388g）。
确认芯片与内存：Apple M1 Max，64GB RAM（10 核，8 性能 + 2 能效）。
确认崩溃仅发生在通过 API 上传文档并触发嵌入时，GUI 上传器是否同样崩溃也需要测试验证。
检查是否存在与 onnxruntime-node 版本绑定的缓存模型目录（Xenova/all-MiniLM-L6-v2），删除后让应用重新下载是否仍复现。
尝试将 worker 数量调整为 1，验证崩溃是否与并发相关（Issue 中已确认无效）。

解决步骤

先排除已确认无效的步骤：worker 数量降为 1、强制退出并重启应用、重启系统、检查本地网络权限、确认应用版本、重新下载 ONNX 模型缓存、切换向量搜索模式（Accuracy Optimized / Default）——这些操作均无法避免崩溃。
观察系统内存压力：在崩溃前通过 Activity Monitor 记录 Helper 进程的物理内存占用，确认是否在 BFCArena::Extend 崩溃前内存接近某个上限。
可优先尝试将嵌入工作改为 GUI 上传器而非 Developer API 批量上传，判断是否仅 API 路径触发（Issue 中描述 API 触发，但 GUI 未进行同样强度的验证）。
如果可能，将 macOS 27 beta 降级或回退到稳定版系统，测试 onnxruntime 崩溃是否消失。
关注 AnythingLLM 官方后续 release 中是否包含对 onnxruntime-node 内存分配逻辑的缩放或配置项；评论中维护者提到“scale it to memory or make it a config for this edge case”，但尚未落地为明确补丁。
如果属于内部工具部署，可考虑在批量上传前分批发请求，降低单次嵌入的并发压力，观察是否能延长崩溃间隔。

验证方法

修复后应确认：连续通过 /api/v1/document/upload 上传超过此前稳定崩溃次数的文档（例如 3 次以上），Helper 进程不再退出，crash report 不再出现 EXC_BREAKPOINT in BFCArena::Extend；同时主服务仍能正常响应 curl 请求，嵌入结果正确写入向量库。