OCR

環境與模型 硬體：NVIDIA GB10 模型：Qwen 3.6 27B（Q4_K_M 量化） 推理引擎實測結論 引擎 結果 vLLM ✅ 多人同時連線 8 線、16 線都撐得住——唯一通過考驗 SGLang 理論上更強，但 demo 和實際上線是兩回事，實戰未驗證 Ollama 很快掛掉，必須自己建 queue 排隊處理 LM Studio 單人測試正常，多人一測就爆，試多次都爆 測試過程 一開始放棄 Ollama，改用 LM Studio 先測 OCR：找到可用模型、設定正確的 threads 寫一個循環 Windows script，上網抓發票、表格圖片至少二、三十張 打到 LM Studio API，一張一張跑，單人全部正常 打包給 MIS 相關人員與預使用人員同時測試 → 多人一測，LM Studio 直接爆掉（試多次都爆） 改用 vLLM 版本 → 不再爆 改成無限循環版本（打開就一直送不停），單一 PC 開 4 線、8 線，從週五下班跑到週一早上 → 完全正常，辨識也正確 只有這樣才證明撐得過高峰並發多人使用，這才是企業內真正的實際運用。 應用場景 會計大量作帳、內部文件 OCR：不定時、大量文件 未來：現場設定即時不斷辨識，壓力更大——每 1 分鐘跑一次；30~50 台設備同時上線，沒有高並發直接爆 文件類型 客戶報價單、公司報價單回填、材料相關表格 MES / WMS / SCM 相關文件、產生履歷文件（目標：減少打字時間） 跟發票這種千奇百怪的類型不同：手寫單據、出場、驗收——人寫的，這些真的要靠 AI 高並發 真實場景 一車來三櫃驗收單，一次來二十車，不同廠區同時運作