Skip to content

2023

Personal Copilot: 訓練自己的程式設計助手

在不斷發展的程式設計和軟體開發領域，對效率和生產力的追求帶來了顯著的創新。其中一項創新就是 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 公共儲存庫。它們是：

  • 'transformers'
  • 'pytorch-image-models'
  • 'datasets'
  • 'diffusers'
  • 'peft'
  • 'tokenizers'
  • 'accelerate'
  • 'text-generation-inference'
  • 'chat-ui'
  • 'deep-rl-class'

這是我們用來產生此資料集的程式碼，這是 Hub 中的資料集。

為了降低專案複雜度，我們沒有考慮資料集的去重。如果您有興趣在生產應用程式中應用重複資料刪除技術，這篇部落格文章是關於 code LLMs 案例的優秀參考資源。

微調 Personal Co-Pilot

在本節中，我們將展示如何微調以下模型：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 記憶體：

  • 權重：2 bytes（混合精準度訓練）
  • 權重梯度：2 bytes
  • 使用 Adam 時的最佳化器狀態：4 bytes 於原始 FP32 權重 + 8 bytes 用於第一和第二矩估計
  • 添加所有上述內容的每個參數的成本：每個參數 16 bytes
  • 15.5B 模型 -> 248GB GPU 內存，甚至無需考慮存儲中間激活的巨大內存要求 -> 至少需要 4X A100 80GB GPU

由於硬體要求很高，我們將使用 QLoRA 進行參數高效的微調。以下是使用 QLoRA 微調 StarCoder 的最低 GPU 記憶體需求：

可訓練參數：110,428,160 || 所有參數：15,627,884,544 || 可訓練％：0.7066097761926236

  • 基本模型權重：0.5 byte * 15.51B 凍結參數 = 7.755 GB
  • 適配器權重：2 bytes * 0.11B 可訓練參數 = 0.22GB
  • 權重梯度：2 bytes * 0.11B 可訓練參數 = 0.12GB
  • 使用 Adam 時的最佳化器狀態：4 byes * 0.11B 可訓練參數 * 3 = 1.32GB
  • 加總上述對於記憶體的所有內容 -> 9.51 GB ~ 10GB -> 需要 1 個 A100 40GB GPU。使用 A100 40GB GPU 的原因是，訓練時長序列長度為 2048 且批量大小為 4 的中間激活會導致更高的記憶體需求。如下所示，所需的 GPU 記憶體為 26GB，A100 40GB GPU 可以容納。此外，A100 GPU 與 Flash Attention 2 具有更好的兼容性。

在上面的計算中，我們沒有考慮中間激活檢查點所需的內存，該內存相當大。我們利用 Flash Attention V2 和梯度檢查點來解決這個問題。

  • 對於 QLoRA 以及 Flash attention V2 和梯度檢查點，模型在單一 A100 40GB GPU 上佔用的總記憶體為 26 GB，批次大小為 4。
  • 對於使用 FSDP 以及 Flash Attention V2 和梯度檢查點進行完全微調，每個 GPU 佔用的記憶體範圍在 70 GB 到 77.6 GB 之間，per_gpu_batch_size 為 1。

請參閱 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 美元。

PEFT

接下來我們將了解如何使用 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 模型的各種範例的推理程式碼。

因此，我們可以觀察到兩個變體的模型都符合預期。驚人！ 🚀

如何在 VS Code 中使用它？

您可以使用 🤗 llm-vscode 來在 VS Code 中輕鬆配置自訂程式碼完成 LLM　的擴充，並透過 🤗 推理端點託管模型。我們將完成下面所需的步驟。您可以在推理端點文件中了解有關部署端點的更多詳細資訊。

設定推理端點

以下是螢幕截圖，其中包含我們建立自訂推理端點所遵循的步驟。我們使用 QLoRA 模型，匯出為全尺寸合併模型，可以輕鬆載入到 Transformer 中。

設定 VS 代碼擴展

只需按照安裝步驟操作即可。在設定中，取代下方欄位中的端點，使其指向您部署的 HF 推理端點。

用法如下：

微調您自己的 Code Chat Assistant

到目前為止，我們訓練的模型被專門訓練為程式碼完成任務的個人副駕駛。他們沒有接受過進行對話或回答問題的訓練。 Octocoder 和 StarChat 是此類模型的很好的例子。本節簡要介紹如何實現這一目標。

資源

LoRA 之舞

如果您曾嘗試使用 Stable Diffusion 模型和 LoRA 來製作自己的 Dreambooth 模型，那麼您可能熟悉將不同的 LoRA 與不同權重相結合的概念，即使用具有與訓練時不同的基礎模型的 LoRA 模型。在文字/程式碼領域，這仍然是未開發的領域。我們在這方面進行了實驗，並觀察到了非常有希望的發現。你準備好了嗎？我們走吧！ 🚀

  • in LLM
  • 10 min read

在生產環境中優化您的 LLM

原文: Optimizing your LLM in production

GPT¾、Falcon 和 LLama 等大型語言模型 (LLM) 處理以人為中心的任務的能力正在迅速提高，成為現代知識型產業的重要工具。然而，在現實世界的任務中部署這些模型仍然具有挑戰性：

  • 為了展現接近人類的文本理解和生成能力，LLM 目前需要由數十億個參數組成（參見 Kaplan 等人、Wei 等人）。因此，這放大了推理的記憶體需求。
  • 在許多現實世界的任務中，LLM 需要獲得廣泛的背景資訊。這需要模型能夠在推理過程中管理很長的輸入序列。

這些挑戰的關鍵在於增強 LLM 的計算和儲存能力，特別是在處理廣泛的輸入序列時。

在這篇文章中，我們將回顧撰寫本文時最有效的技術，以應對高效 LLM 部署的這些挑戰：

  1. Lower Precision: 研究表明，降低的 LLM 模型參數的數值精度（即 8-bit 和 4-bit）可以實現計算優勢，而不會顯著降低模型性能。
  2. Flash Attention: Flash Attention 是 attention 演算法的變體，它不僅提供了一種更節省記憶體的方法，而且由於優化了 GPU 記憶體利用率而實現了效率的提高。
  3. Architectural Innovations: 考慮到 LLM 在推論過程中總是以相同的方式部署，即具有長輸入上下文的自回歸文本生成 (autoregressive text generation)，因此提出了專門的模型架構，以實現更有效的推論。模型架構中最重要的進展是 Alibi、Rotary embeddings、Multi-Query Attention (MQA) 和 Grouped-Query-Attention (GQA)。

在本文的範示筆記本中，我們將從張量的角度對自迴歸產生進行分析。我們深入研究了採用較低精度的利弊，對最新的注意力演算法進行了全面的探索，並討論了改進的 LLM 架構。在此過程中，我們運行實際範例來展示每項功能改進。

平台工程 KPIs

原文: Platform Engineering KPIs

平台即產品(Platform as a product)正在成為工程組織中構建內部平台的越來越流行的方法。雖然軟件驅動的公司正在爭奪市場份額，但另一種更微妙的競爭正在興起：誰能讓他們的工程師最快地推出新功能？誰擁有最有效的內部平台？

在這篇文章中，我們將分享為 Wise（以前稱為 TransferWise）的平台工程團隊構建 KPI 樹的方法。從產品開發過程開始，我們將解釋如何塑造我們的平台願景，從而產生一組可操作的 KPI，我們用它們來識別最大的問題並持續衡量我們平台的性能。

產品開發流程

KPI 樹的目的是幫助我們實現基於假設驅動的實驗和驗證學習的產品開發流程。儘管有大量關於實施產品開發流程的文獻，但更困難的部分是確定適用於平台工程領域的指標。

如上圖所示，產品開發過程從平台願景和模型開始。這些是不變的部分，應該很少改變。模型是指標或槓桿及其相互關係的表示。 KPI 樹是我們為本練習選擇的模型表示類型。讓我們從定義我們的平台願景開始，該願景最終會告知我們認為平台可以影響並負責的相關指標或 KPI。

Llama 2 Prompting 的指南

原文: A guide to prompting Llama 2

宣傳像 Llama 2 這樣的大型語言模型是一門藝術也是一門科學。在這篇文章中，我們將介紹在探索 Llama 2 學到的內容，包括如何格式化聊天提示、何時使用哪種 Llama 變體、何時使用 ChatGPT 而不是 Llama、系統提示如何工作以及一些提示和技巧。

要精通 LLM 的應用還有很多東西需要學習，但是您應該在離開這篇文章時更好地了解如何成為一名擅長與 Llama2 模型互動的人。

下列的相關提示, 建議使用線上免費 a16z-infra/llama-2-13b-chat 的網站服務來練習與驗證。

  • in Llama2
  • 5 min read

免費試用 LLAMA 2 的 8 種方式

原文: 8 WAYS TO TRY LLAMA 2 FROM META FOR FREE

Llama2 以其非凡的基準震撼了 LLM 世界，並通過 OpenAI 和 Anthropic 等 AI 平台對現有的頂尖閉源 LLM 提出了直接挑戰。 Llama 模型很好，但 Llama 2 更加強大和準確，甚至可以影響 ChatGPT 用戶。

自從 Meta 宣布發布 Llama 2 之後，人們已經構建了聊天機器人，您可以嘗試一下。大多數聊天機器人都是付費的，但如果您渴望免費嘗試 Llama 2，那麼不用擔心，本文列出了 8 種測試和嘗試 Llama 2 的方法。

要了解 Llama 2 與其他 LLM 相比的功能，只需查看下圖即可。對於一個開源且可供公眾免費使用的模型來說，這些都是非同尋常的。

讓我們首先嘗試了解 Llama 及其工作原理。

使用 AutoGPTQ 和 transformers 讓大語言模型更輕量化

原文: Making LLMs lighter with AutoGPTQ and transformers

大語言模型在理解和生成人類水平的文字方面所展現出的非凡能力，正在許多領域帶來應用上的革新。然而，在消費級硬件上訓練和部署大語言模型的需求也變得越來越難以滿足。

🤗 Hugging Face 的核心使命是 讓優秀的機器學習普及化 ，而這正包括了盡可能地讓所有人都能夠使用上大語言模型。本著與 bitsandbytes 合作一樣的精神，我們將 AutoGPTQ 代碼庫集成到了 Transformers 中，讓用戶使用 GPTQ 算法(Frantar et al. 2023) 在 8-bit、4-bit、3-bit，甚至是 2-bit 精度下量化和運行模型成為可能。當使用 4-bit 量化時，精度的下降相當微小，同時在小批量推理上保持著與 fp16 baseline 相當的速度。需要注意的是，GPTQ 方法與 bitsandbytes 提出的訓練後量化方法有所不同：它需要在量化階段提供一個校準數據集(calibration dataset)。

本次整合支持 Nvidia GPU 和基於 RoCm-powered 的 AMD GPU。

bitsandbytes 、4-bit quantization 和 QLoRA

原文: Making LLMs even more accessible with bitsandbytes, 4-bit quantization and QLoRA

眾所周知，LLM 參數規模龐大，在消費類硬件中運行或訓練它們對於用戶和可訪問性來說是一個巨大的挑戰。我們的 LLM.int8 博客文章 展示瞭如何使用 bitsandbytes 套件將 LLM.int8 論文中的技術集成到 transformer 中。

當我們努力讓模型更容易被任何人使用時，我們決定再次與 bitsandbytes 合作，允許用戶以 4-bit 精度運行模型。這包括任何模態（文本、視覺、多模態等）的絕大多數 HF 模型。用戶還可以利用 Hugging Face 生態系統中的工具在 4bit 模型之上訓練 adapters。這是 Dettmers 等人今天在 QLoRA 論文中介紹的一種新方法。