1.1、機器學習（ML）在應用場景中遇到了什麼問題？近年來，機器學習（Machine Learning，ML）在影像識別、文字和語音處理等領域中廣泛應用，改變了人們工作、生活的方式，帶來了巨大的便利性。但同時，ML 使用者也面臨著幾個巨大的挑戰，這些挑戰極大地阻礙了 ML 的生產力和效率。首先，使用者通常需要手動配置許多系統級引數，例如工作伺服器 / 引數伺服器的數量、記憶體分配、cpu 數量、物理拓撲等。其次，使用者需要指定大量與 ML 相關的引數，如學習率、學習演算法、神經網路結構等，這些引數與系統級引數之間還存在各種互動作用。第三，ML 工作流通常由多個階段組成，包括預處理、訓練、超引數搜尋等等，每個階段都有 ML 使用者必須考慮的不同計算需求。由於 ML 的這些特點，在實際應用中經常會導致兩個問題：一是，ML 工作流中不同任務的異構性導致了訓練工作流執行過程中資源的嚴重不平衡。ML 使用者需要單獨考慮每個階段的異構資源需求，常常會導致資源過度配置（Resource Overprovisioning）。當前的 ML 框架通常是基於粗粒度的 VM 叢集的，而這些叢集並不具備 ML 相關工作負載所需的靈活性。CPU 總利用率低至 20% 的情況並不少見[1]。在實踐中，開發人員在工作流的不同階段反覆使用不同的 ML 引數進行實驗會進一步加劇資源過度配置的問題；
二是，ML 使用者需要應對複雜的管理問題，他們面臨著為每個 ML 工作負載提供、配置和管理這些資源的挑戰。利用 VMs 進行機器學習工作負載的系統通常需要使用者重複執行一系列繁重的任務，表 1 中展示了一些任務。這種管理複雜性阻礙了互動和迭代用例，降低了使用者生產力和模型的有效性。
在實踐中，過度資源調配和顯式資源管理負擔這兩個問題是緊密耦合的：ML 使用者在遇到工作流不同階段所需資源精確分配所帶來的難度和人工成本的問題時，通常會採用過度資源調配的方式來應對。那究竟用什麼辦法應對 ML 在實踐中應用的這些問題呢？在這篇文章中我們一起來探討一個目前廣泛應用且獲得了非常好效果的辦法：無伺服器計算（Serverless Computing）。表 1. ML 使用者在使用 VM 叢集時遇到的任務挑戰。
1.2、無伺服器計算（Serverless Computing）無伺服器計算是雲原生計算模型的一種落地狀態。雲端計算的發展在經歷了基礎設施即服務（Infrastructure as a Service－IaaS）、平臺即服務（Platform as a Service－PaaS）、軟體即服務（Software as a Service－SaaS）幾個階段後，逐漸進入了無伺服器計算的階段。從與之前幾個階段所能提供的服務進行比較的角度分析，無伺服器計算可以提供以下一種或兩種服務：1. 函式即服務 (Functions-as-a-Service－FaaS）。開發人員使用由事件(event) 或 HTTP 請求觸發的函式執行和管理應用程式程式碼，開發人員將這些小的程式碼單元部署到 FaaS 中，FaaS 按需執行和擴充套件，開發人員則無需管理伺服器或任何其他底層基礎設施。
2. 後端即服務(Backend-as-a-Service－BaaS）。提供第三方的基於 API 的服務用於替換應用程式中的核心功能子集。對於開發人員來說，這些 API 是作為一個自動擴縮容和透明操作的服務提供的，所以對於開發人員來說，這種服務方式也是無伺服器的。
從技術實現的角度分析，無伺服器計算依靠雲基礎設施而不是使用者來自動解決資源調配和管理的挑戰。這種方法依賴於一個更受限制的計算單元，例如 AWS Lambda 的無狀態 Lambda 函式（the Stateless Lambda Function），該計算單元由開發人員提交，並由雲基礎設施安排執行。因此，使用者無需手動配置、部署和管理長期計算單元（例如 VM）。無伺服器模式的優勢促進了資料中心、雲提供商和開放原始碼平臺的快速應用。無伺服器計算所提供的服務包括：一種有時間限制的無狀態函式作為執行程式邏輯的服務 API，以及，一種管理程式狀態的物件儲存系統。透過使用服務 API，使用者可以執行程式碼函式 (也稱為操作) 並返回每個函式的結果。無伺服器計算還提供 HTTPS 終端，允許開發人員檢索函式結果，開發人員可以透過 HTTPS 終端輸入引數後生成相關函式的觸發事件(或連結)。對於能夠清晰地分離程式狀態和邏輯的應用程式設計人員來說，無伺服器計算平臺提供了對大型計算能力的即時訪問，使得程式設計人員無需進行復雜的叢集部署。在無伺服器計算平臺中，雲服務提供商提供了按需執行函式的能力，並對終端使用者隱藏了叢集配置和管理開銷。除了可用性方面的好處外，這種模式還提高了效率：雲提供商可以以比傳統叢集計算更精細的粒度複用資源，並且使用者不需要為空閒資源付費。然而，為了有效地管理資源，雲服務提供商對每種資源的使用進行了限制。計算（computation）。無伺服器計算平臺中提供的計算資源通常僅限於一個 CPU 核和一個較短的計算視窗。例如，AWS Lambda 在單個 AVX 核心上提供 900 秒的計算時間，可以訪問高達 3GB 的記憶體和 512MB 的磁碟儲存。使用者可以執行許多並行函式，並且這些執行的聚合計算效能幾乎呈線性擴充套件。函式執行中的線性可伸縮性只在單個 worker 之間沒有通訊的情況下對平行計算有用。在實際應用中，由於單個 worker 只是瞬時存在的，他們的啟動時間可能是錯開的，因此傳統的類似 MPI 的點對點通訊模型無法在這種環境中工作。我們可以考慮利用儲存作為 worker 之間的間接通訊通道。
儲存（Storage）。雲服務提供商提供了多種儲存選項，從鍵值儲存到關係型資料庫。有些服務不完全是彈性的，因為它們需要預先提供資源。然而，像 Amazon S3 或 Google Cloud Storage 這樣的分散式物件儲存系統提供了無限儲存，使用者只需按儲存的資料量付費。我們可以考慮潛在地將計算期間的中間狀態儲存在分散式物件儲存中，並且仍然可以獲得與從其他節點的 RAM 訪問時相同的頻寬。
控制面（Control Plane）。除了儲存服務，雲服務提供商還提供釋出 - 訂閱服務，如 Amazon SQS 或 Google Task Queue。這些服務通常不支援高資料訪問頻寬，但提供一致性保證，如至少一次傳遞，並且可以用於 “控制平面” 狀態：所有無伺服器函式呼叫之間共享的任務佇列。雲服務提供商還提供一致的鍵值儲存（例如 DynamoDB），可用於跨無伺服器函式呼叫儲存和操作控制平面狀態。
由於無伺服器計算存在上述約束條件，在實際應用中，無伺服器計算也不是 “完美無缺” 的，應用無伺服器計算也面臨很多問題。以 AWS Lambda 為例，利用無伺服器計算的主要挑戰是與 Lambda 函式相關聯的非常小的本地資源約束（記憶體、cpu、儲存、網路），這是無伺服器計算的基礎，正因為這些細粒度的計算單元實現了可伸縮性和靈活性。具體的，無伺服器計算面臨著如下問題：本地記憶體和儲存空間小（Small local memory and storage）。由於存在計算資源限制，阻止了使用任何未使用這些資源設計的計算框架。例如，我們無法在 AWS Lambda 或具有此類資源受限配置的 VM 上執行 Tensorflow 或 Spark。
低頻寬以及缺乏 P2P 通訊（Low bandwidth and lack of P2P communication）。與常規 VM 相比，Lambda 函式的可用頻寬有限。我們發現，最大的 AWS Lambda 只能維持 60MB/s 的頻寬，即使在中型 VM 中，也遠遠低於 1GB/s 的可用頻寬。此外，無伺服器計算對通訊拓撲施加了進一步的限制。諸如 AWS Lambda 之類的無伺服器計算單元不允許對等通訊。因此，傳統的用於資料中心 ML 的通用通訊策略，例如樹結構或環結構 AllReduce 通訊等等，在這樣的環境中都無法有效實現。
短暫且不可預測的載入時間（Short-lived and unpredictable launch times）。Lambda 函式的壽命很短，且啟動時間非常多變。例如，AWS Lambda 在載入後可能需要幾分鐘的時間來啟動。這意味著在訓練過程中，Lambda 會在不可預知的時間開始，並且有可能在訓練中途結束。這就要求 Lambda 的 ML 執行時能夠容忍 worker 的頻繁離開和到達。
缺乏快速共享儲存（Lack of fast shared storage）。因為 Lambda 函式之間不能連線，所以需要使用共享儲存。由於 ML 演算法有嚴格的效能要求，這種共享儲存需要低延遲、高吞吐量，並針對 ML 工作負載中的通訊型別進行最佳化。然而，到目前為止，還沒有能夠為雲提供所有這些屬性的快速無伺服器儲存。
不過，目前已經有不少無伺服器計算的落地應用案例。其中，有代表性的公有云無伺服器平臺有：AWS Lambda。亞馬遜的 AWS Lambda，藉助 Lambda，幾乎可以為任何型別的應用程式或後端服務執行程式碼，而且完全無需管理。只需上傳程式碼，Lambda 會處理執行和擴充套件高可用性程式碼所需的一切工作。開發人員可以將程式碼設定為自動從其他 AWS 服務觸發，或者直接從任何 Web 或移動應用程式呼叫。https://aws.amazon.com/cn/lambda/。
Microsoft Azure Functions。微軟的 Azure 是一個事件驅動（Event-drive）的無伺服器計算平臺，可以解決複雜的編排問題。本地構建和除錯，無需額外設定，在雲中大規模部署和操作，並使用觸發器和繫結整合服務。https://azure.microsoft.com/en-us/services/functions/。
Google Cloud Functions。Google 的 Cloud Functions 是一種事件驅動的計算服務。它具有自動擴充套件、執行程式碼以響應事件的能力，僅在程式碼執行時付費的能力，並且不需要任何伺服器管理。用例包括無伺服器應用程式後端，實時資料處理和智慧應用程式，如虛擬助手，聊天機器人和情緒分析。https://cloud.google.com/functions/
阿里雲函式計算（Function Compute）。阿里的函式計算是一個事件驅動的全託管無伺服器計算服務，無需管理伺服器等基礎設施，只需編寫程式碼並上傳，函式計算會準備好計算資源，並以彈性、可靠的方式執行程式碼。所有客戶，函式計算都將提供每月 100 萬次函式呼叫、400,000 個函式例項資源的免費無伺服器算力支援。https://www.aliyun.com/product/fc?spm=5176.10695662.1112509.1.3b6768bc2OOWFL。
Fission 。Fission 使用 Kubernetes 構建函式。它允許程式設計師使用任何程式語言編寫函式，並將其與任何事件觸發器 (如 HTTP 請求) 進行對映。https://fission.io/。
Funktion 。Funktion 是一個開源的容器本地化伺服器平臺，使用 Kubernetes 構建函式。它允許程式設計師用任何程式語言編寫函式，可以在任何地方、任何雲上或在本地執行。https://github.com/funktionio/funktion。
Kubeless 。是一個 kubernets 原生的無伺服器計算框架。它利用 Kubernetes 資源提供自動縮放、API 路由、監控、故障恢復等功能。https://github.com/kubeless/kubeless。
Apache OpenWhisk 。OpenWhisk 使用 Docker 構建函式，它允許程式設計師使用 Scala 語言編寫函式，允許在任何規模的事件響應中執行程式碼。框架響應類似 HTTP 請求這樣的觸發事件，然後執行 JavaScript 或 Swift 程式碼片段。https://openwhisk.apache.org/。
Iron Functions 。Iron 使用 Docker、Swarm、Kubernetes 構建函式，它允許程式設計師使用 Go 語言編寫函式。https://github.com/iron-io/functions。
OpenLambda。OpenLambda 是一個 Apache 許可的無伺服器計算專案，用 Go 編寫，基於 Linux 容器。OpenLambda 的主要目標是探索無伺服器計算的新方法。https://github.com/open-lambda/open-lambda。
OpenFaas 。OpenFaaS 是一個使用 Docker 構建無伺服器 (Serverless) 功能的框架，它擁有對指標的一級支援。任何流程都可以打包為一個函式，使你能夠使用一系列 web 事件，而無需重複的樣板化編碼。https://www.oschina.net/p/openfaas?hmsr=aladdin1e1。
Zappa（Python，AWS）。Zappa 極大的簡化了在 AWS Lambda + API 閘道器上釋出所有 Python WSGI 應用。相當於是無伺服器的部署執行 Python Web 應用。這意味著無限伸縮、零當機、零維護。https://www.oschina.net/p/python-zappa。
Chalice（Python，AWS）。Chalice 允許開發者快速建立和部署應用，採用 Amazon API 閘道器和 AWS Lambda 。https://www.oschina.net/p/chalice?hmsr=aladdin1e1。
Claudia.js（Node，AWS）。方便快速部署 Node.js 專案到 AWS Lambda 和 API 閘道器。它自動化了所有容易出錯的部署和配置任務，並按照 JavaScript 開發人員所期望的開箱即用的方式設定了一切。開發人員可以輕鬆地開始使用 Lambda 和 API 閘道器，並專注於解決重要的業務問題，而不是處理 AWS 部署工作流。https://github.com/claudiajs/claudia。
由上一節的介紹我們知道，目前已經有很多公有云、私有云無伺服器計算平臺，也有一些無伺服器平臺的包裝框架。可以說，我們想在日常的應用實踐中嘗試無伺服器化，已經是比較容易的一件事了。不過，具體到機器學習的問題，這些無伺服器計算平臺在 ML 應用場景下都或多或少存在一些問題。由第一章中的介紹我們可以看到，無伺服器計算非常適用於離散化資料中心（Disaggregated Datacenters），但對許多效能關鍵型應用（Performance critical applications）卻不是非常適用，因為無伺服器計算方式切斷了傳統的效能最佳化途徑，例如利用資料區域性性進行最佳化或分層通訊等，因此會直接影響效能關鍵型應用的效果。目前無伺服器平臺主要用於簡單的事件驅動應用程式，如物聯網自動化、前端 web 服務和日誌處理等等。最近，一些研究人員將無伺服器計算應用在更廣泛的場景中，如並行資料分析和分散式影片編碼。然而，這些工作負載要麼只能簡單並行，要麼只能跨函式使用簡單的通訊模式。複雜的通訊模式和工作負載如何有效地適應無伺服器計算仍然是一個有待研究的問題。我們這篇文章中重點關注的是用於 ML 的無伺服器計算。我們知道，ML 包含大量的引數、複雜的處理流程，是典型的 “效能關鍵型應用”，我們將在這一節中介紹最新的關於“如何將 ML 引入無伺服器計算” 這一問題的研究進展。2.1、A Case for Serverless Machine Learning [2]
本文是來自 Berkeley 的研究人員發表在 NIPS2018 中的一篇文章，具體分析了 ML 工作負載環境下的資源管理問題，探討了利用無伺服器基礎設施實現 ML 工作流資源管理自動化的研究方向。作者提出了一個無伺服器機器學習框架，該框架專門用於無伺服器基礎設施和 ML 工作流。本文所討論的無伺服器計算依賴於 Amazon S3 的無狀態 Lambda 函式，這些函式由開發人員提交，並由雲基礎設施自動排程。因此，它們避免了開發人員顯式配置、部署和管理長期計算單元（例如 VM）的需要。與一般的無伺服器計算平臺不同，無伺服器機器學習框架需要滿足三個關鍵目標。首先，它的 API 需要支援廣泛的 ML 任務：資料預處理、訓練和超引數最佳化。為了簡化從現有 ML 系統的轉換所涉及的工作量，應該用 Python 之類的高階語言開發這樣的 API。第二，為了為無狀態工作者之間的中間資料和訊息傳遞提供儲存，它需要提供一個具有豐富介面的低延遲可伸縮資料儲存。第三，要在資源受限的 Lambda 上高效執行，它的 Runtime 必須是輕量級和高效能的。為了滿足這些條件，作者構建了一個專門用於 ML 的無伺服器框架。首先，該框架為 ML 工作流的所有階段提供了一個 API，該 API 實用且易於更廣泛的 ML 社群使用。（1）API 完全包含在 Python 包中，允許 ML 開發人員輕鬆呼叫。（2) API 提供了一個抽象底層系統級資源的高階介面。（3) Python 包提供了一個使用者介面，開發人員可以透過該介面視覺化工作進度。
然後，該框架包含 Python 前端提供到客戶端後端的介面。這個後端負責管理臨時計算資源和排程任務。在這個後端中，不同的子模組為 ML 工作流的每個特定階段的邏輯（例如預處理）進行編碼處理。這些子模組啟動 Lambda 上的 worker，跟蹤計算進度，並在計算完成後將結果返回到 Python 前端。客戶端後端使用內部低階排程程式，該排程程式封裝了與啟動、終止和重新生成在無伺服器 Lambda 上執行的任務相關的所有邏輯。這個排程程式還跟蹤所有任務的狀態。
第三，該框架提供一個輕量級 Runtime，它封裝了系統支援的不同計算之間共享的所有函式，從而簡化了新演算法的開發。Worker runtime 提供兩個介面。首先，它提供了一個智慧迭代器來訓練儲存在 S3 中的資料集。這個迭代器在 Lambda 的本地記憶體中預取和緩衝 mini-batch，與 worker 的計算並行，以減輕訪問 S3 的高延遲（>10ms）。它為分散式資料儲存提供了一個 API。
最後，該框架為 workers 之間的中間資料和通訊提供具有豐富介面的共享儲存。此介面有兩種型別的 API：（1）用於一般訊息傳遞、中間資料儲存和資料縮減的鍵值儲存，以及（2）引數伺服器介面。為了達到所需的低延遲，將該資料儲存部署在雲 VMs 上。為了有效地利用稀缺的網路資源，對資料儲存介面進行最佳化處理，例如：資料壓縮、稀疏資料結構、非同步通訊等。
為了實現簡化機器學習工作流執行的目標，理想的系統應該提供一個簡單但足夠通用的 API。這個 API 需要讓使用者在一個單一的、整合的框架內執行 ML 任務，例如：（1）資料集載入，支援常用的資料格式，（2）資料預處理，（3）模型訓練，（4）大規模的超引數調整。作者給出了一個例子來展示這個 API 的功能——圖 1 中給出基於 Criteo Kaggle 競爭開發模型的過程，該模型用於預測使用者點選顯示廣告資料集的廣告的機率。工作流的第一步是載入資料集並將其上載到 Amazon S3。例如，使用者可以呼叫 load_libsvm 方法來載入以 LIBSVM 格式儲存的資料集，解析資料後自動為其建立分割槽，然後將其上載到 Amazon S3。第二步，一旦資料載入到 Amazon S3 中，就可以立即進行預處理。系統應該提供一些開發人員常用的預處理方法。例如，使用者可以透過使用 Amazon S3 中資料集的路徑呼叫 normalize 函式來規範化資料集。一旦載入了資料，使用者就可以透過檢視系統的測試損失來訓練不同的模型並檢視它們的效能。一旦使用者對某個特定的模型獲得了合理的損失，他們就可以透過超引數搜尋對其進行微調。此外，作者設想這樣一個系統允許使用者在每個階段的執行過程中進行多次互動。例如，當超引數搜尋任務正在執行時，使用者應該能夠監視每個單獨實驗的測試損失。對於表現不好的實驗（例如，測試損失發散（test loss is diverging）)，使用者應該能夠終止它們。這個特性可以透過互動環境（比如 Jupyter）中的使用者介面來實現。
圖 1. API 示例。無伺服器 ML 的 API 應該支援 ML 開發工作流的不同階段：（a）預處理，（b）訓練，和（c）超引數調優。為了評估對 ML 無伺服器框架的需求，作者引入兩個框架進行效能比對：PyWren[3]和 Bosen[4]。PyWren 是一個專門用於無伺服器架構的 Map-reduce 框架。PyWren 提供了可縮放到數千個 workers 的 map 和 reduce 原語。Bosen 是一個分佈引數框架，專門用於基於 VM 的 ML 演算法。為了進行評估，作者在 PyWren 上實現了一個非同步 SGD 訓練演算法。在 PyWren 基線實現的基礎上，作者還進行了一組最佳化。作者使用了來自 Criteo Kaggle 競賽的 Criteo 展示廣告資料集進行實驗。作者在 10 個最大的 AWS Lambda（3GB 記憶體）上執行 PyWren，在單個 VM（m5.2xlarge1）中的 8 個核心上執行 Bosen。作者透過記錄隨時間變化的測試損失來測量這兩個系統的效能（圖 2）。對於 PyWren，作者在實現每個最佳化之後報告這個值。作者累計實現了以下最佳化：（1）跨迭代重用 Lambda；（2）使用非同步 SGD 進行小批次預取；（3）使用低延遲儲存（Redis）代替 Amazon S3；（4）使用具有多 get 操作的稀疏資料傳輸。我們觀察到這些最佳化顯著改善了 Pyren 在 600 秒後實現的最終測試損失（從 0.61 到 0.57）。儘管有了這些改進，PyWren 仍然比 Bosen 慢得多。進一步的效能分析表明，PyWren 存在一些開銷，例如序列化 / 反序列化資料，以及使用介面不適合 ML 工作負載的遠端儲存（例如 Redis 或 S3）。這一結果表明，在設計無伺服器計算框架的早期，需要仔細考慮 ML 工作負載的效能需求。
圖 2. PyWren 和 Bosen 在 Criteo-Kaggle 邏輯迴歸任務中的表現。PyWren 基線透過重用 Lambda、新增預取、切換到非同步計算、用更高效能的 Redis 儲存後端替換 S3 以及支援在單個 RPC 上獲取多個金鑰而得到了增量改進。此外，作者還構建了本文所提出的框架的原型，包括：（1）具有引數伺服器介面的高效能資料儲存，（2）mini-batch 資料的迴圈緩衝區預取，（3）邏輯迴歸 SGD 訓練演算法。為了充分驗證這種設計的好處，作者在相同的邏輯迴歸任務中對其進行了評估。作者測量了每個 worker 的平均 SGD 迭代時間（見圖 3）。這個時間是 worker 效能的一個指標；較低的迭代時間意味著更頻繁的模型更新和更快的收斂。作者還將這一次的 SGD 演算法分解為四個主要步驟：（1）從資料儲存中獲取最新模型，（2）從遠端儲存（例如 S3）中獲取一個 minibatch，（3）計算 SGD 梯度，以及（4）將梯度傳送到資料儲存。作者發現，儘管無伺服器計算具有固有的開銷，本文所提出的框架原型還是實現了較低的每次迭代時間（ 500 μs）--- 與 Bosen 這樣的系統不相上下。這種效能源於兩種機制：（1）遠端 mini-batch 的有效預取和緩衝，以及（2）儘可能與資料儲存通訊。首先，minibatch 預取機制透過與計算並行進行，有效地掩蓋了從 S3 獲取 minibatch 所需的時間。實際上，對於中型 / 大型 Lambda，在新的 minibatch 上開始計算所需的時間可以忽略不計，因為大多數情況下，這些資料都是在 worker 需要之前快取在記憶體中的。即使從 S3 獲取一個 mini-batch 需要 10ms 也是這樣的。其次，作者發現與資料儲存的通訊是有效的（例如，傳送梯度的時間可以忽略不計）。由於能夠與資料儲存非同步通訊，進一步提升了該框架的效能。
圖 3. 本文所提出原型每次 SGD 迭代的時間。具體細分為四個主要步驟：（1）將梯度傳送到資料儲存，（2）計算梯度，（3）從資料儲存獲取模型，（4）從 S3 獲取 minibatch。2.2、Cirrus: a Serverless Framework for End-to-end ML Workflows [5]這篇文章也是節 2.1 中所介紹的 Berkeley 研究小組的研究成果，是對節 2.1 中分析的 NIPS’18 中文章所涉及工作的擴充套件和延伸。在專門用於無伺服器基礎設施和 ML 工作流的無伺服器 ML 框架原型的基礎上，將其封裝為一個實現端到端管理的分散式 ML 訓練框架 Cirrus，可以直接呼叫使用（https://github.com/ucbrise/cirrus），並將相關工作內容發表在發表在 SoCC ’19 中。Cirrus 專門用於無伺服器雲基礎設施（如 Amazon AWS Lambda）中的 ML 訓練。它提供高階原語來支援 ML 工作流中的一系列任務：資料集預處理、訓練和超引數最佳化。Cirrus 結合了無伺服器介面的簡單性和無伺服器基礎設施（具體是指 AWS Lambda 和 S3）的可伸縮性，以最小化使用者的工作。自適應的細粒度資源分配。為了避免由於過度配置而造成的資源浪費，Cirrus 應該靈活地調整為每個工作流階段保留的細粒度資源量。
無狀態伺服器端後端。為了確保無伺服器計算資源的健壯和高效管理，Cirrus 設計了一個無狀態的伺服器端後端。有關當前部署的函式以及 ML 工作流任務和計算單元之間的對映的資訊由客戶端後端管理。因此，即使所有云端資源變得不可用，ML 訓練工作流也不會失敗，並且可以在資源再次可用時恢復其操作。
端到端無伺服器 API。模型訓練不是 ML 研究人員的唯一任務，資料集預處理、特徵工程和引數調整等對於最終生成一個好的模型同樣重要。Cirrus 應該提供一個完整的 API，允許開發人員以最小的工作量端到端的大規模地執行這些任務。
高可擴充套件性。ML 任務是高度計算密集型的，在沒有有效並行化的情況下需要很長時間才能完成。因此，Cirrus 應該能夠同時執行數千個 workers 和數百個實驗。
與節 2.1 中所介紹的工作類似，Cirrus 利用四個系統模組來實現上述原則。首先，Cirrus 為 ML 開發人員提供了 Python 前端。這個前端有兩個功能：a）為 ML 訓練的所有階段提供豐富的 API；b）在無伺服器的基礎設施中執行和管理大規模計算。其次，Cirrus 提供了一個客戶端後端。第三，為了克服低延遲無伺服器儲存的不足，Cirrus 為 worker 共享的所有中間資料提供了低延遲分散式資料儲存。第四，Cirrus 提供了一個在無伺服器 Lambda 上執行的 worker 執行時（runtime）。該執行時提供了訪問 S3 中的訓練資料集和分散式資料儲存中的中間資料的有效介面。Cirrus 的完整結構見圖 4。
圖 4. Cirrus 系統結構。系統由（有狀態的）客戶端（左）和（無狀態的）伺服器端（右）組成。預處理和麵向使用者的訓練包含一個前端的 API。客戶端後端管理雲功能和向函式分配任務。伺服器端由 Lambda Worker 和高效能資料儲存元件組成。Lambda worker 將資料迭代器 API 匯出到客戶端後端，幷包含許多迭代訓練演算法的有效實現。資料儲存用於儲存梯度、模型和中間預處理結果。Cirrus 的整體結構與節 2.1 中是類似的。Cirrus 的前端和客戶端後端是用 Python 實現的，方便 Cirrus 與現有的機器學習方法相結合。為了提高效率，分散式資料儲存和 worker runtime 用 C++ 實現。表 2 列出了實現的不同元件以及它們的大小和實現語言。Worker runtime 程式碼包括迭代器介面和資料儲存客戶端實現。worker runtime 和資料儲存透過 TCP 連線進行通訊。作者實現了一個共享元件庫，其中包括線性代數庫、通用實用程式和 ML 演算法，這些元件被所有系統元件共享。作者已經公開發布了 Apache 2 開源許可的實現（https://github.com/ucbrise/cirrus）。
首先，Cirrus 為 ML 工作流的所有階段提供了一個 Python 前端 API。前端是一個高度靈活的 thin Python API，預設情況下，它從開發人員那裡抽象出所有的細節，同時提供了透過 API 的引數覆蓋內部配置引數（例如，最佳化演算法）的能力。前端還提供了一個執行在 Plotly 上的使用者介面，供使用者監控工作負載的進度和啟動 / 停止任務。Cirrus Python API 分為三個子模組。每個子模組都打包了與工作流的每個階段相關的所有函式和類。（1）預處理。預處理子模組允許使用者對儲存在 S3 中的訓練資料集進行預處理。此子模組允許不同型別的資料集轉換：最小 - 最大縮放、標準化和特徵雜湊。（2）訓練。Cirrus 的訓練子模組支援 ML 模型，這些模型可以透過隨機梯度下降進行訓練。目前 Cirrus 支援稀疏 Logistic 迴歸、潛在 Dirichlet 分配、Softmax 和協同過濾。（3）超引數最佳化。超引數最佳化子模組允許使用者在給定的引數集上執行網格搜尋。Cirrus 允許使用者改變 ML 訓練引數（例如，學習率、正則化率、小批次大小）以及系統引數（例如，Lambda 函式大小、併發 worker 數量、梯度過濾）。其次，Cirrus 的 Python 前端提供了一個到 Cirrus 客戶端後端的介面。這個後端的功能和能夠完成的任務與節 2.1 中介紹的框架完全相同。客戶端後端從前端演算法中抽象出 Lambda 的管理。客戶端後臺會儲存一個當前活動的 Lambda 列表，以及一個 AWS Lambda API 的連線列表（每個連線用於啟動一個 Lambda）。在訓練期間載入的 Lambda 在其生存期結束時自動重新載入（每 15 分鐘一次）。由於 Lambda API 的特殊性，從一臺伺服器上快速載入數百個 Lambda 是非常困難的。為了解決這個問題，後端保留一個執行緒池，可用於響應新 Lambda 任務的請求。第三，Cirrus 提供了分散式儲存模組。Cirrus 的資料儲存用於儲存所有 workers 共享的中間資料。由於現有產品中不允許 Lambda 之間進行互動通訊，因此 Lambda 需要共享儲存。無伺服器 Lambda 的儲存需要滿足三個條件：首先，它需要低延遲（本文實現低至 300μs），以便能夠適應延遲敏感的工作負載，例如用於 ML 訓練的工作負載（迭代 SGD）。其次，它需要擴充套件到數百個 workers，以利用無伺服器基礎架構幾乎線性的可擴充套件性。第三，它需要一個豐富的介面來支援不同的 ML 用例。例如，資料儲存必須支援 multiget（§6.5）、常規鍵 / 值的 put/get 操作和引數伺服器介面。為了實現低延遲，將資料儲存部署在雲 VMs 中。它實現了低至 300μs 的延遲，而 AWS S3 的延遲約為 10ms。此延遲對於訓練階段最大化模型的更新至關重要。作者使用稀疏表示來表徵梯度和模型以實現高達 100 倍的壓縮比，以便與儲存和批處理請求進行資料交換。為了實現高可伸縮性，Cirrus 包括以下機制：（1）分片儲存，（2）高度多執行緒，（3）資料壓縮，（4）梯度濾波器和（5）非同步通訊。Cirrus 的分散式資料儲存提供了一個介面，支援所有在 ML 工作流中儲存中間資料的用例。該介面支援鍵值儲存介面（set/get）和引數伺服器介面（send 果然啊 dient/get model）。最後，Cirrus 提供了一個執行時（Runtime），它封裝了系統支援的不同計算之間共享的所有函式。如圖 5，Cirrus 的 Runtime 為 ML 計算提供了通用抽象（General abstractions）和基本資料型別（Data primitives）用於訪問訓練資料、引數模型和中間結果。這些可用於向 Cirrus 新增新的 ML 模型。為了簡化新演算法的開發，Runtime 提供了一組線性代數庫。Cirrus 的初始版本使用外部線性代數庫如 Eigen 進行梯度計算。為了減少 Eigen 處理序列化和反序列化資料的時間，作者最終開發了自己的線性代數庫。對於資料訪問，Runtime 提供了一個由本地迴圈緩衝區支援的基於 minibatch 的迭代器，允許 worker 以低延遲訪問訓練 minibatch。此外，它還提供了一個高效的 API 來與分散式資料儲存進行通訊。
圖 5. Cirrus Runtime。minibatch 是非同步預取的，並在每個 Lambda 的記憶體中本地快取（取決於使用的 Lambda 的大小）。將梯度非同步傳送至引數伺服器，每次迭代模型同步從引數伺服器中進行檢索。作者給出了 Cirrus 在不同階段的詳細工作方式。（1）資料載入和預處理。Cirrus 假設訓練資料儲存在一個全域性儲存中，比如 S3。因此，使用 Cirrus 的第一步就是將資料集上傳到雲端。使用者將資料集的路徑傳遞給系統，然後由系統負責解析和上載資料集。在此過程中，Cirrus 將資料集從其原始格式（如 csv）轉換為二進位制格式。這種壓縮消除了在訓練和超引數調優階段進行反序列化的需要，這有助於減少 Lambda 工作程式中的計算負載。其次，Cirrus 生成資料集大小相似的分割槽，並將其上傳到 S3 儲存桶（S3 Bucket）。
Cirrus 還可以應用變換（Transformations）來提高模型的效能。例如，對於 Cirrus 實現的非同步 SGD 最佳化方法，對資料集中的特徵進行規範化處理能夠提高訓練的效果。對於這些 transformations，Cirrus 啟動了一個大型 Map Reduce 作業：每個輸入分割槽一個 worker。在 map 階段，每個 worker 計算其分割槽的統計資訊（例如，平均值和標準差）。在 reduce 階段，這些區域性統計資訊被聚合以計算全域性統計資訊。在最後的對映階段，worker 轉換每個分割槽樣本，給出最終的每列統計資訊。對於大型資料集，map 和 reduce 階段會跨大量 worker 和列來聚合每列的統計資訊。這會造成每秒生成大量新的寫操作和讀操作，而超出了 S3 支援的事務吞吐量。基於這個原因，作者使用 Cirrus 的低延遲分散式資料儲存來儲存對映的中間結果，並減少了計算量。
（2）模型訓練。Cirrus 使用分散式 SGD 演算法進行模型訓練。在訓練期間，worker 執行 Lambda 函式，並迭代計算梯度步長。每個梯度計算需要兩個輸入：一個 minibatch 和最新的模型。minibatch 是 Cirrus 的執行時透過迭代器從 S3 獲取的。因為迭代器在工作記憶體中緩衝 minibatch，所以檢索 minibatch 的延遲非常低。使用資料儲存 API(get_sparse_model_X)從資料儲存中同步檢索最新的模型。對於每個迭代，每個 worker 都計算一個新的梯度。然後將此梯度非同步傳送到資料儲存（send_gradient_X）以更新模型。
（3）超引數最佳化。超引數最佳化是一種模型引數的搜尋方式，該模型引數能夠保證生成最佳準確度。典型的做法是在多維引數空間上執行網格搜尋。搜尋可以是暴力破解（Brute-force）搜尋或自適應搜尋。常見的做法是讓網格搜尋完整地執行，然後對結果進行後處理，以找到最佳配置。這是一種代價高昂的資源浪費。Cirrus 透過提供超引數搜尋儀表板（Hyperparameter search dashboard），來解決這種超時過度配置問題（over-provisioning over time）。Cirrus 超引數儀表板提供了一個統一的介面，用於監控模型隨時間變化的損失收斂情況。它允許使用者選擇單個損失曲線並終止相應的訓練實驗。因此，Cirrus 提供了：啟動超引數搜尋的 API 和執行後端；監控模型精度收斂的儀表板；終止單個調優實驗的能力，並節省了過度配置成本。
在文獻 [2] 工作的基礎上，Cirrus 為 ML 使用者提供了一個輕量級的 Python API。作者同樣給出了一個例子來展示這個 API 的功能。如圖 6 所示，這個 API 與圖 1 中給出的文獻 [2] 中的 API 幾乎相同。區別在於本文已經將 Cirrus 封裝為模組“cirrus”，可直接在 python 中進行 import。
圖 6. Cirrus API 示例。Cirrus 支援 ML 開發工作流的不同階段：（a）預處理，（b）訓練，和（c）超引數調優。作者利用稀疏邏輯迴歸任務對比 Cirrus 和兩個專門用於基於 VM 的 ML 訓練框架：TensorFlow[6]和 Bosen[4]。TensorFlow 是一個用於 ML 計算的通用資料流引擎。Bosen 是一個分散式和多執行緒引數伺服器，由 CMU 開發 Petuum 商業化，它針對大規模分散式叢集和機器學習演算法的陳舊更新進行了最佳化。邏輯迴歸是計算任何給定樣本屬於兩個感興趣的類的機率問題。本文實驗中作者計算網站廣告被點選的機率，並利用時間函式評估學習收斂性。使用 Criteo 顯示廣告資料集[7]。這個資料集包含 45M 個樣本，大小為 11GB。每個樣本包含 13 個數字特徵和 26 個分類特徵。在訓練之前，對資料集進行了歸一化處理，將分類特徵雜湊為一個大小為 2^20 的稀疏向量。為了評估 Bosen，作者使用 1、2 和 4 個 m5.2xlarge 亞馬遜 AWS 例項（每個例項有 8 個 CPU 和 32GB 記憶體）。對於 Bosen 實驗，作者將資料集分割槽到所有機器上。為了評估 Cirrus，作者使用 Amazon AWS Lambda 作為 worker，m5.large 例項（2 個 CPU，8GB 記憶體，10Gbps 網路）作為引數伺服器，AWS S3 儲存用於訓練資料和定期備份型。作者報告了嘗試兩個系統的學習率範圍後得到的最佳結果。對於 Bosen，只改變學習率和工人數量。所有其他配置引數都保留預設值。圖 7a 顯示了不同數量的伺服器（對於 Bosen）和 AWS Lambda（對於 Cirrus）在一段時間內實現的邏輯測試損失。透過對一個包含 50K 樣本的資料集上的訓練模型評估以得到損失值。作者發現，Cirrus 的收斂速度明顯快於 Bosen。Bosen 的效能因為 worker 相互競爭共享本地快取受到影響，該快取在將梯度傳送到引數伺服器之前聚合梯度。這種設計最終導致了 Bosen 收斂速度較慢。在圖 7b 中，作者使用相同的資料集和相同的預處理步驟將 Cirrus 與 TensorFlow 進行了比較。同樣地，Cirrus 效能優於 TensorFlow。圖 7c 中的實驗對比的是 Cirrus 和 Spark 完成協同過濾任務的效能，該實驗中使用的是 Netflix 資料庫[8]。由圖 7c，Cirrus 比 Spark 收斂得更快，測試損耗更低。此外，作者還觀察到 Spark 的 ALS 實現受到昂貴的 RDD 開銷的影響，因為 Spark 需要將整個資料集載入到記憶體中。這導致 Spark 花了超過 94% 的時間來做與訓練模型不直接相關的工作。相比之下，Cirrus 從 S3 連續向 worker 流式傳輸資料，這使得他們可以立即開始計算。
圖 7. (a) Bosen 和 Cirrus 之間不同設定的時間損失比較。Bosen 達到的最佳損失為 0.485，Cirrus 達到最佳損失的速度至少快了 5 倍（200 秒 vs 1000 秒）。與最先進的 ML 訓練框架相比，Cirrus 可以在一個或兩個 Lambda 的壽命內（300-600 秒）更快地收斂，並且損失更低。(b) Tensorflow Criteo_tft 基準和 Cirrus 的收斂與時間曲線。Tensorflow 是在 32 核節點上執行的，Cirrus 在 10 個 Lambda 中執行。(c) 執行 Netflix 資料集時，Spark (ALS)和 Cirrus 的 RMSE 隨時間變化曲線。Spark 在執行 Netflix 資料集時，前 4 分鐘處理資料，並在 ALS 的 5 次迭代中收斂（RMSE=0.85）後終止。Cirrus 能夠更快收斂到較低的 RMSE（0.833）。圖 8 中的實驗驗證的是 Cirrus 的可擴充套件性（Scalability）。透過設計該系統以實現 3 個維度的擴充套件：用 S3 儲存訓練資料，用 Lambda 計算，以及用分散式引數伺服器共享記憶體，來實現擴充套件性。儲存擴充套件性：Cirrus 透過將 S3 中的訓練資料集分割成中等大小的物件來解決這個問題。作者使用 10MB 的物件，因為作者發現這個大小可以實現良好的網路利用率，同時對於最小尺寸的 Lambda 來說也足夠小。透過使用大型物件，減少了每秒的請求數量。因此，當每個 worker 從 S3 消耗 30MB/s 的訓練資料時，能夠將 S3 的吞吐量線性擴充套件到 1000 個 Cirrus workers（圖 8a）。計算擴充套件性：由圖 8b，沒有模型和引數的同步得情況下 Cirrus 可以透過並行傳輸輸入訓練資料和計算梯度來實現線性計算可伸縮性。引數伺服器擴充套件性：在引數伺服器層面，主要挑戰來自於每個虛擬機器 VM 有限的網路頻寬，以及更新模型和 worker 請求伺服器所需的計算。Cirrus 透過 1）模型分片，2）稀疏梯度 / 模型，3）資料壓縮，4）非同步通訊來解決這個問題。Cirrus 實現了線性可擴充套件性，最高可達 600 個 worker（圖 8c）。
圖 8. AWS 儲存（GB / 秒）、AWS 無伺服器計算（梯度 / 秒）和 Cirrus 資料儲存（樣本 / 秒）的可擴充套件性。每個 worker 消耗 30MB/s 的訓練資料。
最後，作者對比了專門的 ML 系統 PyWren 與 Cirrus。PyWren 是一個執行在無伺服器 Lambda 上的 map-reduce 框架。它提供了可擴充套件至數千名 worker 的 map 和 reduce 原語。PyWren 的 Runtime 經過最佳化可以在 AWS Lambda 上執行，AWS Lambda 也是本文用於 Cirrus 實驗的無伺服器平臺。作者在實驗中對 PyWren 進行了最佳化，使其每次模型更新的平均時間提高了 700 倍（從 14 秒到 0.02），但其模型每秒更新次數仍然遠低於 Cirrus（圖 9b），並且收斂速度明顯慢於 Cirrus（圖 9a）。
圖 9. PyWren 和 Cirrus 在 10 個 Lambda 上執行時在稀疏邏輯迴歸工作負載上的效能。由於結合了預取、在模型訓練迭代中重複使用 Lambda 以及透過 Cirrus 的快速資料儲存進行高效的模型共享，Cirrus 實現了 2 個數量級的模型更新數量增長。訓練資料預取解決了 S3 的高訪問延遲問題，從而使更新速度增加了 10 倍 / 秒。2.3、Distributed Machine Learning with a Serverless Architecture [9]本文作者介紹了一個完全基於無伺服器架構的分散式機器學習新框架：SIREN。SIREN 由本地客戶端和無伺服器雲平臺（例如 Amazon Lambda）組成，前者使用深度強化學習（Deep Reinforcement Learning，DRL）agent 進行資源排程決策，後者根據這些排程決策為 ML 訓練作業載入無狀態函式（Stateless Functions）。SIREN 的完整結構框架如圖 10。
首先，將一個程式碼包部署到無伺服器雲平臺中，其中包含使用者定義的 ML 模型及其所依賴的庫。然後，根據初始資源方案（即函式的數量和記憶體大小）載入無狀態函式群，進行基於 SGD 的第一個 epoch 訓練。在第一個 epoch 結束時，收集作業的函式狀態和統計資料，並以狀態（States）的形式反饋給本地客戶端的 DRL agent，DRL agent 將採取行動為下一個 epoch 做出資源排程決策。SIREN 會隨著訓練作業的 epoch 推進自適應調整資源排程決策：在不同的 epoch 中，可以啟動不同數量、不同記憶體配置的函式。SIREN 採用的是 SGD 演算法，使用 mini-batches 並在多個 Lambda 函式上執行。每個 Lambda 函式的作用就類似於傳統引數伺服器架構中的 worker。SIREN 與引數伺服器架構的一個主要區別是，在 SIREN 中不存在引數伺服器來處理模型引數更新。相反，資料和模型都儲存在一個共同的資料儲存中（例如 Amazon S3），所有函式都可以訪問。每個函式從公共儲存中讀取當前模型，根據 mini-batches 訓練資料計算梯度，然後直接用新計算的梯度更新公共儲存中的模型。因此，整個架構是無伺服器的。在 SIREN 中，作者提出了一種混合同步並行（Hybrid synchronous parallel，HSP）計算模式。如圖 11 所示，在每個 epoch 內，所有的函式都可以非同步更新模型，同時在每個 epoch 結束時施加一個同步屏障（Synchronization barrier），以便完成下一個 epoch 的資源排程。已知 epoch 為 t，第 k 個 mini-batch 為Ξ_t,k，更新模型為：
在 epoch t-1 結束時的模型ω與ω_t,0 相同。HSP 在無伺服器架構中是高效的，因為載入的函式是同質的，從而導致每個 epoch 的同步代價都很低。在無伺服器雲平臺中，呼叫和終止函式也是輕量級的。
圖 11. 無伺服器雲上的混合同步並行（HSP）處理。作者使用 Python 程式碼實現了 SIREN，支援 AWS Lambda 之上的 ML 模型訓練，並全面支援 MXNet APIs。機器學習開發人員可以在 SIREN 上執行他們的傳統 MXNet 專案，而無需重構現有程式碼。如圖 10 所示，SIREN 包括三個主要部分：(1)封裝 MXNet 機器學習庫的程式碼包；(2)用 AWS SDK boto3 構建本地客戶端，呼叫並管理 AWS Lambda 中的無狀態函式；(3)用 TensorFlow 實現 DRL agent，進行動態資源配置決策。此外，還對 AWS Lambda 進行了一系列約束，以保證無狀態函式的輕量級和可移植性。由於 AWS Lambda 的程式設計 runtime 不支援原生的 ML 訓練演算法，作者在程式碼包中引入了一部分 MXNet ML 庫。在 AWS Lambda 上，程式碼包大小限制為 250 MB，這使得直接將任何現成的 ML 庫（如 MXNet、TensorFlow）載入到 AWS Lambda 上都是不可行的。為了縮小 MXNet 程式碼包的大小，作者用不同的編譯選項組合重新編譯了 MXNet 原始碼，並排除了無伺服器雲中不必要的編譯選項。例如，禁用了 USE_CUDA、USE_CUDNN 和 USE_OPENMP 等選項。在 AWS Lambda 上，單個函式的計算能力也受到限制：要求每個 Lambda 函式最多在 300 秒內執行完畢，最大記憶體大小為 3GB。但是，由於 AWS Lambda 支援每個 AWS 賬戶中多達 3000 個函式併發執行，因此 SIREN 透過使用大量 Lambda 函式並行化 ML 訓練工作負載實現了高度的並行性。作者提出了一種深度強化學習（Deep reinforcement learning，DRL）技術，用於完成 SIREN 中的動態資源部署。強化學習 (RL) 是一種經驗驅動的方法，agent 透過與動態環境的互動以及執行行動獲得獎勵來學習如何在動態環境中表現。DRL 利用深度神經網路 (Deep neural network，DNN) 來解決 RL 問題。agent 觀察來自動態環境的各種噪聲訊號，這些訊號被稱為狀態（state），並將這些狀態反饋給 DNN 由其產生動作。agent 在環境中採取動作並獲得獎勵，而獎勵又被用來更新 DNN 中的引數，以做出更好的決策。DRL 在一個閉環中工作以改善決策，其最終目標是使總獎勵最大化。作者考慮在一個有 M 個樣本的資料集上訓練 ML 工作負載，總獎勵預算為 B。如果達到一定的損失值 L 或者總獎勵預算 B 用完，則訓練終止。在任何一個 epoch t，排程器將對並行呼叫的函式數量（用 n_t 表示）以及每個函式的記憶體大小 m_t 做出判斷。令 f_t,i 表示在第 t 個 epoch 載入第 i 個活躍函式，如圖 11 所示。需要注意的是，如果函式 i 已經到了它的執行壽命，則會呼叫一個新的函式來代替它，且仍然用 f_t,i 來表示，所以在 epoch t 中總會有 n_t 個函式在併發執行。在每一個函式 f_t,i 中，重複計算一個新的 mini-batch 資料的聚合梯度，並根據 HSP 模式下的 SGD 更新模型引數。在 epoch t 中，假設函式 f_t,i 花費一個完整週期(P^F)_t,i 來獲取 mini-batch 資料，(P^C)_t,i 計算梯度，(P^U)_t,i 更新模型引數。函式 i 在 epoch t 的完整執行時間為：
epoch t 在 HSP 的全部持續時間為 P_t=max_i(P_t,i)。在 epoch t 結束時，ML 任務的損失值更新為 l_t。無伺服器雲根據函式執行時間和函式記憶體大小向使用者收費。令 c 表示使用 1GB 記憶體執行一個函式一秒鐘的單價。一個 epoch t 的總花費為：
其中，T 表示 epoch 的總數。本文所述任務的目標是最小化作業完成時間，即在一定獎勵預算 B 約束下解決以下最佳化問題：
在每個 epoch t 開始時，DRL agent 決定資源配置計劃 (n_t, m_t)，即 DRL 任務中的動作 action，具體如圖 12。衡量動作(n_t, m_t) 有效性的方法是在每個 epoch t 的結束進行數字 reward 量化計算。計算的依據是這個 epoch 持續的時間 P_t 和任務結束時預算是否透支。
狀態（State）：在本文所描述的問題中，epoch t 的狀態表示為：
其中，l_t 表示 epoch t 的損失值，(P^F)_t、(P^C)_t、(P^U)_t 分別表示獲取、平均計算和平均模型引數更新時間，P_t 為 epoch 的執行時間。u_t 和ω_t 分別表示平均記憶體和 CPU 的利用情況，b_t 為剩餘預算。動作（Action）：在本文所描述的問題中，動作表示為 a_t=(n_t, m_t)。n_t 表示啟用的函式數量，m_t 表示每個函式的記憶體大小。DRL agent 根據策略選擇操作，策略定義為給定當前狀態下整個操作空間的機率分佈π(a | s)。作者使用策略梯度方法，透過引數θ的函式來近似策略π(a | s)。因此，策略π可以寫成π(a | s, θ)，其中θ是要學習的引數。將策略π定義為實值空間的高斯機率密度：
基於條件機率π(a_t | s_t-1, θ)確定動作 a_t。然後，在一個大的離散作用空間上學習機率質量函式的問題就轉化為在一個二維連續空間中尋找引數 (μ(s,θ),σ(s,θ)) 的問題。獎勵（Reward）：在本文所描述的問題中，每個 epoch 結束時獎勵定義為：r_t=-β P_t，其中β為正則化係數。epoch t 的時間越長，agent 得到的獎勵就越少。最後一個 epoch T 的獎勵為：
換句話說，如果作業成功停止，即在不超出預算 B 的情況下滿足收斂閾值 L，則向 agent 分配正 C 的獎勵。否則，如果作業失敗，即在用完預算 B 之前還沒有收斂，則給獎勵賦值為負 C。在 DRL 中，agent 學習的是累計折扣獎勵：
其中，γ ∈ (0, 1]為未來折扣獎勵因子。在整個 DRL 訓練過程中，上式中的目標函式引導著 agent 找到最優的估計值。作者模擬了一個無伺服器的雲環境，執行由 DRL agent 控制的 mini-batch SGD 演算法。作者使用 OpenAI Gym 實現模擬環境（https://gym.openai.com (https://gym.openai.com/)），OpenAI Gym 是一個用於評估強化學習演算法的開源介面。實驗目的是驗證與傳統的網格搜尋（Grid Search）基線方法所找到的最優（靜態）策略相比使用 SIREN 進行排程的優勢。作者比較了在 AWS Lambda 上使用 SIREN 和在 EC2 叢集上使用 MXNet 訓練 ML 作業的完成時間和成本。具體實驗中選擇了三種型別的 EC2 例項來構建測試叢集：m4.large（2 vCPU，8GB 記憶體）、m4.xlarge（4 vCPU，16GB 記憶體）和 m4.2xlarge（8 vCPU，32GB 記憶體），每小時分別收費 0.1 美元、0.2 美元和 0.4 美元。圖 13 給出了 SIREN 與網格搜尋最佳函式數量的比較實驗。圖 13（a）比較了透過網格搜尋和 SIREN 實現的訓練時間。與網格搜尋相比，SIREN 在預算為 300 美元的情況下最多可減少 36% 的訓練時間。如圖 13（b）所示，網格搜尋列舉了不同預算下不同數量的函式的總獎勵情況。SIREN 能夠根據經驗動態調整函式數量。圖 13（c）給出了分配給每個 epoch 的函式數量。在前幾個 epoch 中，SIREN 啟動了大量的函式以快速降低損失值；在後幾個 epoch，agent 減少了函式數量以節省成本。SIREN 的 DRL agent 透過與模擬的無伺服器雲的迭代互動進行線上訓練。圖 13（d）中的學習曲線表明，agent 透過探索不同數量的函式來學習最大化總獎勵。agent 的訓練在大約 200 次迭代之後完成。
圖 13. SIREN 與網格搜尋最佳函式數量比較。
圖 14. 透過 SIREN 和 EC2 上的 MXNet 對 MNIST 資料集訓練 LeNet。圖 14 的實驗對比 SIREN 和 EC2 上的 MXNet。圖 14(a)顯示了使用 12 個 EC2 叢集和使用 SIREN 訓練 LeNet 的完成時間和相應的成本。由於 EC2 叢集的異質性，EC2 上的成本與訓練完成時間呈非線性關係。例如，m4.xlarge×6 叢集和 m4.2xlarge×6 叢集幾乎在同一時間完成訓練，但後者產生的成本是前者的兩倍。相比之下，SIREN 透過更多的投資縮短了完成時間。圖 14(b)顯示，SIREN 動態調整每個訓練 epoch 的函式及其記憶體。當函式數量減少時，每個函式收到的訓練資料分割槽更大，需要更大的記憶體來處理資料分割槽。SIREN 中的 DRL agent 是透過與 AWS Lambda 線上互動進行訓練的。從圖 14(c)中的學習曲線可以看出，經過 150 次左右的迭代，DRL agent 的訓練已經完成。進一步的，作者在 m4.2xlarge instances 的叢集上訓練 LeNet、CNN 模型和線性分類模型並確定相應的成本。然後，在成本相同的情況下在 m4.2xlarge×8 叢集上用 SIREN 訓練同樣的模型。圖 15 中的實驗資料顯示，與相同成本的 EC2 叢集相比，SIREN 使用這些模型分別減少了 40%、39.4% 和 44.3% 的訓練時間。
圖 15. 不同模型相同成本預算下 SIREN 與 EC2 的比較。2.4、Serverless Linear Algebra [10]
本文作者構建了 NumPyWren：一個基於無伺服器程式設計模型的線性代數系統，以及 LAmbdaPACK：一個為高度並行線性代數演算法的無伺服器執行而設計的領域特定語言。相關工作發表在 SoCC’20 中。無伺服器計算（例如，AWS Lambda、Google Cloud Functions、Azure Functions）是一種程式設計模型，雲提供商在其中管理伺服器同時動態管理資源分配。通常，無伺服器平臺計算會公開一個有時間限制的、無狀態的 FaaS API，以及一個管理程式狀態的物件儲存系統。對於能夠清晰地分離程式狀態和邏輯的應用程式設計人員來說，無伺服器平臺提供了對大型計算能力的即時訪問，而無需應對複雜叢集部署的開銷。本文所研究的內容：密集線性代數（Dense linear algebra）極大地受益於現有的以伺服器為中心的資料中心。現有的分散式線性代數框架可以透過利用區域性性、網路拓撲和單個伺服器內的資源緊密整合來完成高效能運算。在這樣的背景下作者提出這樣一個問題：這些線性代數演算法能否成功地移植到一個分散資料中心中？也就是說，我們能否在無伺服器程式設計模型中實現與基於 MPI 的分散式線性代數框架相當的效能？本文作者構建了 NumPyWren，一個在無伺服器架構上完成線性代數任務的系統。NumPyWren 執行使用 LAmbdaPACK 編寫的程式，LAmbdaPACK 是作者構建的一個高階 DSL，可以簡潔地表示任意基於分片的線性代數演算法。NumPyWren 透過無狀態函式執行來執行大規模密集線性代數程式。透過對中間語言 LAmbdaPACK 的分析，作者最終證明了分散式無伺服器計算模型（Disaggregated serverless computing model）可以用於具有複雜通訊程式的計算密集型程式。NumPyWren 解決的是類似 Cholesky 分解的線性代數問題。考慮求解線性方程 Ax=b 的問題，其中 a 是對稱正定矩陣。我們可以先把 a 分解成兩個三角形矩陣 a=LL^T，然後解兩個相對簡單的 Ly=b 和 L^T x=y 得到解 x。從這個過程中可以看出，分解是該求解問題中計算代價最高的步驟。Communication-Avoiding Cholesky 是一個很好的計算 Cholesky 分解的演算法。該演算法將矩陣分成若干塊，並得出一個計算順序使總資料傳輸量最小。具體演算法如下：
如圖 16，在 outer loop(j)的每一步中，演算法首先計算單個塊 Ajj 的 Cholesky 分解(圖 16(a))。這個結果用來更新由 Aij 下面的列塊組成的 "皮膚（panel）"（圖 16（b））。最後，第 j 列右邊的所有區塊都會根據各自的位置，透過索引更新皮膚（圖 16(c)）。透過向下移動對角線重複這一過程（圖 16（d））。
圖 16. 並行 Cholesky 分解的前 4 個時間步驟：0）對角塊 Cholesky 分解，1）並行列更新，2）並行子矩陣更新，3）（後續）對角塊 Cholesky 分解。作者針對 Algorithm 1 提出了兩點問題。首先，作者認為 Algorithm 1 在執行過程中展現出了動態並行性。外迴圈（Outer loop）由三個不同的步驟組成，具有不同的並行度，從 O(1)、O(K)到 O(K2)，其中 K 是每個步驟的封閉子矩陣大小。其次，該演算法在這三個步驟之間存在細粒度的依賴關係，無論是在一個迭代內還是在多個迭代之間。由此，作者提出了本文所考慮的工作，即：實現適應可用的並行化，作者透過將程式分解為可並行執行的細粒度執行單元來實現這一點。為了在無狀態環境中實現這一點，作者建議以分散的方式執行依賴性分析。將描述程式控制流的全域性依賴圖分發給每個 worker。然後，每個 worker 根據其在全域性任務圖中的當前位置，對其下游依賴關係進行本地推理。首先，我們介紹本文提出的 LAmbdaPACK：一種用於實現並行線性代數演算法的特定語言。LAmbdaPACK 是生成和使用矩陣塊（Tiled matrices）的命令式程式。這些程式可以對標量值執行基本的算術和邏輯運算。它們不能直接讀取或寫入矩陣值；相反，所有實質性的計算都是透過呼叫矩陣塊上的本機核心來執行的。矩陣塊由索引引用，LAmbdaPACK 程式的主要作用是對核心呼叫排序，並計算每個呼叫的分塊索引。LAmbdaPACK 包括簡單的 for 迴圈和 if 語句，但是沒有遞迴，只有從 LAmbdaPACK 到核心的一級函式呼叫。每個矩陣塊索引只能寫入一次，這是許多函式式語言的共同設計原則。LAmbdaPACK 中的原語功能強大，包括 Tall Skinny QR（TSQR）、LU、Cholesky 和奇異值分解等等。LAmbdaPACK 的示例性描述如圖 17 所示。
圖 17. LAmbdaPACK 語言的示例性描述。關於 LAmbdaPACK 的演算法分析主要包括兩個階段。由於原始未壓縮的 DAG 非常大，其節點數可能會隨著 Cholesky 或 QR 等演算法的輸入大小呈立方級增長，因此，第一階段的任務是分析程式並提取任務的壓縮 DAG。DAG 中的每個任務對應一個陣列寫入，我們還需提取執行此任務所需的核心計算和陣列讀取。由於每個陣列讀取都有一個唯一的上游寫入任務，因此此過程是可跟蹤處理的。第二個階段發生在 runtime，在執行任務之後，能夠動態發現下游任務。使用當前迴圈變數繫結的資訊來查詢下游任務的壓縮 DAG。圖 18 和圖 19 分別給出了 LAmbdaPACK 的 DAG 和程式示例。
LAmbdaPACK 中沒有並行原語，而是 LAmbdaPACK runtime 透過靜態分析程式來推斷底層依賴關係圖。為了並行執行程式，作者從程式產生的依賴結構構造了一個核心呼叫的 DAG。作者借用並擴充套件了迴圈最佳化技術（loop optimization），將 LAmbdaPACK 程式轉換為隱式有向無環圖（Implicit DAG）。將程式 DAG 中的每個節點 N 表示為一個元組（line_number, loop_indices）。利用這個資訊，可以執行程式迭代空間中的任何語句。接下來，作者解決推導 DAG 中特定節點的下游依賴關係問題。作者提出在 runtime 處理依賴性分析：每當一個儲存位置被寫入時，確定從同一儲存位置讀取的 N（所有行，所有迴圈索引）中的表示式。每當一個儲存位置被寫入時，我們確定從同一儲存位置讀取 N（所有行，所有迴圈索引）中的表示式。作者將約束建模為一個方程組。假設單個線性代數演算法中的行數必然很小，而程式迭代空間通常非常大。當陣列僅由迴圈變數的仿射函式索引時，即形式為 ai+b 的函式，其中 i 是迴圈變數，a 和 b 是編譯時已知的常數，則可以使用迴圈最佳化來有效地查詢特定節點的依賴關係。如圖 19 中的程式示例，如果在 runtime 一個 worker 正在執行程式的第 7 行，i=0、j=1 和 k=1，以查詢下游依賴項，則分析器將掃描這 7 行中的每一行，並計算是否存在一組有效的迴圈索引，以便在程式中的該點讀取 S[1,1,1]。如果是這樣，那麼元組（line_number, loop_indices）定義了該任務的下游依賴項，並確定為當前任務的子任務。為了便於訪問和開發，作者將 LAmbdaPACK 嵌入 Python 中。由於大多數 LAmbdaPACK 呼叫最佳化的 BLAS 和 LAPACK 核心，因此使用高階解釋語言的效能損失很小。LAmbdaPACK 詳細流程見 Algorithm2。
然後，我們介紹本文提出的 NumPyWren 框架。NumPyWren 框架包括五個獨立可擴充套件的主要元件：runtime 狀態儲存、任務佇列、輕量級全域性任務排程器、無伺服器計算 runtime 和分散式物件儲存。圖 20 展示了 NumPyWren 框架元件。
圖 20. NumPyWren 執行框架的體系結構，具體為 6x6cholesky 分解期間的 runtime 狀態。任務排隊（Task Queue）：客戶端程式將需要執行的第一個任務排隊到任務佇列中。任務佇列是一個釋出 - 訂閱樣式的佇列，它包含 DAG 中的所有節點，這些節點的輸入依賴關係都已滿足並準備好執行。
執行器配置（Executor Provisioning）：任務佇列的長度由配置者（Provisioner）監控，provisioner 管理計算資源以匹配執行期間的動態並行性。在第一個任務排隊後，provisioner 啟動一個執行器（executor），並根據任務佇列大小維護活動 executor 的數量。由於 provisioner 的角色只是輕量級的，所以它也可以作為 “無伺服器” 雲函式定期執行。
任務執行（Task Execution）：執行器管理 NumPyWren 任務的執行和排程。一旦執行器準備就緒，它就輪詢任務佇列以獲取可用的任務，並執行任務中的編碼指令。大多數任務涉及從物件儲存讀取輸入和將輸出寫入物件儲存，以及執行 BLAS/LAPACK 函式等。假定物件儲存是一個分散式持久儲存系統，它支援單個金鑰的先讀後寫一致性。使用一個帶有單一靜態賦值語言的持久物件儲存，有助於設計容錯協議。當執行器接近無伺服器系統的 runtime 限制時（AWS Lambda 為 900），執行器自動終止。如果有必要的話，provisioner 將負責僱傭新 worker。容錯協議能夠實現即使工作程式超過 runtime 限制或是在執行過程中被雲提供商殺死，程式仍能在有效狀態下執行。
Runtime 狀態更新（Runtime state update）：一旦任務執行完成並且輸出被持久化，執行器就會更新 runtime 狀態儲存中的任務狀態。runtime 狀態儲存跟蹤整個執行的控制狀態，並且需要支援每個任務的快速更新。如果已完成的任務具有 “ready” 子任務，則執行器會將該子任務新增到任務佇列中。狀態儲存的原子性保證了每個子任務都能夠被排程。這個使用執行器執行排程的過程實現了高效、分散、細粒度的任務排程。由於計算和儲存的分離，NumPyWren 中的容錯非常容易實現。因為對物件儲存的所有寫入都是持久的，所以在任務完成後都不需要重新計算。
任務租用（Task Lease）：在 NumPyWren 中，所有掛起的和可執行的任務都儲存在一個任務佇列中。保持一個不變數，即任務只有在完成後才能從佇列中刪除（例如，runtime 狀態儲存已更新，輸出持久化到物件儲存）。當一個 worker 獲取一條任務，這個 worker 就獲得了該任務的租約（lease）。在租用期間，該任務被標記為不可見，以防止其他 workers 獲取這條任務。
故障檢測和恢復（Failure Detection and Recovery）：在正常操作期間，worker 將使用後臺執行緒續訂任務租約，直到任務完成。如果任務完成，worker 將從佇列中刪除該任務。如果 worker 失敗，它將無法再續訂租約，並且該任務將對任何可用的 worker 可見。因此，故障檢測在租約到期時發生，恢復時間由租約長度決定。
垃圾收集（Garbage collection）：由於 NumPyWren 將所有中間狀態儲存到一個持久物件儲存區，因此在不再需要時清除狀態是非常必要的。但是，由於在物件儲存中儲存位元組的成本極低，與處理 TB 級中間狀態問題的計算成本相比，在程式結束時進行垃圾收集就足夠了。使用與程式相關聯的唯一 id 標記物件儲存中單個程式執行的所有分配。在程式執行終止後，NumPyWren 透過啟動一組並行的無伺服器任務來非同步清理物件儲存，以清理與給定程式 id 關聯的所有物件。
自動縮放（Autoscaling）：與傳統的無伺服器計算模型（每個新任務分配一個新容器）不同，NumPyWren 中的任務排程和 worker 管理是解耦的。這種解耦允許自動擴充套件計算資源，以實現更好的價效比權衡。在 NumPyWren 中，作者採用了一個簡單的自動縮放啟發式演算法，能夠在保持較低作業完成時間的同時獲得很好的利用率。
作者對 4 種線性代數演算法：矩陣乘（Matrix Multiply，GEMM）、QR 分解（QR Decomposition，QR）、奇異值分解（Singular Value Decomposition，SVD）、Cholesky 分解（Cholesky Decomposition，Cholesky）進行了實驗評價。對於這四種演算法，作者將它們與最先進的 MPI 實現進行比較。其中 Cholesky，GEMM 和 SVDwe 使用 ScaLAPACK 實現，ScaLAPACK 是一個工業級 Fortran 庫，專為高效能、分散式密集線性代數而設計。對於 QR 分解，則使用了 communication-avoiding QR 分解演算法的最佳化實現。NumPyWren 實現大約有 6000 行 Python 程式碼，作者將其構建在 Amazon web 服務（AWS）平臺上。對於 runtime 狀態儲存，使用的是 Redis--- 一個由 ElasticCache 提供的鍵值儲存。儘管 ElasticCache 是一種配置的（而不是“無伺服器”）服務，但作者發現使用一個例項就足以滿足所有工作負載。此外，作者還發現，可以用託管供應商提供的鍵值儲存（如 DynamoDB）來替換 Redis，但效能略有下降。作者將 Amazon 的簡單佇列服務（Simple queue Service，SQS）用於任務佇列，Lambda 或 EC2，使用 Amazon S3 作為遠端物件儲存。作者對實驗進行了一些特殊的裝置選擇、環境選擇或引數選擇。首先，由於不能很容易地控制併發 Lambda 執行的數量或 AWS 提供的硬體型別，出於實驗控制的原因，作者透過模仿 EC2 上的無伺服器 runtime 來進行大部分評估以便與其他系統進行比較。其次，本文的 Lambda 模擬基於 PyWren 框架中的“獨立模式”。PyWren 使用一個單獨的 SQS 佇列來模擬 Lambda 作業佇列，並使用有時間限制的程式來模擬短函式呼叫。在控制底層硬體（AVX、NIC 等）時，使用 SQS 會導致不確定性。然後，目前 Lambda 的定價是 EC2 現貨價格的 10 倍，這使得本文的大規模實驗無法在 Lambda 上進行。作者透過實驗對比發現，在 EC2 上執行模擬的無伺服器環境與在 AWS Lambda 上執行的效能差別最小。最後，模擬環境中的實驗還允許修改某些在真實無伺服器環境中使用者無法控制的系統引數，如函式超時等。表 3 中給出針對四種密集線性代數方法 NumPyWren 與 MPI 的端到端效能比較。作者對比了在完全相同的硬體條件下（8 個 r4.16xlarge 例項中的 256 個物理核），處理大小為 256k（262144）的方陣時 MPI 和 NumPyWren 的效能。我們可以看到無伺服器環境施加的限制導致的效能損失在 1.4x 到 1.6x 之間（按 wall-clock time 計算）。
表 3. 在具有 512 個虛擬核的叢集上，在 N=256K 的方陣上執行時，不同演算法的 MPI 與 NumPyWren 執行時間的比較。在表 4 中，作者比較了 NumPyWren 和 MPI 使用的總核秒數（core-seconds）。對於 MPI，core seconds 是指核的總數乘以 wall-clock runtime。對於 NumPyWren，作者只計算“活動核（Active cores）”，因為空閒核是可以被其他任務利用的。作者透過在無伺服器核啟動和冷卻計算過程中每個核的總計算時間中新增一個啟動延時γ來計算總核秒數。具體的，作者選擇γ=20s 以對系統進行保守的評估。對於 QR 和 Cholesky 這些具有可變並行性的演算法，雖然 wall-clock time 相當，但作者發現 NumPyWren 使用的核秒數減少了 1.15 倍。對於 SVD，實驗中顯示出超過 3 倍的資源節省效果，不過，產生這種差異一部分是由於使用的 SVD 演算法不同。然而對於具有固定數量的並行性的演算法（如 GEMM），NumPyWren 中過多的通訊會導致更高的資源消耗。
表 4. 在一個 256K 大小的方陣上執行演算法的 MPI 與 NumPyWren 總 CPU 時間（以核秒為單位）比較。本文重點關注了基於無伺服器計算的機器學習的最新研究進展。隨著雲端計算的不斷髮展，開發人員對於按需執行或擴充套件的需求越來越強烈，越來越希望不去應對伺服器或其它底層基礎設施，而是集中精力關注於自身應用的開發和調優。無伺服器計算的 FaaS 和 BaaS 服務必將迎來更多的關注。但是，正如我們開篇提到的，機器學習的演算法或模型中包含大量的引數、複雜的處理流程，是典型的“效能關鍵型應用”。針對機器學習這種要求複雜通訊模式和工作負載的應用如何基於無伺服器計算去工作仍然是一個有待研究的問題。本文關注了三個研究小組的四篇研究論文。其中前兩篇文章提出了一種無伺服器基礎設施和 ML 工作流的無伺服器 ML 框架原型，並將其封裝為一個實現端到端管理的分散式 ML 訓練框架 Cirrus，可以直接呼叫使用。第三篇文章提出了一個基於無伺服器架構的分散式機器學習新框架，以及一種深度強化學習技術，用於實現 SIREN 中的動態資源供應。作者還提出了一種能夠在無伺服器架構中高效工作的 HSP 計算模式。最後一篇文章重點關注的是無伺服器計算的模密集線性代數程式應用，作者提出了一個在無伺服器架構上完成線性代數任務的系統 NumPyWren，透過對中間語言 LAmbdaPACK 的分析，作者最終證明了該分散式無伺服器計算模型 NumPyWren 可以用於具有複雜通訊程式的計算密集型程式。在幾篇文章中，作者都透過實驗證明了幾種框架在執行機器學習任務時效能遠優於經典的基於粗粒度的 VM 叢集的 ML 框架。儘管無伺服器的機器學習具有敏捷、快速、可伸縮性等優點，但是它對機器學習的整合還處於初級階段，它自身也面臨著工具不全面、不成熟或者配置方式不統一等問題。隨著越來越多的研究人員關注，越來越多的應用開發提出成本節約和效率提高的需要，無伺服器計算將迎來更快更好的發展。[1] Charles Reiss, Alexey Tumanov, Gregory R Ganger, Randy H Katz, and Michael A Kozuch. 2012. Heterogeneity and dynamicity of clouds at scale: Google trace analysis. In Proceedings of the Third ACM Symposium on Cloud Computing. ACM, 7.[2] Joao Carreira, Pedro Fonseca, Alexey Tumanov, et al., A Case for Serverless Machine Learning NIPS'18 http://learningsys.org/nips18/assets/papers/101CameraReadySubmissioncirrus_nips_final2.pdf[3] Eric Jonas, Shivaram Venkataraman, Ion Stoica, and Benjamin Recht. Occupy the cloud: Distributedcomputing for the 99%. CoRR, abs/1702.04024, 2017.[4] Jinliang Wei, Wei Dai, Aurick Qiao, Qirong Ho, Henggang Cui, Gregory R Ganger, Phillip B Gibbons,Garth A Gibson, and Eric P Xing. Managed communication and consistency for fast data-parallel iterativeanalytics. In Proceedings of the Sixth ACM Symposium on Cloud Computing, pages 381–394. ACM, 2015.[5] Joao Carreira, Pedro Fonseca, Alexey Tumanov, et al., Cirrus: a Serverless Framework for End-to-end ML Workflows，SoCC ’19:ACM Symposium on Cloud Computing, https://dl.acm.org/doi/10.1145/3357223.3362711[6] Martín Abadi, Paul Barham, Jianmin Chen, Zhifeng Chen, Andy Davis, Jeffrey Dean, Matthieu Devin, Sanjay Ghemawat, Geoffrey Irving, Michael Isard, et al. [n. d.]. TensorFlow: A System for Large-Scale Machine Learning[7] Criteo Dataset. http://labs.criteo.com/2014/02/kaggle-display-advertisingchallenge-dataset/.[8] Netflix Dataset. https://www.kaggle.com/netflix-inc/netflix-prize-data.[9] Hao Wang, Di Niu, Baochun Li，Distributed Machine Learning with a Serverless Architecture，IEEE INFOCOM 2019， https://ieeexplore.ieee.org/abstract/document/8737391[10] Vaishaal Shankar, et al., Serverless linear algebra, SoCC '20: ACM Symposium on Cloud Computing, https://dl.acm.org/doi/10.1145/3419111.3421287[11] Serverless Machine Learning on Modern Hardware Using Apache Spark， https://databricks.com/session/serverless-machine-learning-on-modern-hardware-using-apache-spark
仵冀穎，工學博士，畢業於北京交通大學，曾分別於香港中文大學和香港科技大學擔任助理研究員和研究助理，現從事電子政務領域資訊化新技術研究工作。主要研究方向為模式識別、計算機視覺，愛好科研，希望能保持學習、不斷進步。
關於機器之心全球分析師網路 Synced Global Analyst Network
機器之心全球分析師網路是由機器之心發起的全球性人工智慧專業知識共享網路。在過去的四年裡，已有數百名來自全球各地的 AI 領域專業學生學者、工程專家、業務專家，利用自己的學業工作之餘的閒暇時間，透過線上分享、專欄解讀、知識庫構建、報告發布、評測及專案諮詢等形式與全球 AI 社群共享自己的研究思路、工程經驗及行業洞察等專業知識，並從中獲得了自身的能力成長、經驗積累及職業發展。