目前市面上探討 ERP 導入 AI 的內容，多數出自 ERP 廠商，結論亦頗為一致：無須汰換既有系統，透過 API 串接並外掛 AI Agent 即可。此一論述本身並無錯誤，卻略過了成本最高、也最容易失誤的另一半——這些 ERP 資料，最終將在哪一台機器上運算。
另一方面，討論地端大型語言模型硬體配置的內容，談的多是 Llama、Qwen 等通用推論情境，鮮少將 ERP 場景納為前提。市場因而形成一道明顯的斷層：熟悉 ERP 者不涉硬體，熟悉硬體者不涉 ERP。本文所要補足的，正是中間這一段。
本文的立論基礎在於實作經驗。MAQ 的進銷存、採購、訂單、電子發票與成本報表系統均為自行開發並每日運行，AI 亦已導入其中。以下所述之判斷與限制，多數來自這套系統的建置過程。
一、多數情況並不需要訓練專屬模型
關於導入 AI，最常見的誤解是認為必須以公司資料訓練（fine-tune）專屬模型。就 ERP 場景而言，約九成的需求不應採用微調，而應採行檢索與工具呼叫的架構。
原因在於資料的時效性。ERP 的庫存、營收與成本每日皆在變動，微調是將知識固化至模型權重之中，資料一旦更新即告過時，而每日重新訓練並不具可行性。檢索與工具呼叫則於每次查詢時即時取用當下資料，在架構上即能跟上變動。
就硬體銷售而言，此一結論實際上調降了所需規格，因為訓練用主機的成本遠高於推論用主機。但事實確係如此：ERP 問答所需的，是一台能夠承載推論的主機，而非一台能夠承載訓練的主機。
二、四種資料接法與各自的取捨
將 ERP 資料交由 AI 使用，實務上有四種路徑。多數專案最終採混合方式，惟各路徑的代價須先行釐清。
| 做法 | 適合什麼 | 代價 |
|---|---|---|
| 唯讀檢視表（View） | 報表類查詢；不想動原系統一行程式碼 | 只能查預先開好的欄位，新需求要再開 |
| 固定工具（Function Calling） | 庫存、進價、客戶歷史這類明確問題 | 要一個一個寫；沒設計過的問法會答不出來 |
| RAG 向量檢索 | 合約、規格書、SOP 這類文件問答 | 不適合精確數字；算錯帳的風險高 |
| Text-to-SQL | 探索式分析、開發者自用 | 會編造。不建議用在對外或對帳場景 |
MAQ 採行的是第二種路徑。後台 AI 配置了 11 項定義明確的唯讀查詢工具，涵蓋庫存查詢、最近進價與供應商、客戶歷史採購、年度營收與熱銷排行等。SQL 語句全數固定於程式碼中，模型僅能選擇工具名稱與結構化參數，白名單之外的呼叫一律回傳錯誤。
此一設計自有代價：遇到未經設計的問法，系統會直接回覆查無資料，而不會勉強作答。這正是設計的目的。Text-to-SQL 在展示情境中表現亮眼，但其產出的數字並不足以支撐對帳作業。在 ERP 場景中，無法作答屬可接受的結果，作答錯誤則否。
三、關鍵分岔點：運算的位置
這是整個導入過程中最應優先決定、卻最常被略過的一項。ERP 所承載的內容包括報價與成本結構、客戶名單、供應商條件與人事薪資，幾乎涵蓋一家公司最不欲外流的全部資訊。
將這些資料傳送至雲端 API 之前，至少應確認四項事實：服務商的資料保存政策、是否用於模型訓練、是否涉及跨境傳輸，以及事故發生時的稽核軌跡。這些條件並非不可接受，重點在於接受之前必須確知其內容。
務實的做法是依資料敏感度分流，而不是全押一邊：
- 可以走雲端：公開規格問答、行銷文案、對外客服的常見問題。
- 建議留地端：成本結構、毛利、客戶名單、報價紀錄、薪資與人事。
MAQ 後台即採可切換架構：一般查詢由區域網路內的本地模型處理，需要更強推理能力時才切換至雲端。資安考量不必然要求全部內部化，便利性亦不足以支持全部外送。
四、對應的硬體規格
這是前述討論的落點，也是最少見到具體數字的一環。下表列出實務上的對應關係。決定規格的因素為模型規模與同時使用人數，而非企業的營業規模。
| 使用情境 | 模型規模 | 顯示記憶體 | 對應機型 |
|---|---|---|---|
| ERP 查詢問答，5 人以內 | 7B–14B 量化 | 24GB | AI-Eco（NT$183,000 起） |
| 跨部門知識庫問答（RAG） | 20B–32B 量化 | 32GB | AI-Medium（NT$152,000 起） |
| 多人並行、需要較強推理 | 70B 4-bit 量化 | 48GB＋128GB ECC | AI-High（NT$686,000 起） |
| 企業知識中樞、長文脈高並行 | 120B 級量化 | 96GB＋256GB ECC | AI-Highend（NT$1,157,000 起） |
其中有三點值得說明：
- 若用途僅止於庫存與報表查詢，並不需要最高階的配置。7B 至 14B 的模型搭配 24GB 顯示記憶體，已足以回應料號庫存一類的問題。原因在於數字係由查詢工具取得，而非由模型推算；模型僅負責將問題轉譯為查詢、並將結果轉譯為自然語言。
- 並行人數較模型規模更容易被低估。依實務經驗，並行人數每增加一倍，系統記憶體需求約提高五成。三人測試時運作順暢的配置，於二十人同時使用時即可能出現排隊。
- 系統記憶體目前價格偏高。ECC 記憶體正處於漲價循環，大容量機種尤為明顯，將實際影響專案預算。相關分析見 DRAM 危機解析。
更完整的模型與硬體對照，見 AI 硬體選購指南。
五、實作過程中的三項限制
其一：資料品質不足，並不等於無法導入
幾乎每一家企業的 ERP 都存在資料品質問題。MAQ 亦然：某一品項名稱欄位長期空白，客戶查詢亦僅部分資料表可及。業界對此的標準建議是先行進行半年期的資料治理，然而多數中小企業並無此等待條件。
較為務實的判斷是：資料品質決定的並非能否導入，而是應先導入哪一類應用。欄位缺漏嚴重的結構化資料，宜先建置文件與知識問答；待資料補齊後，再推進至預測與分析。順序若顛倒，失敗機率極高。
其二：權限應於入口層完成控管
AI 帶來一項 ERP 原本沒有的風險：它會將原先分散於各畫面、各自受權限控管的資料，匯整為單一則回答。業務人員詢問特定客戶的毛利時，若未設限，AI 將逕行計算並揭露。
MAQ 目前以後台既有的權限等級，控管何者得以開啟此一 AI 介面；具備權限者原即可存取相應資料。至於更細緻的逐列權限控管，例如同一份報表中不同業務僅能檢視所屬客戶，MAQ 仍在開發中。組織若有此項需求，務必於專案初期即納入資料模型設計，後續補強的成本相當可觀。
其三：導入範圍應逐步擴大
宜選定單一部門與單一流程先行導入，實際衡量所節省的作業時間後，再評估擴大範圍。多數導入失敗的案例，癥結並非技術能力不足，而是初期範圍過大，致使專案中途缺乏足夠人力維護。
六、建議的導入順序
- 盤點：列出既有 ERP 已涵蓋、但仍耗費大量人力的三個環節，並標記不得離開企業內部的資料範圍。
- 決定運算位置：依前述敏感度分流原則，界定何者採用雲端、何者留存地端。
- 先建置單一工具：就最迫切的查詢需求，建置一項唯讀工具並使其實際運行。
- 驗證成效後再擴充：確認確實縮短作業時間後，再推進至下一項流程。
唯有第二步的結論指向地端部署時，才需進入硬體規劃。順序不宜顛倒；先行採購硬體再回頭定義用途，是整個過程中代價最高的做法。
本文所述之做法與踩坑經驗，來自 MAQ 自家 ERP（進銷存、採購、訂單、電子發票、成本報表）導入 AI 的實作，以及為客戶開發系統的經驗；文中硬體對照為 5 至 10 人企業內部使用的一般起點，實際需求受並行人數、文脈長度與回應速度要求影響。機型價格為 MAQ 現行實售起價，記憶體行情變動快，採購前請以 官網線上估價 之當下報價為準。文中提及之 ERP 產品與品牌名稱為各自所有者之商標，本文與各該廠商無合作或對價關係。