摘要
我在 n8n Cloud Starter 上遇到了可重現的 OOM 當機問題，即使負載很小（約 1-2 MB 的二進位檔案）也會發生。當機點在不同執行中在程式碼節點和 AI Agent 之間波動，這強烈暗示是共享工作執行緒資源波動，而不是使用者程式碼的錯誤。
相同的工作流程 JSON 在自託管環境（Docker，8 GB 主機）上運行完美 — 30+ 次執行，零當機。
環境
- 方案：Cloud Starter
- 例項：
verma-digital.app.n8n.cloud - n8n 版本：2.20.7 (Cloud)
- 節點：
@n8n/n8n-nodes-langchain.agentv1.8 - 模型：
gpt-4.1-mini
可重現的測試 — 最小化 8 節點工作流程
Manual Trigger
→ Code "Prepare Test Data"
(via helpers.httpRequest({encoding:'arraybuffer'}) 逐個擷取 URL
+ helpers.prepareBinaryData，每個檔案發出 1 個項目，包含二進位資料)
→ Switch by MIME (PDF / Image / Fallback)
→ Extract from PDF (僅 PDF 分支) → Merge (附加，3 個輸入)
→ Code "Aggregate"
(將項目收集到單一輸出：json.text + binary.data_0,
data_1, ... for AI Agent)
→ AI Agent (passthroughBinaryImages: true)
→ OpenAI Chat Model
無 Postgres 記憶體，無工具，無儲存子工作流程。在仍能重現問題的前提下，這已是最小化的。
我很樂意分享完整的工作流程 JSON。
測試結果
| 輸入 | 總二進位大小 | 結果 |
|---|---|---|
| 2 個小圖示 (webp) | 約 40 KB |  總是成功 |
| 2 個小型 PDF (176 + 63 KB) | 約 240 KB | 總是成功 |
| 1 個 PDF (2.6 MB，5 頁) | 約 2.6 MB |  當機 |
| 2 張影像 (1.56 MB + 810 KB webp) | 約 2.4 MB | 當機 |
臨界點應在約 240 KB 至約 2.4 MB 的單次執行總二進位大小之間。即使只有一個 2.6 MB 的二進位檔案（僅一個 helpers.httpRequest 呼叫），當機也會發生，所以這不是累積性的多重擷取洩漏。
有趣的部分 — 非確定性當機點
相同的輸入，相同的工作流程，相同的執行路徑：
- 執行 1：在程式碼節點
Prepare Test Data當機（在helpers.httpRequest/prepareBinaryData期間） - 執行 2：在 AI Agent 節點當機（在
passthroughBinaryImagesbase64 處理期間） - 執行 3：再次在程式碼節點當機
- （等等）
兩種當機模式都產生相同的 UI 錯誤：
執行在此節點停止
在執行此程式碼期間，n8n 可能耗盡了記憶體。
展開「其他資訊」僅顯示 n8n 版本 + 時間戳。沒有可見的堆疊追蹤。
如果這是使用者程式碼的錯誤，當機在每次執行時都會在同一節點發生。事實上，在相同輸入下當機點不同，這強烈暗示共享工作執行緒資源壓力。
控制測試 — 自託管環境運行良好
我將相同的工作流程 JSON 匯入到自託管 n8n（Docker，n8n 2.20.7，8 GB 主機），使用相同的外部服務（Supabase、OpenAI）。
結果：在上述所有失敗案例中執行了 30+ 次 — 零當機。包括一個 4.7 MB PDF + 2 個大型影像同時運行。
這將原因隔離到雲基礎設施，而不是工作流程或我的程式碼。
問題
-
有其他人在 Cloud Starter 上遇到過這種情況嗎？特別是在使用二進位擷取 + AI Agent passthroughBinaryImages 的工作流程中，出現 sub-MB 到 low-MB 負載的間歇性 OOM？
-
Starter 上是否有未記錄的每次執行記憶體預算，低於公告的 1 GB 工作執行緒記憶體？觀察到的約 2 MB 二進位當機相比之下小了三個數量級。
-
helpers.httpRequest({encoding:'arraybuffer'})或prepareBinaryData是否有超過緩衝區大小的已知記憶體開銷？ -
LangChain Agent v1.8
passthroughBinaryImages是否有已知問題會在輸入 > 1 MB 時尖峰記憶體？ -
升級到 Pro 會在很大程度上改變情況，還是相同的共享基礎設施也會影響 Pro？
我真的很想留在 Cloud 上（我們想避免自託管的維護開銷），但現在 Starter 對我們的使用案例不穩定。
我很樂意提供：
- 完整的工作流程 JSON
- 失敗的執行 ID（供 n8n 團隊提取伺服器端日誌）
- 額外的測試資料點（更小的負載、二分搜尋等）
感謝任何見解！