開源可自管地端、商用 API 省心卻要外送資料。本文從資料主權、CLOUD Act 合規、GPU 利用率與損益兩平、顯存量化到 RAG 混合架構，帶企業依場景務實選型，而非盲追排行榜。
先搞清楚，你到底在買什麼
市面上的選項，本質上就兩條路。第一條是商用 API，你透過網路呼叫一個放在別人雲端上的閉源模型，按用量付費。它最大的好處是省心，你不用自己準備硬體、不用養工程師，開通帳號就能用，模型還會被廠商默默地一路升級。壞處也一樣清楚：你的資料得送到公司外部去處理，用量一大帳單就一路往上疊，而且整個服務被綁在廠商的政策、定價跟可用性上，哪天它漲價、改條款、甚至下架某個版本，你只能接受。
不同模型、資料集、提示、判分方式與正式流量，結果可能差很多。公開 benchmark 只能用來理解方法，不能直接當成專案承諾；驗收應使用公司自己的題庫，分別記錄正確率、引用支持率、拒答、延遲、成本與人工覆核量。
第一道分水嶺不是效能，是資料出不出得了門
我常跟老闆們說，選型要先誠實回答一件事：這些要餵進去的東西，是公開的行銷文案，還是客戶名單、報價底價、病歷、財務明細、還沒公告的設計圖？只要牽涉到後者，就得非常小心。商用 API 的運作前提，就是把你的資料送到廠商的伺服器上處理，就算對方白紙黑字承諾不拿去訓練，資料的物理位置跟管轄權都已經不在你手上了。
這裡有個很多人沒想到的坑：就算廠商標榜資料中心設在某個國家或地區，只要營運商是受外國法律管轄的企業，資料在法律上仍可能被外國政府依法調取。像美國 2018 年通過的 CLOUD Act 就明訂，可以要求美國企業交出它在全球任何地方保管的資料，機房設在哪裡都一樣。所以「資料放在本地機房」跟「資料受本地法律保護」是兩件事，千萬別混為一談。
反過來說，把模型架在自家機房、資料全程不出公司網路，等於是用架構把合規問題「設計掉」。個資法、醫療、金融這類特別嚴的規範，很多時候本來就是硬性門檻，不是你想接雲端 API 就能過關。如果你是醫療院所、金融業，或是接政府標案的供應商，這條線幾乎沒得商量，地端或私有部署往往是唯一解。這一關過不了，後面的效能、成本都不用談了。
成本的真相，不在單價而在利用率
換句話說，同樣一台機器，量夠大、跑得夠滿，它就便宜；量不夠、三天用一次，它就是台昂貴的暖爐。各家 2026 年的分析抓出來的損益兩平點差異很大，從一天上千萬 token 到一個月上億 token 都有，取決於你選多大的模型、輸入輸出 token 的比例、以及硬體是租是買。但方向是一致的：低用量、量又不穩，選 API；用量高又穩定，才輪得到自管上場。
還有一筆最容易被漏算的帳，就是人。開源模型本身免費，但要把它穩定地跑在正式環境，得有人處理推論服務、版本更新、監控跟故障排除。業界普遍抓，一套正式級的自管光是維運，就要吃掉一到兩個全職人力，一年的人事成本動輒新台幣兩三百萬起跳。這筆錢不會出現在 GPU 報價單上，卻是真金白銀。所以「開源比較便宜」這句話，只有在你的用量大到能把這些固定成本攤平時，才真正成立。
地端要跑一個模型，硬體到底得準備什麼
如果評估下來確實要走地端，硬體規劃就得務實。模型吃多少顯存，跟它的參數量和數值精度直接相關。以一個七百億參數等級的模型來說，用原生的半精度（16 位元）載入，大約要吃掉一百四十 GB 顯存，等於得動用兩張 80GB 等級的旗艦卡才裝得下。但這不是唯一的跑法。
授權條款，最容易踩、代價也最大的雷
選開源模型，除了盯跑分，第一個要老闆親自確認的就是授權條款。同樣叫「開源」，條件天差地別。採寬鬆授權（像是 Apache 2.0、MIT）的模型最單純：可以商用、可以拿去微調、不用付權利金、不用跟原廠分潤、也不需要另外報備核准，你微調出來的版本還不必公開釋出。這種對企業採購跟法務最好過，法務常常不用大費周章就能放行。
但有些模型掛的是廠商自訂的授權，裡面可能藏著使用規模的門檻、特定用途的限制，或是要求你在某些情況下回報、甚至受原廠條款約束。這種就得請法務逐條看過，因為授權出問題的代價，往往比模型差那幾分跑分嚴重得多，你可能整個產品架構都搭上去了，才發現商用條件根本不符。所以我的順序永遠是：先確認授權能用，再談效能好不好。
最務實的答案，通常是「混著用」
要讓這套混合架構真的好用，RAG（檢索增強生成）是關鍵樞紐。它的精神是：把你公司的資料留在自家的檢索層，使用者一問，系統先從你的資料庫撈出相關內容，再把這些內容連同問題一起丟給模型，讓模型「只根據撈到的東西回答」。這樣做有兩個好處：一是敏感資料的主控權留在你手上，二是模型變成一個可以隨時抽換的零件。今天的榜首過幾個月被超車是常態，只要你的檢索層跟資料不動，後端要換開源換商用、換大換小，往往只是改個設定的事。所以架構上務必保留「模型可替換」的彈性，這比你把賭注押在任何一個當紅模型上，都穩健得多。
一張你可以直接拿去用的選型檢查表
- 資料敏感度：要餵進去的資料能不能離開公司？牽涉個資、營業秘密、醫療金融，優先走地端或私有部署。
- 合規要求：所處產業有沒有資料落地、管轄權的硬規範？別被「機房在本地」誤導，要看營運商受誰的法律管。
- 用量規模：月用量到底多大、穩不穩定？低用量或波動大選 API，量高又穩定才考慮自管。
- 維運量能：公司有沒有能扛推論服務、監控、升級的人？沒有就別硬自管，或找有經驗的夥伴代管。
- 授權條款：模型能不能商用、能不能微調、有沒有規模或用途限制？先過這一關再看效能。
- 可替換性：架構有沒有把模型做成可抽換的零件？隨時保留換後端、換大小的彈性。
廷皓科技就在高雄，長期協助南台灣的企業，依照資料敏感度、用量規模跟維運量能，把開源自管、商用 API、或兩者混合的方案規劃到位，也提供地端與私有部署的建置和維運支援。別讓一張排行榜綁架你的決策，帶著你真實的場景跟資料來聊，我們一起挑出真正撐得起你生意的那一個。
