根據 gartner 對全球 cio 的調查結果顯示，人工智慧將成為 2019 年組織革命的顛覆性力量。對於人工智慧來說，算力即正義，成本即能力，利用 docker 和 kubernetes 代表雲原生技術為 ai 提供了一種新的工作模式，將 gpu 機器放到統一的資源池進行排程和管理，這避免了gpu 資源利用率低下和人工管理的成本。因此，全球主要的容器集群服務廠商 kubernetes 都提供了 nvidia gpu 容器集群排程能力，但是通常都是將乙個 gpu 卡分配給乙個容器。這雖然可以實現比較好的隔離性，確保使用 gpu 的應用不會被其他應用影響；對於深度學習模型訓練的場景也非常適合，但是，針對模型開發和模型**的場景還是會顯得比較浪費。基於此，大家有了共享 gpu 的集群排程需求。
共享 gpu 的集群排程就是能夠讓更多的模型開發和**服務共享同乙個 gpu 卡，進而提高集群中 nvidia gpu 的利用率。而這就需要提供 gpu 資源的劃分，而這裡 gpu 資源劃分的維度指的就是 gpu 視訊記憶體和 cuda kernel 執行緒的劃分。通常在集群級別談支援共享 gpu 是以下兩件事情：
1.排程
2.隔離，我們這裡主要討論的是排程，隔離的方案目前需要使用者通過應用限制(比如使用 tensorflow 的per_process_gpu_memory_fraction 來控制)，未來會提供基於 nvidia 的 mps 的可選項, 也會考慮 gpu 的方案。
而對於細粒度的 gpu 卡排程，目前 kubernetes 社群並沒有很好的方案，這是由於 kubernetes 對於 gpu 這類擴充套件資源的定義僅僅支援整數粒度的加加減減，無法支援複雜資源的分配。比如使用者希望使用 pod a 占用半張 gpu卡，這在目前 kubernetes 的架構設計中無法實現資源分配的記錄和呼叫。這裡挑戰是多卡 gpu 共享是實際向量資源問題，而 extened resource 是標量資源的描述。
針對此問題，我們設計了乙個 out of tree 的共享 gpu 排程方案，該方案依賴於 kubernetes 的現有的工作機制:
這個 gpu 共享排程擴充套件的好處是：利用 kubernetes 的擴充套件和外掛程式機制實現，對於 api server，scheduler，controller manager 以及 kubelet 等核心元件沒有侵入性。這就方便了使用者可以在不同 kubernetes 版本上應用這個方案，無需 rebase **和重新構建 kubernetes 二進位製包。
明確問題簡化設計，第一步只負責排程和部署，後續再實現執行時視訊記憶體管控。
有很多的客戶明確的訴求是首先可以支援多ai應用可以排程到同乙個 gpu 上，他們可以接受從應用級別控制視訊記憶體的大小，利用類似gpu_options.per_process_gpu_memory_fraction控制應用的視訊記憶體使用量。那我們要解決的問題就先簡化到以視訊記憶體為排程標尺，並且把視訊記憶體使用的大小以引數的方式傳遞給容器內部。
不做侵入式修改
本設計中不會修改 kubernetes 核心的 extended resource 的設計， scheduler 的實現，device plugin 的機制以及 kubelet 的相關設計。重用 extended resource 描述共享資源的申請 api。這樣的好處在於提供乙個可以移植的方案，使用者可以在原生 kubernetes 上使用這個方案。
按視訊記憶體和按卡排程的方式可以在集群內並存，但是同乙個節點內是互斥的，不支援二者並存；要麼是按卡數目，要麼是按視訊記憶體分配。
依舊延用 kubernetes extended resource 定義，但是衡量維度最小單位從 1 個 gpu 卡變為 gpu 視訊記憶體的 mib。如果所節點使用的 gpu 為單卡 16gib 視訊記憶體，它對應的資源就是 16276mib；
由於使用者對於共享gpu的訴求在於模型開發和模型**場景，在此場景下，使用者申請的gpu資源上限不會超過一張卡，也就是申請的資源上限為單卡。
而我們的工作首先是定義了兩個新的 extended resource： 第乙個是 gpu-mem， 對應的是 gpu 視訊記憶體;第二個是 gpu-count，對應的是 gpu 卡數。 通過兩個標量資源描述向量資源, 並且結合這一資源，提供支援共享 gpu 的工作機制。下面是基本的架構圖：
資源上報
gpu share device plugin 利用 nvml 庫查詢到 gpu 卡的數量和每張 gpu 卡的視訊記憶體， 通過listandwatch()將節點的 gpu 總視訊記憶體（數量 視訊記憶體）作為另外 extended resource 匯報給 kubelet； kubelet 進一步匯報給 kubernetes api server。 舉例說明，如果節點含有兩塊 gpu 卡，並且每塊卡包含 16276mib，從使用者的角度來看：該節點的 gpu 資源為 16276 2 = 32552; 同時也會將節點上的 gpu 卡數量 2 作為另外乙個 extended resource 上報。
2. 擴充套件排程
gpu share scheduler extender 可以在分配 gpu-mem 給 pod 的同時將分配資訊以 annotation 的形式保留在 pod spec 中，並且在過濾時刻根據此資訊判斷每張卡是否包含足夠可用的 gpu-mem 分配。
2.1 kubernetes 預設排程器在進行完所有過濾(filter)行為後會通過 http 方式呼叫 gpu share scheduler extender的filter 方法, 這是由於預設排程器計算 extended resource 時，只能判斷資源總量是否有滿足需求的空閒資源，無法具體判斷單張卡上是否滿足需求；所以就需要由 gpu share scheduler extender 檢查單張卡上是否含有可用資源。
以下圖為例， 在由 3 個包含兩塊 gpu 卡的節點組成的 kubernetes 集群中，當使用者申請gpu-mem=8138時，預設排程器會掃瞄所有節點，發現 n1 所剩的資源為 (16276 * 2 - 16276 -12207 = 4069 )不滿足資源需求，n1 節點被過濾掉。
而 n2 和 n3 節點所剩資源都為 8138mib，從整體排程的角度看，都符合預設排程器的條件；此時預設排程器會委託 gpu share scheduler extender 進行二次過濾，在二次過濾中，gpu share scheduler extender 需要判斷單張卡是否滿足排程需求，在檢視 n2 節點時發現該節點雖然有 8138mib 可用資源，但是落到每張卡上看，gpu0 和分別 gpu1 只有 4069mib 的可用資源，無法滿足單卡 8138mib 的訴求。而 n3 節點雖然也是總共有 8138mib 可用資源，但是這些可用資源都屬於 gpu0，滿足單卡可排程的需求。由此，通過 gpu share scheduler extender 的篩選就可以實現精準的條件篩選。
2.2 當排程器找到滿足條件的節點，就會委託 gpu share scheduler extender 的 bind 方法進行節點和 pod 的繫結，這裡 extender 需要做的是兩件事情
注意：這時還會儲存aliyun_com_gpu_mem_assigned的 pod annotation，它被初始化為「false」。它表示該 pod 在排程時刻被指定到了某塊 gpu 卡，但是並沒有真正在節點上建立該 pod。aliyun_com_gpu_mem_assume_time代表了指定時間。
如果此時發現分配節點上沒有 gpu 資源符合條件，此時不進行繫結，直接不報錯退出，預設排程器會在 assume 超時後重新排程。
以下圖為例，當 gpu share scheduler extender 要把 gpu-mem：8138 的 pod 和經過篩選出來的節點 n1 繫結，首先會比較不同 gpu 的可用資源，分別為 gpu0(12207),gpu1(8138),gpu2(4069),gpu3(16276),其中 gpu2 所剩資源不滿足需求，被捨棄掉；而另外三個滿足條件的 gpu 中, gpu1 恰恰是符合空閒資源滿足條件但同時又是所剩資源最少的 gpu 卡，因此 gpu1 被選出。
3. 節點上執行
當 pod 和節點繫結的事件被 kubelet 接收到後，kubelet 就會在節點上建立真正的 pod 實體，在這個過程中, kubelet 會呼叫 gpu share device plugin 的allocate方法,allocate方法的引數是 pod 申請的 gpu-mem。而在allocate方法中，會根據 gpu share scheduler extender 的排程決策執行對應的 pod
目前專案已經開源到 github.com 上
gpushare-scheduler-extender
gpushare-device-plugin
請參照部署文件
首先建立乙個使用aliyun.com/gpu-mem的應用
複製**
請參照使用文件
請參照如何構建
阿里（1 深度學習）
深度學習的概念由hinton等人於2006年提出，於人工神經網路的研究，含多隱層的多層感知機就是一種深度學習結構。深度網路通常意味著具有多於 1 個隱藏層的人工神經網路，神經網路模仿大腦的神經元將資訊進行傳遞並解釋資料，主要是影象 聲音和文字，實現人類的學習行為。dl通過組合低層特徵形成更加抽象的高...
飛槳開源深度學習（一）
一些問題q 深度學習 我們可以很容易理解，即機器學習中人工智慧的乙個研究方面 機器學習 人工智慧 深度學習 而這裡的框架，實際上就是指乙個平台，在這個平台中，我們程式設計師只需要考慮一小部分函式實現，而其他的系統層面的細節均有平台自動處理，不需要程式設計師顧慮擔心。所以，學習深度學習，我們能用較小的...
阿里雲深度學習平台試玩
python cifar pai.py buckets users kylefan program cifar 10 cifar 10 batches py checkpointdir users kylefan program cifar 10 checkpoint 其中 buckets對應下圖的...