原文: https://docs.vultr.com/how-to-set-up-a-jupyterlab-environment-on-ubuntu-22-04
JupyterLab 為資料科學和人工智慧專案提供基於 Web 的開發環境。它是一個靈活的介面，允許開發人員配置和管理機器學習和科學計算工作流程。 JupyterLab 是下一代 Jupyter Notebook。它旨在解決 Notebook 的許多可用性問題，並透過支援 40 多種程式語言（包括 R、Python、Scala 和 Julia）大大擴展了其使用的範圍。
在開始之前，您應該：
Docker 無疑以其輕量級、可移植的容器改變了軟體開發和部署的世界。但是如果我告訴你 Docker 本身可以在另一個 Docker 容器中運作呢？恩，那就對了！這個概念通常被稱為 “Docker Inside Docker” 或 “DinD”，為開發人員和系統管理員開闢了一個全新的可能性領域。在這篇文章中，我們將探索嵌套容器化的世界，討論它的眾多好處、各種用例以及在 Docker 中啟動 Docker 的逐步過程。那麼，讓我們深入了解一下吧！
簡單來說，Docker Inside Docker 涉及在 Docker 容器內執行 Docker。容器內產生了一個新的 Docker 引擎，而不是與主機的 Docker 守護程式交互，為管理容器和映像提供了一個隔離的環境。
1. Isolated Development and Testing:
在 Docker 中執行 Docker 允許開發人員創建專門為其應用程式量身定制的隔離環境。這可確保依賴項、配置和執行時間環境在不同的開發階段保持一致，從而更輕鬆地重現和偵錯問題。
2. Enhanced Security and Isolation:
在 Docker 中執行 Docker 允許開發人員創建專門為其應用程式量身定制的隔離環境。這可確保依賴項、配置和執行時間環境在不同的開發階段保持一致，從而更輕鬆地重現和偵錯問題。
3. Simplified CI/CD Pipelines:
Docker Inside Docker 廣泛應用於持續整合和持續部署 (CI/CD) 工作流程。它支援創建用於建置、測試和部署應用程式的獨立的一次性環境，從而實現更快、更可靠的自動化管道。
4. Multi-tenancy and Resource Management:
在多個團隊或使用者需要共用基礎架構上的隔離環境的情況下，嵌套容器化非常有用。透過在 Docker 內部啟動 Docker，可以為每個團隊或使用者提供單獨的 Docker 引擎，確保資源隔離並防止不同應用程式之間的干擾。
原文: How to Manage Dependencies and Build & Publish Python Packages using Poetry
本教程涵蓋:
在建立 Python 套件時，開發人員通常會依賴外部程式庫或不屬於 Python 標準庫的依賴項。手動管理這些第三方函式庫的安裝、卸載或更新是一項繁瑣的任務。這些第三方函式庫具有額外的外部相依性的情況並不罕見，這使得手動管理相依性變得更加複雜。
幸運的是，Python 有依賴管理工具，可以讓第三方函式庫的管理變得更容易。 Poetry 是其中一個值得注意的工具，它不僅有助於依賴管理，還負責創建虛擬環境以及建置和發布 Python 套件。
在本教程中，我們將使用 Poetry 建立、建構和發布一個命令列工具，該工具接收國家/地區名稱作為輸入並輸出其對應的 Alpha3 程式碼。
原文: Configure a Poetry environment
Poetry 是一個有助於根據專案依賴關係建立 Python 虛擬環境的工具。您可以聲明您的專案所依賴的程式庫，Poetry 將為您安裝和更新它們。
專案依賴項記錄在 pyproject.toml 檔案中，該檔案指定所需的套件、腳本、外掛程式和 URL。有關其結構和格式的更多信息，請參閱 pyproject 參考。
要在 PyCharm 中使用 Poetry，您需要將其安裝在您的電腦上並建立特定的 Python 環境。
原文: How to Create and Upload Your First Python Package to PyPI
在開始之前，我們應該知道在 Python 中套件的含義。
Python 套件是一個目錄，其中包含一堆模組以及名為 __init__.py 的依賴檔案。該檔案可以完全為空，您可以使用它來將磁碟上的目錄標記為 Python 套件。
下面顯示了套件目錄的範例：
__init__.py 是一個依賴文件，可協助 Python 在套件目錄中尋找可用模組。如果我們刪除這個文件，Python 將無法導入我們的模組。
PyPI 是 Python Package Index 的縮寫，是 Python 程式語言的官方第三方套件儲存庫。它是一個中央儲存庫，託管和分發軟體包供 Python 開發人員使用。
開發人員可以將 Python 套件上傳到 PyPI，其他人可以輕鬆存取這些套件。這些套件可以包括函式庫、框架、實用程式和工具來擴展和增強 Python 的功能。
本文將介紹 PyPI 的優點、套件的元件以及如何建立 PyPI 套件。
PyPI 用於尋找和安裝專案的套件。它允許開發人員輕鬆管理依賴項並簡化應用程式的安裝過程。借助 PyPI，他們可以透過重複使用現有程式碼而不是從頭開始編寫所有內容來節省時間和精力。
PyPI 由 Python 軟體基金會 (PSF) 維護，可供開發人員和最終用戶免費使用。它是 Python 生態系統的重要組成部分，為該語言的流行和發展做出了貢獻。
在 Python 中，套件是一種分層組織相關模組、函數和類別的方式。它提供了一種捆綁程式碼的結構化方法，可以將其視為包含一個或多個 Python 模組的目錄。它有助於組織程式碼並使其更易於管理和分發。
Package 通常包含一個 init.py 文件，該文件在導入套件時執行。它可以定義包級屬性、函數和類，可供套件中的其他模組存取。 init.py 檔案也可以包含導入語句以從其他套件導入模組和函數。
可以使用 pip 等套件管理器來安裝和管理 Python 套件，pip 可以自動下載並安裝所需的依賴項。
透過套件，開發人員可以將相關功能封裝到一個單元中，從而更容易重複使用和維護程式碼。例如，流行的 NumPy 套件提供了處理數組和矩陣的功能，而 Pandas 套件提供了用於資料分析和操作的工具。
來源: All You Need to Know to Build Your First LLM App
本文提供了對文件載入器、詞嵌入、向量儲存和提示模板的 step-by-step 教學內容。
在不斷發展的程式設計和軟體開發領域，對效率和生產力的追求帶來了顯著的創新。其中一項創新就是 Codex、StarCoder 和 Code Llama 等程式碼產生模型的出現。這些模型在產生類似人類的程式碼片段方面表現出了卓越的能力，從而顯示出作為編碼助手的巨大潛力。
然而，雖然這些預先訓練的模型可以在一系列任務中表現出色，但還有一個令人興奮的可能性：能夠根據您的特定需求定製程式碼產生模型。想想可以在企業規模上利用的個人化編碼助手。
在這篇文章中，我們展示瞭如何建立 HugCoder 🤗，這是一個根據 Huggingface GitHub 組織的公共儲存庫中的程式碼內容進行微調的程式碼 LLM。我們將討論我們的資料收集工作流程、訓練實驗和一些有趣的結果。這將使您能夠根據您的專有程式碼庫創建您自己的個人副駕駛。我們將為您留下該項目的一些進一步擴展以供實驗。
讓我們開始吧🚀
我們想要的資料集在概念上很簡單，我們的結構如下：
| Repository Name | Filepath in the Repository | File Contents |
|---|---|---|
| --- | --- | --- |
使用 Python GitHub API 從 GitHub 抓取程式碼內容非常簡單。然而，根據儲存庫的數量以及儲存庫中程式碼檔案的數量，人們可能很容易遇到 API 速率限制問題。
為了防止此類問題，我們決定在本地克隆所有公共儲存庫並從中提取內容，而不是透過 API。我們使用 Python 中的多處理模組並行下載所有儲存庫，如該下載腳本所示。
儲存庫通常可以包含非程式碼文件，例如圖像、簡報和其他數據資產。我們對收集它們不感興趣。我們創建了一個擴展列表來過濾掉它們。為了解析 Jupyter Notebooks 以外的程式碼文件，我們只需使用 "utf-8" 編碼。對於 Jupyter Notebooks，我們只考慮代碼單元(code cells) 裡的內容。
我們也排除了所有與程式碼不直接相關的檔案路徑。其中包括：.git、__pycache__ 和 xcodeproj。
為了保持該內容的序列化相對記憶體友好，我們使用了進行了分塊和使用 feather 格式來序列化。請參閱此腳本以了解完整的實作。
最終的hf-codegen-v2 資料集可在 Hub 上找到，如下所示：
在本文中，我們考慮了基於 stargazer 的前 10 個 Hugging Face 公共儲存庫。它們是：
這是我們用來產生此資料集的程式碼，這是 Hub 中的資料集。
為了降低專案複雜度，我們沒有考慮資料集的去重。如果您有興趣在生產應用程式中應用重複資料刪除技術，這篇部落格文章是關於 code LLMs 案例的優秀參考資源。
在本節中，我們將展示如何微調以下模型：bigcode/starcoder（15.5B 參數）、bigcode/starcoderbase-1b（1B 參數）、Deci/DeciCoder-1b（1B 參數）。我們將使用一台 A100 40GB Colab 筆記本，並使用 🤗 PEFT（參數高效微調）進行所有實驗。此外，我們將展示如何使用 🤗 Accelerate 的 FSDP 整合在具有 8 個 A100 80GB GPU 的機器上完全微調 bigcode/starcoder（15.5B 參數）。訓練目標是 fill in the middle（FIM），其中訓練序列的部分內容被移動到末尾，並且對重新排序的序列進行自回歸預測。
為什麼選擇PEFT? 進行完全微調的成本很高。讓我們用一些數字來正確看待事情：
完全微調所需的最小 GPU 記憶體：
由於硬體要求很高，我們將使用 QLoRA 進行參數高效的微調。以下是使用 QLoRA 微調 StarCoder 的最低 GPU 記憶體需求：
可訓練參數：110,428,160 || 所有參數：15,627,884,544 || 可訓練％：0.7066097761926236
在上面的計算中，我們沒有考慮中間激活檢查點所需的內存，該內存相當大。我們利用 Flash Attention V2 和梯度檢查點來解決這個問題。
請參閱 model-memory-usage 情況，輕鬆計算在 🤗 Hugging Face Hub 上託管的模型上訓練和執行大模型推理所需的 vRAM 量。
我們將了解如何使用 PyTorch 全分片資料並行 (FSDP) 技術在 8 個 A100 80GB GPU 上對 bigcode/starcoder（15B 參數）進行全面微調。有關 FSDP 的更多信息，請參閱使用 PyTorch FSDP 微調 Llama 2 70B 和使用 PyTorch 全分片資料並行加速大型模型訓練。
資源
透過 run_fsdp.sh 來啟動訓練的指令。
accelerate launch --config_file "configs/fsdp_config.yaml" train.py \
--model_path "bigcode/starcoder" \
--dataset_name "smangrul/hf-stack-v1" \
--subset "data" \
--data_column "content" \
--split "train" \
--seq_length 2048 \
--max_steps 2000 \
--batch_size 1 \
--gradient_accumulation_steps 2 \
--learning_rate 5e-5 \
--lr_scheduler_type "cosine" \
--weight_decay 0.01 \
--num_warmup_steps 30 \
--eval_freq 100 \
--save_freq 500 \
--log_freq 25 \
--num_workers 4 \
--bf16 \
--no_fp16 \
--output_dir "starcoder-personal-copilot-A100-40GB-colab" \
--fim_rate 0.5 \
--fim_spm_rate 0.5 \
--use_flash_attn
總訓練時間為9小時。根據 lambdalabs 計算 8 個 A100 80GB GPU 的成本為 12.00 美元/小時，總成本為 108 美元。
接下來我們將了解如何使用 QLoRA 使用 🤗 PEFT 在單一 A100 40GB GPU 上微調 巷bigcode/starcoder（15B 參數）。有關 QLoRA 和 PEFT 方法的更多信息，請參閱 Making LLMs even more accessible with bitsandbytes, 4-bit quantization and QLoRA 和 🤗 PEFT: Parameter-Efficient Fine-Tuning of Billion-Scale Models on Low-Resource Hardware。
資源
啟動訓練的命令在 run_peft.sh 中。總訓練時間為12.5小時。根據 lambdalabs，以 1.10 美元/小時的成本計算，總成本為 13.75 美元。那就相當不錯了🚀！就成本而言，它比完全微調的成本低7.8倍。
下圖顯示了 QLoRA 與完全微調的評估損失、訓練損失和學習率調度程序。我們觀察到，與 QLoRA 相比，完全微調會導致損失略低且收斂速度更快。 pef 微調的學習率比 full 微調的學習率高 10 倍。
為了確保我們的 QLoRA 模型不會導致災難性遺忘，我們在其上運行了 Python Human Eval。以下是我們得到的結果。 Pass@1 衡量完成的通過率，僅考慮每個問題產生的單一候選代碼。我們可以觀察到，基本 bigcode/starcoder（15B 參數）和微調 PEFT 模型 smangrul/peft-lora-starcoder15B-v2-personal-copilot-A100-40GB-colab 在 humaneval-python 上的表現相當。
|Model |Pass@1| |bigcode/starcoder |33.57| |smangrul/peft-lora-starcoder15B-v2-personal-copilot-A100-40GB-colab |33.37|
現在讓我們來看一些定性樣本。在我們的手動分析中，我們注意到 QLoRA 導致了輕微的過度擬合，因此我們透過 PEFT 的 add_weighted_adapter utility 程式創建權重為 0.8 的新加權適配器來降低其權重。
我們將看兩個程式碼填充範例，其中模型的任務是填入 <FILL_ME> 佔位符表示的部分。我們將考慮填滿來自 GitHub Copilot、QLoRA 微調模型和完整微調模型的補全。
Qualitative Example 1
在上面的範例中，GitHub Copilot 的補全是正確的，但沒有太大幫助。另一方面，QLoRA 的補全和完全微調的模型正確地用必要的參數填充了整個函數呼叫。然而，他們之後也增加了更多的噪音。這可以透過後處理步驟來控制，以將完成限制為右括號或新行。請注意，QLoRA 和完全微調模型都會產生類似品質的結果。
Qualitative Example 2
在上面的第二個範例中，GitHub Copilot 沒有給出任何補全資訊。這可能是因為 🤗 PEFT 是一個新函式庫，尚未成為 Copilot 訓練資料的一部分，而這正是我們試圖解決的問題類型。另一方面，QLoRA 的補全和完全微調的模型正確地用必要的參數填充了整個函數呼叫。
再次請注意，QLoRA 和完全微調的模型都提供了類似的品質。 Full_Fintuned_StarCoder_Inference.ipynb 和 PEFT_StarCoder_Inference.ipynb 分別提供了完整微調模型和 peft 模型的各種範例的推理程式碼。
因此，我們可以觀察到兩個變體的模型都符合預期。驚人！ 🚀
您可以使用 🤗 llm-vscode 來在 VS Code 中輕鬆配置自訂程式碼完成 LLM 的擴充，並透過 🤗 推理端點託管模型。我們將完成下面所需的步驟。您可以在推理端點文件中了解有關部署端點的更多詳細資訊。
以下是螢幕截圖，其中包含我們建立自訂推理端點所遵循的步驟。我們使用 QLoRA 模型，匯出為全尺寸合併模型，可以輕鬆載入到 Transformer 中。
只需按照安裝步驟操作即可。在設定中，取代下方欄位中的端點，使其指向您部署的 HF 推理端點。
用法如下：
到目前為止，我們訓練的模型被專門訓練為程式碼完成任務的個人副駕駛。他們沒有接受過進行對話或回答問題的訓練。 Octocoder 和 StarChat 是此類模型的很好的例子。本節簡要介紹如何實現這一目標。
資源
如果您曾嘗試使用 Stable Diffusion 模型和 LoRA 來製作自己的 Dreambooth 模型，那麼您可能熟悉將不同的 LoRA 與不同權重相結合的概念，即使用具有與訓練時不同的基礎模型的 LoRA 模型。在文字/程式碼領域，這仍然是未開發的領域。我們在這方面進行了實驗，並觀察到了非常有希望的發現。你準備好了嗎？我們走吧！ 🚀
原文: Optimizing your LLM in production
GPT¾、Falcon 和 LLama 等大型語言模型 (LLM) 處理以人為中心的任務的能力正在迅速提高，成為現代知識型產業的重要工具。然而，在現實世界的任務中部署這些模型仍然具有挑戰性：
這些挑戰的關鍵在於增強 LLM 的計算和儲存能力，特別是在處理廣泛的輸入序列時。
在這篇文章中，我們將回顧撰寫本文時最有效的技術，以應對高效 LLM 部署的這些挑戰：
在本文的範示筆記本中，我們將從張量的角度對自迴歸產生進行分析。我們深入研究了採用較低精度的利弊，對最新的注意力演算法進行了全面的探索，並討論了改進的 LLM 架構。在此過程中，我們運行實際範例來展示每項功能改進。
平台即產品(Platform as a product)正在成為工程組織中構建內部平台的越來越流行的方法。雖然軟件驅動的公司正在爭奪市場份額，但另一種更微妙的競爭正在興起：誰能讓他們的工程師最快地推出新功能？誰擁有最有效的內部平台？
在這篇文章中，我們將分享為 Wise（以前稱為 TransferWise）的平台工程團隊構建 KPI 樹的方法。從產品開發過程開始，我們將解釋如何塑造我們的平台願景，從而產生一組可操作的 KPI，我們用它們來識別最大的問題並持續衡量我們平台的性能。
KPI 樹的目的是幫助我們實現基於假設驅動的實驗和驗證學習的產品開發流程。儘管有大量關於實施產品開發流程的文獻，但更困難的部分是確定適用於平台工程領域的指標。
如上圖所示，產品開發過程從平台願景和模型開始。這些是不變的部分，應該很少改變。模型是指標或槓桿及其相互關係的表示。 KPI 樹是我們為本練習選擇的模型表示類型。讓我們從定義我們的平台願景開始，該願景最終會告知我們認為平台可以影響並負責的相關指標或 KPI。