本地 AI vs 雲端 API：客戶最常問的 7 個問題

客戶先嫌 API 帳單貴，公司裡剛好有 GPU，就把模型搬回自己的機器。跑了一陣子，同一位老闆嫌的變成模型很爛，什麼都做不了。付錢的方式變了，問題沒變。 這條路我們在教育訓練和客戶對談裡反覆被問到，卡住的位置也差不多。客戶要做的是重新分配工作，不只是換供應商。下面七題是客戶真的會講出口的話，以及我們怎麼接。 ## Q1 API 怎麼這麼貴？我們自己有算力，部署不是比較便宜？ 用量長期很大的話，自己部署確實可能划算。但我會先看，是不是所有工作都丟給同一個最強的模型。複雜規劃用它，接案的報價單換版型、請款明細整理成固定欄位也用它。這像請最資深的工程師順便幫你改檔名。 所以第一步不是換平台，是做模型分流。分流不只是分成「貴的」和「便宜的」兩格，比較好用的做法是列一張任務對照表：一個主力模型當預設，負責判斷、分派與收尾；翻譯、摘要、固定格式轉換這類規則清楚的工作，指定給小而專的模型，放本地或便宜的雲端都行；要讀很長文件的，交給擅長長內容的模型；多步驟、要連續呼叫工具的，留給工具用得最穩的那一個；資料不能外流的，只准走本地。表上還要寫清楚，某個模型掛掉時退回給誰。 預設值要保守。只有任務明確落在便宜模型的強項裡，才把它分出去，其餘照舊交給主力模型。這張表做出來，帳單通常先降一段，你也會第一次看清楚錢花在哪一類工作上。 我不會講「本地一定比較便宜」。省下的是呼叫費用，但硬體、電力、維運與雲端原本包好的工具，都變成你自己的成本。認真算投資報酬率，除了資料不能外流、或量極大但任務單純這幾種情況，雲端通常還是划算的那一邊。多大的用量才值得自己部署，要看任務組成，不是總量。 ## Q2 機器已經買到很高階了，怎麼還是這麼爛？是不是你技術有問題？ 落差是真的，但它不是配置錯誤，是三件事疊在一起。第一，閉源平台可以在後端放非常大的模型、配上大量 GPU，完整版本的超大模型本來就是資料中心等級的硬體在跑，一般公司不會為此蓋機房，只能選符合現有硬體的開放模型。第二，還要用壓縮過的量化版本才塞得進去，能力會有損失。第三件最容易被忽略：原本雲端產品後面那一整套東西不見了。 很多客戶的直覺是「那就再買更好的卡」。硬體升級能讓你塞進更大的模型、跑得更快，但補不了另外兩件事。就算換上工作站等級的顯卡、跑得動相當大的開放模型，接上 Agent 框架之後，常見的走向仍是工具叫錯、複雜任務得靠人一路盯著糾正，最後把主要工作搬回雲端，本地只留下少數明確的任務。這不是誰技術不好，這條路本來就長這樣，差別只在部署前講清楚了沒。 我不會說模型其實都差不多，客戶已經實測過，這句會毀掉可信度。硬體是限制，不是錯誤。被問機器是不是白買了，答案是不會，接下來要判斷它適合哪一類工作，這測得出來。 ## Q3 不是說支援 Tool Calling 嗎？怎麼什麼都不能做？ 本地模型現在可以做 Tool Calling，但它的範圍比大家想的窄。模型只負責判斷該用哪個工具、要傳什麼進去；把工具跑起來、整理結果、失敗重試、再交回模型，都是外面的 Agent 系統在做。拿電商客服來說，要它讀信、查訂單、判斷退換貨條件再寫回信，模型只出了一小段力。用雲端產品時這套是平台包好的，自己部署後變成你要接。 規格表上寫「支援」，跟實際用得穩是兩回事。標了支援工具呼叫的開放模型，跑起來可能根本不去用工具，或是挑錯工具、傳錯參數。Agent 框架碰到複雜任務時會自己拆出子任務分頭處理，這個機制換成本地模型常常直接跑不起來，只能先關掉。開瀏覽器操作網頁、截圖回報這種多步驟動作，更容易卡在半路。 所以第一個感覺是什麼都不能做，實際上是兩件事：缺了外面那一層，加上模型用工具的穩定度還不夠。前者是系統工程的工作量，補得回來；後者要靠實測劃出邊界，換一個模型不會自動長出工具鏈。被問要多久，我會先挑一條最常用的流程做完，再決定展開多少。 ## Q4 Context 明明標很長，為什麼跑久了就忘記限制、重試失敗過的方法？ Context 常被說成短期記憶，更好懂的講法是，模型工作時桌面上放著多少資料。連續工作很久的話，看過的檔案、提過的要求、工具回傳的結果、失敗過的方法，後面全部可能用得到。關鍵是帳面上塞得下，不等於它一直抓得對重點；模型小或量化壓得兇，長任務跑久就更容易忽略限制、把失敗過的方法拿回來重試。 雲端產品除了模型本身強，外面還替你做了快取、摘要與檢索，把工具結果整理過才交給模型。自己部署之後，這些 Context 管理變成系統設計的一部分，得自己補上。桌面要大，靠的是記憶體；想把 Context 拉長，硬體也得撐得住，這會回到 Q7 談的記憶體容量。 標示的長度是容量，不是專注力。實際做法是把長任務切段，每段有明確的輸入輸出與驗收，讓每一步只看該看的資料。重試次數會降，也知道是哪一段失敗。 ## Q5 那什麼工作真的值得搬回本地？ 有三類工作本地的優勢很明顯。第一類是大量、高重複、規則清楚的批次任務，例如幾百份講義掃描檔要抓出課名與題型。這種工作資料量大、每一筆要的判斷卻不多，用不到最強模型的腦力，流程與驗證方式定清楚，量一大優勢就出來了。第二類是規格已經明確的執行工作，像把三十個舊頁面的元件依同一份規格改寫，可以整晚跑，早上看結果。第三類是資料不能離開自己環境的工作，就算得接受模型笨一點，也只能留在自己的機器上，這個放到下一題細談。 還有一個理由是控制權，而且不只是系統提示、工具權限、資料流向可以自己設計。外部模型的價格、用量上限、哪個版本什麼時候下架，都是對方決定的。把一部分日常工作放在本地，換來的是外面有變動時，你的流程還能繼續跑，不是省了多少錢。 但規則不清楚的工作搬過去只會把問題放大。一條要搬的流程，至少答得出這幾件事：誰發現問題、誰判斷、誰執行、誰驗收、失敗了怎麼退、最後誰負責。答不出來的，先別搬。先做哪一類，看交集：盤點每天重複做的、不能外流的、寫得出 SOP 的，交集就是第一批。 ## Q6 資料丟到 API 會不會被拿去訓練？ 先講清楚，把資料送進企業 API，不等於它會被拿去訓練，多數企業 API 有自己的資料政策，看合約就知道；反過來說「一定會」也是錯的。這一題真正該看的是資料能不能離開自己的環境。客戶名單、內部財務、未公開的產品文件，或產業本身有合規要求，這時對方的政策寫得多好都不是重點。 這時本地部署的價值，是從文件切割到模型回答全部留在內網，不是便宜。這類工作通常也不需要最聰明的模型，掃信件、分類、抽欄位，小一點的模型就做得來，剛好是本地最有把握的範圍。也不必全有全無，敏感的留在自己環境，不敏感的走外部服務，用資料分級決定，不是用直覺。面對合規的人要把問題拆成資料落點與資料用途，前者用架構圖說明，後者看合約。 ## Q7 本地跟雲端到底怎麼分？真的要買機器，該看什麼？ 我不會把它當成二選一。不確定性越高的工作越適合強模型，像規劃與第一次碰到的問題；重複性越高、資料越敏感的越適合往本地搬，像批次文件處理、內部知識庫。再往前一步是 Local-first，先讓本地處理，只有它判斷失敗或結果不符規格，才交給更強的雲端模型。Q1 那張任務對照表上的退回路線，做的就是這件事。 至於買機器，我建議先不要買。現在有不少服務可以直接用 API 測開放模型，拿一批去識別化的客戶詢價信看它分類準不準。用不到的硬體就是擱置的資本支出，先租雲端 GPU 是個好過渡。 測完真的要買，先問的是你要跑的模型連同整條流程，裝不裝得進記憶體，不是哪張卡比較快。裝不進去，算力再強也得妥協：換更小的模型、壓得更兇，或把一部分挪到系統記憶體、讓速度掉下來。其次看生態系。NVIDIA 的優勢有很大一部分在它後面那套軟體環境，多數新模型與工具先在上面測過，照著說明裝起來就能跑。Mac 的統一記憶體讓 CPU 與 GPU 共用同一塊，放得進一般顯卡放不下的大型語言模型，但同一個模型不見得能直接搬過去，有時得等人做適配。主要跑語言模型，Mac 值得放進選項；圖像生成、新出的模型都想第一時間試，NVIDIA 比較省事。系統記憶體與硬碟空間也別省，模型一換再換，很快就滿。 能跑，跟適合每天拿來工作，是兩回事。小機器靠各種壓縮硬塞成功，不代表你天天用它不折騰。本地算力也不必只想成一台大主機，把幾台較小的工作站串起來、讓系統自己找到可用的算力，是正在發展的方向，但現在還偏實驗，先別當成採購依據。 ## 怎麼判斷你的工作該放哪 先分類工作，再選平台，七題說的都是這件事。我們常畫的是不確定性與資料敏感度兩條軸，落在「流程固定、量大、資料敏感」那一格的，就是第一批該搬的。全搬或全不搬通常都不對。 **本地 AI 值得做的，是找出哪些工作根本不需要每次都動用最強的模型，不是把雲端最強的模型搬回公司。**  再往後看，企業導入 AI 真正會累積下來的只有兩樣。一是工作流，把人的判斷拆成機器跑得動、驗得了的步驟；二是自己掌握的算力，讓這些流程在外部價格或服務變動時還能運作。工作流決定 AI 做什麼，本地算力決定它能不能長期做下去。 順序不能反。沒有跑通的工作流就先買機器，最後多半拿來聊天，放著積灰；只有工作流、全部靠外部，用量一大帳單跟著膨脹，上游一限額流程就停。先讓一條流程在雲端跑穩，再決定哪些段落值得搬回自己的機器。 ## 先測再買：四個要記的數字 買硬體之前，先用真的工作流程測幾天，記四個數字： 1. **成功率**：同一批任務跑下來，有多少次輸出直接可用。 2. **速度**：單筆從送進去到拿到結果多久，一批跑完多久。 3. **人工修正量**：可用的輸出平均還要動幾個地方。 4. **年度次數**：這任務一年會跑多少次。 前三個決定模型做不做得了，第四個決定值不值得為它買硬體。機器上線之後也照樣記，數字一變，就回頭調 Q1 那張任務對照表。