利用率，而非智慧本身，是 AI 領域的下一個真正限制。

航空業深諳此道。在該產業的大部分歷史中，最能預測航空公司能否生存的數字，就是每架飛機每天停留在地面的時間長短。

原因在於其結構性。飛機的成本是按日曆小時累積的：融資、折舊、機體保險、定期維護和機組人員合約。然而，其收入卻只按飛行小時累積。每停留在地面一小時，都會縮減該方程式的產出端，而成本端卻一如既往地持續運作。利用率也幾乎是航空公司所有其他營運的最終結果。無論是周轉紀律、航線設計、維護規劃、機組排班，還是備件可用性，最終都會體現在這個數字上，因為底層的營運問題會讓飛機停飛，即使其他方面都順利也無濟於事。

擁有更大的機隊仍然有幫助。更多的飛機意味著更多可用的運力，這是顯而易見的。然而，兩家航空公司即使擁有相似的機隊並飛行相似的航線，最終的經濟效益也可能大相徑庭，而大部分差距都可歸因於一項衡量標準，而非機隊規模。

企業級 AI 正面臨相同的結構性問題，只是硬體不同。GPU 的成本也是按日曆小時累積的，包括融資、折舊、電力和散熱，無論它在特定時刻是否有在做有用的事情。其產出僅按運算小時累積。更多的 GPU 就像更大的機隊對航空公司的幫助一樣：提供實際運力，帶來真正的優勢，但仍無法保證最終決定勝負的結果。

兩家擁有相似 GPU 預算的公司，其表現差異越來越大，取決於其硬體在任何特定時刻的有效利用程度，而非擁有多少硬體。這個數字，就像航空公司的利用率一樣，是公司幾乎所有其他基礎設施決策的最終結果。智慧已將這個產業帶到此處，而利用率則是下一個真正限制的所在。

隨著 AI 規模的擴大，稀缺性並未消失。它只是向上游移動，完全轉移到不同的資源上。

第一波企業級 AI 的成功取決於模型品質。更大的模型，透過更多的運算進行訓練，並根據更嚴苛的基準進行評估：參數數量和排行榜位置主導了討論，這場競賽產生了真正足以運行實際企業工作負載的模型。然而，這種能力也伴隨著一項依賴性。生產級 AI 運行在專用硬體上，而如今這種硬體幾乎完全是 GPU。

GPU 價格昂貴、供應受限，且需求遠超供應，即使在市場頂端也是如此。2020 年，Microsoft 為 OpenAI 建造了一台專用超級電腦：超過 10,000 個 GPU 和 285,000 個 CPU 核心，當時被報導為全球五大系統之一，旨在訓練後來的 GPT-3。

當時，這看起來像是幾乎難以想像的硬體集中，這樣的數字讓運算看起來像是任何能取得它的人都能解決的問題。六年後，這個數字更像是起點而非上限。到了 2026 年，即使是全球資金最雄厚的實驗室，也將運算資源的取得視為一個持續存在的戰略限制，而非已解決的問題。

光是 Anthropic 就同時在 Amazon、Google、Microsoft 和 AMD 四個獨立硬體平台上執行數十億瓦的承諾，這些承諾在數月內層層疊加，而 Meta 也簽署了類似的數十億瓦交易。當買家擁有幾乎無限的資金，卻仍無法從任何單一來源獲得足夠的資源時，同時向四家供應商分散承諾，就是運算稀缺的寫照。

這兩起相隔六年的事件，都標誌著實驗室維持競爭力所需的極限。期間的變化與 AI 能力的提升關係不大，而與能力不再是主要限制有關。同樣的模式也以不同形式出現在實驗室的下游。企業透過 API 使用這些模型時，遇到的更多是定價問題而非硬體問題。成本隨使用的 token 數量線性增長，這一點幾乎完全區分了概念驗證 (PoC) 和生產環境的經濟效益。

每月處理數千個請求的 PoC 看起來負擔得起，但相同的工作負載在生產規模下，成本線可能永遠無法結清。越來越受歡迎的替代方案很直接：企業購買自己的 GPU 並在本地運行模型，將可變的線性擴展成本換成固定的資本成本。

API 成本隨使用量增加，而自有基礎設施成本則趨於固定。超過損益平衡點後，兩者的優勢會逆轉。

這種轉變將 GPU 從單一項目變成了基礎設施，其規模考量了成長和需求高峰，因此通常會超出任何特定週的實際需求。這意味著購買本身並不能解決問題，反而開啟了新的問題。當叢集上線的那一天，問題不再是我們能否取得加速器，而是我們能否讓它們保持忙碌，而只有第一個問題有採購團隊負責。簽訂硬體合約是有期限和負責人的部分，但讓硬體持續運作才是默默決定這筆交易是否值得簽署的部分。

這些交易描述的是運力承諾，而非效率。這些運力如何被有效利用是一個獨立的問題，由不同的人負責，衡量標準遠不夠嚴謹，且距離解決還有很長一段路。

即使一個充滿忙碌 GPU 的叢集，仍然可能浪費大部分潛力，原因幾乎總是相同的。GPU 日夜不停地運行，但對它們的需求卻不是如此。基礎設施必須根據高峰期進行規劃，也就是訓練運行、批次作業和即時流量同時湧入的時刻，這導致在非高峰期有相當一部分運力被配置卻未使用。如果每個 GPU 都能同樣良好地處理各種工作，更好的預測本身就能解決這個問題。然而，很少有 GPU 能做到這一點，這也成為問題更困難的一半。

不匹配的問題更深一層。在第一代企業級 AI 中，GPU 的工作大多是單一的：執行推論。如今，相同的硬體支援訓練、微調、量化、即時推論、批次推論、嵌入生成和模型評估，這些工作通常來自同一個組織，有時甚至針對同一個模型，在同一個叢集上運行。這些工作負載對硬體的需求各不相同，且差異很大。

即時推論幾乎比任何其他需求都更需要低延遲，因為緩慢的回應等同於失敗。批次工作則注重吞吐量並能容忍延遲，有時甚至數小時。訓練可以連續佔用 GPU 數小時甚至數天。量化需要大量運力，但時間很短。為其中一種工作負載優化的排程器，幾乎預設會錯誤分配其他三種。

這種失敗也不總是會顯示在利用率儀表板上。一個叢集可能報告高平均佔用率，但同時有幾個排隊中的作業正在等待某種 GPU 配置，而該配置卻正忙於運行完全不同的東西。

確切的工作負載組合因組織而異，但問題的本質卻是相同的。這也是飛機類比的極限所在，而這個極限不僅僅是限定了比較，它還帶來了啟示。一架閒置的飛機通常可以重新部署到機隊中的任何航線：一架停在芝加哥的 737 可以飛往丹佛而不是達拉斯，而不會有太大損失。

然而，一個閒置的 GPU 只能處理其記憶體、延遲和持續時間特性能夠服務的工作負載。這種差異使得協調比機隊排程更困難，這也是為什麼問題不再是 GPU 是否被佔用，而是哪個工作負載應該在哪個 GPU 上運行，在什麼時間，以及以什麼優先級運行。購買另一個 GPU 機架增加了運力和成本，但並不能解決不匹配的問題，而且這些新運力也可能在錯誤的時機以錯誤的配置閒置，就像已安裝的運力一樣。

最大化 GPU 投資報酬率 (ROI) 不僅僅是一次性的配置決策。它需要對基礎設施本身進行持續、主動的管理，每小時都在運行，而不僅僅是在採購時。為此應運而生的是一門獨特的學科，即 GPU 管理，這是一個介於工作負載、模型和硬體之間的協調層。

它的職責是持續決定哪個工作負載運行、何時運行、如何運行以及在叢集中的哪個特定 GPU 上運行。這些概念並非奇特，它更接近於一個優秀的營運團隊憑直覺已經在做的事情，只是將其正式化並持續運行，而不是依賴於有人發現問題。

智慧不再僅限於模型邊界。協調層正在做出模型本身無法察覺的即時分配決策。過去，智慧幾乎完全存在於模型中：更大、訓練更好、能力更強，這就是遊戲的大部分內容。現在，它也必須存在於基礎設施中，在決定哪個競爭工作負載獲得剛釋放的 GPU，以及相對於佇列中其他所有等待項目的優先級的層面。

讓 GPU 保持忙碌本身不再是目標，因為透過運行可以等待的低優先級工作很容易假裝忙碌。最大化每個已安裝 GPU 所產生的回報成為實際目標，而這被證明是一個比之前的配置問題更為持續的問題。

良好的配置並不能消除這個問題，而只是改變了它的形式。配置決策是在購買時一次性做出的。而分配決策則是持續不斷地做出：每次作業完成時、每個新請求到達時、客戶服務與內部訓練運行之間優先級的每次轉變時。這種頻率解釋了為什麼決策已從人工逐案處理轉變為必須自動運行。

沒有工程師會在凌晨三點盯著儀表板，決定一個已完成的訓練運行是否應該將其 GPU 交給排隊中的批次作業，還是保留它以應對即將到來的客戶流量高峰。必須有其他機制來持續做出這個判斷，並且要足夠正確，讓沒有人需要去檢查。

這門學科還很新，其工具和慣例仍在形成中，對於成熟的 GPU 管理實踐應該是什麼樣子，目前還沒有單一的標準。至少，限制轉移到何處這一點已經確定。

專業化和協調解決了同一個問題的不同面向。專業化、小型化的模型能夠以大型通用模型執行相同任務所需資源的一小部分成本，來完成特定任務，同時不犧牲任務所需的品質。這對利用率有直接影響。過去需要單一大型模型、佔用叢集大部分運力來完成整個作業的工作負載，現在可以改為在佔用資源較少的小型、任務專用模型上運行。

過去完全被佔用的運力突然變得空閒。專業化釋放的運力多少因工作負載和模型而異，但這些釋放的運力仍然需要去處，否則它只是...