一、背景

微信現(xiàn)在已經(jīng)成為人們?nèi)粘Ｉ钪蟹浅Ｖ匾慕M成部分，而隨著人工智能的發(fā)展，微信內(nèi)也為用戶提供了多種涉及 AI 計算的服務體驗。例如，語音消息的文字轉(zhuǎn)換、視頻號的 AIGC 和推薦、掃一掃功能的圖像識別等。這些功能由于微信的用戶規(guī)模巨大，所以 AI 計算的服務規(guī)模也非常大。

為了應對大規(guī)模的 AI 計算任務，我們建立了 Astra 平臺，目前，有許多業(yè)務已經(jīng)接入了 Astra 平臺，這些業(yè)務在平臺上構(gòu)建了眾多 AI 算法服務，覆蓋了 LLM/多媒體處理等多個方面。

目前我們對于 Ray 的使用場景主要是 Ray Serve，在 Astra 平臺之前，我們團隊是一個純粹的后臺開發(fā)團隊。因此在我們在實際工作中，會更加深入的思考 AI 算法服務與傳統(tǒng)微服務之間的區(qū)別。

首先，關(guān)于應用規(guī)模，傳統(tǒng)的微服務一般最多只有幾千個節(jié)點、十來萬核。然而，在AI算法這種計算密集型的任務上，我們的 AI 算法服務往往需要數(shù)十萬節(jié)點，其計算資源需求可達數(shù)百萬核。這種超級應用對我們的模塊管理系統(tǒng)以及 K8S 集群提出了極高的要求，要支撐如此大規(guī)模的應用部署是非常困難的。

其次，隨著資源數(shù)量和資源種類的增加，部署復雜度快速升高。AI 算法服務對 GPU 資源有特殊需求，市場上存在多種類型的 GPU，例如 NVIDIA、紫霄、昇騰等品牌。這些不同型號的 GPU 需要特定的適配工作，這無疑增加了每次部署時的復雜性和工作量。

再者，運維難度亦不容忽視。微服務主要涉及業(yè)務邏輯，不存在復用性，但 AI 算法是一種純算法服務，并不存在業(yè)務邏輯，不同的業(yè)務可能都會需要分別部署獨立的集群，這也相應地提高了運維工作的復雜程度。

最后，成本問題同樣突出。當前 GPU 的價格高昂，算力資源十分昂貴。降低 AI 推理的成本并提高資源利用率也是我們的重要目標之一。

鑒于上述考慮，我們選擇了 Ray。它可以提供統(tǒng)一的分布式平臺，整合多種計算模式，構(gòu)建一個完整的生態(tài)系統(tǒng)。

早在 2022 年，我們就注意到 Ray 的優(yōu)勢，當時對于 Ray 的理解尚淺，但觀察到國內(nèi)外眾多企業(yè)，包括 ChatGPT 等先進應用的成功案例，我們決定加大對 Ray 的投入，利用其將單機應用輕松擴展至分布式環(huán)境的能力，簡化我們的開發(fā)流程，并實現(xiàn)更高效的資源管理。

接下來介紹 Astra 平臺與 Ray 結(jié)合的整體架構(gòu)。在這一架構(gòu)中，平臺管理的基本單位是基于 Ray 的應用，其底層由我們自主設計的聯(lián)邦集群架構(gòu)支撐。該架構(gòu)底層連接至公司內(nèi)部多個 K8S 集群，允許我們的應用部署于不同的 K8S 集群之上。這些 K8S 節(jié)點是我們預先從 K8S 申請的資源，每個節(jié)點上都會集成我們 Starlink 集群管理的 Agent、網(wǎng)絡穿透 P2P 下載組件以及 TFCC AI 運行時。

架構(gòu)圖的下層展示了 Starlink 集群管理模塊，它主要提供了以下幾項核心能力：服務發(fā)現(xiàn)、負載均衡、容災調(diào)度以及應用調(diào)度。面對的主要挑戰(zhàn)是支持多達數(shù)十萬個節(jié)點的大規(guī)模集群管理，這意味著我們需要具備處理百萬級 Pod 節(jié)點的能力，并確保高效的集群管理。此外，為了降低成本，考慮到騰訊內(nèi)部可能存在資源利用不充分的情況，我們致力于優(yōu)化資源配置，充分利用那些利用率較低或空閑的資源。最后，為了簡化應用部署流程，我們?yōu)樗惴ㄩ_發(fā)人員提供了便捷的方式，使他們能夠迅速且輕松地部署應用程序。

通過這樣的架構(gòu)設計，我們不僅能夠應對大規(guī)模集群管理帶來的技術(shù)挑戰(zhàn)，還能夠在成本控制和部署效率上取得顯著進步，從而更好地支持微信平臺上的 AI 計算需求。

二、百萬級節(jié)點的集群管理

接下來，將詳細探討在處理百萬級節(jié)點集群管理時所面臨的挑戰(zhàn)及解決方案。

調(diào)度架構(gòu)通?？梢苑譃槿N類型：單層、兩層以及共享調(diào)度。每種架構(gòu)都有其特點和適用場景。

單層調(diào)度：這種架構(gòu)類似于 K8S，適用于規(guī)模較小的集群，一般為數(shù)千個節(jié)點。單層調(diào)度的一個主要限制是其較低的并發(fā)度，因為整個集群通常只依賴于單一的調(diào)度器進行資源分配。

兩層調(diào)度：此架構(gòu)預先將資源池中的機器分配給上層調(diào)度器，例如 Spark 采用的就是這種模式。相比單層調(diào)度，兩層調(diào)度具有更高的并發(fā)度，支持更大規(guī)模的集群。

共享調(diào)度：這一概念源于谷歌的 Omega 論文。其核心特點是支持無限數(shù)量的調(diào)度器，每個應用都有自己的調(diào)度器，且所有調(diào)度器都能查看到整個資源池的狀態(tài)。我們實現(xiàn)了樂觀調(diào)度策略，即每個調(diào)度器假設沒有沖突地分配資源，并在檢測到?jīng)_突時進行調(diào)整。這種方法不僅能夠顯著提升調(diào)度規(guī)模和資源利用率，還能大幅提高調(diào)度并發(fā)度，非常適合處理數(shù)十萬節(jié)點的大規(guī)模集群需求。

對于需要管理幾十萬甚至更多節(jié)點的超級應用而言，選擇共享調(diào)度架構(gòu)幾乎是必然的。它通過允許多個調(diào)度器同時工作，確保了高并發(fā)度和高效的資源利用，滿足了大規(guī)模集群管理的需求。我們的 Astra 平臺結(jié)合 Ray，正是采用了這樣的共享調(diào)度策略，以應對微信 AI 計算中遇到的巨大挑戰(zhàn)。

接下來，將深入介紹 Astra 自研調(diào)度架構(gòu)的整體設計，我們從下往上介紹。

最底層是部署在不同 K8S 集群上的節(jié)點，這些資源是預先分配好的。例如，特定業(yè)務可以向 K8S 申請所需的資源，并將其集成到我們的平臺中使用。每個 K8S 集群包含各自的節(jié)點，這些節(jié)點會定期向 resource 集群發(fā)送心跳信號，以報告其狀態(tài)。

Resource 集群會聚合這些心跳信息，并通過廣播的方式實現(xiàn)輕量級的狀態(tài)同步。這一機制保證了即使單個集群僅由幾臺機器組成，也能夠支持多達百萬級別的節(jié)點管理，并維持一個在線節(jié)點列表，作為高性能資源管理的基礎(chǔ)。

Resource 是整個系統(tǒng)的核心部分，它不僅負責收集和同步節(jié)點狀態(tài)，還提供了高效的資源管理能力。Resource 集群能夠?qū)崟r掌握所有節(jié)點的最新狀態(tài)，為上層調(diào)度提供準確的信息。

在 Resource 集群之上，是 APP 級別的獨立調(diào)度器。每個應用程序（APP）都有自己的調(diào)度器，這些調(diào)度器可以直接訪問整個集群中所有節(jié)點的狀態(tài)信息。每個調(diào)度器的主要職責包括：資源調(diào)度、負載均衡、容災調(diào)度。得益于共享調(diào)度的設計，調(diào)度器每分鐘可以處理數(shù)萬節(jié)點的調(diào)度任務，極大提升了系統(tǒng)的響應速度和效率。

最上層是用戶操作界面，用于執(zhí)行諸如擴縮容等操作。這一層直接與最終用戶交互，提供了直觀的操作體驗，使得用戶可以輕松管理其應用程序和服務。

這套架構(gòu)構(gòu)成了我們進行百萬級別集群管理的基礎(chǔ)，通過分層設計和資源共享調(diào)度機制，實現(xiàn)了對大規(guī)模節(jié)點的有效管理，同時保證了高并發(fā)度和資源利用率，滿足了微信 AI 計算中的復雜需求。此架構(gòu)不僅支持了數(shù)十萬節(jié)點的大規(guī)模集群管理，還顯著降低了運維復雜度和成本，提高了整體的服務質(zhì)量和用戶體驗。

三、高效穩(wěn)定地利用低優(yōu)資源

下面探討如何高效且穩(wěn)定地利用低優(yōu)資源。騰訊內(nèi)部低優(yōu)資源的總量非常龐大，但與此同時也伴隨著諸多挑戰(zhàn)，“天下沒有免費的午餐”，盡管低優(yōu)資源的成本較低，但也帶來了新的問題。

以下是從我們系統(tǒng)監(jiān)控中截取的幾張圖，能說明我們所遇到的一些問題。

首先，節(jié)點處于亞健康狀態(tài)的比例較高，例如 CPU 時間片可能會被搶占，或者節(jié)點可能隨時被高優(yōu)先級任務搶占。在 Ray 的應用上，當 Ray 應用部署到低優(yōu)資源時，節(jié)點被搶占會導致集群難以恢復。特別是在 Ray Cluster 錯誤處理方面，如果頭節(jié)點出現(xiàn)故障，會難以恢復。當前社區(qū)版僅提供通過 Redis 備份的方式進行恢復，但我們不希望在服務中引入額外的依賴。因此，我們希望有一種簡潔的解決方案，能快速的地解決這一問題。

針對亞健康節(jié)點及被移除節(jié)點的快速處理，我們采取了一系列措施以確保系統(tǒng)的高效與穩(wěn)定。以下是具體方法：

首先，對于異常節(jié)點的下線，K8S 平臺通常不會提前很長時間通知即將縮容。因此，我們使用 K8S 的 Pre Stop 特性來迅速響應。由于我們的心跳檢測頻率為每秒一次，一旦觸發(fā) Pre Stop，我們可以立即從在線列表中移除該節(jié)點。在3秒鐘內(nèi)更新路由表，這意味著在 Pre Stop 觸發(fā)后的 4 秒內(nèi)，該節(jié)點將被完全移除。即使節(jié)點隨后被資源平臺直接終止，也不會對我們的服務造成影響。

其次，對于性能較低的節(jié)點，我們會實時監(jiān)控并收集其運行數(shù)據(jù)。通過自動調(diào)節(jié)權(quán)重的路由算法調(diào)整節(jié)點接收的請求量。具體而言，性能較差的節(jié)點將被賦予較低權(quán)重，而高性能節(jié)點則保持較高權(quán)重。這種機制確保了任務能夠根據(jù)節(jié)點的實際性能進行合理分配，從而優(yōu)化了 serving 層的工作負載分配，優(yōu)化了整體服務吞吐和耗時。

通過上述措施，我們不僅能夠快速處理異常節(jié)點，還能有效管理性能差異較大的節(jié)點，確保系統(tǒng)在面對低優(yōu)資源固有問題時仍能保持高效穩(wěn)定的運行。

從我們在 Astra 平臺上使用低優(yōu)資源的效果圖中可以清晰地看到優(yōu)化前后的對比。圖中的綠色線條代表優(yōu)化之前的狀態(tài)，而紅色線條則展示了優(yōu)化之后的結(jié)果。通過對比可以看出，優(yōu)化后我們的失敗率顯著降低，同時平均處理時間也得到了大幅改善。

在低優(yōu)資源上使用 Ray 時，我們必須良好的設計系統(tǒng)來容忍節(jié)點（包括 worker 和頭節(jié)點）被頻繁踢出的情況。為此，我們借鑒了 K8S 聯(lián)邦集群的概念，提出了 Ray 聯(lián)邦集群的架構(gòu)。這一架構(gòu)的核心特點是每個 Ray cluster 作為一個服務的最小單位，每個 Ray Cluster 都能夠獨立提供完整的服務。這種設計確保了即使任意一個 Ray cluster 出現(xiàn)故障，整體服務依然不受影響。

Ray 聯(lián)邦集群的特點包括：

• 服務單元化：每個 Ray cluster 都是一個獨立的服務單元，可以單獨提供完整的服務。
• 容災能力：通過增加更多的 Ray cluster 來實現(xiàn)容災。每個 cluster 都可以視為一個容災單元，從而增強了系統(tǒng)的魯棒性。
• 突破規(guī)模限制：由于我們的基礎(chǔ)設施本身支持百萬級節(jié)點管理，我們可以將每個 Ray cluster 設計得較小，從而突破單個 cluster 的規(guī)模限制。
• 無狀態(tài)服務般的容災：無論哪個節(jié)點或整個 cluster 掛掉，我們都可以迅速替換，確保服務的連續(xù)性。

具體容災方案如下：

• 頭節(jié)點故障處理：當頭節(jié)點出現(xiàn)心跳異常時，我們會立即從路由算法中移除該 cluster，并調(diào)度一個新的 Ray cluster 進行替換。
• Worker 節(jié)點故障處理：如果僅是 worker 節(jié)點故障，該 cluster 仍可繼續(xù)使用，只需替換故障的 worker 節(jié)點即可。
• 擴展性：我們的 Ray Cluster 機制支持縱向擴容，可以根據(jù)需要調(diào)整 worker 數(shù)量，從而解決了大規(guī)模部署下的擴展性問題。

通過上述措施，我們不僅提升了系統(tǒng)的容災能力，還確保了在大規(guī)模節(jié)點管理中的高效性和靈活性。此架構(gòu)使得每個 Ray APP 可以擁有無數(shù)個請求者，集群能夠像無狀態(tài)服務一樣靈活應對節(jié)點或 cluster 級別的故障，確保了服務的高可用性和穩(wěn)定性。

針對訓練任務的自動調(diào)速，我們開發(fā)了一套內(nèi)部工具用于數(shù)據(jù)處理。鑒于低優(yōu)資源隨時可能被移除，這會導致集群處理能力下降，我們對每個節(jié)點的性能進行了預估，即根據(jù)資源類型和數(shù)量來評估其處理能力。隨著集群資源指標的變化，我們會自動調(diào)整任務的消費速率，以確保服務的正常運行。自動調(diào)速機制如下：

• 性能預估：我們根據(jù)資源類型（如不同型號的 GPU）和可用資源的數(shù)量，動態(tài)評估每個節(jié)點的處理能力。這一預估考慮了多種卡型共存的情況，確保評估結(jié)果的準確性。
• 動態(tài)調(diào)整消費速率：基于性能預估的結(jié)果，當檢測到集群中的資源變化時，系統(tǒng)會自動調(diào)整任務的消費速率。這種調(diào)整確保即使在資源減少的情況下，也能維持服務的穩(wěn)定性和性能。
• 保障服務連續(xù)性：通過上述機制，即使低優(yōu)資源被移除或集群處理能力發(fā)生變化，我們的系統(tǒng)仍能保持正常運行，避免因資源波動導致的服務中斷。

通過這套自動調(diào)速機制，我們的離線任務可以穩(wěn)定的在低優(yōu)資源上進行部署，確保了在復雜多變的環(huán)境中，離線任務能夠持續(xù)高效地運行。

四、降低應用部署復雜度

接下來探討如何降低應用部署的復雜度。一個 APP 可能包含多個模型，每個模型需要部署在不同類型的 GPU 上，且每種 GPU 類型可能會超出系統(tǒng)單個集群的數(shù)量、規(guī)模限制。這種情況下，我們面臨的復雜度大約是 O(N^3)。為了有效降低這一復雜度，我們采取了以下措施：

首先，多模型擴展。我們選擇 Ray 作為解決方案的關(guān)鍵原因之一在于其能夠簡化多模型擴展。以往，服務中可能需要引入一個中間模塊來專門管理各個模型之間的調(diào)用。而現(xiàn)在使用 Ray，僅需一個腳本即可實現(xiàn)多模型的有效管理和調(diào)度，大大簡化了部署流程。

其次，多卡型擴展。針對不同類型的 GPU，我們設計了相應的擴展機制。這部分內(nèi)容將在后續(xù)詳細說明。

最后，多模塊擴展。我們的架構(gòu)還支持多模塊的擴展，確保系統(tǒng)能夠靈活應對不同類型和數(shù)量的組件需求。

通過上述措施，我們顯著降低了應用部署的復雜度，使得多模型、多卡型以及多模塊的管理變得更加高效和簡便。

接下來我們詳細描述我們?nèi)绾巫龅竭@一點。首先，統(tǒng)一基座環(huán)境。

• 核心組件：該環(huán)境包含了所有必需的核心組件，例如 P2P 網(wǎng)絡穿透、TFCC 以及特定版本的 CUDA，以確保一致性和兼容性。
• 包管理：允許用戶使用 Conda 管理包，允許用戶選擇不同版本的 Python，并實現(xiàn)自定義環(huán)境配置。這一系統(tǒng)是我們自行開發(fā)的環(huán)境管理工具，旨在為用戶提供靈活的包管理能力。
• 自定義庫與編譯：支持用戶自定義使用各種庫及進行 CI（持續(xù)集成）編譯操作，以滿足多樣化的開發(fā)需求。

其次， TFCC 引擎的支持。

針對不同類型的 GPU（如 NVIDIA、昇騰等），特別是當 NVIDIA 卡用于 TensorRT 時可能需要不同的模型編譯，TFCC 引擎起到了關(guān)鍵作用，它能夠屏蔽底層 GPU 卡的具體類型，使得用戶無需關(guān)心底層硬件細節(jié)。用戶只需調(diào)用 TFCC 提供的推理接口，即可完成推理任務，無論底層使用何種 GPU 卡。

通過上述標準化的環(huán)境管理方案，不僅簡化了多依賴項的服務部署，還確保了跨多種 GPU 類型的無縫支持，極大提升了用戶體驗和服務靈活性。

最后是 P2P 下載優(yōu)化。隨著 AI 模型規(guī)模的不斷擴大，正如前面提到當前的模型體積已經(jīng)顯著增加。例如，一些常見的 72B 模型可能達到 140GB 的大小。將如此龐大的模型下發(fā)至各節(jié)點進行部署耗時會比較長。為此，我們使用 P2P 對下載能力進行了多項優(yōu)化：

• NAT 穿透：實現(xiàn)了 NAT 穿透功能，確保在復雜網(wǎng)絡環(huán)境下也能高效傳輸數(shù)據(jù)。
• 節(jié)點限速與全局限速：為保證網(wǎng)絡資源的合理分配，引入了節(jié)點級別的限速和全局限速機制。

通過這些優(yōu)化措施，我們現(xiàn)在能夠?qū)⒁粋€大約 140GB 的模型在大約 10 分鐘左右的時間內(nèi)完成下發(fā)。這大大縮短了模型部署的時間，提高了整體工作效率。

五、Astra-Ray 使用樣例

下面是在平臺上的一些截圖，幫助大家了解我們平臺的使用界面和部署流程。以下是具體步驟：

第一步是修改代碼，只需要按照 ray serve 做簡單的改寫即可。

第二步是將修改后的代碼打包并上傳至 Git 倉庫。在此過程中，需要選擇一個 Python 版本。平臺會根據(jù)選擇自動打包，生成一個可以在我們平臺上運行的部署包。

第三步是變更 Ray 配置，這實際上是調(diào)整服務的 deployment 配置。此步驟允許用戶通過配置變更來動態(tài)調(diào)整服務參數(shù)?？紤]到在線服務的穩(wěn)定性，我們設計了灰度發(fā)布機制。為了確保配置變更能夠平穩(wěn)生效，而不對現(xiàn)有服務造成即時沖擊，用戶可以通過灰度發(fā)布的方式逐步應用新的配置。這種方式允許新配置在一部分流量中先行驗證，確保其穩(wěn)定性和兼容性后再全面推廣。通過這一機制，用戶可以在不影響整體服務的情況下，安全地測試和應用新的配置調(diào)整，從而保障了服務的連續(xù)性和可靠性。

第四步是進行擴容。完成擴容后，可以立即看到服務啟動，并在平臺頁面上查看集群的機器列表。例如，展示的一個集群機器列表中，包含大約 4,000 多個請求者（requester），每個請求者對應 5 臺機器，總計超過 2 萬個節(jié)點。

此外，我們還提供了以下功能以支持更高效的管理和調(diào)試：

• Ray Dashboard：用戶可以通過 dashboard 查看請求的狀態(tài)和性能指標。
• 日志調(diào)試：平臺支持日志記錄和調(diào)試功能，幫助用戶快速定位和解決問題。

六、Q&A

Q1：關(guān)于低優(yōu)資源的抖動狀態(tài)問題

問：您剛才提到的低優(yōu)資源存在 3 秒更新路由表和每秒更新機制。對于一些狀態(tài)不穩(wěn)定的資源，例如其性能可能一會兒好一會兒壞，這種情況是否會引發(fā)抖動？這種不穩(wěn)定狀態(tài)是如何處理的？

答：理解您的問題，確實存在兩種情況：

性能波動：當節(jié)點的 CPU 被壓制時，可能會出現(xiàn)性能不穩(wěn)定的情況。我們通過動態(tài)調(diào)整權(quán)重來應對這一問題，確保即使性能波動也不會影響服務的整體質(zhì)量。

節(jié)點掉線與重啟：如果一個節(jié)點突然掉線后重新啟動，我們會將其視為一個新節(jié)點進行處理。若它快速重啟，可能不會特別關(guān)注；但如果觸發(fā)了 PreStop 機制，則該節(jié)點會被移除，并在重新上線時作為新節(jié)點加入資源池。

Q2：關(guān)于每秒更新頻率的問題

問：每秒更新的頻率是否過高？這是否會帶來額外的壓力？

答：每秒心跳確實會帶來較高的請求量，尤其在面對數(shù)十萬個節(jié)點時，會產(chǎn)生較高的 QPS 壓力。為此，我們采用了聚合擴散機制來減輕集群負擔。首先，我們要保證自身服務的性能；其次，在集群容量接近極限時，可以通過擴展更多集群來支持更大的規(guī)模。Starlink 架構(gòu)并非局限于單一 Resource 集群，而是也可以靈活擴展至多個集群。

Q3：超級 APP 跨集群調(diào)度機制

問：超級 APP 如何實現(xiàn)跨多個 Ray Serve 的調(diào)度？是通過每個集群內(nèi)部的調(diào)度器還是有更高層次的調(diào)度機制？

答：通過 RPC 的方式，不同 Ray 集群之間是不互通的，但是我們保證每個 Ray 集群都有完整的功能。

Q4：超級 APP 副本故障恢復機制

問：在一個超級 APP 擁有大量副本的情況下，如果部分副本掛掉，是由哪個調(diào)度器負責重啟這些副本？

答：由 APP 自身的調(diào)度器負責維護其所有 Ray Serve 的狀態(tài)。即便應用規(guī)模龐大，調(diào)度器也僅需定時掃描即可管理。假設一個超級 APP 有 100 萬個集群，掃描一次也只需一秒鐘左右的時間。因此，即使是超大規(guī)模的應用，其調(diào)度器也不太可能成為瓶頸。

Q5：聯(lián)邦集群的逐步擴展與負載均衡

問：聯(lián)邦集群是如何逐步擴展并淘汰舊集群的？特別是在進行版本升級時，如何保持負載均衡？

答：聯(lián)邦集群的擴展和淘汰是一個漸進的過程。頭節(jié)點并不執(zhí)行具體的業(yè)務邏輯或 worker 任務，而是與 worker 等價，以減少對系統(tǒng)的影響。在做路由算法時，我們將所有節(jié)點視為等同，簡化了管理和調(diào)度過程。

Q6：在線服務 Runtime 優(yōu)化

問：是否在 Ray 的 runtime 層面進行了特定優(yōu)化？

答：目前我們尚未對 Ray 框架本身進行修改。該項目從今年上半年開始引入 Ray，因此現(xiàn)階段的重點在于集成而非深度定制。

Q7：TFCC 引擎的透明性與模型轉(zhuǎn)換

問：實際使用者是否需要關(guān)注推理引擎的選擇？模型轉(zhuǎn)換和優(yōu)化是如何處理的？

答：用戶無需關(guān)注底層使用的具體推理引擎。我們在打包過程中將運行內(nèi)容分為三個部分：軟件包、環(huán)境包和數(shù)據(jù)集（通常是模型）。上傳時，我們會對模型進行預處理，轉(zhuǎn)換成適用于各種 GPU 卡的版本，并對其進行性能優(yōu)化。這一切都是自動完成的，用戶只需提供輸入?yún)?shù)。

Q8：推理引擎通用接口

問：不同推理引擎的特性（如 Dynamic Batch、Attention 機制）是否通過通用接口封裝？

答：當前并不是所有推理任務都使用 TFCC，但我們計劃未來增加支持。最常用的接口只需要提供輸入形狀等基本信息。對于不同推理引擎的特性，我們正在考慮如何通過通用接口進行適配，但目前尚未完全封裝。

Q9：Ray 聯(lián)邦集群間的通信

問：騰訊內(nèi)部的 Ray 聯(lián)邦集群是否實現(xiàn)了分布式共享內(nèi)存的打通？不同 Ray serve 之間是否可以直接通信？

答：不同 requester 之間的對象無法直接獲取。要訪問其他 requester 的對象，只能通過 API 接口進行間接訪問。

Q10：TFCC 與顯存管理

問：TFCC 是否實現(xiàn)了顯存的分布式管理？

答：目前還未實現(xiàn)。