隨着大語言模型和生成式 AI 的爆發式增長，AI 推理服務已從單純的實驗室驗證走向了大規模生產環境的核心。然而，在雲原生架構下部署這些服務，開發者和架構師們正面臨着前所未有的挑戰。
AI 推理服務對延遲具有極高的敏感度。與傳統的 Web 服務不同，推理任務往往涉及大量的矩陣運算，任何微小的計算資源抖動都可能導致 P99 延遲飆升，直接影響終端用户的體驗。
同時，推理業務具有顯著的“潮汐”特性。日間流量高峯與夜間低谷之間的資源需求差異巨大，導致昂貴的算力在低谷期被大量閒置。為了降低成本，企業傾向於將推理服務與數據預處理等業務混合部署。但這往往引發嚴重的“鄰居干擾”問題，離線任務對 CPU 緩存和內存帶寬的爭搶，成了破壞推理穩定性的“隱形殺手”。
面對上述挑戰，構建高效 AI 推理基礎設施的核心訴求逐漸清晰。一方面，必須提供極致的服務質量保障，確保在線推理服務在任何負載下都能獲得確定性的低延遲；另一方面，必須實現對 NPU 或 GPU 等異構資源的高效利用，打破資源孤島。openFuyao 正是為解決這些痛點而生的雲原生調度引擎，它旨在通過獨特的智能調度算法和精細化的資源管理能力，為 AI 推理場景提供穩健的運行環境與極致的資源利用率。
一、 為推理護航：在離線混部的三級QoS服務質量定義
在 Kubernetes 的原生調度體系中，服務質量僅被粗略地劃分為 Guaranteed、Burstable 和 BestEffort 三類。這種粒度對於複雜的 AI 生產環境而言顯得過於粗糙。標準調度器難以區分核心推理服務與次要任務的優先級，往往導致關鍵業務在資源緊張時受到波及，無法滿足低延遲的嚴苛要求。
openFuyao 在 v25.06 版本中引入了更為精細的三級 QoS 服務質量模型，這是實現“在離線混部”的技術基石。首先是 HLS（高時延敏感）級別，這是 openFuyao 為核心在線業務量身定製的最高優先級。被定義為 HLS 的 Pod，在調度層面擁有絕對的資源優先權，系統會為其預留充足的物理核並綁定特定節點。
其次是 LS（時延敏感）級別，適用於對延遲有一定要求但容忍度略高的場景，例如內部使用的 AI 輔助工具，它在保障基本服務水平的前提下允許一定程度的資源彈性。
最後是 BE（盡力而為）級別，這是提升資源利用率的關鍵變量，通常涵蓋批量數據清洗或模型增量訓練等離線任務。
通過這種分級機制，openFuyao 能夠實現毫秒級的資源管控。開發者可以將對延遲極敏感的在線推理服務劃分為 HLS 或 LS 級別，確保其獲得最高的資源優先級。當在線流量涌入時，系統會自動限制 BE 級別任務的資源使用，使其免受干擾。這就像是在高速公路上開闢了應急車道，確保核心推理服務始終擁有一條暢通無阻的快車道。
二、 硬件感知：NPU與眾核拓撲的智能調度優化
現代 AI 推理服務器正朝着“眾核高密”的方向演進，單台服務器往往配備數百個 CPU 核心及多張高性能 NPU 加速卡。這種硬件架構雖然算力強大，但也帶來了兩層複雜性。
一方面是 NPU 等異構硬件的管理缺乏統一標準，往往需要人工硬編碼設備 ID。另一方面是 CPU 拓撲結構的影響，在 NUMA 架構下，跨節點的內存訪問會導致顯著的延遲，嚴重影響推理性能。
針對異構算力管理，openFuyao 提供了專門的 NPU Operator。它不再僅僅是一個資源發現工具，更是一個全生命週期的管理者。NPU Operator 能夠自動識別節點上的昇騰 NPU 資源（包括虛擬 NPU 卡），並接管了從驅動、固件到設備插件的自動化安裝、配置、升級與故障診斷。這意味着運維人員可以從繁瑣的底層硬件適配中解放出來，確保異構算力底座始終處於健康就緒狀態。
更為核心的是 openFuyao 的“眾核高密集羣層調度”能力，它做到了真正的拓撲感知。在調度推理 Pod 時，系統不僅關注 CPU 的空閒狀態，還會深入分析服務器的 NUMA 結構。
通過優化資源分配策略，openFuyao 強制確保 Pod 申請的 CPU 核心、內存以及 NPU 設備位於同一個 NUMA 節點內。這種策略避免了跨 NUMA 訪問帶來的延遲抖動。此外，針對高密度部署下的鎖競爭問題，openFuyao 優化了調度算法，智能分散高爭搶型任務的物理核分佈，減少了多線程併發時的上下文切換開銷。
三、 彈性與觀測：openFuyao Ray 賦能分佈式AI集羣
隨着大模型參數量的激增，單機推理往往難以滿足需求，分佈式推理成為常態。Ray 作為當前最流行的分佈式 AI 計算框架，因其易用性和強大的擴展性被廣泛應用。然而，在 Kubernetes 上原生運行 Ray 集羣，往往面臨着監控缺失、資源狀態不透明等運維難題。
openFuyao 深度擁抱 AI 生態，推出了 openFuyao Ray 組件。除了提供 Ray 集羣的生命週期管理外，其最大的價值在於新增的監控面板功能。這一功能填補了 Ray 在雲原生環境下的可觀測性空白。
通過這一面板，AI 開發者和 SRE 團隊可以獲得前所未有的直觀視角。無論是 Ray Head 節點和 Worker 節點的健康信息，還是細粒度的資源利用率和推理任務狀態，都能一目瞭然。
這些信息為高效運維提供了數據支撐，使得 Ray 集羣的彈性伸縮策略不再是基於猜測，而是基於實時的業務負載和資源狀態，從而實現毫秒級的擴縮容響應。
四、 實戰推演：構建企業級高可用推理集羣
為了更深入地理解 openFuyao 的核心機制，我們不再侷限於簡單的命令交互，而是從架構師的視角，通過聲明式配置來推演一個生產級 AI 推理集羣的構建過程。我們構建一個典型的混合負載場景，集羣中同時運行着 HLS 級的在線推理服務、LS 級的內部服務和 BE 級的離線訓練任務。
在 openFuyao 的體系中，所有的資源隔離策略都通過 Kubernetes 標準的 YAML 文件進行聲明。開發者無需修改代碼，只需在 Deployment 中添加特定的註解或標籤，即可完成服務分級。
對於核心的在線推理服務，我們在配置中明確聲明其 HLS 地位：
apiVersion: apps/v1
kind: Deployment
metadata:
name: deepseek-inference-online
labels:
# 聲明 QoS 等級為 HLS，獲取最高優先級
openfuyao.io/qos: HLS
spec:
template:
spec:
containers:
- name: inference-container
resources:
# 申請獨佔資源，確保穩定性
limits:
cpu: "8"
memory: "32Gi"
nvidia.com/gpu: "1"而對於離線訓練任務，我們則將其標記為 BE，並允許其使用共享資源池：
apiVersion: batch/v1
kind: Job
metadata:
name: offline-model-training
labels:
# 聲明 QoS 等級為 BE，利用空閒算力
openfuyao.io/qos: BE這種“配置即策略”的設計，使得運維團隊可以像管理代碼一樣管理算力策略。當上述配置應用到集羣后，openFuyao 的調度器將接管資源分配權，並根據實時負載進行動態決策。
在業務低谷期，在線推理服務的流量較低，CPU 利用率不高。調度器感知到大量閒置算力，於是允許 BE 級的離線訓練任務全速運行，填滿剩餘的資源空間。此時，集羣如同滿載的貨輪，每一寸空間都產生了價值。
當突發流量洪峯到來時，調度器的微秒級監控探針檢測到 HLS 服務的資源競爭加劇。“資源水位線驅逐機制”會瞬間觸發，系統立即壓制甚至暫停該節點上的 BE 任務，將算力無縫歸還給 HLS 業務。整個過程無需人工干預，在線用户的請求延遲始終保持在毫秒級的穩定水平。
基於上述架構推演，在同等硬件規模下，openFuyao 能為企業帶來顯著的收益。它不僅將資源利用率提升了 40% 以上，徹底消除了“資源孤島”，更在混部環境下將核心推理服務的 P99 延遲波動控制在極低範圍，實現了真正的“混部而不混亂”。
五、 賦能開發者：構建下一代AI推理基礎設施
openFuyao 通過這一套組合拳，系統性地解決了 AI 推理場景的三大難題。智能調度和三級 QoS 解決了性能與穩定性的矛盾，讓混部不再是冒險；硬件感知能力挖掘了底層算力的極致潛能，降低了算力成本。
AI 技術的競爭，歸根結底是算力效率的競爭。在硬件摩爾定律放緩的今天，軟件定義的算力優化將成為新的增長引擎。我們呼籲廣大的 AI 開發者、MLOps 工程師和架構師關注 openFuyao，利用這一開源利器構建高效、穩定、低成本的 AI 推理平台。
探索 openFuyao 的旅程非常簡單。您可以訪問官方文檔瞭解架構細節，或者參考快速入門指南在測試環境中部署，親身體驗 AI 場景下的加速效果。
總結
openFuyao 不僅僅是一個技術項目，更是雲原生技術與 AI 業務深度融合的產物。它為 AI 開發者提供了一條通往高效算力管理的捷徑。隨着 AI 應用場景的不斷拓展，openFuyao 將持續深耕異構計算與智能調度領域，助力企業在 AI 時代從容應對算力挑戰，實現業務價值的最大化。
