本文由微信后臺(tái)Astra項(xiàng)目團(tuán)隊(duì)分享，原題“Ray在微信AI計(jì)算中的大規(guī)模實(shí)踐”，下文進(jìn)行了排版和內(nèi)容優(yōu)化。

1、引言

微信存在大量AI計(jì)算的應(yīng)用場(chǎng)景，主要分為三種：流量分發(fā)、產(chǎn)品運(yùn)營(yíng)和內(nèi)容創(chuàng)作。流量分發(fā)場(chǎng)景中的 AI 計(jì)算主要用于搜索、廣告、推薦場(chǎng)景的核心特征生產(chǎn)，產(chǎn)品運(yùn)營(yíng)相關(guān)的 AI 計(jì)算主要用于產(chǎn)品功能相關(guān)和內(nèi)容運(yùn)營(yíng)相關(guān)（低質(zhì)、優(yōu)質(zhì)、生態(tài)建設(shè)），由于大模型的興起，AIGC 相關(guān)的文生圖、圖生圖、AI 特效等內(nèi)容創(chuàng)作場(chǎng)景的 AI 計(jì)算也有了較多的落地。目前AI 計(jì)算幾乎覆蓋了微信的所有業(yè)務(wù)場(chǎng)景。

▲ 圖 1：微信內(nèi) AI 計(jì)算應(yīng)用場(chǎng)景

然而，我們?cè)谑褂梦⑿乓延械暮笈_(tái)基礎(chǔ)設(shè)施實(shí)現(xiàn)AI應(yīng)用時(shí)遇到各種問(wèn)題：

• 1）在資源層面，AI應(yīng)用屬于計(jì)算密集型，計(jì)算復(fù)雜度高，需要大量資源，直接使用在線資源會(huì)導(dǎo)致成本過(guò)高；
• 2）在部署層面，微信后臺(tái)常見(jiàn)的部署平臺(tái)更適合部署I/O密集、高并發(fā)、高請(qǐng)求量的微服務(wù)，而AI應(yīng)用則需要適配大量異構(gòu)硬件和異構(gòu)資源平臺(tái)，部署復(fù)雜度呈指數(shù)級(jí)上升；
• 3）在應(yīng)用編排層面，直接通過(guò)消息隊(duì)列等基礎(chǔ)組件解決復(fù)雜特征依賴及相關(guān)異步過(guò)程，開(kāi)發(fā)效率低，變更風(fēng)險(xiǎn)高，可觀測(cè)性差；
• 4）在平臺(tái)層面，由于缺乏平臺(tái)支撐，算法迭代速度慢，模型能力使用門(mén)檻高。因此，微信亟需一個(gè)低成本、高效率、低門(mén)檻的AI計(jì)算平臺(tái)來(lái)解決上述問(wèn)題。

▲ 圖 2：微信內(nèi)原有基礎(chǔ)設(shè)施

比如，OCR作為視頻號(hào)推薦和視頻號(hào)搜索依賴的一個(gè)重要特征，計(jì)算量非常大，需要超過(guò)100 萬(wàn)核的CPU計(jì)算資源，同時(shí)對(duì)實(shí)時(shí)性和可靠性的要求很高，需要在 1 分鐘內(nèi)完成特征生成。P6n平臺(tái)適合做高實(shí)時(shí)(毫秒級(jí)響應(yīng))的在線任務(wù)，實(shí)時(shí)性上可以滿足需求，但固定部署的資源成本較高，多模型部署復(fù)雜度高，不符合需求。Gemini 平臺(tái)更適合做大規(guī)模長(zhǎng)時(shí)間的離線任務(wù)，在實(shí)時(shí)性和可靠性上不滿足需求。我們需要一個(gè)高實(shí)時(shí)（10 秒級(jí)響應(yīng)），支持大規(guī)模異構(gòu)資源部署，低成本和高可靠的近線任務(wù)平臺(tái)。

2、為何在AI計(jì)算中引入Ray？

▲ 圖 3：使用 Ray 構(gòu)建 AI 計(jì)算的企業(yè)

Ray是一個(gè)通用的分布式計(jì)算引擎，2016年開(kāi)源于加州大學(xué)伯克利分校 RISELab，是發(fā)展最快的計(jì)算引擎之一。目前已經(jīng)廣泛應(yīng)用于OpenAI、螞蟻、字節(jié)和華為等公司，是新一代的明星計(jì)算框架。

首先：編寫(xiě)分布式計(jì)算既簡(jiǎn)單又直觀。開(kāi)發(fā)者不必了解所有通信和調(diào)度細(xì)節(jié)，也不必對(duì)此進(jìn)行推理。借助 Ray 的簡(jiǎn)單原語(yǔ)，可以將任何 Python 函數(shù)或類轉(zhuǎn)換為分布式執(zhí)行：只需添加一個(gè)裝飾器，就大功告成了。Ray 的分布式API 很簡(jiǎn)單，所有復(fù)雜性都由 Ray 的執(zhí)行框架處理。函數(shù)將被安排為無(wú)狀態(tài)任務(wù)執(zhí)行，而類將是一個(gè)有狀態(tài)的遠(yuǎn)程服務(wù)。

def detect(image_data):

    model = load_detect_model()

    return model(image_data)

 

def recognize(det_result):

    model = load_recognize_model()

    return model(det_result)

 

def ocr(image_data):

    det_result = detect(image_data)

    return recognize(det_result)

 

image_data = load_image_data()

ocr_result = ocr(image_data)

以上是一個(gè)圖片ocr本地執(zhí)行的 python 腳本，如果使用微服務(wù)部署，因?yàn)槟Ｐ瓦^(guò)大，單機(jī)顯存不夠，無(wú)法加載所有模型，則需要部署三個(gè)微服務(wù)模塊：detect、recognize和ocr，應(yīng)用部署的復(fù)雜度較高。

@ray.remote(num_gpus=1,num_cpus=16)

def detect(image_data):

    model = load_detect_model()

    return model(image_data)

 

@ray.remote(num_gpus=2,num_cpus=16)

def recognize(detect_result):

    model = load_recognize_model()

    return model(detect_result)

 

@ray.remote(num_cpus=4)

def ocr(image_data):

    det_result = detect.remote(image_data)

    return recognize.remote(det_result)

 

image_data = load_image_data()

ocr_result = ocr.remote(image_data)

如果使用 ray 來(lái)做 ocr 推理，只需要添加裝飾器@remote，指定模型使用的 cpu 和 gpu 資源數(shù)，通過(guò)一個(gè)python 腳本即可完成ocr應(yīng)用的部署，效率提升至少一個(gè)數(shù)量級(jí)。

▲ 圖 4：Ray AIR 如何以簡(jiǎn)單的方式統(tǒng)一 ML 庫(kù)

其次：大多數(shù)流行的 ML 庫(kù)都與 Ray 有很強(qiáng)的集成性，而且 Ray 的原生庫(kù)也整合了這些庫(kù)。例如，開(kāi)發(fā)者可以輕松地將 XGBBoost 與 Ray Train 結(jié)合使用，可以輕松地將 HuggingFace 與 Ray Serve 結(jié)合使用。或者，可以輕松地將 PyTorch 和 TensorFlow 與 Ray Train 結(jié)合使用。簡(jiǎn)而言之，它擁有豐富的集成生態(tài)系統(tǒng)，不僅與 ML 庫(kù)集成，還與其他工具和框架集成。

第三：開(kāi)發(fā)人員可以使用筆記本電腦進(jìn)行開(kāi)發(fā)。當(dāng)你想將其擴(kuò)展到 Ray 集群時(shí)，只需更改一行代碼或不更改任何代碼即可輕松完成。

RAY_ADDRESS=ray://<cluster>:<port> python your_script.py

總的來(lái)說(shuō)，Ray提供了高性能的分布式框架和簡(jiǎn)單的分布式原語(yǔ)，提供了統(tǒng)一的分布式底盤(pán)。Ray融合不同計(jì)算范式，與眾多開(kāi)源組件便捷地結(jié)合從而實(shí)現(xiàn)對(duì)現(xiàn)有流程的提效。同時(shí)，Ray有完善的生態(tài)，數(shù)據(jù)處理、訓(xùn)練、推理和服務(wù)等AI基礎(chǔ)設(shè)施需要的主流框架都可以很方便地在Ray上進(jìn)行集成，大量知名企業(yè)選用 Ray開(kāi)發(fā) AI 計(jì)算。綜上，我們選擇了Ray 作為微信 AI 計(jì)算平臺(tái)的分布式底座。

3、微信基于Ray的AstraRay平臺(tái)

P6n是基于 Kubernetes微服務(wù)部署平臺(tái)，通過(guò)自動(dòng)化編排和彈性擴(kuò)縮容機(jī)制，很好的解決了在線高實(shí)時(shí)的后臺(tái)服務(wù)運(yùn)維自動(dòng)化問(wèn)題，但不支持大規(guī)模的批處理服務(wù)，單應(yīng)用多模型的部署復(fù)雜度較高，機(jī)器成本較高，不適合“在離線一體”的 AI計(jì)算場(chǎng)景。

Gemini 是基于 kubernetes 的大數(shù)據(jù)平臺(tái)，適合處理離線大規(guī)模的數(shù)據(jù)清洗和模型訓(xùn)練，但是由于調(diào)度的實(shí)時(shí)性不夠，不適合高實(shí)時(shí)性、高吞吐的和高可靠的AI計(jì)算場(chǎng)景。

Astra 平臺(tái)要實(shí)現(xiàn)高實(shí)時(shí)、高吞吐、高可靠、低成本的 AI 計(jì)算平臺(tái)，需要解決如下幾個(gè)核心問(wèn)題。

比如：

• 1）為了低成本，需要支持各種異構(gòu)資源擴(kuò)展；
• 2）為了高吞吐，支持超大規(guī)模資源調(diào)度；
• 3）降低單應(yīng)用多模型的部署復(fù)雜度。

我們基于 Ray 計(jì)算底座，解決了上述三個(gè)核心問(wèn)題，構(gòu)建出適合 AI 計(jì)算平臺(tái)：AstraRay，在微信內(nèi)進(jìn)行了大規(guī)模 AI 應(yīng)用部署的實(shí)踐。

AstraRay 相比社區(qū)版本Ray(KubeRay) 有以下改進(jìn)：

4、AstraRay平臺(tái)架構(gòu)概覽

▲ 圖 7：kuberay 架構(gòu)

▲ 圖 8：KubeRay 提交任務(wù)流程

業(yè)界使用社區(qū)成熟的 KubeRay 方案，通過(guò) Ray 和 K8s 結(jié)合，提供了易用、高可用、高伸縮的云原生 Ray 集群服務(wù)，可以滿足中小規(guī)模 AI 應(yīng)用的需求。但它有集群規(guī)模小（最大僅支持?jǐn)?shù)千個(gè)節(jié)點(diǎn)），異構(gòu)資源擴(kuò)展困難（單個(gè) ray 集群只能部署在一個(gè) k8s 集群，不支持聯(lián)邦k8s 集群）和伸縮慢（受限于 K8s 的擴(kuò)縮容速度）的問(wèn)題，不適合微信內(nèi)超大規(guī)模 AI 應(yīng)用的需求。

▲ 圖 9：AstraRay 整體架構(gòu)

我們?cè)诼涞?Ray 的過(guò)程中遇到了三個(gè)核心技術(shù)挑戰(zhàn)：

• 1）百萬(wàn)級(jí) pod 的集群管理：在視頻號(hào)業(yè)務(wù)場(chǎng)景中，有超過(guò)百萬(wàn)核的超級(jí)應(yīng)用，已經(jīng)遠(yuǎn)超 K8s 集群上限，我們希望單個(gè) Ray 應(yīng)用能支持百萬(wàn)級(jí)別的 pod 的擴(kuò)展；
• 2）不穩(wěn)定資源下構(gòu)建穩(wěn)定服務(wù)：由于 AI 計(jì)算的資源消耗大，為了降低成本，我們大量使用了低成本、閑置，但穩(wěn)定性差的計(jì)算資源。我們希望可以在不穩(wěn)定資源上提供可靠穩(wěn)定的服務(wù)；
• 3）降低應(yīng)用部署的復(fù)雜度：微信內(nèi) AI 應(yīng)用遇到模型、硬件、模塊三種維度的異構(gòu)問(wèn)題，部署復(fù)雜度高。我們希望使用統(tǒng)一的應(yīng)用維度來(lái)簡(jiǎn)化應(yīng)用部署，即將 O(n^3) 復(fù)雜度降低為 O(1)。

Astra 的部署系統(tǒng)架構(gòu)如上圖，在 Poseidon/算力/太極/Gemini 等多個(gè)資源平臺(tái)基礎(chǔ)上擴(kuò)展多個(gè)tke模塊，組成擁有數(shù)百萬(wàn)核CPU、萬(wàn)卡GPU級(jí)別的超大集群。我們通過(guò)服務(wù)發(fā)現(xiàn)的架構(gòu)設(shè)計(jì)，解決了百萬(wàn)級(jí)pod集群管理的問(wèn)題，通過(guò)負(fù)載均衡和容災(zāi)調(diào)度解決了不穩(wěn)定資源構(gòu)建穩(wěn)定服務(wù)的挑戰(zhàn)，同時(shí)通過(guò)應(yīng)用調(diào)度解決了多模型應(yīng)用部署復(fù)雜度的問(wèn)題。接下來(lái)詳細(xì)介紹我們?nèi)绾螒?yīng)對(duì)這三個(gè)技術(shù)挑戰(zhàn)。

5、技術(shù)挑戰(zhàn)1：?jiǎn)渭褐С职偃f(wàn)級(jí)計(jì)算節(jié)點(diǎn)

5.1 架構(gòu)選擇

▲ 圖 11：集群調(diào)度架構(gòu)分類

業(yè)界系統(tǒng)的調(diào)度架構(gòu)主要分為四類：?jiǎn)误w調(diào)度、兩層調(diào)度、共享調(diào)度和混合調(diào)度。

這些調(diào)度架構(gòu)的本質(zhì)區(qū)別其實(shí)只有兩點(diǎn)：

• 1）調(diào)度時(shí)調(diào)度器是否擁有全局的資源視圖；
• 2）不同的應(yīng)用是否擁有多個(gè)資源調(diào)度器。

單體調(diào)度顧名思義，即只有一個(gè)調(diào)度器，調(diào)度器擁有全局資源視圖的架構(gòu)，Google Borg 和 K8s 都采用這個(gè)架構(gòu)。單體架構(gòu)的好處是，所有的任務(wù)都由唯一的調(diào)度器處理，調(diào)度器可以充分的考慮全局的資源使用情況，能方便的做出最優(yōu)調(diào)度。但由于調(diào)度架構(gòu)的限制，集群性能受限于單體的性能，無(wú)法支撐過(guò)大的集群。

兩層調(diào)度擁有多個(gè)調(diào)度器，Apache Mesos 和 Hadoop YARN 都采用這個(gè)架構(gòu)。兩層調(diào)度中，每個(gè)應(yīng)用的調(diào)度器首先向中心節(jié)點(diǎn)獲取資源，再將其分配給應(yīng)用中的各個(gè)任務(wù)。兩層調(diào)度解決了單體調(diào)度的性能問(wèn)題，但是調(diào)度器僅擁有局部資源視圖，無(wú)法做出最優(yōu)調(diào)度。

共享調(diào)度擁有多個(gè)調(diào)度器，每個(gè)調(diào)度器擁有全局資源視圖，Omega 采用了這個(gè)架構(gòu)。共享調(diào)度方案中，每個(gè)調(diào)度器都可以并發(fā)地從整個(gè)資源池中申請(qǐng)資源，解決了性能問(wèn)題和最優(yōu)調(diào)度問(wèn)題，且可以支持較大集群。因此，AstraRay 選擇共享調(diào)度來(lái)支持超大規(guī)模的資源管理。調(diào)度器間資源申請(qǐng)沖突可通過(guò)悲觀鎖或樂(lè)觀鎖來(lái)解決，AstraRay 實(shí)現(xiàn)了基于樂(lè)觀鎖的方案，出現(xiàn)沖突后再處理，無(wú)需中心節(jié)點(diǎn)，并發(fā)度更高。

5.2 Starlink調(diào)度

我們提出了一個(gè)新的調(diào)度系統(tǒng) Starlink 來(lái)更好適配異構(gòu)資源和硬件。Starlink采用共享調(diào)度架構(gòu)，通過(guò)樂(lè)觀并發(fā)調(diào)度處理沖突，支持部署在任何基礎(chǔ)資源平臺(tái)(K8s/Yard/CVM)之上，且允許單個(gè)應(yīng)用運(yùn)行于多種異構(gòu)的資源節(jié)點(diǎn)上。

▲ 圖 12：Starlink 調(diào)度架構(gòu)

Starlink主要分為四個(gè)部分：

• 1）Node：任意部署了 Starlink 的 Agent 節(jié)點(diǎn)都可以成為 Node，Node 每秒會(huì)向Resource 上報(bào)自己的狀態(tài)，并處理APP部署的任務(wù)；
• 2）Resource：Resource 從 Node 接收心跳，并預(yù)聚合心跳后廣播到其他 Resource 節(jié)點(diǎn)。Resource 整合所有 Node 組成在線列表，可像無(wú)狀態(tài)服務(wù)一樣水平擴(kuò)容。為提供業(yè)務(wù)間隔離性和降低廣播的扇出比，Resource集群數(shù)也會(huì)擴(kuò)展；
• 3）App：App 是運(yùn)行在 Starlink 上的應(yīng)用，每個(gè) App 都擁有獨(dú)立的資源調(diào)度器，這些調(diào)度器都從 Resource 獲取全局的資源視圖，通過(guò)樂(lè)觀并發(fā)搶占的方式分配資源；
• 4）Scheduler：Scheduler 負(fù)責(zé)應(yīng)用的負(fù)載均衡和容災(zāi)，Scheduler 會(huì)根據(jù)不同的節(jié)點(diǎn)的性能和狀態(tài)動(dòng)態(tài)的調(diào)整節(jié)點(diǎn)的權(quán)重，并通過(guò)帶權(quán)路由算法來(lái)分配請(qǐng)求。

在微信的后臺(tái)服務(wù)中，每個(gè)微服務(wù)都是獨(dú)立的模塊。而面對(duì)超大規(guī)模的應(yīng)用，由于 K8s 自身擴(kuò)縮容性能的限制，往往需要部署多個(gè)模塊才能滿足一個(gè)AI應(yīng)用，擴(kuò)縮容速度受限。與K8s 不同的是，Starlink 使用預(yù)創(chuàng)建的 Pod，加快了擴(kuò)縮容的速度，資源遷移變得非常簡(jiǎn)單。基于良好的設(shè)計(jì)，Starlink可以支持單應(yīng)用百萬(wàn)節(jié)點(diǎn)，樂(lè)觀調(diào)度也使得調(diào)度速度極快，每分鐘可完成數(shù)萬(wàn)節(jié)點(diǎn)的調(diào)度。Starlink 還可以跨多個(gè)資源平臺(tái)調(diào)度，支持異構(gòu)機(jī)型，不必為每個(gè)應(yīng)用創(chuàng)建多個(gè)模塊進(jìn)行部署，大幅提高了內(nèi)部的資源利用率和資源的周轉(zhuǎn)效率。

6、 技術(shù)挑戰(zhàn)2：不穩(wěn)定資源下構(gòu)建穩(wěn)定服務(wù)

6.1 概述

AstraRay 大量接入低價(jià)或免費(fèi)資源，pod 穩(wěn)定性較差，日常會(huì)出現(xiàn)較高的資源驅(qū)逐率和亞健康的情況，直接使用會(huì)導(dǎo)致服務(wù)失敗率高、延時(shí)高。

另外，用傳統(tǒng)的調(diào)度方法調(diào)度 AI 計(jì)算任務(wù)很容易出現(xiàn)計(jì)算傾斜，從而導(dǎo)致整體資源利用率低。我們通過(guò)更快的容災(zāi)調(diào)度解決服務(wù)失敗率高的問(wèn)題，通過(guò)更優(yōu)的調(diào)度算法來(lái)解決服務(wù)延時(shí)高和資源利用率低的問(wèn)題。

▲ 圖 14：Starlink 調(diào)度流程

6.2 快速容災(zāi)調(diào)度

▲ 圖 15：kubernetes PreStop Hook 機(jī)制

我們通過(guò)兩個(gè)手段來(lái)加速容災(zāi)調(diào)度：

1）在資源平臺(tái)實(shí)際驅(qū)逐 pod 之前，通過(guò) K8s 的 PreStop Hook 機(jī)制實(shí)現(xiàn)服務(wù)程序優(yōu)雅退出，同時(shí)Node將自己標(biāo)記為離線，并通過(guò)心跳上報(bào)到 Resource。

2）Resouce 通過(guò)預(yù)聚合廣播，快速將狀態(tài)同步到整個(gè) Resouce 集群，Scheduler 每隔 3s 通過(guò)拉取 Resouce 的在線列表來(lái)進(jìn)行動(dòng)態(tài)權(quán)重計(jì)算，定期更新路由表。最終可以實(shí)現(xiàn)在 4s 內(nèi)將節(jié)點(diǎn)驅(qū)逐，從而大幅降低了應(yīng)用的失敗率。

6.3 動(dòng)態(tài)權(quán)重SWRR路由算法

AI 應(yīng)用往往具有計(jì)算量大，單機(jī) QPS 低的特點(diǎn)。在這種服務(wù)場(chǎng)景下，微信后臺(tái)常用的一致性哈希已經(jīng)無(wú)法將請(qǐng)求均勻的分發(fā)了。除此之外，低優(yōu)和免費(fèi)資源因?yàn)榻?jīng)常被在線任務(wù)搶占，節(jié)點(diǎn)間性能往往參差不齊。我們選用 SWRR(Smooth Weighted Round-Robin)算法作為基座，并進(jìn)行優(yōu)化，首次應(yīng)用到低 QPS 的任務(wù)調(diào)度系統(tǒng)中，實(shí)現(xiàn)請(qǐng)求分布的快速調(diào)整。

算法步驟如下。

1）更新節(jié)點(diǎn)權(quán)重(3s一次)：

對(duì)于每個(gè)節(jié)點(diǎn)：節(jié)點(diǎn)權(quán)重=節(jié)點(diǎn)核數(shù)或卡數(shù)∗log(剩余利用率)∗(當(dāng)前利用率/節(jié)點(diǎn)當(dāng)前并發(fā))

這個(gè)公式構(gòu)建了一個(gè)模型，簡(jiǎn)單的描述了請(qǐng)求量預(yù)期的分布，節(jié)點(diǎn)權(quán)重描述的是當(dāng)前節(jié)點(diǎn)處理新增任務(wù)的能力，處理能力越高的節(jié)點(diǎn)應(yīng)該分配到更多的請(qǐng)求。

其中：

• 1) 節(jié)點(diǎn)核數(shù)或卡數(shù)是代表節(jié)點(diǎn)的資源總數(shù)，資源總數(shù)與處理能力成正比，對(duì)于不同的GPU，資源總數(shù)即不同卡的性能對(duì)比系數(shù)；
• 2) log(剩余利用率)是節(jié)點(diǎn)當(dāng)前剩余資源，剩余資源量與處理能力成正比。其中，log是一個(gè)經(jīng)驗(yàn)值，在log后，算法在高負(fù)載時(shí)表現(xiàn)較好；
• 3) (當(dāng)前利用率/節(jié)點(diǎn)當(dāng)前并發(fā))本質(zhì)上是機(jī)器性能的體現(xiàn)，假設(shè)大盤(pán)下每個(gè)任務(wù)同一時(shí)刻的消耗是接近的時(shí)，這個(gè)公式成立。

2）選擇節(jié)點(diǎn)流程：

這里是SWRR的標(biāo)準(zhǔn)流程，因?yàn)镾WRR算法的復(fù)雜度是O(n)，我們的實(shí)現(xiàn)會(huì)對(duì)性能做一定的優(yōu)化，比如分block，多算法實(shí)例等。

• 1) 對(duì)于每個(gè)節(jié)點(diǎn)：節(jié)點(diǎn)路由權(quán)重 = 節(jié)點(diǎn)路由權(quán)重 + 節(jié)點(diǎn)權(quán)重；
• 2) 選擇當(dāng)前路由權(quán)重最大的節(jié)點(diǎn)；
• 3) 被選擇的節(jié)點(diǎn)的路由權(quán)重減去所有節(jié)點(diǎn)權(quán)重之和。

算法流程樣例，假設(shè){A,B,C}節(jié)點(diǎn)權(quán)重為{5,1,1}。

最終，我們使用自適應(yīng)權(quán)重的 SWRR 算法，動(dòng)態(tài)平衡請(qǐng)求分布，拉平利用率的同時(shí)，還降低了請(qǐng)求耗時(shí)。

7、 技術(shù)挑戰(zhàn)3：降低應(yīng)用部署的復(fù)雜度

▲ 圖 20：AI應(yīng)用的部署復(fù)雜度

AI 應(yīng)用的部署涉及三個(gè)方面：多模型擴(kuò)展、多卡型擴(kuò)展、多模塊擴(kuò)展（單模塊超過(guò) K8s 部署上限），一個(gè)超級(jí)應(yīng)用的部署復(fù)雜度為 O(n^3)。AstraRay 的創(chuàng)新方案使得一個(gè)應(yīng)用可實(shí)現(xiàn)三個(gè)維度的擴(kuò)展，將復(fù)雜度降低為O(1)，極大提升了 AI 應(yīng)用部署的效率。

7.1 多模型擴(kuò)展挑戰(zhàn)

多模型擴(kuò)展問(wèn)題的本質(zhì)是模型運(yùn)行環(huán)境的動(dòng)態(tài)切換，這里包含兩個(gè)問(wèn)題：

• 1）運(yùn)行時(shí)動(dòng)態(tài)切換；
• 2）模型的快速下發(fā)。

動(dòng)態(tài)切換運(yùn)行時(shí)：

▲ 圖 21：Ray動(dòng)態(tài)運(yùn)行時(shí)

我們首先解決運(yùn)行環(huán)境的問(wèn)題。Ray自身提供RuntimeEnv作為運(yùn)行環(huán)境管理，但Ray的RuntimeEnv無(wú)法切換Python版本，且Ray對(duì)于Python運(yùn)行環(huán)境之外的依賴，只能依靠機(jī)器本身Docker環(huán)境，不夠靈活。

我們支持了Conda作為Python運(yùn)行環(huán)境的隔離和打包，與Ray本身的Conda不同在于：Ray的Conda要先拉起Ray，而 Ray 的worker節(jié)點(diǎn)要求和Ray的頭節(jié)點(diǎn)使用相同的版本，導(dǎo)致應(yīng)用無(wú)法切換Python版本。而我們通過(guò)在啟動(dòng)Ray之前初始化運(yùn)行環(huán)境，使每個(gè)應(yīng)用自定義不同的Python版本。

具體的操作為：在應(yīng)用的代碼打包上傳之前，我們會(huì)根據(jù)用戶填寫(xiě)的 requirement.txt，使用conda-pack打包對(duì)應(yīng)的Conda環(huán)境，在啟動(dòng)Ray之前，分發(fā)到對(duì)應(yīng)的節(jié)點(diǎn)上。其中提前打包可以避免大規(guī)模快速擴(kuò)容對(duì)軟件源帶來(lái)下載壓力。我們也支持用戶自定義打包例如 TensorRT 等環(huán)境，提供更強(qiáng)大的環(huán)境自定義能力。

▲ 圖 22：AstraRay 運(yùn)行時(shí)

快速的模型下發(fā)：

隨著大模型時(shí)代的到來(lái)，模型文件變得越來(lái)越大，LLM模型有數(shù)十GB，下載一個(gè)模型需要數(shù)十分鐘。

Ray可以指定working_dir來(lái)分發(fā)代碼和模型，但是Ray單點(diǎn)依賴gcs節(jié)點(diǎn)，默認(rèn)的大小限制也僅僅500MB，無(wú)法用于真正的生產(chǎn)環(huán)境。

為此，我們?cè)贜ode上嵌入了P2P網(wǎng)絡(luò)。P2P分為Server端和SDK接入端，server端通過(guò)心跳管理P2P節(jié)點(diǎn)，并維護(hù)集群中的種子信息。P2P節(jié)點(diǎn)則提供文件分片的緩存和傳輸能力。

▲ 圖 23：P2P server 端架構(gòu)

▲ 圖 24：P2P sdk 端架構(gòu)

我們還對(duì)P2P的網(wǎng)絡(luò)和性能做了極致的優(yōu)化：

• 1）網(wǎng)絡(luò)打洞能力：面對(duì)復(fù)雜的網(wǎng)絡(luò)環(huán)境，P2P支持NAT探測(cè)打洞，盡最大努力避免網(wǎng)絡(luò)不通的情況；
• 2）節(jié)點(diǎn)自動(dòng)限速能力：P2P作為一個(gè)嵌入式的組件，要避免節(jié)點(diǎn)的帶寬和CPU被P2P進(jìn)程消耗完，所以節(jié)點(diǎn)加入P2P網(wǎng)絡(luò)時(shí)，會(huì)對(duì)節(jié)點(diǎn)進(jìn)行測(cè)速，并設(shè)定合適的閾值，避免影響正常服務(wù)；
• 3）全局限速：即使已經(jīng)限制了單節(jié)點(diǎn)的速度，仍然有可能會(huì)因?yàn)樯蠈咏粨Q機(jī)或核心網(wǎng)絡(luò)帶寬限制，影響到其他服務(wù)，支持從服務(wù)端下發(fā)全網(wǎng)限速，避免影響其他服務(wù)；
• 4）冷啟動(dòng)和熱點(diǎn)下載加速：一個(gè)新的文件下發(fā)時(shí)，因?yàn)槿W(wǎng)都不存在這個(gè)文件，如果按序下載，可能會(huì)導(dǎo)致下載緩慢，請(qǐng)求的節(jié)點(diǎn)分片集中。通過(guò)打亂分片下載的順序，可以將請(qǐng)求分布到不同的節(jié)點(diǎn)。

▲ 圖 25：P2P下載加速

7.2 多模塊擴(kuò)展挑戰(zhàn)

▲ 圖 26：Ray 聯(lián)邦集群架構(gòu)

為了提升 Ray 應(yīng)用的擴(kuò)展能力，我們通過(guò)starlink實(shí)現(xiàn)了Ray聯(lián)邦集群架構(gòu)，每個(gè)Ray應(yīng)用可以擁有多個(gè)Ray集群，單個(gè)Ray集群都擁有完整的功能。用戶可以調(diào)整單個(gè)Ray集群的大小，在單個(gè)Ray集群內(nèi)進(jìn)行Actor的資源分配，提升應(yīng)用處理能力，提升資源利用率，實(shí)現(xiàn)垂直擴(kuò)展能力；可以通過(guò)擴(kuò)容Ray 集群數(shù)量，實(shí)現(xiàn)水平擴(kuò)展。

我們還在 Ray 聯(lián)邦集群架構(gòu)基礎(chǔ)上，增強(qiáng)了 Ray集群的容災(zāi)能力，具體策略為：當(dāng)head node下線，則水平重新擴(kuò)容一個(gè)Ray集群。當(dāng)worker node下線，則在這個(gè)Ray集群重新拉起一個(gè)worker。通過(guò)上述策略，我們使用不穩(wěn)定的低優(yōu)資源的情況下，Ray自身架構(gòu)引起的失敗影響可以降低到最低。

7.3 多卡型擴(kuò)展

▲ 圖 27：TFCC推理運(yùn)行時(shí)

多卡型擴(kuò)展的模型推理部署有三個(gè)比較大的挑戰(zhàn)：

• 1）不同的推理業(yè)務(wù)形態(tài)多樣：引擎種類多模型類型多（pytorch/onnx/tensorrt...）；
• 2）異構(gòu)卡型的適配工作繁瑣且重復(fù)度高（英偉達(dá)/紫霄/華為）；
• 3）多種引擎支持、模型切換引擎成本高。

我們基于TFCC框架提供標(biāo)準(zhǔn)服務(wù)框架，統(tǒng)一了接入模式，透明化了引擎實(shí)現(xiàn)，算法僅需聲明模型，不再需要手寫(xiě)推理代碼，同時(shí)內(nèi)化異構(gòu)卡型適配工作，屏蔽硬件細(xì)節(jié)，在應(yīng)用層實(shí)現(xiàn)一份代碼、多處推理，支持靈活多樣的AI應(yīng)用場(chǎng)景。

8、本文小結(jié)

AI 時(shí)代的來(lái)臨對(duì)微信后臺(tái)的基礎(chǔ)設(shè)施帶來(lái)了許多挑戰(zhàn)。我們引入業(yè)界先進(jìn)的Ray作為基座，適配了微信的基礎(chǔ)環(huán)境，提供了方便快捷的AI應(yīng)用開(kāi)發(fā)范式。同時(shí)，在Ray的基礎(chǔ)上，簡(jiǎn)化了Ray本身集群管理的難度，并使用低成本的閑置資源節(jié)省了大量的機(jī)器成本。AstraRay作為一個(gè)剛誕生一年的項(xiàng)目，為微信的AI應(yīng)用的工程化提供了堅(jiān)實(shí)基礎(chǔ)，并且在持續(xù)不斷的優(yōu)化，為將來(lái)更多AI應(yīng)用在微信落地做好了準(zhǔn)備。

9、參考資料

[1] Ray on Kubernetes

[2] OpenAI 背書(shū)的計(jì)算引擎迎里程碑：螞蟻集團(tuán)成功部署百萬(wàn)核心計(jì)算平臺(tái)

[3] 使用 KubeRay 和 Kueue 在 Kubernetes 中托管 Ray 工作負(fù)載

[4] Four Reasons Why Leading Companies Are Betting On Ray

[5] The evolution of cluster scheduler architectures

[6] API7 Cloud Integrates with Kubernetes Service Discovery

[7] Upstream: smooth weighted round-robin balancing

[8] Handling files and packages on your cluster with Ray runtime environments

10、微信團(tuán)隊(duì)其它技術(shù)文章

《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）》

《騰訊技術(shù)分享：GIF動(dòng)圖技術(shù)詳解及手機(jī)QQ動(dòng)態(tài)表情壓縮技術(shù)實(shí)踐》

《微信團(tuán)隊(duì)分享：Kotlin漸被認(rèn)可，Android版微信的技術(shù)嘗鮮之旅》

《微信團(tuán)隊(duì)首次揭秘微信紅包算法，為何你搶到的是0.01元》

《微信團(tuán)隊(duì)分享：極致優(yōu)化，iOS版微信編譯速度3倍提升的實(shí)踐總結(jié)》

《IM“掃一掃”功能很好做？看看微信“掃一掃識(shí)物”的完整技術(shù)實(shí)現(xiàn)》

《微信團(tuán)隊(duì)分享：微信支付代碼重構(gòu)帶來(lái)的移動(dòng)端軟件架構(gòu)上的思考》

《IM開(kāi)發(fā)寶典：史上最全，微信各種功能參數(shù)和邏輯規(guī)則資料匯總》

《微信團(tuán)隊(duì)分享：微信直播聊天室單房間1500萬(wàn)在線的消息架構(gòu)演進(jìn)之路》

《企業(yè)微信的IM架構(gòu)設(shè)計(jì)揭秘：消息模型、萬(wàn)人群、已讀回執(zhí)、消息撤回等》

《IM全文檢索技術(shù)專題(四)：微信iOS端的最新全文檢索技術(shù)優(yōu)化實(shí)踐》

《微信團(tuán)隊(duì)分享：微信后臺(tái)在海量并發(fā)請(qǐng)求下是如何做到不崩潰的》

《微信Windows端IM消息數(shù)據(jù)庫(kù)的優(yōu)化實(shí)踐：查詢慢、體積大、文件損壞等》

《微信技術(shù)分享：揭秘微信后臺(tái)安全特征數(shù)據(jù)倉(cāng)庫(kù)的架構(gòu)設(shè)計(jì)》

《企業(yè)微信針對(duì)百萬(wàn)級(jí)組織架構(gòu)的客戶端性能優(yōu)化實(shí)踐》

《揭秘企業(yè)微信是如何支持超大規(guī)模IM組織架構(gòu)的——技術(shù)解讀四維關(guān)系鏈》

《微信團(tuán)隊(duì)分享：詳解iOS版微信視頻號(hào)直播中因幀率異常導(dǎo)致的功耗問(wèn)題》

《微信團(tuán)隊(duì)分享：微信后端海量數(shù)據(jù)查詢從1000ms降到100ms的技術(shù)實(shí)踐》

《大型IM工程重構(gòu)實(shí)踐：企業(yè)微信Android端的重構(gòu)之路》

《IM技術(shù)干貨：假如你來(lái)設(shè)計(jì)微信的群聊，你該怎么設(shè)計(jì)？》

《微信團(tuán)隊(duì)分享：來(lái)看看微信十年前的IM消息收發(fā)架構(gòu)，你做到了嗎》

（本文已同步發(fā)布于：http://www.52im.net/thread-4731-1-1.html）