基於 Lyft 的 Flyte Kubernetes 排程器，FlyteInteractive 連線到 Kubernetes pod 內的 VSCode Server，以存取集群上的資源和大規模數據。
盡管容器承載應用程式及其依賴關系的承諾意味著在開發周期內具有可移植和一致的環境，但對於像生成式人工智能中使用的大型模型來說，這對於本地工作的開發人員來說是不切實際的，因為數據集和 GPU 硬件都不可用。
"本地開發可用的資源並不包括與生產環境中使用的高端、昂貴的 GPU、相同數量的記憶體，或分布式系統的復雜性。你可以犧牲模型的大小和復雜性（在本地執行），但這也會犧牲上傳模型到真實的生產數據後成功的可能性。"
早期的 Flyte
正如其名稱所示，FlyteInteractive 是一個外掛程式，用於為 LinkedIn 已經在使用的另一個開源專案 Flyte 添加更多功能。
Flyte 還有助於進行機器學習中非常重要的快速實驗，數據集經常變化，新演算法不斷湧現。Hsu 在接受 New Stack 采訪時表示：「排程時間非常非常快，因此使用者可以快速進行實驗。」
Python 介面也使得 Flyte 對於機器學習開發人員來說易於上手：「如果你想要在你的工作流中添加一個自訂的 Python 任務，在 Flyte 中做到直觀而簡單。這絕對使得機器學習開發人員更快。」
Zhu 也解釋道，Flyte 還帶來了一些熟悉的 DevOps 功能，加速了機器學習的開發過程。他在 LinkedIn 主頁資訊流中使用了類似於 Flyte 的大型模型：「以前，每次我們構建流水線時，我們都必須在本地拉取依賴項，我們必須等待這一過程完成。但由於 Flyte 是基於映像的，我們可以提前將所有這些依賴項打包到映像中，因此使用者只需幾秒鐘就可以上傳其作業，而將所有這些依賴項放入執行時的過程則會在執行時發生。」 這節省了大量時間，包括每次更新工作流並重新執行機器學習作業的時間。
為了鼓勵程式碼重用，並避免每個團隊為每個新專案重新構建相同的元件和流程，LinkedIn 在 Flyte 之上建立了一個元件中心，其中已經有超過 20 個可重用元件，可以節省大量重復工作。"這些是用於常見工具，如數據預處理、訓練或推斷，"Hsu 解釋道。"訓練團隊可以構建類似於 TensorFlow 訓練器的訓練元件，所有的 ML 工程師都可以使用它，而不需要重新實作它。"
這也使得像 Zhu 最近一直在研究的模型量化等更強大和復雜的技術變得更加普遍，方法是將其轉換為一個函數或 API 呼叫。有多種演算法可以將模型的表示從高到低精度轉換，因此您可以壓縮模型並使用盡可能少的資源進行服務，通常機器學習開發人員需要研究最新的進展，選擇一個演算法，然後為自己的專案實作它。
"我們將其構建為一個元件，因為 Flyte 具有可重用元件的概念，對於其他每個使用者的流水線，他們都可以選擇將其作為介面或外部 API 呼叫。因此，他們可以在模型訓練完成後對其進行量化，無論它是用於摘要的模型，還是用於推理的模型，還是用於實體提取的模型，" Zhu 說。
開發人員可以快速探索多種演算法，因為他們可以將它們簡單地插入到他們的工作流中，以測試它們對資源使用情況以及模型準確性的影響。
「如果你不確定量化對於你特定的用例是否有效，我們可以建立一個集中式的中心，包含所有不同的量化演算法，這樣你就可以測試它們，並檢視結果矩陣和延遲，以了解權衡，並找出正確的方法。隨著領域的發展，會出現更多的量化演算法，因此我們必須有一個非常靈活的平台，可以測試所有這些演算法，並將它們添加到所有下遊流水線都可以受益的集中式的中心中。」 Zhu 表示。
遠端互動式偵錯
能夠更快地編寫流水線並重用元件加快了機器學習的開發速度，以至於 LinkedIn 的軟件工程師開始註意到其他減慢工作流程的因素：從必須使用與生產數據集不夠匹配的較小的模擬數據集，到本地開發和測試環境缺乏生產環境的硬件和資源，這意味著模型大小受到人為限制，再到長時間的偵錯周期，以及必須等待程式碼部署，才能確定是否真正修復了錯誤。
由於本地和生產環境之間的差異，大約有五分之一的錯誤第一次就被修復了：每次程式碼推播至少需要 15 分鐘才能進入生產環境。追蹤甚至是一個微小的錯誤可能需要數十次嘗試：在某些情況下，尋找並修復問題幾乎花費了一個星期的時間。
這些問題並不局限於機器學習開發，但它們不僅受到機器學習模型和它們處理的數據集的規模之大、以及在生產環境中執行模型所需的昂貴基礎設施的影響，而且還受到生態系的影響，該生態系並不總是提供其他領域開發人員視為理所當然的工具，如程式碼檢查和遠端偵錯。
Zhu 指出，即使是最小的生成式人工智能模型，只要具有合理的體量，就不能在 CPU 上執行。他說：「當你達到那個階段時，我們自然會將編碼和偵錯過程轉移到 Kubernetes Pod 或 GPU 集群中，並使用真實數據和與生產環境中相同的資源。」
FlyteInteractive 可以從 HDFS 或 S3 儲存載入數據，並支持單節點作業以及更復雜的多節點和多 GPU 設定。
開發人員只需將 VSCode 裝飾器添加到他們的程式碼中，連線到 VSCode 伺服器，並像往常一樣使用「執行和偵錯」命令，即可獲取一個互動式偵錯會話，在其中在 VSCode 中執行他們的 Flyte 任務。Flyte 緩存工作流輸出以避免重新執行昂貴的任務，因此 VSCode 可以從上一個任務中載入數據。
您將獲得所有常見的選項，如設定斷點（甚至是在分布式訓練過程中設定斷點）或執行本地指令碼，以及程式碼導航和檢查工具，這些工具可以幫助您理解具有多個模組的大型模型的復雜程式碼結構，並檢視數據如何流入模型。
你還可以設定外掛程式在 Flyte 任務失敗時自動執行，這會阻止任務終止，並為你提供檢查和偵錯失敗點的機會。當你找出問題所在並重寫了程式碼後，你可以關閉 VSCode 伺服器，讓 Flyte 繼續執行工作流。"你可以使用修改後的程式碼恢復工作流：你只需點選一個按鈕，然後任務將使用新的修改後的程式碼執行，並且整個工作流程將繼續執行，" Hsu 解釋道。
他建議，FlyteInteractive 中的 Jupyter 筆記本支持也會很有幫助："它是一個快速的編排器，具有 Jupyter 筆記本和互動式偵錯的功能，因此你可以用它來快速實驗，也可以用於定期作業或批次處理作業。"
雖然目前它是一個外掛程式，但現在它是開源的，他希望有了社區的輸入，它將成為 Flyte 的內建功能。
探索資源和程式碼
FlyteInteractive 已經在 LinkedIn 節省了數千小時的編碼和偵錯時間；它還可能透過其資源監控選項幫助控制成本。"如果一個 Pod 在一段時間內處於空閑狀態，我們將清理它，並行送郵件通知使用者‘嘿，您的 Pod 已經空閑一段時間了。考慮釋放資源或采取一些行動。" 未來，Hsu 告訴我們，這將更細粒度。"例如，我們想要檢測 GPU 利用率。如果它們占用了 GPU，但實際上沒有使用它，我們可能希望在十分鐘後將其終止，這樣我們就可以更好地控制 GPU 系統的預算。」
這依賴於 Flyte 中的檢查點支持，因為生成檢查點是昂貴的，通常不適用於機器學習中使用的叠代訓練迴圈。"我們必須提供良好的檢查點支持，以便在使用者的作業被搶占時，它也能保存模型。」
但對於開發人員來說，最吸引人的特性甚至不是快速偵錯，Zhu 表示。"我喜歡程式碼檢查功能，因為它讓我能夠快速理解演算法的內部工作機制，也幫助我提出一些新的方法。"
他指出，這不僅對你自己的程式碼有用。"工程師不僅可以將這種方法套用於他們的內部倉庫，還可以將其套用於開源倉庫。作為一個領域，機器學習發展非常迅速：每周都會出現新的演算法，我們這樣的工程師不得不進行測試。我們可以將這個工具指向一個開源倉庫，快速了解它是否是我們想采用的技術。"
