AI 基礎設施正變得愈來愈動態。工作負載可以在雲端、邊緣與裝置之間移動；運算資源可能壅塞，也可能隨時釋出；網路路徑可能劣化，也可能恢復，而某一時刻最適合執行工作負載的位置，下一刻未必仍然是最佳選擇。
然而，應用仍然必須正常運作。如果某個工作負載需要在特定時間範圍內獲得回應，需要一定程度的持續性，或對通訊效能有明確且可預測的要求，那麼即使底層基礎設施發生變化，這些服務目標仍然需要被滿足。
這也帶出一個對分散式 AI 愈來愈重要的問題：基礎設施究竟應該優化什麼？
今天，關於 AI 的討論很自然地聚焦在個別元件：更強大的模型、更快的加速器、更高的推論吞吐量，以及更低的延遲。這些都很重要。但隨著 AI 應用愈來愈多地跨越不同運算環境與通訊路徑，任何單一元件的效能，都愈來愈難完整反映整個應用是否真正按照需求運作。
換句話說，單一元件表現良好，並不代表整個系統就一定表現良好。
因此，對分散式 AI 而言，下一階段的基礎設施挑戰，或許不再只是讓每一個元件都達到最高效能，而是確保整個系統即使持續變動，仍能維持在工作負載所需要的運作條件內。
我們可以把它理解為應用與基礎設施之間的一種**「效能約定」**：明確定義基礎設施需要維持哪些運作條件，才能讓該工作負載如預期運行。
實體 AI（Physical AI）讓這個問題特別容易看見，因為基礎設施的選擇最終會直接影響現實世界中的結果。
以移動式機器人為例。感知、導航、推理與實體動作，可能有非常不同的運算需求與時間限制。有些功能可能必須留在裝置本地執行，另一些則可能更適合使用邊緣或雲端更強大的運算資源。問題在於，並不存在一個適用於所有情境的最佳運算位置。
Microsoft Research 在 2026 年的一項研究中，測試了移動式機器人操作工作負載在本地、邊緣與雲端 GPU 平台上的表現。研究發現，較小型的本地 GPU 難以實際承載完整工作負載，而效能更高的本地 GPU 則會帶來更大的能源消耗。將部分推論工作卸載至遠端雖然可以緩解部分限制，卻也會引入新的問題：額外的網路延遲會影響任務準確性，而頻寬需求也可能讓單純的雲端卸載方式變得不切實際。
這裡真正重要的，並不是雲端優於邊緣，也不是算力愈強就一定愈好。
真正值得注意的是：應用的最終表現，是整個系統中多個要素互相作用的結果。
更快的處理器可能改善工作流程中的一個環節；更低的網路延遲可能改善另一個環節；更高的能源效率則可能延長裝置的運作時間。但任何一項指標單獨來看，都無法判斷機器人是否能在所需條件下完成任務。
這個問題也不只存在於機器人領域。實際的 AI 工作負載已經展現出非常不同的服務需求。Microsoft Research 針對大規模 LLM 服務的研究顯示，從高度重視即時回應的互動式應用，到對處理時間要求相對寬鬆的任務，不同工作負載需要在請求路由、運算資源分配與模型部署之間做出不同的協調。
這些應用可能非常不同，但背後的觀察卻相似：
不同的應用，會對底層基礎設施提出不同的要求。
因此，「即時 AI」很可能不會存在一個單一且通用的定義。
對話式 AI 服務可能更重視回應速度；工業視覺系統可能需要在穩定的時間範圍內完成處理；自動化設備的安全關鍵功能可能必須留在本地，因為它不能依賴外部連線；而複雜的推理工作負載，則可能願意接受更長的處理時間，以換取更強大的運算資源。
因此，更有意義的起點並不是：
延遲還能做到多低？
而是：
這個工作負載真正需要什麼？
根據不同應用，這些要求可能包括回應時間、尾端延遲、頻寬、持續性、韌性、恢復能力，甚至地理位置限制。當這些需求被明確定義之後，就可以進一步轉化為可衡量的服務等級目標（SLO）。
相關研究也已經開始往這個方向發展。一項於 2026 年發表在《IEEE Transactions on Services Computing》的研究，針對邊緣 LLM 工作負載中不同的首 Token 時間（TTFT）、每個輸出 Token 的生成時間，以及端到端延遲目標進行分析。研究發現，如果主要以提升吞吐量為目標，反而可能無法達到不同工作負載各自的 SLO，因此提出了依據差異化服務目標進行資源調度的方法。
比任何單一指標更重要的是背後的原則：
單一元件的最高效能，並不一定等於應用真正需要的效能。
對基礎設施決策者而言，這代表設計邏輯需要改變。首先應該明確了解應用所需要的運作條件，接著再考慮工作負載應該在哪裡執行、所需資料如何送達、如何衡量完整執行鏈路的效能，以及當現實環境發生變化時，系統應該如何回應。
基礎設施可以是動態的，但當下的服務目標仍然必須被達成。
在本系列上一篇文章中，我們探討了網路決策與運算決策正變得愈來愈相互依賴，以及這為何推動網路層朝向更智慧化的方向發展。
近期的一些發展進一步印證了這個趨勢。
2026 年 10 月，IETF 發布了關於 Computing-Aware Traffic Steering（CATS，運算感知流量導引）的 RFC 10053 與 RFC 10054。這套框架在將流量導向不同服務實例時，不再只考量網路連線資訊，而是同時考量運算資源的狀態。值得注意的是，RFC 10054 明確將分散式 AI 推論與訓練列為其應用情境之一。
商業基礎設施也正往類似方向發展。NVIDIA 所提出的分散式「AI Grid」架構，正將加速運算從集中式基礎設施延伸至區域節點與邊緣環境，而工作負載的部署位置與路由方式，也愈來愈受到實際效能需求影響。
這些發展顯示，現在真正的問題已經不只是網路與運算是否應該更加協同。
更重要的問題是：
這種協同最終應該優化什麼？
我們的觀點是，答案愈來愈需要來自工作負載本身。
最低延遲的網路路徑、負載最低的運算位置，或可用頻寬最高的連線，都可能是重要的輸入條件，但它們本身未必是最終目標。
真正的目標，是協助應用維持其所需要的運作條件。
這也讓網路智慧有了更明確的方向。
一個具備應用感知能力的通訊層，需要掌握目前基礎設施的即時狀態，也需要明確知道工作負載本身需要什麼。可視性告訴系統「現在正在發生什麼」；應用意圖告訴系統「什麼才是重要的」；而即時控制能力則讓系統能夠做出回應。
所謂「應用感知」，並不是指網路可以自行理解應用。服務需求仍然需要透過政策、服務目標、編排系統或工作負載中繼資料等方式明確表達。
但一旦這些需求可以與即時基礎設施狀態結合，路由、韌性與傳輸策略就能夠愈來愈多地依據應用真正需要的條件動態調整。
其中的原則其實很直接：
了解基礎設施目前能提供什麼，了解工作負載真正需要什麼，並在兩者開始出現差距時及時調整。
這正是「智慧資料流動（Intelligent Data Movement）」開始變得更具意義的地方。
它不再只是更有效率地傳輸資訊，也不只是找到一條更好的網路路徑，而是逐步演變為協助分散式智慧維持其持續運作所需要的通訊條件。
隨著智慧逐步分散到裝置、邊緣基礎設施與雲端資源之間，通訊已經不再只是連接兩個端點。
資料、上下文資訊與決策結果，可能需要持續在不同的智慧節點之間流動，而每一個節點對時效性與可靠性的要求都可能不同。
對 Caton 而言，這類問題並不陌生。多年來，我們一直專注於如何讓對時間敏感的資料，在公共 IP 網路條件持續變化的情況下，仍然能夠可靠地即時傳輸。專業即時媒體曾經成為這項能力極為嚴苛的驗證場景：持續的大頻寬資料必須跨越不同網路與地域，即時傳輸，同時對中斷幾乎沒有容忍空間。
即時媒體成為這項底層能力的重要驗證場景，但它所代表的基礎設施挑戰並不局限於任何一種應用。
分散式 AI 與實體 AI 帶來的是更廣泛、也更複雜的挑戰。運算位置開始成為整體架構的一部分，通訊可能是雙向的，而不同工作負載對服務條件的要求也可能截然不同。為即時媒體發展出來的技術不能直接原封不動地套用到 AI 場景，但其背後的基礎設施方法依然具有高度相關性：了解應用需要什麼，觀察通訊環境目前能夠提供什麼，並在兩者開始出現落差時及時調整。
隨著 AI 進一步進入實體世界，這種能力將變得愈來愈重要。模型決定智慧如何產生，運算決定智慧在哪裡被處理；但分散式智慧能否真正發揮作用，還取決於資料、上下文與決策能否在這些不同位置之間，以應用所需要的條件可靠地流動。
我們認為，這也是通訊層下一步需要演進的方向：從可靠傳輸，進一步走向更智慧、也更具應用感知能力的資料流動。
底層基礎設施仍會持續變化。網路狀況會波動，運算負載會轉移，工作負載也會遷移，但服務目標仍然必須被滿足。
對分散式智慧而言，真正的挑戰不只是讓每一個端點變得更聰明，而是讓這些端點之間的連線足夠可靠，讓整個系統真正能夠協同運作。