上週去了 KubeSummit 2026，每年晃去總會湧現一股「想當年」的懷舊感，腦海中不禁浮現早期為了架設 1.1x 環境而加班的日子，不過也強烈感受到 Kubernetes 生態系已經徹底從早期的微服務調度，全面轉向 AI 工作負載 (AI Workloads) 。
特別是 Agent AI 跳耀式發展的這兩年，跟平台工程有關的的技術討論收斂非常明顯，稍微記錄一下有聽到＋沒聽到＋有想到的幾個議題。
- K8s 基礎設施的 M 型化 這兩年來這1-2年來特別是 DRA 的成熟，解決了過去 GPU 資源分配僵化的痛點，對 GPU 切割 (MIG, Time-slicing) 有了更原生的支援，而 eBPF 提供的Observability也幾乎解掉過去網路與資安的不少盲點＆issue。
從現場的擺攤的幾家大型地端提供商來看，因為 AI 算力資料不出境、醫療或高科技製造的隱私需求，企業必須在地端自建龐大的 GPU 叢集，而這也促使各大基礎設施廠商快速跟進，提供整合式的 GPU 驅動與監控方案，整體技術成熟度與客戶規模都有著顯著的成長。
- Day 2 維運與 SRE Agent 的實踐
面對極度複雜的 Day 2 維運，SRE Agent 成為釋放 Infra 團隊壓力的解方，今年議程中展示了利用類似 ReAct 模式的 Agent 架構來處理系統異常。當開發者遇到 Pod Pending 或 OOM 時，SRE Agent 能自動調用 kubectl 或查詢log/metrics，並用自然語言回覆診斷結果，必要時也可以在規定的namespace內直接動手修復，這種將 LLM 結合工具呼叫 (Tool Calling) 的應用，直接把SRE 升級成高級大人版ＸＤ。
不過，相比於年中在 CyberSec 看到各大廠積極推展的 SIEM Agent，K8s 領域的 SRE Agent 實際落地的企業案例在體感上似乎相對較少，這點值得持續觀察。
也記錄一下一些想聽沒聽到的topic
Ray Serve + vLLM
雖然 vLLM 已經是 LLMOps 的標配，但在處理大規模、跨節點的分散式推論請求時，滿多blog post 都會推崇 Ray Serve 作為排程與資源分配的上層框架，再結合底層的 vLLM 引擎，這次好像沒有看到類似的分享。企業級地端 LLM Serving 的架構斷層
大家都知道怎麼用 vLLM 把模型跑起來，現場的解決方案商也都有在自己的場次提到可行，但要讓內部開發者享受到類似 Claude 或 GitHub Copilot 的體驗，地端架構在「算力」與「體驗」之間仍存在一層厚厚的斷層。這包含了需要 LiteLLM 來統一 API 與分流任務、上下文管理、RAG 基礎設施，以及完整的工具呼叫層。如果有個support百人團隊的地端 Qwen/Gemma 服務經驗分享，是不是很棒？WebAssembly (Wasm) 與邊緣輕量化
Wasm 比 Container 更極致的微秒級冷啟動速度與沙盒安全性，對於未來需要部署到極端邊緣 (Edge AI) 或是高度要求冷啟動效能的 Serverless 推論場景，Wasm 與 K8s 的深度綁定極具潛力，也十分期待未來能聽到更多相關的實戰技術體驗。
從 Infrastructure as Code 到現今的 AI as a Service，Kubernetes 正在經歷一場本質上的蛻變，它不再只是一個單純的容器調度平台，而是逐漸成為企業級 AI 算力與 Agentic 應用的底層作業系統。
Top comments (0)