個(gè)人編程助手: 訓(xùn)練你自己的編碼助手
在編程和軟件開(kāi)發(fā)這個(gè)不斷演變的領(lǐng)域中，對(duì)效率和生產(chǎn)力的追求催生了許多卓越的創(chuàng)新。其中一個(gè)顯著的創(chuàng)新就是代碼生成模型的出現(xiàn)，如 Codex、StarCoder 和 Code Llama。這些模型在生成類(lèi)似人類(lèi)編寫(xiě)的代碼片段方面表現(xiàn)出驚人能力，顯示出了作為編程助手的巨大潛力。
然而，雖然這些預(yù)訓(xùn)練模型在各種任務(wù)上已經(jīng)表現(xiàn)出了卓越的性能，但在不遠(yuǎn)的未來(lái)，我們?nèi)匀豢梢云诖粋€(gè)令人興奮的前景: 想象一下，你能夠根據(jù)自己的特定需求定制代碼生成模型，并且這種個(gè)性化的編程助手能夠在企業(yè)規(guī)模上得到應(yīng)用。
在這篇博客中，我們將展示如何創(chuàng)建 HugCoder ??，一個(gè)在?huggingface?GitHub 組織 的公共倉(cāng)庫(kù)代碼內(nèi)容上進(jìn)行微調(diào)的代碼大模型。我們將講述我們的數(shù)據(jù)收集工作流程、訓(xùn)練實(shí)驗(yàn)，以及一些有趣的結(jié)果。這將使你能夠根據(jù)你的專(zhuān)有代碼庫(kù)創(chuàng)建自己的個(gè)人編程助手。我們還將為這個(gè)項(xiàng)目的進(jìn)一步擴(kuò)展留下一些實(shí)驗(yàn)的方向。
讓我們開(kāi)始吧 ??
數(shù)據(jù)收集的工作流
我們想要的數(shù)據(jù)集在概念上非常簡(jiǎn)單，我們像下面所示那樣構(gòu)建它。
使用 Python GitHub API 從 GitHub 上抓取代碼內(nèi)容是直截了當(dāng)?shù)?。然而，這取決于倉(cāng)庫(kù)的數(shù)量和倉(cāng)庫(kù)內(nèi)代碼文件的數(shù)量，通常情況，人們很容易會(huì)遇到 API 速率限制等問(wèn)題。
為了防止這類(lèi)問(wèn)題發(fā)生，我們決定將所有公共倉(cāng)庫(kù)克隆到本地，并從中提取內(nèi)容，而不是通過(guò) API。我們使用 Python 的?multiprocessing?模塊并行下載所有倉(cāng)庫(kù)，如 這個(gè)下載腳本。
一個(gè)倉(cāng)庫(kù)通常可能包含非代碼文件，如圖片、演示文稿和其他資料。我們對(duì)抓取它們不感興趣。我們?yōu)榇藙?chuàng)建了一個(gè) 擴(kuò)展名列表 來(lái)過(guò)濾掉它們。為了解析除了 Jupyter Notebook 之外的代碼文件，我們簡(jiǎn)單地使用了 “utf-8” 編碼。對(duì)于 notebook，我們只考慮了代碼單元。
我們還排除了所有與代碼不直接相關(guān)的文件路徑。這些包括:?.git?，?__pycache__?和?xcodeproj?。
為了保持這些內(nèi)容的序列化相對(duì)內(nèi)存友好 (即處理代碼時(shí)不會(huì)過(guò)多占用內(nèi)存)，我們使用了分塊處理方法和 feather 格式 (儲(chǔ)存序列化的數(shù)據(jù))。完整實(shí)現(xiàn)請(qǐng)參見(jiàn) 這個(gè)腳本。
最終的數(shù)據(jù)集 可在 Hub 上獲取，它看起來(lái)像這個(gè)樣子:
對(duì)于這篇博客，我們選取了基于點(diǎn)贊數(shù)排名前十的 Hugging Face 公共倉(cāng)庫(kù)。它們分別是:
['transformers', 'pytorch-image-models', 'datasets', 'diffusers', 'peft', 'tokenizers', 'accelerate', 'text-generation-inference', 'chat-ui', 'deep-rl-class']
這是我們用來(lái)生成這個(gè)數(shù)據(jù)集的代碼，而 這是數(shù)據(jù)集在 Hub 上的鏈接。下面是它的一個(gè)快照:
為了降低項(xiàng)目復(fù)雜性，我們沒(méi)有考慮對(duì)數(shù)據(jù)集進(jìn)行去重。如果你對(duì)在生產(chǎn)應(yīng)用中應(yīng)用去重技術(shù)感興趣，這篇博客文章 是一個(gè)極佳的資源，它在代碼大模型的內(nèi)容中詳細(xì)討論了這個(gè)主題。
微調(diào)你的個(gè)人代碼助手
在這一部分，我們將展示如何微調(diào)以下模型:?bigcode/starcoder?(15.5B 參數(shù)) 、bigcode/starcoderbase-1b?(1B 參數(shù)) 和?Deci/DeciCoder-1b?(1B 參數(shù))。我們將使用一個(gè)帶有 40GB 顯存的 A100 Colab Notebook，并使用 ?? PEFT (Parameter-Efficient Fine-Tuning，參數(shù)高效微調(diào)) 進(jìn)行所有實(shí)驗(yàn)。此外，我們還將展示如何使用 ?? Accelerate 的 FSDP (Fully Sharded Data Parallel，全分片數(shù)據(jù)并行) 集成，在一臺(tái)配備 8 個(gè) 80GB 顯存的 A100 GPU 的機(jī)器上完全微調(diào)?bigcode/starcoder?(15.5B 參數(shù))。訓(xùn)練目標(biāo)是 ?fill in the middle (FIM) ，其中訓(xùn)練序列的一部分被移動(dòng)到序列的末尾，并且重排序后的序列被自回歸地預(yù)測(cè)。
為什么選擇 PEFT ？因?yàn)槿⒄{(diào)代價(jià)高昂。讓我們來(lái)看一些數(shù)字以便更好地理解:
全微調(diào)所需的最小 GPU 內(nèi)存:
參數(shù)權(quán)重: 2 字節(jié) (混合精度訓(xùn)練)
參數(shù)權(quán)重梯度: 2 字節(jié)
使用 Adam 優(yōu)化器時(shí)的優(yōu)化器狀態(tài): 4 字節(jié)用于原始 FP32 權(quán)重 + 8 字節(jié)用于一階和二階矩估計(jì)
將以上所有內(nèi)容加在一起的每個(gè)參數(shù)成本: 每個(gè)參數(shù) 16 字節(jié)
15.5B 模型 -> 248GB 的 GPU 內(nèi)存，甚至還沒(méi)有考慮存儲(chǔ)中間激活值所需的巨大內(nèi)存 -> 至少需要 4 個(gè) A100 80GB GPU
由于硬件需求巨大，我們將使用 QLoRA 進(jìn)行參數(shù)高效微調(diào)。下面是使用 QLoRA 進(jìn)行 Starcoder 微調(diào)的最小 GPU 內(nèi)存需求:
trainable params: 110,428,160 || all params: 15,627,884,544 || trainable%: 0.7066097761926236
基礎(chǔ)模型權(quán)重: 0.5 字節(jié) * 15.51B 凍結(jié)參數(shù) = 7.755GB
適配器 (Adapter) 權(quán)重: 2 字節(jié) * 0.11B 可訓(xùn)練參數(shù) = 0.22GB
權(quán)重梯度: 2 字節(jié) * 0.11B 可訓(xùn)練參數(shù) = 0.22GB
使用 Adam 優(yōu)化器時(shí)的優(yōu)化器狀態(tài): 4 字節(jié) * 0.11B 可訓(xùn)練參數(shù) * 3 = 1.32GB
將以上所有內(nèi)容加在一起 -> 9.51GB ~ 10GB -> 需要 1 個(gè) A100 40GB GPU???。選擇 A100 40GB GPU 的原因是，訓(xùn)練時(shí)長(zhǎng)序列長(zhǎng)度為 2048，批量大小為 4，這會(huì)導(dǎo)致更高的內(nèi)存需求。如下所示，所需的 GPU 內(nèi)存為 26GB，可以在 A100 40GB GPU 上容納。此外，A100 GPU 與 Flash Attention 2 具有更好的兼容性。
在上面的計(jì)算中，我們沒(méi)有考慮中間激活值檢查點(diǎn)所需的內(nèi)存，這通常是相當(dāng)巨大的。我們利用 Flash Attention V2 和梯度檢查點(diǎn)來(lái)解決這個(gè)問(wèn)題。
對(duì)于 QLoRA，加上 flash attention V2 和梯度檢查點(diǎn)，單個(gè) A100 40GB GPU 上模型占用的總內(nèi)存為?26GB，?批量大小為 4。
對(duì)于使用 FSDP 進(jìn)行全微調(diào)，加上 Flash Attention V2 和梯度檢查點(diǎn)，每個(gè) GPU 上占用的內(nèi)存在?70GB 到 77.6GB?之間，?每個(gè) GPU 的批量大小為 1。
請(qǐng)參考 model-memory-usage 以輕松計(jì)算在 ?? Hugging Face Hub 上托管的大型模型上進(jìn)行訓(xùn)練和推理所需的 vRAM。
全微調(diào)
我們將探討如何使用 PyTorch Fully Sharded Data Parallel (FSDP) 技術(shù)在 8 個(gè) A100 80GB GPU 上完全微調(diào)?bigcode/starcoder?(15B 參數(shù))。欲了解更多關(guān)于 FSDP 的信息，請(qǐng)參閱 Fine-tuning Llama 2 70B using PyTorch FSDP 和 Accelerate Large Model Training using PyTorch Fully Sharded Data Parallel。
資源
代碼庫(kù): 鏈接。它使用了 Transformers 中最近添加的 Flash Attention V2 支持。
FSDP 配置: fsdp_config.yaml
模型: bigcode/stacoder
數(shù)據(jù)集: smangrul/hf-stack-v1
微調(diào)后的模型: smangrul/peft-lora-starcoder15B-v2-personal-copilot-A100-40GB-colab
啟動(dòng)訓(xùn)練的命令在 run_fsdp.sh 中給出。
總的訓(xùn)練時(shí)間為?9 小時(shí)。根據(jù) lambdalabs 的價(jià)格，8 個(gè) A100 80GB GPU 的成本為每小時(shí) $12.00，總成本將為?$108。
PEFT
我們將探討如何使用 ?? PEFT 的 QLoRA 方法對(duì)?bigcode/starcoder?(15B 參數(shù)) 進(jìn)行微調(diào)，使用的硬件是單個(gè) A100 40GB GPU。有關(guān) QLoRA 和 PEFT 方法的更多信息，請(qǐng)參閱 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。
資源
代碼庫(kù): 鏈接。它使用了 Transformers 中最近添加的 Flash Attention V2 支持。
Colab notebook: 鏈接。請(qǐng)確保選擇帶有 High RAM 設(shè)置的 A100 GPU。
模型: bigcode/stacoder
數(shù)據(jù)集: smangrul/hf-stack-v1
QLoRA 微調(diào)模型: smangrul/peft-lora-starcoder15B-v2-personal-copilot-A100-40GB-colab
啟動(dòng)訓(xùn)練的命令在 run_peft.sh 中給出。總的訓(xùn)練時(shí)間為?12.5 小時(shí)。根據(jù) lambdalabs 的價(jià)格，每小時(shí)?$1.10，總成本將為?$13.75。這真是太棒了??！從成本上講，它比全微調(diào)的成本低了?7.8 倍。
對(duì)比
下面的圖展示了 QLoRA 與全微調(diào)的評(píng)估損失、訓(xùn)練損失和學(xué)習(xí)率調(diào)度器。我們觀察到，全微調(diào)的損失略低，收斂速度也略快一些，與 QLoRA 相比。PEFT 微調(diào)的學(xué)習(xí)率是全微調(diào)的 10 倍。
為了確保我們的 QLoRA 模型不會(huì)導(dǎo)致災(zāi)難性遺忘，我們?cè)谄渖线\(yùn)行了 Python Human Eval。以下是我們得到的結(jié)果。Pass@1?評(píng)估了單個(gè)問(wèn)題的通過(guò)率，考慮了每個(gè)問(wèn)題僅生成一個(gè)代碼候選。我們可以觀察到，在?humaneval-python?上，基礎(chǔ)模型?bigcode/starcoder?(15B 參數(shù)) 和微調(diào)后的 PEFT 模型?smangrul/peft-lora-starcoder15B-v2-personal-copilot-A100-40GB-colab?的性能是可比的。
現(xiàn)在讓我們來(lái)看一些定性的樣本。在我們的手動(dòng)分析中，我們注意到 QLoRA 導(dǎo)致了輕微的過(guò)擬合，因此我們通過(guò)使用 PEFT 的?add_weighted_adapter?工具，創(chuàng)建一個(gè)權(quán)重為 0.8 的新加權(quán)適配器 (Adapter) 來(lái)降低其權(quán)重。
我們將看兩個(gè)代碼填充的例子，其中模型的任務(wù)是填充由?<FILL_ME>?占位符表示的部分。我們將考慮從 GitHub Copilot、QLoRA 微調(diào)模型和全微調(diào)模型的填充完成。
定性示例 1
在上面的示例中，GitHub Copilot 的補(bǔ)全是正確的，但幫助不大。另一方面，QLoRA 和全微調(diào)模型的補(bǔ)全正確地填充了整個(gè)函數(shù)調(diào)用及其必要的參數(shù)。然而，它們之后也添加了許多噪聲。這可以通過(guò)后處理步驟來(lái)控制，以限制補(bǔ)全到閉括號(hào)或新行。注意，QLoRA 和全微調(diào)模型產(chǎn)生的結(jié)果質(zhì)量相似。
定性示例 2
在上面的第二個(gè)示例中，?GitHub Copilot 沒(méi)有給出任何補(bǔ)全。這可能是因?yàn)??? PEFT 是一個(gè)最近的庫(kù)，還沒(méi)有成為 Copilot 訓(xùn)練數(shù)據(jù)的一部分，這?正是我們?cè)噲D解決的問(wèn)題類(lèi)型。另一方面，QLoRA 和全微調(diào)模型的補(bǔ)全正確地填充了整個(gè)函數(shù)調(diào)用及其必要的參數(shù)。再次注意，QLoRA 和全微調(diào)模型提供的生成質(zhì)量相似。全微調(diào)模型和 PEFT 模型的各種示例的推理代碼分別可在 Full_Finetuned_StarCoder_Inference.ipynb 和 PEFT_StarCoder_Inference.ipynb 中找到。
因此，我們可以觀察到，兩種變體的生成都符合預(yù)期。太棒了！??
怎么在 VS Code 中使用?
你可以輕松地使用 ?? llm-vscode VS Code 擴(kuò)展配置一個(gè)自定義的代碼補(bǔ)全大模型，并通過(guò) ?? Inference EndPoints 托管模型。我們將在下面逐步介紹所需的步驟。你可以在 推理端點(diǎn)文檔 中了解有關(guān)部署端點(diǎn)的更多詳細(xì)信息。
設(shè)置推理端點(diǎn)
下面是我們創(chuàng)建自定義推理端點(diǎn)時(shí)遵循的步驟的截圖。我們使用了我們的 QLoRA 模型，導(dǎo)出為一個(gè)可以輕松加載到?transformers?中的全尺寸的?merged?模型。
設(shè)置 VS Code 擴(kuò)展
只需按照 安裝步驟 操作。在設(shè)置中，將下面字段中的端點(diǎn)替換為你部署的 HF 推理端點(diǎn)的地址。
使用起來(lái)如下所示:
微調(diào)你自己的代碼聊天助手
到目前為止，我們訓(xùn)練的模型特別是作為代碼完成任務(wù)的個(gè)人助手培訓(xùn)。它們沒(méi)有被訓(xùn)練來(lái)進(jìn)行對(duì)話或回答問(wèn)題。Octocoder?和?StarChat?是這類(lèi)模型的絕佳示例。本節(jié)簡(jiǎn)要描述了如何實(shí)現(xiàn)這一點(diǎn)。
資源
代碼庫(kù): 鏈接。它使用了 Transformers 中最近添加的 Flash Attention V2 支持。
Colab notebook: 鏈接。請(qǐng)確保選擇帶有 High RAM 設(shè)置的 A100 GPU。
模型: bigcode/stacoderplus
數(shù)據(jù)集: smangrul/code-chat-assistant-v1?；旌狭?
LIMA+GUANACO?并以適合訓(xùn)練的格式正確格式化。訓(xùn)練好的模型: smangrul/peft-lora-starcoderplus-chat-asst-A100-40GB-colab
LoRA 的組合
如果你曾經(jīng)涉足 Stable Diffusion 模型和 LoRAs，以及用于制作你自己的 Dreambooth 模型，你可能會(huì)熟悉將不同的 LoRAs 與不同的權(quán)重結(jié)合起來(lái)的概念，使用一個(gè)與其訓(xùn)練基模型不同的 LoRA 模型。在文本/代碼領(lǐng)域，目前仍是未被探索的領(lǐng)域。我們?cè)谶@方面進(jìn)行了實(shí)驗(yàn)，并觀察到了非常有趣的發(fā)現(xiàn)。你準(zhǔn)備好了嗎？我們出發(fā)吧！??
混合匹配 LoRAs
PEFT 目前支持 3 種結(jié)合 LoRA 模型的方式，linear?、?svd?和?cat?。更多細(xì)節(jié)，請(qǐng)參考 tuners#peft.LoraModel.add_weighted_adapter。
我們的 notebook Dance_of_LoRAs.ipynb 提供了所有推理代碼，并展示了多種 LoRA 模型的加載組合。例如，它展示了如何在?starcoder?模型上加載聊天助手適配器 (Adapter)，盡管?starcoderplus?是我們用于微調(diào)的基礎(chǔ)模型。
這里，我們將考慮 2 種能力 (?聊天/問(wèn)答?和?代碼完成?) 在 2 種數(shù)據(jù)分布 (?前 10 公共 hf 代碼庫(kù)?和?通用代碼庫(kù)?) 上。這給了我們 4 個(gè)軸，我們將在上面進(jìn)行一些定性評(píng)估分析。
首先，讓我們考慮聊天/問(wèn)答?任務(wù)。
如果我們禁用適配器 (Adapter)，我們觀察到對(duì)于兩個(gè)數(shù)據(jù)集來(lái)說(shuō)任務(wù)都失敗了，因?yàn)榛Ｐ?(?starcoder?) 僅用于代碼完成，不適合?聊天/問(wèn)答?。啟用?copilot?適配器 (Adapter) 的表現(xiàn)類(lèi)似于禁用的情況，因?yàn)檫@個(gè) LoRA 也是專(zhuān)門(mén)為代碼完成而微調(diào)的。
現(xiàn)在，讓我們啟用?assistant?適配器 (Adapter)。
基于生成代碼的 QA
基于 HF 代碼的 QA
我們可以觀察到，關(guān)于?scrapy?的通用問(wèn)題得到了妥善的回答。然而，它未能解答與 HF (Hugging Face) 代碼相關(guān)的問(wèn)題，因?yàn)檫@不是它預(yù)訓(xùn)練數(shù)據(jù)的一部分。
現(xiàn)在讓我們考慮?代碼補(bǔ)全?任務(wù)。
在禁用適配器 (Adapter) 時(shí)，我們觀察到對(duì)于通用的兩數(shù)之和問(wèn)題，代碼補(bǔ)全如預(yù)期般工作正常。然而，對(duì)于 HF 代碼補(bǔ)全任務(wù)，由于基礎(chǔ)模型在其預(yù)訓(xùn)練數(shù)據(jù)中未曾見(jiàn)過(guò)，所以在向?LoraConfig?傳遞參數(shù)時(shí)出現(xiàn)了錯(cuò)誤。啟用?assistant?的表現(xiàn)與禁用時(shí)相似，因?yàn)樗窃谧匀徽Z(yǔ)言對(duì)話的基礎(chǔ)上訓(xùn)練的，這些對(duì)話中沒(méi)有任何 Hugging Face 代碼倉(cāng)庫(kù)的內(nèi)容。
現(xiàn)在，讓我們啟用?copilot?適配器 (Adapter)。
我們可以觀察到，在兩種情況下?copilot?適配器 (Adapter) 都得到了正確的結(jié)果。因此，無(wú)論是在處理 HF (Hugging Face) 特定代碼庫(kù)還是通用代碼庫(kù)時(shí)，它都能如預(yù)期地完成代碼補(bǔ)全任務(wù)。
現(xiàn)在，作為用戶(hù)，我希望能結(jié)合?assistant?和?copilot?的能力。這將使我能夠在 IDE 中編碼時(shí)使用它進(jìn)行代碼補(bǔ)全，同時(shí)也能將它作為聊天機(jī)器人來(lái)回答我關(guān)于 API、類(lèi)、方法、文檔的問(wèn)題。它應(yīng)該能夠提供對(duì)問(wèn)題的答案，如?我該如何使用 x?，請(qǐng)?jiān)谖业拇a的基礎(chǔ)上?為 Y 編寫(xiě)一段代碼片段?。
PEFT 允許你通過(guò)?add_weighted_adapter?來(lái)實(shí)現(xiàn)這一點(diǎn)。讓我們創(chuàng)建一個(gè)新的適配器?code_buddy?，給予?assistant?和?copilot?適配器相同的權(quán)重。
結(jié)合多種適配器 (Adapter)
現(xiàn)在，讓我們看看?code_buddy?在?聊天/問(wèn)答?任務(wù)上的表現(xiàn)。
我們可以觀察到?code_buddy?的表現(xiàn)比單獨(dú)的?assistant?或?copilot?適配器要好得多！它能夠回答?編寫(xiě)代碼片段?的請(qǐng)求，展示如何使用特定的 HF 倉(cāng)庫(kù) API。然而，它也出現(xiàn)了錯(cuò)誤鏈接/解釋的幻覺(jué)，這仍然是大型語(yǔ)言模型面臨的一個(gè)開(kāi)放性挑戰(zhàn)。
下面是?code_buddy?在代碼補(bǔ)全任務(wù)上的表現(xiàn)。
我們可以觀察到?code_buddy?的表現(xiàn)與專(zhuān)門(mén)為這個(gè)任務(wù)微調(diào)的?copilot?不相上下。
將 LoRA 模型遷移到不同的基礎(chǔ)模型
我們還可以將 LoRA 模型遷移到不同的基礎(chǔ)模型上。我們將取剛出爐的?Octocoder?模型，并在其上應(yīng)用我們之前用?starcoder?基礎(chǔ)模型訓(xùn)練的 LoRA。請(qǐng)查看以下 notebook PEFT_Personal_Code_CoPilot_Adapter_Transfer_Octocoder.ipynb，了解全部代碼。
代碼補(bǔ)全任務(wù)上的表現(xiàn)
我們可以觀察到?octocoder?的表現(xiàn)很好。它能夠完成 HF (Hugging Face) 特定的代碼片段。如 notebook 中所見(jiàn)，它也能夠完成通用的代碼片段。
聊天/問(wèn)答任務(wù)上的表現(xiàn)
由于 Octocoder 被訓(xùn)練用來(lái)回答有關(guān)編程的問(wèn)題和進(jìn)行對(duì)話，讓我們看看它是否能使用我們的 LoRA 適配器來(lái)回答 HF (Hugging Face) 特定的問(wèn)題。
太棒了！它詳細(xì)正確地回答了如何創(chuàng)建?LoraConfig?和相關(guān)的 peft 模型，并且正確地使用了模型名稱(chēng)、數(shù)據(jù)集名稱(chēng)以及 LoraConfig 的參數(shù)值。當(dāng)禁用適配器時(shí)，它未能正確使用?LoraConfig?的 API 或創(chuàng)建 PEFT 模型，這表明它不是 Octocoder 訓(xùn)練數(shù)據(jù)的一部分。
我如何在本地運(yùn)行它？
我知道，在經(jīng)歷了這一切之后，你想在你自己的代碼庫(kù)上微調(diào) starcoder 并在本地使用，比如在帶有 M1 GPU 的 Mac 筆記本電腦上，或者帶有 RTX 4090/3090 GPU 的 Windows 電腦上……別擔(dān)心，我們已經(jīng)為你準(zhǔn)備好了。
我們將使用這個(gè)超酷的開(kāi)源庫(kù) mlc-llm ??。具體來(lái)說(shuō)，我們將使用這個(gè)分支 pacman100/mlc-llm，它進(jìn)行了一些修改，可以與 VS Code 的 Hugging Face 代碼完成擴(kuò)展配合使用。在我的搭載 M1 Metal GPU 的 Mac 筆記本上，15B 模型運(yùn)行得非常慢。因此，我們將縮小規(guī)模，訓(xùn)練一個(gè) PEFT LoRA 版本以及一個(gè)完全微調(diào)版本的?bigcode/starcoderbase-1b?。以下是訓(xùn)練用的 Colab notebook 鏈接:
全微調(diào)和 PEFT LoRA 微調(diào)?
starcoderbase-1b?的 Colab notebook: 鏈接
下面繪制了訓(xùn)練損失、評(píng)估損失以及學(xué)習(xí)率計(jì)劃圖:
現(xiàn)在，我們將看看詳細(xì)步驟，本地托管合并后的模型 smangrul/starcoder1B-v2-personal-copilot-merged 并使用 ?? llm-vscode VS Code 擴(kuò)展。
克隆倉(cāng)庫(kù)?
2. 安裝 mlc-ai 和 mlc-chat (在編輯模式):
3. 通過(guò)以下方式編譯模型:
4. 在?dist/starcoder1B-v2-personal-copilot-merged-q4f16_1/params/mlc-chat-config.json?中更新配置，設(shè)定以下的值:
5. 運(yùn)行本地服務(wù):
6. 將 VS Code 中的 HF Code Completion 擴(kuò)展的端點(diǎn)更改為指向本地服務(wù)器:
7. 在 VS Code 中打開(kāi)一個(gè)新文件，粘貼下面的代碼，并將光標(biāo)放在文檔引號(hào)之間，這樣模型就會(huì)嘗試填充文檔字符串:
瞧！??
這篇文章開(kāi)頭的演示就是這個(gè) 1B 模型在我的 Mac 筆記本上本地運(yùn)行的效果。
結(jié)論
在這篇博客中，我們探索了如何對(duì)?starcoder?進(jìn)行微調(diào)，從而創(chuàng)建了一個(gè)能理解我們代碼的個(gè)人編程助手。我們稱(chēng)之為 ?? HugCoder，因?yàn)樗窃?Hugging Face 的代碼上進(jìn)行訓(xùn)練的 :) 在回顧了數(shù)據(jù)收集流程之后，我們對(duì)比了使用 QLoRA 和全面微調(diào)進(jìn)行訓(xùn)練的效果。我們還嘗試了組合不同的 LoRAs，這在文本和代碼領(lǐng)域是一項(xiàng)尚待開(kāi)發(fā)的技術(shù)。在部署方面，我們研究了使用 ?? Inference Endpoints 進(jìn)行遠(yuǎn)程推理，并且還展示了如何在 VS Code 和 MLC 上本地執(zhí)行一個(gè)較小的模型。
如果你將這些方法應(yīng)用到了你自己的代碼庫(kù)，請(qǐng)告訴我們！
致謝
我們要感謝 Pedro Cuenca、Leandro von Werra、Benjamin Bossan、Sylvain Gugger 和 Loubna Ben Allal 在撰寫(xiě)這篇博客時(shí)提供的幫助。
英文原文:?https://hf.co/blog/personal-copilot
原文作者: Sourab Mangrulkar, Sayak Paul
譯者: innovation64
審校/排版: zhongdongy (阿東)
