在 Day 01 中，我們建立了「AI 系統工程化」的核心心法：

企業導入 AI 不能只當作玩具或單點 Chatbot，而必須將其視為具備明確服務水準協議(SLA)、資安邊界與成本效益的軟體架構。

當團隊準備著手串接 API 或建構自動化工作流（如 n8n、Agent）時，決策者與工程團隊面臨的第一個核心問題通常是：

「我們該選哪一顆模型？直接無腦調用最強的閉源模型，還是為了資料安全全數在地端架設 Llama 開源模型？」

現實中，許多企業專案往往在第一個月就踩坑：要不是選用頂規模型導致 Token 費用爆炸、回應延遲高達數十秒；就是花費大量資源租用高規格 GPU 伺服器架設開源模型，最後發現後續的伺服器維護成本與工程負荷吞噬了所有投資報酬率（ROI）。

今天從企業架構師與資安顧問的雙重重視角出發，拆解四大評估維度，剖析 Google AI Studio、Gemini API 以及開源模型（如 Llama 系列）的優劣與適用場景，並提供一套可落地的模型選型決策樹。

一、破除迷思：為什麼企業不能「一套模型打天下」？

在傳統軟體架構中，我們不會用昂貴的大型資料庫去處理單純的暫存快取（那是專用暫存快取系統的工作）。同樣的道理，在 AI 系統中，不同的任務節點對智慧深度、回應速度與成本的要求截然不同：

1. 常態性管線任務（High-throughput, Low-complexity）：

   • 例如情緒分析、意圖分類、簡單文字摘要、格式正規化。
   • 這類任務需要的是極快的回應速度與極低的調用單價。

2. 複雜決策與 Agent 節點（Low-throughput, High-complexity）：

   • 例如多步驟推理、動態呼叫外部工具（Tool Calling / Function Calling）、跨文件長文本關聯分析。
   • 這類任務需要的是頂尖的邏輯推導能力與高穩定度的結構化輸出。

若將兩者混為一談，架構要嘛因性能低落無法上線，要嘛因成本失控被財務部門喊停。

二、模型選型的四大核心評估維度

在選擇模型時，建議以以下四個量化與質化指標建立評估矩陣：

1. 成本與 Token 效益（Total Cost of Ownership, TCO）

• 雲端 API：通常按 Token 計費（輸入 Token + 輸出 Token）。需特別注意輸入與輸出的價差（輸出通常比輸入貴 2~4 倍），以及上下文快取機制（Context Caching）對重複讀取固定文件的成本削減幅度。
• 開源自建推論：看似「免授權費」，但必須計入雲端算力租用（高階 GPU 執行個體費用）、離峰時段伺服器開著沒人用的空轉成本，以及專案人員維護伺服器與推論引擎的隱性人力成本。

2.延遲與處理速度（Latency & Throughput）

• 產生第一個字的時間（Time To First Token, TTFT）：首字延遲時間，也就是使用者送出訊息後「等待系統開始回應」的時間，直接影響即時客服或對話體驗。
• 每秒輸出字數（Tokens per Second, TPS）：整體的吐字與處理速度。在非同步工作流（如夜間批量批改合約、n8n 排程處理報表）中，TPS 決定了批次作業何時能跑完。

3. 安全合規與資料邊界（Security & Compliance）

• 數據再訓練權限（Training Opt-out）：API 服務商是否會將企業輸入的商業資料拿去訓練下一代模型？
• 資料傳輸與儲存合規：是否符合國際資安標準（如 GDPR、ISO 27001）或特定產業法規？機敏資料能否在進入外部 API 前完成去識別化遮罩？

4. 工程生態與工具支援（Ecosystem & Tooling）

• 上下文視窗（Context Window）：單次對話能塞入的資料容量上限，是否能一次容納整份產品規格書、年報或多份合約？
• 工具呼叫穩定度（Function Calling / Structured Outputs）：模型是否支援嚴格遵循標準資料格式（如 JSON）？如果輸出的格式跑掉，自動化流程就會直接報錯中斷。

三、三大主力陣營橫向深度對比

1. Google AI Studio（原型驗證與概念驗證 PoC 利器）

• 定位：開發者與顧問的快速實驗場、快速打造產品原型與提示詞壓力測試。

• 優勢：

  • 提供視覺化網頁介面，完全不需要寫程式碼即可測試文字、圖片、音訊、影片與 PDF 等多元檔案。
  • 可直接在畫面上調整系統指令（System Instructions）、回答的隨機度／創意溫度（Temperature）與安全防護過濾器（Safety Filters），並能一鍵匯出 Python、JavaScript 或 API 呼叫指令。
  • 支援免費試用額度（Free Tier），非常適合專案前期的商業可行性驗證。

• 企業落地注意事項

• 資料條款差異：在 Google AI Studio 的免費層下，輸入的內容可能被用於改善 Google 產品；若涉及企業機敏資料，必須升級綁定雲端帳單（Google Cloud）以切換至商業版資料保護條款（承諾資料不留存、不拿去再訓練）。

• 調用頻率限制：免費層的每分鐘請求數（RPM）與每日請求數（RPD）限制較嚴格，無法支撐正式上線的商業流量。

2. Gemini API（企業級生產環境主力）

• 定位：高吞吐量、多元檔案處理、超大資料容量與複雜 Agent 的商業核心引擎。

• 雙層階梯架構（Flash vs. Pro）：

  • Gemini Flash 系列：主打極致性價比與高速回應。適合高頻率呼叫的資料整理、即時翻譯、客服分類、大量文件批次掃描。
  • Gemini Pro 系列：主打深度邏輯推理與高階決策。適合多步驟複雜決策、高精準度函式呼叫（Function Calling）、合約漏洞分析。

• 核心優勢

• 百萬級上下文視窗（Context Window）：原生支援百萬級 Token 的輸入容量，能一次將整本數百頁手冊或數小時音訊直接餵入，省去傳統檢索切塊時容易遺漏前後文脈絡的困擾。

• 原生上下文快取（Context Caching）：針對重複讀取的大型背景資料（如公司規章、常用 API 規格），系統快取後只收極低的讀取費，能大幅壓低長期營運成本。

3. 開源模型陣營（以 Llama 3 / 4 等為代表）

• 定位：資料極度機密、完全封閉內網環境、或需深度客製化微調的特定任務。

• 優勢：

  • 資料完全自主權（Data Sovereignty）：模型直接部署在企業自己的專屬私有雲或地端機房，資料完全不出公司大門，滿足最高等級的合規要求。
  • 高度客製化：可透過模型微調技術，將企業內部專有的特殊格式、代號或特定產業語彙直接固化到模型能力中。

• 隱性成本與限制

  • 伺服器維護負擔重：需要專職工程團隊架構伺服器與負載平衡，還常面臨「併發請求過多導致排隊卡住」或「顯示卡記憶體不足而當機」等底層硬體維運挑戰。
  • 模型能力邊界：在超大文件一次性閱讀、複雜指令理解以及多模態整合上，開源模型往往需要拼湊多種外掛套件，系統複雜度與出錯機率大幅增加。

四、生產環境的隱形殺手：頻率限制與流量調節

在測試階段一切順暢的 API，一旦正式上線，最常引發系統停擺的就是觸發了服務商的 Rate Limits（調用頻率限制），導致系統收到「429: 請求過於頻繁」的錯誤回絕。

評估 API 的三個關鍵指標：

1. RPM（Requests Per Minute）：每分鐘允許呼叫的次數上限。
2. TPM（Tokens Per Minute）：每分鐘允許處理的文字總量上限（長文件最容易踩爆此限制）。
3. RPD（Requests Per Day）：每天總呼叫量上限。

架構層面的防禦設計：

• 指數退避重試（Exponential Backoff）：遇到請求被拒時，系統切勿立即連續狂刷 API，而應導入漸進式等待策略，逐次拉長重試間隔，讓流量平滑通過。
• 生產佇列（Message Queue）：在自動化流程（如 n8n）或後端系統前方加入排隊緩衝機制，將突發的大量工作「削峰填谷」，依 API 能承受的速度逐一消化。
• 降級備援機制（Fallback Routing）：當高階模型（Gemini Pro）達到處理上限時，自動將非核心的簡易工作分流給輕量模型（Gemini Flash），或切換至備用供應商，確保企業前台服務不中斷。。

五、企業級模型選型決策樹

在設計具體的自動化流程前，可依照以下商業與技術脈絡進行快速決策：

[新任務需求評估]
       │
       ├─► 是否有嚴格合規限制（如完全斷網、資料絕對不能出境機房）？
       │      ├─ 是 ──► 【開源模型 + 私有伺服器部署】（如 Llama 3/4 + vLLM）
       │      └─ 否 ──► 進入雲端 API 評估
       │
       ├─► 任務是否涉及超長文件（單次 > 10 萬字）或大量影音多模態？
       │      ├─ 是 ──► 【Gemini API (結合上下文快取 Context Caching)】
       │      └─ 否 ──► 評估任務複雜度
       │
       └─► 任務邏輯複雜度與延遲要求？
              ├─ 基礎任務（資料分類、格式正規化、即時客服、大量掃描）
              │     └──► 【Gemini Flash】（速度極快、成本極低）
              │
              └─ 深度任務（多步驟決策、Agent 跨工具操作、核心合約審核）
                    └──► 【Gemini Pro】（邏輯精準、格式輸出穩定）

總結

模型選擇並非技術競賽，而是成本、回應速度、安全邊界與商業效益的平衡取捨。一套務實且可持續營運的企業級架構，通常是「開源與閉源混用」、「大模型與小模型分層協同」：

• 利用 Google AI Studio 快速驗證概念，在最短時間內確認商業可行性。
• 利用 Gemini Flash 作為自動化工作流中 80% 基礎任務的平價工作引擎。
• 將 Gemini Pro 或私有部署的專用模型保留給 20% 最具商業價值的關鍵決策節點。

當我們選定合適的模型只是搭好了骨架，下一步該如何確保 AI 模型能「精準聽懂人話」且「穩定輸出系統可解析的格式」？

明天我們將探討如何用工程思維馴服模型的不確定性：《打造模組化提示詞工程》，帶你掌握結構化 Prompt 設計與版本控制心法。