作者 | 袁鐿

編輯｜李忠良

策劃｜AICon 全球人工智能開發(fā)與應(yīng)用大會(huì)

從 vLLM、SGLang，到 TensorRT-LLM、MindIE，再到新興的“一念”，不同團(tuán)隊(duì)在算子優(yōu)化、顯存管理與調(diào)度策略上不斷博弈，性能指標(biāo)在短短半年間就提升了數(shù)倍。為什么會(huì)出現(xiàn)這樣激烈的競(jìng)爭(zhēng)？現(xiàn)有的開源框架是否已足夠成熟？推理系統(tǒng)究竟卡在哪些“瓶頸”？

InfoQ 榮幸邀請(qǐng)到了 袁鐿 騰訊 /PCG 機(jī)器學(xué)習(xí)平臺(tái)技術(shù)負(fù)責(zé)人在 AICon 全球人工智能開發(fā)與應(yīng)用大會(huì)·深圳站上分享了《一念 LLM 分布式推理優(yōu)化實(shí)踐》，從 KV cache 全鏈路管理、算子封裝與自研，到多維并行（PP/DP/EP）、MoE 負(fù)載均衡與 MLA、以及 PD 分離與多階段流水線調(diào)度，給出了一套工程化解法。

12 月 19～20 日的 AICon 北京站 將錨定行業(yè)前沿，聚焦大模型訓(xùn)練與推理、AI Agent、研發(fā)新范式與組織革新，邀您共同深入探討：如何構(gòu)建起可信賴、可規(guī)?；⒖缮虡I(yè)化的 Agentic 操作系統(tǒng)，讓 AI 真正成為企業(yè)降本增效、突破增長(zhǎng)天花板的核心引擎。

詳細(xì)日程見：

https://aicon.infoq.cn/202512/beijing/schedule

以下是演講實(shí)錄（經(jīng) InfoQ 進(jìn)行不改變?cè)獾木庉嬚恚?/strong>

“一念 LLM”是一款面向大語言模型的推理框架，與 vLLM、SGLang、TensorRT-LLM 等同屬一類。那么，在已有眾多開源框架的前提下，為什么還需要開發(fā)“一念 LLM”？

要回答這個(gè)問題，先看大語言模型推理框架的基本工作流：當(dāng)系統(tǒng)接收到大量并發(fā)請(qǐng)求，請(qǐng)求首先進(jìn)入并行調(diào)度模塊，隨后進(jìn)入顯存管理。顯存管理包括為 KV cache 分配顯存；當(dāng)顯存不足時(shí)，需要決定是從外部 KV Cache 調(diào)入，還是將部分請(qǐng)求 offload 到內(nèi)存，或更遠(yuǎn)的存儲(chǔ)介質(zhì)。

顯存就緒后，系統(tǒng)會(huì)對(duì)請(qǐng)求進(jìn)行批處理，并針對(duì)不同模型進(jìn)行算子調(diào)度，生成 KV cache。隨后算子開始執(zhí)行，完成后進(jìn)入采樣階段。在生成過程中，會(huì)設(shè)置諸如 temperature 等參數(shù)，系統(tǒng)隨之生成一系列 Token。生成結(jié)束后，可能還需進(jìn)一步處理，例如將 Token 轉(zhuǎn)換為結(jié)構(gòu)化輸出（如 JSON），或?qū)R業(yè)務(wù)約定的模式；又或者在生成某個(gè) Token 后，基于對(duì)下一個(gè) Token 的概率分布，執(zhí)行投機(jī)解碼以加速推理。

整體流程中，不同模塊大體對(duì)應(yīng)并行調(diào)度、顯存與隊(duì)列管理，以及算子調(diào)度，這些也是各框架之間的主要差異所在。至于算子層面，若深入代碼會(huì)發(fā)現(xiàn)各框架相互借鑒較多：由于 Transformer 架構(gòu)和模型結(jié)構(gòu)相對(duì)穩(wěn)定，優(yōu)化路徑趨于一致；一旦某個(gè)算子實(shí)現(xiàn)效果更優(yōu)，往往會(huì)被迅速吸收并推廣。

從貢獻(xiàn)角度來看，硬件廠商通常在算子研發(fā)上具備天然優(yōu)勢(shì)，因?yàn)槠鋵?duì)自家硬件的理解最為深入，能夠充分利用硬件特性進(jìn)行設(shè)計(jì)。典型代表是 TensorRT-LLM 與 MindIE。

對(duì)于非硬件廠商而言，研發(fā)的重點(diǎn)更多集中在調(diào)度與顯存管理，例如 vLLM 最初從 paged attention 入手，SGLang 以 prefix caching 作為起點(diǎn)，而“一念”等框架也在此方向進(jìn)行探索。同時(shí)，學(xué)術(shù)界也持續(xù)在這些機(jī)制上開展研究與創(chuàng)新。

另一個(gè)在算子方面貢獻(xiàn)顯著的群體是模型廠商，他們貢獻(xiàn)了大量算子。隨著 DeepSeek 的興起，過去半年間推理框架領(lǐng)域的競(jìng)爭(zhēng)異常激烈。為什么會(huì)如此激烈？假設(shè)在 H20 16 張卡的條件下，可以部署完整版本的 DeepSeek 模型，如果所有算子的 MFU 僅為 60%，理論吞吐量應(yīng)可達(dá)到 30K。

然而，實(shí)際情況是在今年 2 月份時(shí)，vLLM 和 SGLang 的性能僅為 2K。經(jīng)過半年的激烈競(jìng)爭(zhēng)與優(yōu)化，目前 vLLM 和 SGLang 的性能已提升至原來的兩到三倍。與此同時(shí)，TensorRT-LLM 橫空出世，最新測(cè)試數(shù)據(jù)達(dá)到 11.2 K。

一念的最新數(shù)據(jù)則為 14.6K。但整體來看，與理論預(yù)估的 30K 相比，仍存在巨大的差距。這也意味著，在基礎(chǔ)設(shè)施層面仍有廣闊的優(yōu)化空間，相關(guān)工作需要持續(xù)深入推進(jìn)。

“一念 LLM”的設(shè)計(jì)思路與實(shí)踐

那么，為什么要做一念框架這件事？我們的判斷基于兩個(gè)核心因素。

首先，推理環(huán)節(jié)在業(yè)務(wù)邏輯中的比重將會(huì)越來越大。一個(gè)模型即可完成整個(gè)業(yè)務(wù)流程時(shí)，推理就會(huì)成為后臺(tái)系統(tǒng)中最龐大的服務(wù)。這一趨勢(shì)直接帶來對(duì)業(yè)務(wù)快速響應(yīng)和系統(tǒng)穩(wěn)定高效的更高要求。

對(duì)于一個(gè)開源框架而言，如果無法在研發(fā)路徑上保持較高的可控性，那么在定制能力與系統(tǒng)穩(wěn)定性之間就會(huì)產(chǎn)生沖突，從而可能影響業(yè)務(wù)收益與整體的穩(wěn)定性。

其次，在算子優(yōu)化方面，硬件廠商和模型發(fā)布者往往會(huì)進(jìn)行深度優(yōu)化。因此，“一念”在設(shè)計(jì)時(shí)便以高效引入開源算子、支持多種硬件為基礎(chǔ)假設(shè)，并在此之上構(gòu)建了基本結(jié)構(gòu)。

在整體架構(gòu)的最上層，我們采用的是手寫模型。事實(shí)上，大語言模型本質(zhì)上都是手寫模型，只是常見的實(shí)現(xiàn)方式多基于 PyTorch，用 Python 編寫；而我們選擇使用 C++ 實(shí)現(xiàn)，并在此過程中進(jìn)行顯存優(yōu)化。

顯存優(yōu)化的重要性不言而喻。以 Kv-cache 為例，其本身就會(huì)消耗大量顯存，而在追求更高吞吐量與更長(zhǎng)序列長(zhǎng)度的場(chǎng)景中，顯存問題尤為關(guān)鍵。同時(shí)，還需要通過高效的調(diào)度來進(jìn)一步提升吞吐性能。

在算子層面由三部分組成：開源封裝、移植算子、自研算子。針對(duì)不同硬件進(jìn)行適配，我們額外封裝了一層類 CUDA 的接口，以支持多種硬件平臺(tái)，包括 Nvidia GPU、華為昇騰芯片以及騰訊紫霄芯片。通過這一設(shè)計(jì)，可以實(shí)現(xiàn)對(duì)下層異構(gòu)硬件的屏蔽，對(duì)上層提供統(tǒng)一使用體驗(yàn)。

需要特別指出的是，由于我們對(duì)顯存實(shí)現(xiàn)了全流程的自主管理，在 R1 模型上，Kv-cache 的可用顯存比業(yè)界水平提升約 130%，而吞吐量提升約 30%。

推理優(yōu)化的挑戰(zhàn)與突破

在進(jìn)行大語言模型推理優(yōu)化時(shí)，首先需要明確所面臨的問題與限制。隨著應(yīng)用規(guī)模的擴(kuò)大，Prefilling Tokens 的長(zhǎng)度不斷增加，而真正導(dǎo)致效率低下的環(huán)節(jié)主要集中在 Decoding Tokens 階段。

如上圖，在 A100 上進(jìn)行 Forwarding 計(jì)算時(shí)，隨著輸入 Token 數(shù)量的增加，GPU 的實(shí)時(shí)有效計(jì)算能力會(huì)逐漸逼近硬件上限。一旦達(dá)到上限，即便繼續(xù)增加 Token 數(shù)量，計(jì)算功率也無法進(jìn)一步提升，只能通過延長(zhǎng)計(jì)算時(shí)間來完成額外的任務(wù)。

另一個(gè)瓶頸在于 decoding 階段。其效率較低，因?yàn)樵诔Ｒ?guī)情況下每次僅能生成一個(gè) Token，即便結(jié)合投機(jī)解碼，通常也只能生成兩到三個(gè) Token。因此，提高 batch size 成為一個(gè)顯著的優(yōu)化手段。

然而，增加 batch size 會(huì)帶來新的挑戰(zhàn)。由于序列長(zhǎng)度不斷增長(zhǎng)，較大的序列長(zhǎng)度疊加更大的 batch size，將導(dǎo)致 Kv-cache 的需求急劇增加，從而直接受限于顯存容量。

因此，在有限顯存條件下，提升推理階段 Token 的并行處理能力。同時(shí)需要注意，一旦某一階段達(dá)到硬件極限，就不應(yīng)繼續(xù)增加負(fù)載，否則只會(huì)導(dǎo)致整體耗時(shí)增加。

接下來，來看推理過程中的多個(gè)階段。在 MoE 部分，采用 256 個(gè)路由專家加 1 個(gè)共享專家的架構(gòu)。如上 DeepSeek 的結(jié)構(gòu)圖可以看到，在計(jì)算過程中，大量 Token 經(jīng)過路由表時(shí)，會(huì)導(dǎo)致各個(gè)專家之間的負(fù)載分布不均。而共享專家的路徑則是全量 Token 直接通過，沒有經(jīng)過路由，因此共享專家的負(fù)載會(huì)異常集中。

換言之，上半部分是稀疏計(jì)算但負(fù)載不均，下半部分則是高負(fù)載計(jì)算。典型的解決方案有兩點(diǎn)：一是通過增加并行 Token 數(shù)，使不均衡效應(yīng)被攤薄；二是采用 EP 的方式，為共享專家設(shè)置多副本，將其分配到不同的卡或芯片上進(jìn)行并行計(jì)算，從而獲得更多計(jì)算資源。

在 MLA 部分，其最大特點(diǎn)是對(duì) Kv-cache 進(jìn)行壓縮，從而減少單個(gè)副本內(nèi)各卡的 Kv-cache 占用。但這也帶來新的問題：多卡之間的壓縮 CompressedKv 出現(xiàn)重復(fù)，造成顯存浪費(fèi)。同時(shí)，額外的 Project 操作也進(jìn)一步增加了開銷。對(duì)應(yīng)的解決方案包括權(quán)重吸收，以及采用全 DP（Data Parallelism），即只保留一份副本，避免重復(fù)存儲(chǔ)。

目前的技術(shù)主要從計(jì)算、通信和顯存三個(gè)維度展開優(yōu)化。最原始的方案是 全 TP（Tensor Parallelism），這種方式實(shí)現(xiàn)最為簡(jiǎn)單，但其特點(diǎn)是：在 MoE 階段計(jì)算呈稀疏狀態(tài)，同時(shí)通信開銷較大；另一個(gè)關(guān)鍵問題是 Kv-cache 的冗余存儲(chǔ)。在全 TP 方案中 ，若使用 4 張卡，就會(huì)產(chǎn)生 4 份冗余副本。

針對(duì)這一問題，出現(xiàn)了第一批改進(jìn)方案：通過減少冗余，將不同的 MoE 分配到盡量少的卡上。例如，將兩張卡之間的內(nèi)容保持一致，計(jì)算邏輯相同，只是輸入數(shù)據(jù)不同（如 batch1 與 batch2）。

在這種情況下，可以邏輯上等價(jià)于將 batch 擴(kuò)大一倍，從而使后續(xù) MoE 階段的 batch 規(guī)模加倍。該方案的優(yōu)勢(shì)在于顯著增大了 MoE 階段的 Token 數(shù)量，同時(shí)降低了部分通信與 Kv-cache 的冗余。但也帶來了新的問題：權(quán)重和 buffer 有所增加。

在實(shí)際的小規(guī)模部署中，會(huì)遇到 DP 無法擴(kuò)展過大的問題。原因在于，當(dāng) DP 規(guī)模增大時(shí)，雖然 Kv-cache 的冗余有所減少，但權(quán)重與 buffer 占用卻顯著增加。如果資源消耗超過可用顯存，就會(huì)無法正常運(yùn)行。

進(jìn)一步擴(kuò)展的思路是增加 MLA 與 DP 的份數(shù)，并在跨機(jī)時(shí)引入 EP。EP 的優(yōu)勢(shì)在于通信量減少，因?yàn)樗恍鑲鬏攲?duì)應(yīng)專家所需的參數(shù)、路由信息及部分狀態(tài)數(shù)據(jù)。

然而，采用共享專家進(jìn)行負(fù)載均衡會(huì)增加顯存開銷，形成“蹺蹺板”效應(yīng)。常見的解決方式是擴(kuò)大批處理規(guī)模，將更多專家分布到多張卡上，即使每張卡只增加一個(gè)專家或共享專家，也能獲得收益。

不過，僅依靠擴(kuò)大 DP + 大 EP 的組合方案仍不足以解決問題，因此引入了PD 分離（Prefill 與 Decode 分離）的思路。其原因在于 Prefill 與 Decode 兩個(gè)階段混合執(zhí)行時(shí)會(huì)相互影響性能。Prefill 階段通常一次性輸入數(shù)千個(gè) Token，會(huì)將硬件完全占滿。例如，若系統(tǒng)吞吐能力為 1K，卻一次性輸入 4K Token，則耗時(shí)將增加至原來的 4 倍；此時(shí)若 Decode 與之混合執(zhí)行，Decode 的延遲也會(huì)隨之放大。

此外，在 DeepSeek 中，由于引入了權(quán)重吸收機(jī)制，Prefill 與 Decode 混合執(zhí)行還會(huì)帶來額外的權(quán)重和顯存開銷。更重要的是，二者的最優(yōu) batch size 本就不同：Prefill 階段每個(gè)請(qǐng)求的 Token 數(shù)量較大，因此只需較小的 batch size 就能充分利用集群；而 Decode 階段則需要更大的 batch size 才能達(dá)到集群利用率最大化。

但其缺點(diǎn)在于需要進(jìn)行 Kv-cache 同步，同時(shí)需要較大的并行請(qǐng)求規(guī)模，才能充分發(fā)揮硬件性能。這類需求往往適合高性能大規(guī)模集群，因此成為硬件廠商和云廠商最關(guān)注的場(chǎng)景。如果確有 PD 分離的需求，并不建議自行實(shí)現(xiàn)。因?yàn)樵摲桨干婕罢{(diào)度、集群管理、故障排查等復(fù)雜問題，對(duì)周邊系統(tǒng)提出極高要求，實(shí)施和維護(hù)成本巨大。因此更為可行的方式是依賴云廠商的成熟解決方案。

最后值得思考的是，為什么推理系統(tǒng)會(huì)逐漸走向“小型機(jī)化”？按理來說，互聯(lián)網(wǎng)服務(wù)應(yīng)當(dāng)依托海量、低成本、具備柔性伸縮能力的機(jī)器來支撐，而不是依賴高性能單機(jī)。

但現(xiàn)實(shí)情況是，由于推理請(qǐng)求普遍為同步執(zhí)行，且伴隨大量數(shù)據(jù)交換，這種模式逐漸推動(dòng)了“小型機(jī)化”的趨勢(shì)。以上述推理過程為例，61 層的 DeepSeek 模型在輸出一個(gè) Token 時(shí)需要進(jìn)行 122 次跨機(jī)通信。如果中間環(huán)節(jié)的性能不足，其結(jié)果可想而知。

基于這一問題，我們必須探索其他路徑來減少跨機(jī)通信。從并行技術(shù)的角度來看，流水線并行是一種較為傳統(tǒng)的方案。以兩機(jī)為例，該方法僅需進(jìn)行兩次跨機(jī)通信：一次將數(shù)據(jù)傳遞過去，另一次再傳回來，并且是異步進(jìn)行的。這在通信量上具有明顯優(yōu)勢(shì)。

然而，由于 Kv-cache 以及自回歸邏輯等特性，使得當(dāng)前推理框架在實(shí)現(xiàn)多 batch 推理時(shí)的復(fù)雜度和成本依然較高。

在“一念”的實(shí)踐中，目前在多階段流水線并行方面實(shí)現(xiàn)較為完善，整體性能處于領(lǐng)先水平。需要注意的是，在 Forward 階段，流水線要求資源得到充分填充，因此任務(wù)的劃分必須盡量均勻。

在此過程中，需要通過多 batch 的方式實(shí)現(xiàn)負(fù)載均衡，因?yàn)樵谕评磉^程中部分 batch 可能退出，同時(shí)新的 batch 會(huì)不斷進(jìn)入。

例如，在 prefill 階段，可能很多的請(qǐng)求仍處于 decode 狀態(tài)，如果此時(shí) prefill 與 decode 混合在同一批次中，再疊加更多的 decode 請(qǐng)求，就可能導(dǎo)致 decode 階段因 prefill 的操作而性能下降。

為此，必須在 batch 調(diào)度中引入多種負(fù)載均衡策略。這并不是一種全新的技術(shù)，而是流水線并行本應(yīng)具備的特性。不同之處在于，我們首次在大規(guī)模語言模型推理這種有狀態(tài)服務(wù)中實(shí)現(xiàn)了這一點(diǎn)。完成優(yōu)化后，系統(tǒng)吞吐量從 5K 提升至 9K。

關(guān)于如何進(jìn)一步提升 MoE 的利用率，這里存在幾個(gè)關(guān)鍵問題。

首先，在 DP（Data Parallelism）中，最直接的方式是僅保留一份 KvCache，從而避免在多卡之間的冗余存儲(chǔ)。但這樣會(huì)帶來新的挑戰(zhàn)：權(quán)重需要集中放置在單卡上，而非分散在 2 張、4 張或 8 張卡上，從而顯著增加單卡的顯存壓力。如果再遇到一個(gè) 64K 的請(qǐng)求，必須保證任意一個(gè) DP 都能處理該請(qǐng)求，這對(duì)中間計(jì)算過程中 buffer 的要求更為嚴(yán)格。

其次，當(dāng)多個(gè) DP 將資源切分得過細(xì)時(shí)，如果同時(shí)出現(xiàn)大規(guī)模請(qǐng)求，例如在 8 個(gè) DP、8 張卡的情況下，每個(gè) DP 都接收到一個(gè) 64K 的請(qǐng)求，那么 MoE 階段的壓力將放大為 64K × 8，導(dǎo)致中間緩存成為瓶頸。因此，需要在 DP 之間引入負(fù)載均衡機(jī)制，確保無論如何調(diào)度，都不會(huì)使 MoE 的 buffer 被過載。

為應(yīng)對(duì)這些問題，一方面必須進(jìn)行更精細(xì)化的顯存管理，以承載更高的權(quán)重與 buffer 開銷。這也是我們選擇直接從顯卡層面進(jìn)行顯存分配，而不是依賴 PyTorch 等框架自動(dòng)管理的原因。

另一方面，還需要在 DP 之間進(jìn)行調(diào)度與均衡。結(jié)合前述的 MT-Batch 與流水線并行，我們還可以在不同 batch 之間進(jìn)行調(diào)度，從而確保每個(gè) batch 內(nèi)部的 DP 負(fù)載更加均衡。

通過這些優(yōu)化，目前系統(tǒng)吞吐量已提升至 14.6K。然而，如果仔細(xì)對(duì)比會(huì)發(fā)現(xiàn)問題：從單 DP 擴(kuò)展到 8 DP，理論上吞吐應(yīng)接近 8 倍，但實(shí)際僅提升不足一倍。這表明我們的優(yōu)化仍不充分。

相較之下，TensorRT-LLM 在開啟 DP 前后幾乎實(shí)現(xiàn)一倍的提升，說明其 DP 算子的性能明顯優(yōu)于我們。這也是后續(xù)我們需要重點(diǎn)借鑒的地方。

總結(jié)與展望

我們并非不做 EP 和 PD 分離，而是選擇先實(shí)現(xiàn) PP。這一順序主要取決于硬件條件。從下圖中可以看到 Token 并行數(shù)與最終硬件性能的關(guān)系。藍(lán)色曲線代表 H800，橙色曲線代表 H20，二者之間存在約十倍的性能差距。

這意味著在不同 Token 數(shù)下，算子的性能上限存在顯著差異。H20 很快便會(huì)達(dá)到天花板并進(jìn)入平穩(wěn)期，再增加只會(huì)帶來時(shí)延。

EP 和 PD 分離的首要收益在于可支持更大的 batch size。而 PP 帶來更優(yōu)的顯存利用率和更低的通信開銷。

因此，我們先實(shí)現(xiàn)了 PP，目前正推進(jìn) EP 與 PD 分離。在 batch size 已接近上限的情況下，下一步的重點(diǎn)是進(jìn)一步釋放顯存并優(yōu)化通信。

我們當(dāng)前的工作也聚焦在幾個(gè)關(guān)鍵問題上：

一是調(diào)度策略與業(yè)務(wù)場(chǎng)景的兼容。如果業(yè)務(wù)峰值是 10 倍量級(jí)，現(xiàn)有策略更偏向“保吞吐”，那么后續(xù)調(diào)度需要在保證吞吐的同時(shí)，把 TPOT、TTFT 等體驗(yàn)指標(biāo)也做上去（既降低首 Token 時(shí)延、又提升持續(xù)輸出效率），這對(duì)調(diào)度提出了更高要求；

二是柔性 KV cache 匹配。目前我們的 prefix cache 采用嚴(yán)格匹配：例如一個(gè)會(huì)話約 50 輪，對(duì)到第 51 輪時(shí)會(huì)發(fā)生窗口回滾（從第 2 輪到第 51 輪重新送入模型）。此時(shí)大部分上下文相同，但由于嚴(yán)格匹配，KV cache 往往無法命中。因此我們?cè)谕七M(jìn)“柔性 KV cache”，力圖在上下文高度相似的情況下也能復(fù)用緩存，減少重復(fù)計(jì)算。

三是模型層間進(jìn)度是否必須同步。從研究與實(shí)踐看，答案是否定的：不同層的計(jì)算負(fù)載與時(shí)序分布并不一致，沒必要強(qiáng)行保持層層同速。適度引入層間解耦 / 異步有望提升整體效率。

四是batch 之間的流程編排。雖然兩個(gè) batch 在邏輯上相互獨(dú)立，但若把它們視為計(jì)算圖，并不必然沖突；因此沒必要做硬件強(qiáng)隔離。通過在不沖突的算子間交叉 / 穿插執(zhí)行，可進(jìn)一步提升資源利用率與吞吐。此外，我們也在推進(jìn)多模態(tài)支持與國(guó)產(chǎn) GPU適配等相關(guān)工作。

謝謝大家！

AI 重塑組織的浪潮已至，Agentic 企業(yè)時(shí)代正式開啟！當(dāng) AI 不再是單純的輔助工具，而是深度融入業(yè)務(wù)核心、驅(qū)動(dòng)組織形態(tài)與運(yùn)作邏輯全面革新的核心力量。

把握行業(yè)變革關(guān)鍵節(jié)點(diǎn)，12 月 19 日 - 20 日，AICon 全球人工智能開發(fā)與應(yīng)用大會(huì)（北京站） 即將重磅啟幕！本屆大會(huì)精準(zhǔn)錨定行業(yè)前沿，聚焦大模型訓(xùn)練與推理、AI Agent、研發(fā)新范式與組織革新，邀您共同深入探討：如何構(gòu)建起可信賴、可規(guī)?；⒖缮虡I(yè)化的 Agentic 操作系統(tǒng)，讓 AI 真正成為企業(yè)降本增效、突破增長(zhǎng)天花板的核心引擎。