面向邊緣集群內AI數據流的雙平面調度模型

吳明杰，陳慶奎

1(上海理工大學 管理學院，上海 200093)2(上海理工大學 光電信息與計算機工程學院，上海 200093)

E-mail ：WMJ826WMJ@163.com

1 引 言

近年來隨著物聯網[1]終端設備的劇增，基于云計算[2]的物聯網解決方案開始顯露其短板.終端設備規模的不斷擴大將極大的增加通信延遲和計算延時，這將無法為用戶提供可接受的計算需求和響應需求.邊緣計算[3]正是為緩解這一現狀而提出的新解決方案.其作為云計算模式的拓展延伸，能夠在更加接近用戶端進行部署.這將極大的降低通信開銷，減少響應延遲，為用戶提供更好的體驗.如圖1所示的′云-邊協作框架′[4]將會是未來非常流行的物聯網解決方案.

圖1 云-邊協作框架Fig.1 Cloud-edge collaboration framework

AI(人工智能)[5]技術近幾年得到了快速的發展，并且逐漸向邊緣端拓展.云計算模式的高延遲限制了AI的廣泛應用，終端設備的低計算能力也無法使AI部署于其上，這使得邊緣數據中心[6]成為承載AI計算負載的最佳平臺.而且，設備端持續增長的實時AI計算需求對邊緣數據中心的性能也提出了更高的要求[7].

為了滿足邊緣AI對邊緣數據中心的高性能需求，本文針對邊緣集群提出一種由控制平面和數據平面組成的雙平面通信架構.控制平面負責處理數據流調度和集群監控等控制信息，數據平面負責數據的快速傳輸.本文也針對AI數據流提出了基于消息的傳輸協議，能夠有效的降低數據傳輸負載.最后還提出了AI數據流的集群內調度模型.實驗表明，雙平面AI數據流的調度模型，能夠有效的降低AI數據流的計算延時，提高邊緣集群的數據流接入和處理能力.

2 相關工作

隨著邊緣計算的興起，邊緣微型數據中心作為云計算數據中心的縮小版，面臨著同樣的任務通信和調度問題[8].而且，實時邊緣計算對于邊緣集群的響應時間提出了更高的要求[9].

對于通信延時問題，研究人員提出了基于硬件和基于軟件的通信性能提升技術.硬件方面已經提出了各種專用的網絡硬件解決方案.代表性的如EZChip的NP-4和Yorneam Illit的NPS-400(Mellanox Technologies)(1)http://www.mellanox.com，Cavium的OCTEON(2)http://www.cavium.com系列，Tilera的Tile-Gx(3)http://www.mellanox.com產品.基于軟件的解決方案使得人們對于SDN[10](軟件定義網絡)和NFV(網絡功能虛擬化)[11]的興趣.代表性的如NTOP的PF-RING(4)http://www.ntop.org/products/packet-capture/pf-ring，Intel的DPDK[12]，以及6WIND的6WINDGate(5)http://www.6wind.com/products/6windgate.一些研究和應用中已經提出了通過將兩個平面分離而實現靈活的網絡控制的網絡切片技術，如Pongracz等人[13]提出一種LTE環境下的SDN架構.此外，將SDN技術應用于物聯網環境也出現了一些研究.Yaakoumis等[14]描述了一種在物聯網環境中分割家庭網絡的原型，他將物理網絡切成多層，以隔離不同運營商的流量和帶寬.Qing等[15]提出了1個SDN控制器和控制器角色，例如資源匹配和流調度.

任務調度方面研究人員也提出了很多方案.Dong等[16]提出基于優先級的邊緣計算資源分配方法.Cao等[17]提出結合網絡資源和設備資源對CNN網絡進行動態切片的模型，以優化任務完成時間.Jia等[18]提出了一種在線啟發式負載均衡任務遷移算法，以縮短終端設備上的應用完成時間.Guo等[19]提出一種節能的動態遷移和資源調度策略，以降低能耗并縮短應用完成時間.Fang等[20]提出一種基于GPU能耗的并發數據流實時動態遷移模型，旨在提高任務執行的可靠性.目前邊緣環境下的計算遷移任務調度問題也有一些研究.Zhang等[21]將終端設備延遲敏感的計算任務遷移到邊緣云，并提出兩階段任務調度成本優化算法，以降低系統成本.Qi等[22]提出一種結合網絡狀況和設備條件的自適應調度算法.

基于前人的研究成果，結合SDN雙平面以及物理網絡切片的思想，本文提出基于Intel DPDK(6)http://www.dpdk.org技術的針對邊緣集群的雙平面通信框架，將控制平面網絡和數據平面網絡從物理上隔離.其次，考慮邊緣集群內計算節點網絡資源和計算資源使用情況，提出數據流動態遷移模型.

3 設計

3.1 物理拓撲

邊緣集群作為云計算在物聯網應用方面的補充，決定了其應對物聯網數據接入和計算的高密度任務.任務調度和監控往往需要近乎實時，對于時延非常敏感.傳統的單平面架構會存在一些缺陷.當數據傳輸占用了大量帶寬時，會造成控制或者調度命令的傳輸滯后，這可能會加重計算節點的負載，甚至是宕機.

圖2 物理拓撲Fig.2 Physical topology

如圖2所示，通過使用多張網卡，本文的雙平面通信框架能夠從物理上將控制平面和數據平面分離，互不干擾，從而實現控制和調度命令的即時傳輸.數據平面數據通過DPDK技術進行快速傳輸，能夠提供較高的傳輸速率.

3.2 系統框架

本文所研究的邊緣集群節點都配有多張網卡，分為控制平面網口和數據平面網口.控制平面網口通過傳統網絡架構和協議互連，構成1個LAN環境.數據平面通過1個或者多個二層交換機相連，其在DPDK之上構建傳輸協議.邊緣集群節點分為3類：管理節點，數據流接入節點，GPU計算節點.管理節點上包括終端設備管理模塊，接入負載均衡模塊，節點資源狀態監控模塊，數據流調度模塊，計算模型管理模塊，即時信息反饋模塊.數據流接入節點上包括數據流接入轉發模塊和節點資源狀態模塊.數據流接入轉發模塊負責設備數據流的接收和根據數據流轉發表進行數據流轉發；節點資源狀態模塊負責定時上傳節點帶寬負載和接入負載等監控信息.GPU計算節點上包括數據流接收計算模塊和節點資源狀態監控模塊.數據流接收計算模塊負責數據流的接收和模型計算；節點資源狀態模塊負責定時上傳節點帶寬負載和計算負載等監控信息.

圖3 框架概覽Fig.3 Framework overview

系統整體流程如圖3所示.1)管理員在集群管理節點上注冊和上傳任務計算模型；集群管理節點將計算模型分發給GPU計算節點；2)終端設備向集群管理節點注冊數據流以及數據流需要的計算模型，管理節點返回該終端設備數據流的接入節點地址，終端設備進行數據流發送；3)數據流接入節點和GPU計算節點定時向管理節點發送實時帶寬負載，接入負載和計算負載等信息；4)管理節點根據GPU計算節點上傳的資源狀態信息進行數據流調度，并下發數據流轉發規則到數據流接入節點，數據流接入節點根據本地的數據流轉發進行數據流轉發；5)GPU計算節點接收數據流，并根據對應計算模型進行數據計算，如果產生即時反饋信息，則需要發送給管理節點，由管理節點將信息推送給終端設備；需要儲存和記錄的結果信息上傳至云端數據中心.

3.3 AI數據流特征分析

隨著邊緣AI的興起，如何在資源受限的終端設備上執行AI計算成為研究熱點.目前，終端設備進行部分數據預處理或者計算部分任務，后續任務通過網絡交由附近的邊緣集群進行計算的方式成為主流.其中，中間結果數據稱為AI數據流.AI數據流往往是源源不斷地數值型矩陣數據，包括小數.如圖片預處理的結果，CNN計算的中間結果.

巨量的AI數據流必然對網絡傳輸造成嚴重的壓力，這就需要高壓縮的通信協議來緩解.目前比較流行的技術包括Protobuf，XML，JSON，Thrift等.其中最熱門的當屬Google的Protobuf了.Protobuf由于更小，更快，更簡便備受人們青睞.但是Protobuf作為Google公司內部使用的工具[23]，在通用性上差很多.而且，對于數值型矩陣或者圖片的傳輸不夠友好，往往需要轉換為文件形式后進行傳輸，這將增加傳輸的數據量.為此，本文專門設計了基于消息的AI數據流傳輸協議，這將會在后續章節詳細介紹.

4 實 現

4.1 控制平面

控制平面的主要功能是:1)處理與終端設備之間的相關消息；2)監控集群各節點包括接入節點和計算節點資源狀態；3)根據狀態信息實時調度集群內數據流的傳輸；4)管理集群內計算模型的上傳和分發.由于控制平面構建于局域網之上，因此傳統的數據傳輸協議都可以使用，如HTTP，TCP，UDP，RPC等.

數據流調度是控制平面最重要的功能之一，如何高效的進行數據流調度成為難題.在數據流遷移的過程中會產生延遲：控制消息的傳輸和執行可能會產生延時；數據流遷移到目標節點的過程中可能由于網絡原因會產生延時；數據流到達目的節點之后，由于目的節點并發能力有限，可能需要排隊等待，也會增加延時.如果遷移的總延時太長，將會增加任務的響應時間，影響用戶體驗.任務的遷移對于保持邊緣集群的可靠性和穩定性至關重要.數據流的接入負載均衡已經有很多成熟、高效的算法，本文不予研究.

4.2 數據平面

數據平面的主要任務是數據流的快速傳輸和任務計算.其通信功能是基于Intel DPDK技術設計和實現的，以提高數據傳輸的性能，基于之前的研究中所提出的基于 DPDK 的邊緣集群內高速通信方案.該方案充分利用的DPDK的眾多特性，提供快速的數據報處理、轉發和傳輸特性，并借助于Linux系統的socket本地回環機制，為上層提供了與編程語言無關的類UDP通信接口.如圖4所示，雙平面通信路徑在集群節點內的流程從物理線路上進行了隔離，兩個平面的數據傳輸不會相互影響.

圖4 基于DPDK的通信模型Fig.4 Communication model based on DPDK

4.3 基于消息的數據傳輸協議

針對AI數據流傳輸，本文設計和實現了基于消息的傳輸機制.如圖5所示，每一消息都包含有FID(流編號)、MID(消息編號)、M_Time(消息時間戳)和M_Type(消息類型).消息類型分為字符型數據和數值型數據.字符型數據作為計算結果或者通知的格式.數值型數據作為待計算的圖像或者矩陣數據的格式，需要指明該數據的Model_ID(計算模型編號)，Byte_Type(矩陣數值類型)，以及矩陣的Len(長)和Wid(寬)，方便數據解析.Byte_Type指定了單個矩陣數值占用的字節數.

消息的大小往往超過了以太網數據幀大小的限制，在傳輸的過程中需要切片和重組.因此也設計和實現了消息切片的格式和可靠傳輸協議.每一個消息切片都包含有FID(流編號)、MID(消息編號)、M_Time(消息時間戳)字段、M_len(消息長度)、P_Type(消息切片類型)和P_content(消息切片內容).根據P_Type(消息切片類型)可以分為消息切片數據，切片重傳請求，消息重傳回應，消息重傳詢問.每一個消息切片都有P_Num(切片編號)、P_Total(切片總數)和P_Len切片長度，最后為切片數據.

圖5 消息和切片格式定義Fig.5 Message and fragment format definition

基于消息傳輸的可靠傳輸機制實現如下：1)發送節點緩存消息切片，并進行發送；發送完成后向接收節點發送消息重傳詢問；2)接收節點不斷的接收消息切片并緩存；若收到消息切片的最后一個切片或者是發送節點的消息重傳詢問，需要回應一個消息重傳請求；3)發送節點收到消息重傳請求，進行丟失校驗并對對應的數據包重新發送.在規定時間內如果發送節點收到接收節點接收完全的通知，完成此消息的發送；如果超時，則進行下一條消息的發送.如果接收端在規定的時間內未收齊該消息，則丟棄.這樣是為了保證AI數據流實時計算的特性.

4.4 數據流調度模型和算法

數據流在集群內的耗時包括傳輸時間，排隊時間和計算時間.傳輸時間可以分為外網傳輸時間和集群內傳輸時間.其中，外網傳輸時間受外部網絡環境的影響；集群內傳輸時間不僅受集群內帶寬限制，也受調度算法的影響.排隊時間可以通過好的調度算法進行優化.計算時間受到節點計算力的影響.因此，集群管理節點對于集群內數據流的調度不僅要考慮計算節點的計算負載，還要考慮計算節點的網絡負載.無論是網絡負載還是計算負載的過高，都會影響任務的完成時間.因此，本文對GPU計算節點的實時網絡負載和計算負載進行模型分析，為數據流的高效調度提供理論依據.相關符號在表1中進行了詳細的說明.

表1 符號描述Table 1 Symbol description

首先是對GPU計算節點的網絡負載建立數學模型.DPDK提供了最基本的網口參數如Nip-Gj-porti(網口接收數據包的總數)，Nib-Gj-porti(網口成功接收字節的總數)，Niep-Gj-porti(網口接收錯誤數據包的總數)，Nimp-Gj-porti(網口接收丟棄數據包的總數).通過公式(1)-公式(7)可以計算出Vib-Gj-porti(網口成功接收字節的速率)，Vieb-Gj-porti(網口接收錯誤字節的速率)，Vimb-Gj-porti(網口接收丟棄字節的速率).公式(8)為網口真實的字節接收速率(應該包括錯誤和丟棄的).通過公式(9)可以計算出該網口的實時負載率.為了防止信息采集時的突發干擾，本文采用平滑過渡方式對網口負載率進行修正，通過調整因子γ，通常取值為0.8，結合前次采集值與當前采集值進行一定比例的求和，計算出調整后的網口實時負載率，如公式(10).計算節點總的網絡負載由公式(11)計算得出，為后續節點是否進行遷移作參考.

(1)

(2)

(3)

(4)

(5)

(6)

(7)

(8)

(9)

(10)

(11)

公式(12)計算出單個網口的剩余帶寬，并通過公式(13)進行平滑調整，計算出調整后的剩余可用帶寬.公式(14)為計算節點的總的剩余帶寬，這將為后續的遷移節點選擇提供參考.

(12)

(13)

(14)

對GPU節點的計算負載建立數學模型.基于多任務并行計算時任務的響應時間為優化目標，以提升響應速度.公式(15)為整個集群內的數據流數量.通過公式(16)可以計算出計算節點上每條數據流占用的平均帶寬.數據流的單個任務計算耗時由公式(17)得出，并且由公式(18)可以計算出計算節點上所有數據流單個任務的計算耗時總和，再由公式(20)計算每條數據流單個任務的平均計算耗時.公式(19)作為計算節點所有數據流單個任務的最大計算耗時，一定程度上反應了計算節點的計算負載.由公式(22)和(23)，可以計算出計算節點的計算負載率.公式(21)計算出計算節點剩余可用的計算耗時，為后續的遷移節點選擇提供參考.

(15)

(16)

Tdelay-flowk-Gj(t)=Tend-flowk-Gj(t)-Tarrive-flowk-Gj(t)

(17)

(18)

Tdelay-MAX-Gj(t)=max{Tdelay-flowk-Gj(t)}，k=1，2，…，N-flow-Gj(t)

(19)

(20)

Tdelay-ava-Gj(t)=T-Tdelay-MAX-Gj(t)

(21)

Tdelay-Gj(t)=Tdelay-MAX-Gj(t)-T

(22)

(23)

公式(24)顯示出計算節點數據流遷移的情況.當計算節點網絡故障或者計算故障時，該節點上的數據流需要整體遷移到其他計算節點；當計算節點出現網絡超載或者計算超載時，需要將該節點上部分數據流遷移到其他節點上.無論是整體遷移還是部分遷移，都可以通過公式(25)計算出該節點待遷出數據流的數量.在遷入節點選擇時，還需要評估每個節點可接受的遷入數據流數量.公式(26)結合計算節點的網絡容量和計算容，選擇最小可接受遷入數據流的數量.

(24)

Nmigr-Gj(t)=

(25)

(26)

數據流遷移分為3個步驟:首先，計算出計算節點的待遷出數據流數量n，并從計算節點當前數據流集合中選出n條數據流組成待遷出數據流集合F；其次，計算出所有可遷入數據流的計算節點集合G，并根據其可用帶寬資源和可用計算資源進行降序排序；最后，依次遍歷可遷入計算節點集合G，根據其可接受數據流數量m(m<=n)，將F中的m條數據流遷入節點G[k]，一直到F中的數據流為空.在整過過程中，如果可遷入數據流的計算節點集合G為空，則說明集群中數據流以達到飽和狀態，需要提醒管理人員或者寫事件日志.在一輪數據流遷移后，待遷出數據流集合F不為空，也說明集群中數據流以達到飽和狀態，需要提醒管理人員或者寫事件日志.具體的遷移過程由算法1給出.

算法1.數據流遷移算法

Start

Step 1.get the set F of data flows to be migrated for node j

1)Get the number n of data flows to be migrated based on formula 26

2)Select F from the data flow set of node j

Step 2.get the set G of computing nodes that can be migrated into the data flows

1)Select the set M with bandwidth resources and computing resources that are not 0 from the set of computing nodes

2)Sort the nodes of set M in descending order by bandwidth resources and computing resources

3)Then get the set G

Step 3.Traverse the set G，and match the data flows

For：k = 0；k++；G[k]do

If：G[k] is nonethen

Alarm events and write logs

If：F is nonethen

Allocation is complete，and end

Else：

Calculate the number m of data streams that G[k] can migrate by formula 27

Endif

Endfor

If：F is not nonethen

Alarm events and write logs

Endif

Perform data flow migration according to the correspondence between G[k] and m

End

5 實 驗

5.1 實驗環境

為了驗證本文方案的性能，本文使用10臺主機搭建邊緣集群，其中3臺作為接入節點，剩余6臺作為計算節點，1臺作為管理節點.每個節點配置詳細信息如表2所示，計算節點配置了GTX970或者GTX1080顯卡.每臺服務器Hug Page 為8G，rx和tx各1個，且大小為1024，CPU核心占用5個.

表2 主機配置信息Table 2 Host configuration information

5.2 評估指標

為了對本文模型進行性能評估，提出了多個指標，如數據流容量，消息丟棄率，任務延遲率和任務丟棄率.

數據流容量FN是指集群可以穩定接入的數據流數量.

FN=N-flow-G

(27)

消息丟棄率MAR是指在周期T內因網絡傳輸而丟棄消息的數量占消息總數量的比例，能夠反映網絡性能.

(28)

任務延遲率TDR是指任務計算的延時與周期T之比，能夠反映任務計算的延遲程度.

(29)

任務丟棄率TAR是指排隊任務因超時未計算而放棄的任務數量與排隊任務的總數量之比.

(30)

5.3 實驗分析

本文將所提出的雙平面架構應用于社區養老視頻監控系統.首先終端設備如樹莓派等對采集到的視頻圖像進行人體輪廓粗略檢測；將檢測到的人體輪廓區域中人體特殊部位進行模糊處理以保護隱私；將模糊處理后的人體輪廓區域的圖像進行OpenPose人體姿態檢測的部分計算；將中間計算結果封裝為單個消息，發送到邊緣集群進行后續人體姿態檢測與狀態識別.其中，消息大小為1MB，消息切片大小為750B.

圖6 節點單張千兆網口的MARFig.6 MAR of a Gigabit NIC for node

首先對調度模型的網絡傳輸性能進行測試.該實驗測試傳統單平面模型和本文雙平面模型在網絡傳輸方面的性能.在一對一模式下，1臺接入節點和1臺計算節點(各配1張千兆網卡，消息到達計算節點不進行計算)，發送不同數量的數據流消息FN，記錄MAR隨FN的變化值.從圖6中可以看出，本文的網絡方案比傳統方案能夠在無消息丟失的情況下提升約30%的數據流容量，這歸功于前者數據傳輸基于DPDK的快速包處理和轉發技術.

圖7 集群單張千兆網口的MARFig.7 MAR of a Gigabit NIC for cluster

對集群模式下的網絡性能進行對比，結果如圖7.3臺接入節點和6臺計算節點(各配一張千兆網卡，每個計算節點的數據流均勻分配，消息到達計算節點不進行計算)，發送不同數量的數據流消息FN，記錄MAR隨FN的變化值.同樣的，在集群模式下，本文的網絡方案比傳統方案能夠在無消息丟失的情況下提升約一倍的數據流容量.最后也發現，3臺接入節點比1臺接入節點的數據流容量多出3倍左右，說明集群數據流容量的大小與接入節點的數量有關.

在一對一模式下，數據平面使用多張網卡的網絡性能進行測試.1臺接入節點和1臺計算節點(各配5張千兆網卡，一張連接控制平面，4張連接數據平面，消息到達計算節點不進行計算)，發送不同數量的數據流消息FN，記錄MAR隨FN的變化值，如圖8所示.在數據流到達300以后開始出現消息丟失，相比圖6中的70以后出現消息丟失，翻了4倍左右，與網卡數量相同，說明集群數據流容量的大小與接入節點的數據平面網卡數量有關.

圖8 節點5張千兆網口的MARFig.8 MAR of five Gigabit NICs for node

在集群模式下，3臺接入節點和6臺計算節點(各配5張千兆網卡，1張連接控制平面，4張連接數據平面，每個計算節點的數據流均勻分配，消息到達計算節點不進行計算)，發送不同數量的數據流消息FN，記錄MAR隨FN的變化值，如圖9所示.集群的數據流容量達到了900而未出現消息丟失，可以從數據看出，集群的數據流容量與接入節點數量以及接入節點數據平面網卡數量有關，擴展集群數據流容量可以通過增加接入節點數量和接入節點數據平面網卡數量.

圖9 集群5張千兆網口的MARFig.9 MAR of five Gigabit NICs for cluster

最后，對所提出集群內數據流調度算法性能進行了測試.經過前期測試，GTX1080GP能夠達到每秒處理45數據流的數據，而GTX970GPU能夠達到每秒處理21數據流的數據.在一對一模式下，1臺接入節點和兩臺計算節點(各配一張千兆網卡，每個計算節點的數據流均勻分配，消息到達計算節點進行GPU計算，計算節點分別安裝GTX1080和GTX970)，發送不同數量的數據流消息FN，記錄和TDR，TAR隨FN的變化值.從圖10中可以看出，無調度模型的TDR和TAR在數據流數量到達40以后開始增長；有調度模型的TDR和TAR在數據流數量超過50以后開始增長.有調度模型相比于無調度模型將數據流容量提升了20%.相同情況下，無GPU計算時數據流容量超過70以后出現MAR，有GPU計算時數據流容量超過40以后出現MAR，可以看出GPU的處理能力也影響著數據流容量.

圖10 節點單張千兆網口的TDR，TARFig.10 TDR and TAR of a Gigabit NIC for node

圖11 集群5張千兆網口的TDR，TARFig.11 TDR and TAR of five Gigabit NICs for cluster

在集群模式下，3臺接入節點和6臺計算節點(各配5張千兆網卡，一張連接控制平面，4張連接數據平面，消息到達計算節點進行GPU計算，兩臺計算節點安裝GTX1080，4臺計算節點安裝GTX970，每個計算節點的數據流均勻分配)，發送不同數量的數據流消息FN，記錄和TDR，TAR隨FN的變化值.從圖11中可以看出，無調度模型的TDR和TAR在數據流數量到達140以后開始明顯增長；有調度模型的TDR和TAR在數據流數量超過160以后開始增長.有調度模型相比于無調度模型將數據流容量提升了15%.從數據也可以看出，集群GPU數量的增加能夠增大集群數據流容量.

6 總 結

在本文中提出一種針對邊緣計算場景下的AI數據流計算系統的雙平面架構.該架構分為控制平面和數據平面.控制平面負責集群管理和數據流調度等控制命令的傳輸，基于傳統TCP/IP網絡協議的LAN.數據平面負責AI數據流的傳輸，基于之前的研究，利用DPDK多網卡并行通信技術實現基于消息的傳輸協議.雙平面的架構能夠從物理線路上將集群控制和數據流命令與數據流數據分離，避免數據流數據擁塞時造成調度命令的傳輸延遲和丟棄，進而導致集群性能下降或者故障.在雙平面架構的基礎上，本文提出了兼顧計算節點網絡負載和計算負載的任務遷移調度模型.該模型旨在通過數據流調度，保證任務的完成時間和集群的穩定運行.實驗結果顯示，本文提出的雙平面架構傳輸方案能夠增加集群數據流容量30%而不丟消息；雙平面架構調度模型能夠增加集群數據流容量15%而不出現任務丟棄.

本文接下來的研究工作將集中于擴展基于消息的傳輸協議和調度模型優化.作為AI計算的中間數據，AI數據流可能是多維的，因此擴展該協議使其更具普適性非常有意義.調度模型優化的方向應該考慮到集群能耗以及GPU計算能耗等因素.