最近“龍蝦”徹底火了，一個24*7待命的數字員工，效率直接起飛，看得人心里直癢癢。

不少老板看到后一拍大腿：上！

真把“龍蝦”請進公司，劇情開始反轉：表面上是自動化流水線，背地里卻像是給Token打工，月底一算賬，好家伙，比雇人還貴。

你以為請來的是個全能員工，結果更像一個“高薪但不太穩定的實習生”。

為什么會這樣呢？因為像“龍蝦”這樣的Agent，其工作方式和過去完全不同。

普通的聊天，一問一答，幾百幾千個Token就結束了，現在“龍蝦”自主規劃，多輪迭代，上下文超級長，一個任務跑下來，動不動就是幾十萬，甚至上百萬 Token。

現在大家通過FlashAttention、混合精度、融合算子、KV Cache池化緩存等技術拼命優化模型、優化推理性能，也只能解決單機的性能問題。

如果把目光移向整個AI算力池，重新審視Token性價比的時候，就會發現這里的平均推理利用率竟然不到30%，相當于花費重金建設、動輒數萬、數十萬卡的AI硬件算力池，竟有超過一半以上的算力在“摸魚，吃空餉”！

面對這個核心挑戰，華為云走出了一條創新的道路。

他們沒有再去一味堆模型、卷算力，而是在推理/訓練框架和底層算力（比如 CANN、CUDA）之間，插入了一層全新的系統——FlexNPU，你可以把它理解成一個“AI算力操作系統”。

FlexNPU通過創新的虛擬化和智能調度系統，把一塊塊固定僵硬的“硅片”，拆開、重組、再分配，變成了一種可以自由流動的柔性或“液態化”資源。

就像孫悟空的金箍棒那樣，需要的時候，可以撐到整個集群那么大，不需要的時候，可以縮到一根針那么細，“可大可小、變化隨心”，完全根據業務需求，“隨需而動”。

FlexNPU具體是怎么做的呢？ 我們詳細來看一看。

0 1

讀題目+寫答案：AI算力混合部署

你給大模型發送了消息后，它就需要讀取你的輸入，建立上下文，相當于在考試時把題目完整讀一遍。這一階段叫做Prefill（預填充），計算量很大，NPU需要全力運作。

大模型回答你的時候，就像是“寫答案”，是一個字(token)一個字往外生成，這一階段叫Decode，每次計算量小，但是持續生成。

由于兩階段任務的特點不同，所以業界的主流方案就是PD分離，一個NPU專門讀題目，另一個專門寫答案。

但是在“龍蝦”這種Agent場景下，用戶的請求充滿了極端的上下文和不可預測性，根本沒法提前規劃“讀題目”需要多少機器，“寫答案”需要多少機器。很容易出現有的機器閑著，有的忙死。

FlexNPU則采用了一種“PD動態混合部署”的方法，把“讀題目”和“寫答案”部署在同一套NPU上，然后用負載感知、算子劫持、資源調度等技術來調度兩種任務。

當系統“寫答案”的時候，如果發現算力閑著（因為Decode不怎么計算），立刻塞一個“讀題目” (Prefill) 任務進去！

當然，這種調度非常之快（微秒級），讓硬件利用率直接拉滿。最終實現在同等服務質量下，完美解決了傳統PD分離架構下Prefill和Decode集群不均衡的AI Core與顯存利用率問題，將帶來至少40%的Token性價比提升空間。

0 2

不會摸魚的打工人：白天接單，晚上加班

中小企業上AI系統，通常需要兩套集群。

一套是“在線集群”，處理白天的實時請求，例如用戶聊天、問答這些需要“秒回”的任務，資源調度要高效，避免任何卡頓。

另外一套是“離線集群”，處理晚上的非實時任務，如生成embeddings，數據清洗、預處理等，延遲不敏感，可以慢慢排隊等。

這種部署的問題就是白天的實時請求其實不穩定，很多時候NPU就用了30%，剩下的70%在發呆，資源浪費。

能不能把在線任務和離線任務在同一套機器上混著跑呢？

白天優先跑在線任務（用戶請求），同時如果有空閑資源，插入離線任務。

晚上在線請求變少，系統自動把大部分資源給離線任務。

華為的FlexNPU就是這么干的，在同一套集群中實現了毫秒級無縫穿插實時請求和非實時任務。

這就像一個超級打工人，他既能不斷地回答用戶的各種問題，“沒人”的時候見縫插針地去做一些數據清洗，文檔總結的離線任務。

到了深夜的業務低谷期，它會自動釋放出大量計算資源，利用自研的 iTransformer 預測算法會精準判斷這些資源能閑置多久，然后協同彈性引擎立刻把這些空閑資源“調度”給其他嗷嗷待哺的任務，比如正在排隊的Agent強化學習作業等。

利用這種削峰填谷的方式，每一分的NPU的算力都不浪費。

在華為云內部的AI代碼生成和外部MaaS業務場景中，這種方式解決了推理業務潮汐變化規律所導致的大量AI算力空轉浪費難題，同樣為大模型推理貢獻了至少40%的性價比提升！

0 3

AI合租時代：多模型共卡不打架

研究表明，現在Agent中的任務很多都是重復性和專業化的子任務，比如調用工具、解析文檔、生成報告。這些工作如果使用千億參數的“巨無霸”模型，那簡直就是用超級計算機玩掃雷，是巨大的資源浪費。

最好是把這些子任務放到小模型中來運行，例如一個大模型負責路由，一個小模型做記憶壓縮，另外一個做常識推理，還需要一個小模型做摘要提取。

在傳統云上，你得為這四個模型買四張卡，TCO直接爆炸，中小企業根本扛不住。

當然，為了省錢，可以把模型硬塞在一張卡上，但沒有底層資源隔離和精細調度，結果在極端情況下性能會崩。

一個模型突然來一波高并發，占滿了算力和帶寬，直接影響其他模型，推理變慢，延遲增加，甚至超時。

這就像多家公司擠在一個開放辦公區， 雖然分了桌子，但網絡是共用的，電源是共用的，空調是共用的。

一家公司開大會，網絡卡了，別人全被影響。

FlexNPU參照操作系統的理念，接管了物理的NPU資源，通過對AI Core的時分調度和對顯存的空分調度，實現了多個AI模型在同一張NPU卡上的精細化混部。

FlexNPU不但實現最小粒度達1% NPU卡及128MB顯存的顆粒度的AI Core時分復用，以及顯存空分復用。還實現了堅實的QoS與安全隔離。更重要的是可以在運行時可按需調整NPU算力大小、上層業務根本感知不到。

實戰效果顯示，在保障時延前提下，單NPU卡部署密度從5個提升到7個，FlexNPU為小模型提供了真正完美匹配其算力訴求、量體裁衣的虛擬NPU資源，將小模型的平均算力成本降低2-3倍以上。真正實現了降本增效。

0 4

斷點續命：任務不會再“白干一場”

現在的Agent有個致命的缺點：任務鏈路特別長。

它不是“一次推理就結束”，而是需要幾十步甚至上百步，持續幾分鐘甚至幾十分鐘。

就像你寫一篇幾萬字報告，寫到第95%時，沒有存盤，電腦突然死機了！

全部白寫，只好從頭再來。

在AI推理的時候也是類似，因為任務必須一口氣跑完，中間一旦某個NPU出問題， 完了，任務直接失敗，狀態丟失，不得不回到第一步從頭兒再來。

你剛剛消耗的Token、算力、時間全部作廢，讓人欲哭無淚。

FlexNPU做了什么呢？ 它實現了一套軟硬件解耦的架構：

推理服務不再直接綁定物理卡，而是通過虛擬映射實現靈活調度。

在任務運行的過程中，系統不斷“偷偷”記錄當前狀態，比如：模型推理進度，中間計算結果（KV Cache、狀態機），Agent 的上下文等。

而且關鍵點是：開銷極低，你幾乎感覺不到。

這樣一旦發生問題，FlexNPU就會讀取最近一次快照，恢復任務狀態，從中斷點開始執行，這一切，秒級即可完成，相當于原地滿血復活了。

這一切對上層完全無感，你不需要寫任何恢復邏輯，不需要重試機制，不需要 checkpoint 管理，一切自動完成。

一句話：AI 任務變得“又長又脆”，而 FlexNPU 讓它變成“又長又穩”。

0 5

總結

從上面的介紹可以看出，FlexNPU通過架構創新，為智能體帶來了3重突破性價值。

(1) 動態混合部署，用戶不需要為閑置資源買單；

(2) 小模型共卡復用，用戶不需要為生態冗余買單；

(3) 秒級快速恢復，用戶不需要為硬件故障買單。

華為云FlexNPU所做的一切，其實都是為了一個最終的目標：降低Agent的入局門檻。

讓每一分錢的AI算力投入，都迸發出最大化的價值；讓智能體時代海量的Token，人人都能消費得起。

值得注意的是，FlexNPU 其實只是華為云整個 AI 解決方案中的一塊拼圖：

在最底層，是 AI 基礎設施。

依托 CloudMatrix 超節點和 FlexNPU 這套“柔性智算”能力，華為云解決的，是最核心的問題——算力不再浪費，成本真正可控。為上層各種模型、各種 Agent 形態，提供了一個極致性價比的算力底座。

再往上一層，是模型服務層。通過 MaaS，華為云把主流開源大模型都“整理好、調教好”，企業不需要自己折騰部署和適配，就可以直接使用。

再往上，是開發者最熟悉的一層：Agent 平臺。這里更像一個“AI 操作臺”， 無論是程序員，還是業務人員，都可以通過簡單編排，快速搭建屬于自己的智能體。

最上面這一層，其實是最有意思的：場景工廠。

華為云把過去服務 2600 多家企業、500 多個實際場景的經驗，沉淀成了 40+ 個高頻 AI 模板。 不需要從零開始，開箱即用，對于中小企業來說，這一層的價值，甚至是最大的。

華為云給我的感覺就是，它不只在賣各種黑技術，而是深刻地洞察了企業在使用AI的過程中遇到的各種問題，然后提供了一站式的、全方位的解決方案，這才是正確的AI之路。