彈性部署的分布式AI 計(jì)算架構(gòu)系統(tǒng)研究

李茜萌，陳春雨，何恒翔

哈爾濱工程大學(xué) 信息與通信工程學(xué)院，黑龍江 哈爾濱 150000

近年來(lái)，以ARM 陣營(yíng)為代表的嵌入式計(jì)算平臺(tái)的性能高速增長(zhǎng)帶來(lái)了嵌入式產(chǎn)業(yè)的繁榮，ARM 芯片開(kāi)始進(jìn)入越來(lái)越多的平臺(tái)，如無(wú)人機(jī)、平板、智能機(jī)器人。ARM 芯片內(nèi)部集成了CPU、GPU、ISP 等模塊，部分芯片內(nèi)甚至集成了通訊基帶，這種系統(tǒng)級(jí)芯片(system-on-a-chip，Soc)的封裝特點(diǎn)在于大大簡(jiǎn)化了嵌入式設(shè)備的硬件研發(fā)難度的同時(shí)，為嵌入式平臺(tái)帶來(lái)了強(qiáng)大的圖像、音頻及其他傳感器數(shù)據(jù)獲取的能力[1]。在具備了可靠的數(shù)據(jù)高速獲取能力之后，如何更加高速可靠地處理這些數(shù)據(jù)則對(duì)平臺(tái)性能提出了更高的要求。當(dāng)前，人工智能技術(shù)的第三次繁榮，其在計(jì)算機(jī)視覺(jué)(computer vision，CV)、自然語(yǔ)言處理(natural language processing，NLP)等領(lǐng)域取得了比傳統(tǒng)算法更加優(yōu)良的效果，部分領(lǐng)域甚至實(shí)現(xiàn)了大幅度的超越。但是深度學(xué)習(xí)技術(shù)對(duì)于計(jì)算力的需求極高，很多網(wǎng)絡(luò)需要高性能的GPU 或者TPU 才能運(yùn)行，無(wú)法直接將其移植至嵌入式端[2]。本系統(tǒng)利用現(xiàn)代社會(huì)已經(jīng)實(shí)現(xiàn)完善部署的Wi-Fi 網(wǎng)絡(luò)及蜂窩網(wǎng)絡(luò)，將嵌入式設(shè)備需要計(jì)算的圖像數(shù)據(jù)傳送至云端，云端通過(guò)部署的服務(wù)器、工作站集群進(jìn)行高速計(jì)算并返回結(jié)果，充分利用了嵌入式設(shè)備體積小巧、適合部署于前端的特性，以及云計(jì)算高性能、高可靠、存儲(chǔ)容量大的特性，實(shí)現(xiàn)了成本及性能的最優(yōu)化配置，對(duì)多種現(xiàn)代流行的AI 框架都能很好的兼容。大量嵌入式設(shè)備的同時(shí)接入，對(duì)系統(tǒng)的計(jì)算能力也提出了巨大的挑戰(zhàn)，本文將探究一種能夠解決以上矛盾的可彈性部署的分布式AI 計(jì)算架構(gòu)系統(tǒng)。

1 系統(tǒng)各模塊

在傳統(tǒng)方法中，為了讓嵌入式設(shè)備采集到的數(shù)據(jù)能被高速處理，多采用有線連接的模式在其附近部署一套工作站。這種方式雖然初步實(shí)現(xiàn)了深度學(xué)習(xí)計(jì)算的功能，但是其能耗高、發(fā)熱量大，在部分工業(yè)生產(chǎn)環(huán)境中是不被允許的，特別是部分現(xiàn)場(chǎng)潮濕、多塵、電壓不穩(wěn)的情況，這些不利因素直接導(dǎo)致了工作站不能穩(wěn)定工作。并且因?yàn)閿?shù)據(jù)并非時(shí)刻需要計(jì)算，那么這種方案也將導(dǎo)致計(jì)算資源長(zhǎng)時(shí)間處于閑置狀態(tài)，是一種極大的成本和資源的浪費(fèi)。本文結(jié)合分布式設(shè)計(jì)思路[3-5]，提出了一種框架，將計(jì)算平臺(tái)部署于云端，工作站集群部署于環(huán)境適宜的機(jī)房?jī)?nèi)，為設(shè)備長(zhǎng)時(shí)間高負(fù)荷運(yùn)行提供了有效保障[6]。分布式計(jì)算、彈性部署的特點(diǎn)能為大量嵌入式設(shè)備的計(jì)算需求提供有效的計(jì)算性能保障，同時(shí)也減少了計(jì)算資源的限制和浪費(fèi)。與單純利用嵌入式設(shè)備進(jìn)行計(jì)算對(duì)比，本方案具有極大的性能優(yōu)勢(shì)，以Mask RCNN[7]網(wǎng)絡(luò)為例，相較在樹(shù)莓派4 平臺(tái)直接運(yùn)行，速度提升幾十倍。

本系統(tǒng)由中央服務(wù)器、集群服務(wù)器、GPU 工作站集群、嵌入式端4 部分組成。中央處理器是整個(gè)網(wǎng)絡(luò)的核心節(jié)點(diǎn)，負(fù)責(zé)綜合調(diào)度各個(gè)設(shè)備進(jìn)行工作，接收到嵌入式端的請(qǐng)求后會(huì)為其分配當(dāng)前最空閑的計(jì)算集群的連接方式；然后嵌入式設(shè)備連接集群服務(wù)器后開(kāi)始傳送數(shù)據(jù)，集群服務(wù)器會(huì)進(jìn)一步將數(shù)據(jù)轉(zhuǎn)發(fā)給集群內(nèi)運(yùn)行對(duì)應(yīng)模型，且最為空閑的GPU 工作站進(jìn)行計(jì)算并接收計(jì)算結(jié)果；最后將結(jié)果回傳給嵌入式終端，如圖1 所示。

圖1 系統(tǒng)架構(gòu)

中央服務(wù)器在整個(gè)系統(tǒng)中擔(dān)當(dāng)?shù)氖呛诵恼{(diào)度的工作，其對(duì)設(shè)備的穩(wěn)定性要求極高[8]，故采用了阿里云服務(wù)器作為中央服務(wù)器的硬件載體。云服務(wù)器具有安全、可靠、穩(wěn)定及可彈性增加容量等特點(diǎn)[9]。本系統(tǒng)中的云服務(wù)器配置為單核Xeon處理器，主頻2.4 GHz，2 GB 內(nèi)存，40 GB 硬盤(pán)，1 Mb固定IP 帶寬，操作系統(tǒng)為Windows Server 2013。

為了實(shí)現(xiàn)多地分布式部署，一個(gè)系統(tǒng)中允許存在多個(gè)計(jì)算工作站集群，每個(gè)集群中都有一臺(tái)專(zhuān)門(mén)的服務(wù)器作為集群服務(wù)器，由其與中央服務(wù)器以及嵌入式設(shè)備進(jìn)行通信，然后再轉(zhuǎn)發(fā)給與它連接的各臺(tái)GPU 工作站。集群服務(wù)器需要運(yùn)行大量的通信進(jìn)程以及調(diào)度進(jìn)程，同時(shí)需要保存大量原始數(shù)據(jù)和計(jì)算結(jié)果，故對(duì)CPU 核心數(shù)量、內(nèi)存容量以及存儲(chǔ)空間要求較高，本系統(tǒng)中集群服務(wù)器使用了一臺(tái)搭載i7-8700k 處理器、64 GB DDR4 內(nèi)存、1 TB 固態(tài)硬盤(pán)、12 TB 機(jī)械硬盤(pán)的工作站，并為其開(kāi)通了50 Mb 帶寬的固定IP，操作系統(tǒng)為Ubuntu 18.04。

一個(gè)集群內(nèi)部會(huì)部署多臺(tái)GPU 工作站，GPU 作為AI 計(jì)算的實(shí)際主體，為了盡可能多部署GPU，每臺(tái)GPU 工作站內(nèi)部都擁有多塊顯卡[10]。本系統(tǒng)采用的GPU 工作站配置為:i9-10900k 處理器、128 GB DDR4 內(nèi)存、4 塊2080Ti 顯卡、2 TB 固態(tài)硬盤(pán)、12 TB 機(jī)械硬盤(pán)，操作系統(tǒng)為Ubuntu 18.04。深度學(xué)習(xí)框架支持主流的Tensorflow、Keras、Pytorch、Caffe 等[11]。

嵌入式端采用最新推出的樹(shù)莓派4B 作為主控板，其搭載了1.5 GHz 四核A72 核心CPU，500 MHz的GPU，2 GB DDR4 內(nèi)存，802.11ac 無(wú)線網(wǎng)卡，千兆有線網(wǎng)卡，USB3.0 接口。四核心的高性能ARM核心搭配大容量的內(nèi)存，使其能運(yùn)用多線程技術(shù)來(lái)很好地支持?jǐn)?shù)據(jù)采集工作，千兆網(wǎng)口和802.11ac無(wú)線網(wǎng)卡的配備使其能很方便地接入有線網(wǎng)絡(luò)或Wi-Fi 網(wǎng)絡(luò)。再結(jié)合小巧的體積和低功耗、低發(fā)熱設(shè)計(jì)，完善的操作系統(tǒng)適配，使其極其適合作為本系統(tǒng)的嵌入式端核心板，操作系統(tǒng)采用其官方系統(tǒng)(基于Debian 開(kāi)發(fā))。

2 系統(tǒng)網(wǎng)絡(luò)架構(gòu)

本系統(tǒng)是一套面向?qū)嶋H應(yīng)用的可彈性部署的分布式AI 計(jì)算系統(tǒng)，當(dāng)前整套系統(tǒng)跨越了Windows、Ubuntu、Debian 這3 個(gè)操作系統(tǒng)，且未來(lái)很可能會(huì)移植代碼至不同的操作系統(tǒng)進(jìn)行運(yùn)行。為了實(shí)現(xiàn)代碼能方便地進(jìn)行跨系統(tǒng)開(kāi)發(fā)，我們選定了C++作為主要開(kāi)發(fā)語(yǔ)言，并且采用Boost 這個(gè)實(shí)際意義上的C++標(biāo)準(zhǔn)庫(kù)來(lái)實(shí)現(xiàn)代碼與操作系統(tǒng)無(wú)關(guān)的特性。同時(shí)，在深度學(xué)習(xí)模型中，調(diào)用部分采用Python 編寫(xiě)，采用C++調(diào)用Python 的方法將兩者融合。C++和Python 這2 種語(yǔ)言都具有很好的跨平臺(tái)適配能力，C++擁有極高的運(yùn)行速度，多用于系統(tǒng)、平臺(tái)框架開(kāi)發(fā)；Python 具有開(kāi)發(fā)方便、工具包眾多等優(yōu)點(diǎn)，在人工智能等領(lǐng)域被廣泛采用。C++與Python 的混合開(kāi)發(fā)，使整個(gè)系統(tǒng)兼具運(yùn)行速度快和開(kāi)發(fā)方便的優(yōu)點(diǎn)。

在通訊程序部分，本系統(tǒng)采用了Boost.Asio作為通訊框架，以TCP 為通信協(xié)議。本項(xiàng)目需要傳送大量文件數(shù)據(jù)，TCP 相比UDP 擁有更好的可靠性，能很好地支持系統(tǒng)工作。通訊模式采用異步非阻塞模式，以實(shí)現(xiàn)在盡可能少占用資源的情況下進(jìn)行大量設(shè)備的連接和數(shù)據(jù)收發(fā)[12]。在本系統(tǒng)中，服務(wù)器端和客戶(hù)端各自擁有一個(gè)處理交互類(lèi)，在該類(lèi)中，定義了一系列收發(fā)處理函數(shù)及超時(shí)檢測(cè)等函數(shù)。因異步非阻塞通信的特殊性，為了實(shí)現(xiàn)錯(cuò)誤重發(fā)和文件收發(fā)等功能，在類(lèi)內(nèi)定義了一個(gè)保存狀態(tài)的標(biāo)志位。默認(rèn)狀態(tài)標(biāo)志是normal，服務(wù)器在該狀態(tài)可以接收客戶(hù)端發(fā)送的字符串信息。接收到字符串后，按照指定格式解碼字符串，從而提取到客戶(hù)端的需求，如:登陸、心跳檢測(cè)、信息傳輸、文件發(fā)送請(qǐng)求等。接著服務(wù)器端調(diào)用相信函數(shù)處理客戶(hù)端需求后并回傳結(jié)果信息。以收發(fā)圖像為例，如客戶(hù)端發(fā)送的字符串屬于請(qǐng)求發(fā)送圖像，則該字符串內(nèi)同時(shí)會(huì)包含圖像文件大小等信息，此時(shí)服務(wù)器的狀態(tài)和客戶(hù)端的狀態(tài)標(biāo)志都會(huì)改變?yōu)槭瞻l(fā)文件狀態(tài)。下一步客戶(hù)端會(huì)在收到服務(wù)器回信后發(fā)送文件，服務(wù)器端則會(huì)啟動(dòng)一個(gè)循環(huán)接收的程序，直至收到的文件大小等于上一步中客戶(hù)端發(fā)送的文件大小值，收發(fā)成功后，服務(wù)器和客戶(hù)端的狀態(tài)再次回歸normal，如出錯(cuò)則再次進(jìn)行文件傳送。

2.1 中央服務(wù)器

中央服務(wù)器是整個(gè)系統(tǒng)的核心節(jié)點(diǎn)，其擁有固定公網(wǎng)IP 且開(kāi)發(fā)特定端口允許設(shè)備連接，其核心功能由3 部分構(gòu)成:與集群服務(wù)器通訊程序、與嵌入式端通訊程序、與其他服務(wù)器通訊程序，

如圖2 所示。中央服務(wù)器支持負(fù)載均衡功能，能為用戶(hù)設(shè)備提供最合適的算力分配。中央服務(wù)器內(nèi)部擁有一個(gè)儲(chǔ)存各個(gè)集群服務(wù)器實(shí)時(shí)狀態(tài)信息的vector，該vector 內(nèi)的信息每秒會(huì)更新一次。當(dāng)中央服務(wù)器收到嵌入式端計(jì)算請(qǐng)求后，會(huì)遍歷該vector，首先檢測(cè)哪幾個(gè)集群服務(wù)器能提供滿足該計(jì)算需求的計(jì)算能力，接著對(duì)比這幾個(gè)集群服務(wù)器負(fù)載壓力，找出壓力最小的那個(gè)服務(wù)器集群并將其連接方式轉(zhuǎn)發(fā)給嵌入式端，以此實(shí)現(xiàn)負(fù)載均衡，平衡各個(gè)集群的計(jì)算壓力。

圖2 中央服務(wù)器

2.1.1 與集群服務(wù)器通信

該模塊能管理接入的集群服務(wù)器信息，其內(nèi)部擁有一個(gè)vector 用于存儲(chǔ)集群服務(wù)器的信息，包括連接模式、IP 地址、端口、當(dāng)前負(fù)載、支持運(yùn)行的模型名稱(chēng)及其版本等。

其首先會(huì)啟動(dòng)一個(gè)異步非阻塞模式的通訊服務(wù)器端用于接收集群服務(wù)器的連接。當(dāng)一臺(tái)集群服務(wù)器進(jìn)行接入時(shí)，服務(wù)器端會(huì)先接收到一條帶有l(wèi)ogin 標(biāo)志為用戶(hù)名及密碼的字符串，可以以此進(jìn)行身份校驗(yàn)，防止惡意接入。身份校驗(yàn)通過(guò)后，服務(wù)器會(huì)接收到一條字符串信息，解碼該字符串即可獲取其連接方式，該信息將用于轉(zhuǎn)發(fā)給嵌入式端。以上步驟完成后，服務(wù)器端會(huì)每秒和集群服務(wù)器通信一次，接收其發(fā)送的實(shí)時(shí)負(fù)載狀態(tài)并更新vector 中對(duì)應(yīng)位置的信息。

2.1.2 與嵌入式端通訊

該模塊負(fù)責(zé)與嵌入式設(shè)備進(jìn)行通訊，工作模式為異步非阻塞。當(dāng)嵌入式設(shè)備接入時(shí)，同樣會(huì)首先進(jìn)行賬號(hào)和密碼驗(yàn)證，確認(rèn)無(wú)誤后進(jìn)一步接收設(shè)備需要計(jì)算的模型信息。接著該模塊開(kāi)始檢索存儲(chǔ)有集群服務(wù)器信息的vector 列表，找出支持該模型計(jì)算的、且當(dāng)前負(fù)荷最小的那個(gè)集群，進(jìn)一步取出該集群的連接方式等信息后轉(zhuǎn)發(fā)給嵌入式端，待嵌入式端接收完畢后，中央服務(wù)器會(huì)斷開(kāi)連接以減少整個(gè)系統(tǒng)的負(fù)荷。

2.1.3 與其他服務(wù)器通訊

此模塊主要與其他服務(wù)器，如數(shù)據(jù)庫(kù)服務(wù)器、管理服務(wù)器進(jìn)行通訊和信息交互，通訊模式為同步阻塞模式，屬于客戶(hù)端。此模塊屬于對(duì)外交互模塊，主要用于上傳狀態(tài)信息、計(jì)算結(jié)果等信息給其他服務(wù)器，同時(shí)可以幫助中轉(zhuǎn)其他服務(wù)器的指令給嵌入式端。

2.2 集群服務(wù)器

集群服務(wù)器扮演著一個(gè)計(jì)算集群的管理者的角色，也是整個(gè)集群對(duì)外交互的唯一設(shè)備。其作為一個(gè)客戶(hù)端與中央服務(wù)器進(jìn)行通訊，用于上傳自身的連接方式和實(shí)時(shí)狀態(tài)信息，同時(shí)其自身也作為一個(gè)服務(wù)器端與嵌入式端進(jìn)行通訊，將需要計(jì)算的數(shù)據(jù)分發(fā)給各個(gè)工作站，如圖3 所示。

圖3 集群服務(wù)器

由于部分復(fù)雜任務(wù)需要依次經(jīng)過(guò)多個(gè)模型進(jìn)行計(jì)算才能完成，如先經(jīng)過(guò)一個(gè)Mask R-CNN模型，再經(jīng)過(guò)一個(gè)ResNet[13]才能輸出結(jié)果，所以集群服務(wù)器內(nèi)部維護(hù)著一個(gè)上下文列表，這個(gè)上下文列表記錄著每個(gè)任務(wù)需要依次調(diào)用的模型以及模型的版本。當(dāng)一個(gè)計(jì)算任務(wù)到達(dá)時(shí)，集群服務(wù)器會(huì)先檢索這個(gè)上下文列表，尋找到該任務(wù)需要進(jìn)行的計(jì)算步驟，然后依次將該數(shù)據(jù)發(fā)送給進(jìn)行對(duì)應(yīng)任務(wù)的GPU 工作站進(jìn)行計(jì)算，并取回結(jié)果。

集群服務(wù)器管理著一個(gè)集群內(nèi)部的所有GPU工作站，它會(huì)建立一個(gè)通訊服務(wù)器程序，當(dāng)GPU工作站上的各種計(jì)算程序接入后，就會(huì)被集群服務(wù)器進(jìn)行集中管理，實(shí)時(shí)監(jiān)控各個(gè)任務(wù)的計(jì)算負(fù)荷、模型名稱(chēng)和版本等數(shù)據(jù)。

2.3 GPU 工作站集群

GPU 工作站集群由多臺(tái)GPU 工作站構(gòu)成，每臺(tái)都安裝有多塊高性能GPU，每一塊GPU 視部署的模型大小可以運(yùn)行一個(gè)或多個(gè)任務(wù)進(jìn)程，每一個(gè)進(jìn)程都是一個(gè)獨(dú)立的程序。

當(dāng)一個(gè)計(jì)算進(jìn)程啟動(dòng)后，會(huì)首先調(diào)用Python加載深度學(xué)習(xí)模型，同時(shí)讀取該模型的記錄文檔，獲取模型名稱(chēng)和版本信息。以上步驟完成后，該進(jìn)程會(huì)啟動(dòng)一個(gè)Python 版的Socket 程序主動(dòng)連接集群服務(wù)器，身份校驗(yàn)以及字符串解碼等格式與本系統(tǒng)中其他部分的通信程序一致，不同的是此處采用同步阻塞模式，可以大大減輕編程復(fù)雜度。依托通信程序，GPU 進(jìn)程能告知集群服務(wù)器自身的模型版本以及負(fù)載壓力等信息，后續(xù)當(dāng)收到集群服務(wù)器發(fā)送的圖像數(shù)據(jù)后，GPU 立刻開(kāi)始計(jì)算并返回計(jì)算結(jié)果。為了提高軟硬件運(yùn)行效率，每一個(gè)計(jì)算進(jìn)程都支持?jǐn)?shù)據(jù)緩存隊(duì)列，會(huì)提前接收后續(xù)數(shù)據(jù)放入隊(duì)列中，這樣可以減少每次計(jì)算的數(shù)據(jù)等待時(shí)間。

當(dāng)前存在很多熱門(mén)的深度學(xué)習(xí)框架，而一個(gè)任務(wù)很可能在不同的處理階段需要依賴(lài)不同的框架進(jìn)行計(jì)算。為了實(shí)現(xiàn)對(duì)多種深度學(xué)習(xí)框架的支持，本系統(tǒng)允許各個(gè)計(jì)算進(jìn)程在單獨(dú)的Python 環(huán)境中運(yùn)行。即利用Anaconda 生成多個(gè)獨(dú)立的深度學(xué)習(xí)環(huán)境，分別安裝不同的深度學(xué)習(xí)框架[14]，然后再在各個(gè)框架內(nèi)建立任務(wù)進(jìn)程。各個(gè)進(jìn)程都依靠網(wǎng)絡(luò)通訊單獨(dú)與集群服務(wù)器建立連接，再依賴(lài)集群服務(wù)器的上下文管理功能進(jìn)行任務(wù)調(diào)度，這種模式有效避免了不同深度學(xué)習(xí)框架依賴(lài)庫(kù)版本不同而導(dǎo)致的系統(tǒng)混亂，完美實(shí)現(xiàn)了一個(gè)系統(tǒng)內(nèi)多種深度學(xué)習(xí)框架的共存。

2.4 嵌入式端

嵌入式端是用戶(hù)使用的設(shè)備，當(dāng)用戶(hù)有數(shù)據(jù)需要云端進(jìn)行計(jì)算時(shí)，其首先會(huì)以客戶(hù)端的身份連接中央服務(wù)器的通訊端口，同時(shí)上傳自身的身份驗(yàn)證和任務(wù)需求，在接收到云服務(wù)器返回的計(jì)算集群連接信息后，斷開(kāi)與中央服務(wù)器之間的連接。接著又以客戶(hù)端的身份連接集群服務(wù)器，支持以IP 和網(wǎng)址的形式進(jìn)行連接，在連接到集群服務(wù)器后，同樣是先進(jìn)行身份驗(yàn)證，然后再上傳任務(wù)需求和所需計(jì)算的數(shù)據(jù)，如圖4 所示。因?yàn)榍度胧蕉诵枰?jì)算的往往是圖像數(shù)據(jù)，以項(xiàng)目中經(jīng)常需要計(jì)算的3D 圖像和RGB 高清圖像數(shù)據(jù)為例，單份數(shù)據(jù)的體積往往能達(dá)到3 MB。為了盡可能地減少網(wǎng)絡(luò)資源占用及降低通訊延時(shí)，同時(shí)為了防止數(shù)據(jù)在公網(wǎng)進(jìn)行傳輸時(shí)發(fā)生泄密，需要在數(shù)據(jù)發(fā)送前對(duì)其進(jìn)行一定壓縮及加密[15]。最后，嵌入式端會(huì)等待集群服務(wù)器回傳計(jì)算結(jié)果，一次完整的計(jì)算過(guò)程便完成了。

圖4 嵌入式端

3 系統(tǒng)性能分析

3.1 性能指標(biāo)

為了使本套系統(tǒng)能符合項(xiàng)目使用需要，故列出如表1 所示性能指標(biāo)。

表1 系統(tǒng)性能指標(biāo)

本系統(tǒng)采用Boost.Aasio 作為核心通信框架，相比經(jīng)典的Socket 通信程序，Boost.Asio 可以看成是Boost 庫(kù)對(duì)Socket 的進(jìn)一步封裝，能更好地支持異步通信模式。相比ACE 等通信框架，鑒于Boost 庫(kù)已經(jīng)成為事實(shí)上的C++標(biāo)準(zhǔn)庫(kù)，其自帶的Asio 擁有比ACE 框架更加容易安裝和使用的優(yōu)勢(shì)。

3.2 實(shí)際測(cè)試性能

在實(shí)際測(cè)試場(chǎng)景中，中央服務(wù)器帶寬為1 Mb，計(jì)算集群帶寬為50 Mb，嵌入式端上行帶寬受用戶(hù)實(shí)際使用場(chǎng)景不同而不同。每份數(shù)據(jù)經(jīng)過(guò)壓縮后約為0.6 MB。因?yàn)槊總€(gè)設(shè)備不是連續(xù)發(fā)送數(shù)據(jù)的，經(jīng)測(cè)試，整個(gè)系統(tǒng)可以同時(shí)為超過(guò)50 臺(tái)設(shè)備提供服務(wù)，同一時(shí)刻并發(fā)接收8 個(gè)設(shè)備上傳數(shù)據(jù)，基本接近了網(wǎng)絡(luò)帶寬極限。在客戶(hù)端連接數(shù)量方面，實(shí)測(cè)最大可保持連接數(shù)可保持500 以上，短時(shí)可保持1 000 以上。

模型計(jì)算方面以GPU 集群中部署的Mask RCNN 模型為例，計(jì)算一張圖像的平均時(shí)間約為0.15 s，數(shù)據(jù)傳輸時(shí)間受用戶(hù)上行帶寬不同而不同，按平均0.2 s 計(jì)算，設(shè)備端完整運(yùn)行一次云計(jì)算的時(shí)間花費(fèi)約0.35 s，完全滿足用戶(hù)需求。

經(jīng)測(cè)試，整個(gè)程序可完美兼容Ubuntu、Mac OS、Windows 這3 款主流操作系統(tǒng)，支持C++和Python 混合編程，對(duì)Tensorflow 和Pytorch 這2 款學(xué)術(shù)界熱門(mén)的深度學(xué)習(xí)框架能很好地支持。

中央服務(wù)器工作狀態(tài)如圖5 所示。

圖5 中央服務(wù)器工作狀態(tài)

4 結(jié)論

隨著嵌入式產(chǎn)業(yè)與人工智能產(chǎn)業(yè)的蓬勃發(fā)展，以及最新5G 及Wi-Fi 6 的入局，為大量嵌入式設(shè)備提供AI 計(jì)算云服務(wù)成為了一個(gè)重要的研究方向。

1)本系統(tǒng)構(gòu)建了一套可彈性擴(kuò)容、分布式部署的AI 計(jì)算系統(tǒng)；

2)該系統(tǒng)試驗(yàn)期間穩(wěn)定運(yùn)行無(wú)崩潰現(xiàn)象；

3)本系統(tǒng)是智能養(yǎng)殖場(chǎng)景下，使用深度學(xué)習(xí)方法進(jìn)行體尺計(jì)算的一種創(chuàng)新型方法；

4)本系統(tǒng)具有硬件資源利用率高、成本低、安全可靠的特點(diǎn)，有效解決了嵌入式設(shè)備對(duì)快速可靠的AI 計(jì)算的需求。

5)本系統(tǒng)很容易擴(kuò)展至其他應(yīng)用場(chǎng)景。