把 AI 助理搬進自己機房的時代來臨：UbiGPT × UbiCode × UbiWork On-Premise 企業 AI 協作解決方案
26-08-26
撰文：AI 創新與資安研發總監 吳英豪 (Isaac Wu)、編輯：行銷副理 呂宜家（Helen Lyu）
開放權重模型的能力還在快速前進——兩年前它像個需要逐行檢查的實習生，如今已接近碩、博士級的全職員工。當模型能力不再是瓶頸，「模型跑在誰的機器上」就從技術偏好變成了資安與成本的核心問題。把 AI 助理搬進自己機房的時代，已經到了。
前言：模型能力跨過了一條線
過去幾年，反對自架 AI 的理由裡最有力的一個是：「開源模型不夠強，省下的錢會用品質賠回去。」
這個前提正在失效，而且失效的速度比多數人預期的快。
用一個比喻來說明這段進展。兩年前的開放權重模型像個實習生：你得把任務切到夠小、把上下文餵到夠清楚，產出還要逐行檢查——很多時候檢查的時間比自己動手還久。一年前它大概到了新鮮人的水準：能完成有明確規格的工作，但遇到規格沒寫到的地方就會卡住或亂猜。
而現在這一代的開放權重模型，能力已經接近碩、博士畢業的全職員工：
- 它能讀懂完整脈絡，而不只是回應最後一句話。
- 它會自己把模糊的需求拆解成可執行的步驟，並在動手前先問清楚關鍵前提。
- 它對自己的產出有判斷力——知道哪裡沒把握、哪裡需要驗證。
- 被指出錯誤時，它能針對性地修正，而不是整段重寫一次碰運氣。
這四點加起來造成一個質變：產出從「需要人重做一遍」變成「可以直接拿來用」。
這個差別在成本上的意義遠比模型評測分數重要。當 AI 的產出還需要人花時間收尾，你省下的其實不是工時，只是把工作從「寫」移到「改」；而當產出可以直接用，省下的才是真的。
於是三條線在此刻交會：
- 模型能力跨過了「可交付」的門檻，自架不再等於將就。
- 推論框架與硬體成熟到讓中型企業也負擔得起像樣的吞吐量。
- 資料主權的要求隨著 AI 讀取的資料越來越敏感而急速升高。
前兩條解除了自架的技術與成本障礙，第三條則讓自架從「可以考慮」變成「不得不做」。把 AI 助理搬進自己機房的時代，就是在這個交會點上到來的。
本文要談的，就是這個時代來臨之後的實務問題：為什麼資料非留在自己的邊界內不可、我們自己內部怎麼用（五個橫跨法務、業務、研發與基礎架構的真實場景），以及一套完整的自架方案由哪三層組成。
一、問題不在「要不要用 AI」，而在「資料流去哪裡」
過去兩年，多數企業導入 AI 的方式大同小異：法務把合約貼進聊天視窗、業務把銷售報表上傳、工程師裝一個雲端 IDE 外掛並填入 API Key，讓它讀專案原始碼。這個流程能跑，但仔細拆解會發現幾件事：
- 要有用，就得餵完整脈絡。AI 只看得到片段，給出的就是片段等級的答案。真正有價值的任務——通讀一份合約、分析一整年的銷售數據、理解一個既有系統——本質上都是「大量讀取 + 反覆推論」。一次任務可能讀進數百個檔案或整份尚未公開的文件，而這些內容全部會離開公司網段。上下文的深度，等於資料外洩面的大小。
- 「不會用於訓練」是條款，不是架構。多數商用 API 條款確實載明企業方案不使用客戶資料訓練，但這是契約承諾；一旦條款版本更新、帳號被誤設為消費級方案、或是流量走了不同的中介 gateway，控制權就不在你手上。條款可以改，網路拓撲不會自己改。
- 成本隨使用規模線性膨脹，且不可預測。Token 計價模式下，一個「做得很認真」的 AI 反而最貴。當它開始自動排程、反覆檢查、迭代修正時，單一任務的 token 消耗可以是人工提問的數十倍，月底帳單無法事前估算。
- 合規審查擋在最前面。金融、醫療、遊戲營運、政府標案，或任何簽了 NDA 的合作案，光是「這份文件或這段程式碼能不能傳送到第三方服務」這一題，就足以讓整個導入計畫停在法務會議室。
這四點的共同解法只有一個方向：把模型推論、身分認證與 AI 的執行環境，一起搬回自己可控的邊界內。
二、On-Premise 的四個實質效益
1. 隱私邊界等於網路邊界
當推論服務跑在內網的 GPU 節點上，「資料不外流」不再需要靠信任，而是可以用防火牆規則驗證。AI 讀取的合約、報價單、銷售明細、內部 Wiki、專案原始碼與生產環境 log，全程在同一個 VLAN 內流動。稽核時你能拿出的不是一份供應商的合規白皮書，而是一張網路拓撲圖與一份 egress 阻擋規則。
2. 機密資料確定不會成為訓練語料
自架模型的權重是靜態的。除非你自己啟動 fine-tuning pipeline，否則沒有任何一次對話會回流進模型。注意這裡的主詞——「要不要拿來訓練」變成你自己的選擇題，而不是供應商的條款題（後續第 5.4 節會談到如何把這個選擇權變成優勢）。這對三類資產特別關鍵：
- 尚未申請專利的技術實作——一旦成為第三方模型的訓練資料，先前技術（prior art）的認定風險難以量化。
- 受客戶 NDA 保護的文件與交付物——合約、規格書、整合程式碼。你對客戶的保密義務，無法透過「我們的供應商說他們不會用」來轉嫁。
- 沒有專利也沒有著作權保護的營業秘密——定價策略、成本結構、客戶名單、談判底線。這類資產的價值完全建立在「別人不知道」之上，一旦外流就無法回復，也無從主張權利。
3. 成本從變動費用變成固定資產
這是最容易被低估的一點。商用 API 是變動成本，且與「AI 用得好不好」正相關——團隊越熟練、自動化跑得越多，花費越高，等於對正確的使用行為課稅。自架推論則是固定成本：GPU 佈建之後，多跑一個任務的邊際成本趨近於電費。
一份示意性的試算（數字為說明用途，實際請以自身壓測與報價替換）：
重點不是「哪個一定便宜」，而是成本曲線的形狀不同。小團隊、低用量，API 幾乎必然划算；一旦跨過損益兩平點且用量還在成長，自架的邊際優勢會持續擴大，而且你可以放心鼓勵團隊「多用一點」。
值得一提的是，上表假設所有任務都用同一個模型處理——這其實是最沒有效率的用法。後文會談到，把不同性質的工作分派給不同分級的模型，本身就能再壓下可觀的成本。
4. 可用性與延遲自己說了算
沒有第三方的 rate limit、沒有跨海 RTT、沒有「供應商今天服務降級」導致全公司作業停擺。內網推論的 first-token latency 通常明顯優於跨區域 API；對於「一個任務跑幾十輪來回」的自動化工作負載，累積差異相當可觀。
三、實戰驗證：Ubitus 內部的真實應用場景
以上四點如果只停留在理論層次，說服力有限。所以在往下談架構之前，先說明一件事：這套系統，Ubitus 內部已經全面在用。
它不是為了對外銷售而做的展示品，而是我們自己每天在跑的基礎設施——而且不只在研發部門。以下五個場景橫跨法務、業務、軟體開發與基礎架構調校，全部在內網完成，沒有任何一份文件、一筆數據或一行程式離開過公司網段。
請留意這五個場景的共同特徵：它們都不是「AI 給建議、人再做一次」，而是 AI 直接交出可用的成果。 這正是前言所說的那條線——若模型還停在需要逐行檢查的階段，這五件事沒有一件划得來。
3.1 法務：合約初審與追蹤修訂
合約大概是企業裡「最不可能上傳到雲端 AI」的文件類型——裡面有客戶名稱、授權條件、報價結構、違約條款，而且往往還受另一份 NDA 的約束。用第三方 AI 服務審合約，這件事在法遵上幾乎不用討論就會被否決。
在自架環境下，這個限制消失了，於是我們把 UbiWork 用成了法務的第一道防線：
- 初審與風險標記——AI 通讀合約，逐條比對雙方的權利義務，標記出明顯不對等的條款：單方面的無限期保密義務、不對稱的責任上限、只約束一方的終止條件、模糊到可任意解釋的驗收標準。
- 提供修改建議——針對每個標記處給出具體的改寫方向，而不是只說「此處對我方不利」。
- 人工確認——法務同仁逐項檢視 AI 的判斷，採納、修改或駁回。這一步不能省，AI 是初審，不是決策者。
- 直接產出可寄出的檔案——確認後直接生成帶有追蹤修訂與註解的 Word 檔，格式與人工修訂完全一致，可以直接寄給對方窗口。
第 4 步是整個流程真正的關鍵。市面上多數 AI 法務工具的產出是一份「建議清單」，法務人員還得自己打開 Word、一條一條把修改搬進去、再手動加註解——這段搬運工作往往比審閱本身更花時間。直接產出可交付的檔案，才是把工時真正省下來的地方。
UbiWork 實際畫面：AI 以乙方視角通讀合約，逐條列出建議批註的條文與理由——付款驗收標準、期中報告時程、擔保與侵權責任上限、沉默視為同意條款。確認後即可直接輸出帶追蹤修訂的 Word 檔。
3.2 業務：銷售數據分析與洞察
第二個場景同樣不在研發部門：把銷售數據的 Excel 檔丟給 UbiWork，請它分析並提出洞察與建議。
這件事的門檻通常不在分析本身，而在前置作業——傳統上要先有資料工程師建 pipeline、把資料匯進 BI 系統、設計好儀表板，一個臨時的問題往往要排上兩週才有答案。現在的流程是：把檔案丟進去，直接問問題。
實際用途包括趨勢與季節性變化的解讀、異常數值的定位與可能成因、產品線與區域別的交叉比較，以及據此提出的具體行動建議。搭配排程功能，還能設定成每週自動跑一次，主管一早就收到最新的分析摘要。
而銷售數據的敏感度不需要多做說明——營收結構、客戶貢獻度、定價策略，這些是競爭對手最想知道的東西。它們能被放心地交給 AI 分析，唯一的原因就是模型跑在自己的機房裡。
3.3 研發：CI 整合，commit 之後測試自己長出來
我們把 AI Agent 直接接進 CI pipeline。工程師 git commit 之後，Agent 自動分析這次變更的內容，補完對應的 unit test。
這件事的價值必須放進實際的工時結構才看得出來。軟體開發中，大約有一半的時間花在撰寫測試上——而且是工程師公認必要、卻最缺乏成就感的一半。它不產生新功能，但少了它，重構就沒人敢動、上線就得靠祈禱。
現在這一半的時間，AI 幫我們省下來了。
更關鍵的是它改變了團隊行為。過去「這次先不寫測試，之後補」是專案趕工時的標準妥協，而「之後」通常不會來。當補測試的成本趨近於零，測試覆蓋率不再需要靠紀律維持，而是流程的自然產物。
3.4 研發：自動初步 review，把 shift-left 真正做到第一步
同一條 pipeline 上，Agent 也會對變更進行初步的 code review。
成效相當直接：它已經多次成功找出人工手寫程式中的 bug——注意，是人寫的程式，不是 AI 寫的。這些問題如果沒被攔下來，最好的情況是在 code review 被同事抓到（浪費兩個人的時間），普通的情況是進到 QA 階段（浪費一輪測試循環），最壞的情況是上線後才爆開（浪費整個團隊的一個晚上）。
大家談 shift left 談了很多年，但真正的困難從來不是觀念，而是「越早檢查、成本越低」與「越早檢查、越沒有人力」之間的矛盾。沒有團隊養得起一個專門在 commit 當下逐行審查每個人程式的資深工程師。
AI Agent 補上的正是這個位置：它不會累、不挑時間、對每一次 commit 一視同仁。缺陷在生命週期的第一步就被攔截，災難在成為災難之前就消失了。
UbiCode 對 GitLab MR #12 的自動審查結果：依嚴重度分類，逐項指出檔案與行號。其中 cert.py:25 把 SSL 驗證失敗自動降級為不驗證——這類「看起來能動、實際上關掉了 TLS 檢查」的寫法，正是人工 review 最容易放過的一種。
3.5 研發：「審到沒有意見為止」的品質迴圈
這是我們認為最能體現 on-premise 價值的一個做法。
我們讓 AI 去審核程式——不論那段程式是它自己寫的、還是另一個模型寫的——找出問題後自動修正，然後再審一次。如此反覆，直到審核者提不出任何進一步的修改建議為止，才把成果交出來。
這個迴圈在技術上並不複雜，難的是它的成本結構：一次任務可能要跑上十幾二十輪推論。在按 token 計費的模式下，這種做法幾乎必然會被主管在月底的帳單面前叫停——團隊會開始自我審查「這個任務值不值得多跑一輪」，而品質就是在這種計算裡被犧牲掉的。
自架環境把這個顧慮整個拿掉了。GPU 已經在機房裡了，多跑十輪的邊際成本只是電費。於是我們可以理直氣壯地告訴團隊：不用怕燒 token，跑到好為止。
結果是產出品質的全面提升，以及一個很實際的改變——AI 交出來的是「可以直接用的成果」，而不是「一個需要人類再花時間收尾的草稿」。這兩者之間的差距，決定了 AI 輔助開發到底是真的在節省時間，還是只是把工作從「寫」轉移到「改」。
3.6 基礎架構：讓 AI 自己調校 AI 的推論引擎
最後一個場景比較特別——我們讓 AI 去優化 UbiGPT 自己的推論引擎。
任何跑過模型部署的人都知道，「把模型服務起來」和「把模型服務調到最快」是兩件事。後者的搜尋空間大得驚人：張量並行的切法、批次大小、KV cache 配置、量化策略、上下文長度上限、排程參數……每一項都會互相影響，而且沒有任何一組參數在所有工作負載下都是最佳解。
傳統作法是資深工程師手動試：改一組參數、部署、跑 benchmark、等結果、記錄、再改下一組。問題不在於難，而在於它同時具備「極度耗時」與「極度機械」兩種性質——工程師大部分時間是在等 benchmark 跑完，然後把數字抄進試算表。
現在這件事交給 AI 做多輪自動化迭代：
Agent 自己部署、自己壓測、自己讀數據，整夜無人值守。
Agent 自己部署、自己壓測、自己讀數據、自己決定下一組要試什麼參數，然後重跑。整晚跑下來，隔天早上拿到的是一份完整的參數掃描結果與最佳組合建議，附帶每一輪的實測數據佐證。
這個場景的效益是複利式的：調校出來的吞吐量提升，直接降低了每一次推論的成本，而降低的成本又讓前面那些高頻使用的場景更划算。 用 AI 優化 AI 的基礎設施，省下的算力再回頭餵給 AI ——這是一個會自己加速的循環。
3.7 小結：五個場景，兩個共同前提
回頭看這五個場景，它們橫跨完全不同的部門與工作性質，但共享兩個前提。
前提一：最敏感的資料，只有在內網才敢餵給 AI。
這些工作之所以能交給 AI，不是因為我們對供應商的條款有信心，而是因為資料根本沒有離開過機房。
前提二：推論成本可預測，且不會懲罰高頻使用。
- 每次 commit 都自動補測試 → 高頻觸發，用量極大
- 每次 commit 都自動 review → 高頻觸發，用量極大
- 反覆自我審查修正 → 單次任務用量極大
- 多輪參數掃描與壓測 → 整夜連續運算
任何一項放到按量計費的模式下，都會立刻面臨「要不要限制使用頻率」的討論。而在自架環境中，這些討論根本不需要發生。
這就是為什麼我們認為 on-premise 不是保守的選擇，而是讓 AI 真正發揮效益的前提。
下一篇，我們將進一步拆解 UbiGPT、UbiCode 與 UbiWork 如何分別對應推論治理、研發 Agent 團隊與跨部門 AI 協作，組成完整的 On-Premise 企業 AI 解決方案。
關於優必達
優必達（Ubitus）是首家獲得 NVIDIA 投資的台灣科技公司，在 GPU 虛擬化技術與 雲端串流技術領域具備全球領先地位，並持續為各產業提供世界級的雲端與 AI 解決方案。
優必達與 國立臺灣大學（National Taiwan University）、東京大學（The University of Tokyo） 等頂尖學術機構合作，致力於開發符合在地語言與文化脈絡的 繁體中文與日文大型語言模型（LLM）。
同時，優必達亦提供多元的 AIGC（AI 生成內容）服務，包括：
- UbiArt：AI 圖像生成服務
- UbiONE：AI 虛擬角色解決方案
- UbiAnchor：AI 虛擬新聞主播
- Ubi-chan（AI VTuber）：官方品牌大使，展現優必達在生成式 AI 領域的創新成果
作為雲端遊戲領域的全球領導者，優必達提供完整的一站式解決方案，協助遊戲開發商快速將遊戲導入雲端，並支援電信業者建置自有的雲端遊戲平台。此外，優必達的技術亦廣泛應用於全球互動式媒體與虛擬實境（VR）內容的即時串流服務。
聯繫我們
TEL : +81-3-6435-3295 (Tokyo)
+886-2-2717-6123 (Taipei)
Media contact: pr@ubitus.ai
Business inquiry: contact@ubitus.ai
Website: www.ubitus.ai
