CodeLlama – 70B，基礎(chǔ)編碼模型；
CodeLlama – 70B – Python，專門用于 Python 編碼的 70B 模型；
Code Llama – 70B – Instruct 70B，針對自然語言指令理解進行微調(diào)的版本。
為了對比現(xiàn)有解決方案測試 Code Llama 的性能表現(xiàn)，Meta 選擇了兩項流行的編碼基準(zhǔn)：HumanEval 與 Mostly Basic Ptyon Programming（MBPP）。其中 HumanEval 主要測試模型根據(jù)文檔字符串補全代碼的能力，而 MBPP 則測試模型根據(jù)描述編寫代碼的能力。
從基準(zhǔn)測試結(jié)果來看，Code Llama 的表現(xiàn)優(yōu)于編碼專用的開源 Llama，甚至超越了 Llama 2。例如，Code Llama 34B 在 HumanEval 上的得分為 53.7%，優(yōu)于 GPT-3.5 的 48.1%，更接近 OpenAI 論文報告的 GPT-4 的 67%。在 MBPP 上，Code Llama 34B 得分為 56.2%，超越了其他最先進的開源解決方案，已經(jīng)與 ChatGPT 基本持平。
扎克伯格在 Facebook 上說道，“編寫和編輯代碼已經(jīng)成為當(dāng)今人工智能模型最重要的用途之一。編碼能力也被證明對人工智能模型更嚴(yán)格、更符合邏輯地處理其他領(lǐng)域的信息非常重要。我對這個進展感到自豪，并期待 Llama 3 和未來的模型中包括這些進展。”
Code Llama 是 Llama 2 模型的編碼專用版本，是后者在編碼數(shù)據(jù)集之上接受進一步訓(xùn)練的產(chǎn)物，且數(shù)據(jù)采集周期更長。從本質(zhì)上講，Code Llama 擁有比 Llama 2 更強的編碼功能。它可以根據(jù)代碼和自然語言提示詞生成代碼及與代碼相關(guān)的自然語言（例如，“為我這一條輸出斐波那契序列的函數(shù)”），亦可用于代碼補全和調(diào)試。
Code Llama 支持當(dāng)今多種高人氣編程語言，包括 Python、C++、Java、PHP、Typescript (Javascript)、C# 和 Bash。
這次，Meta 將發(fā)布四種 Code Llama 模型版本，參數(shù)分別為 7B、13B、34B 和 70B。各模型版本使用 500B 代碼 token 與代碼相關(guān)數(shù)據(jù)進行訓(xùn)練，且 70B 模型則采用 1TB token 進行訓(xùn)練。7B 與 13B 基礎(chǔ)與指令模型還經(jīng)過 fill-in-the-middle（FIM）訓(xùn)練，允許向現(xiàn)有代碼中插入新代碼，因此可以支持開箱即用的代碼補全等任務(wù)。
三種模型分別能夠滿足不同的服務(wù)與延遲要求。例如，7B 模型可以在單一 GPU 上運行。34B 和 70B 模型則可返回最佳結(jié)果并提供更好的編碼輔助功能。其中 7B 與 13B 模型運行速度更快，適合實時代碼補全等強調(diào)低延遲的編碼任務(wù)。
Code Llama 模型可實現(xiàn)最多 10 萬個上下文 token 的穩(wěn)定生成能力。所有模型均在 1.6 萬個 token 的序列上進行訓(xùn)練，并在最多 10 萬個 token 的輸入場景下表現(xiàn)出性能提升。
除了能夠生成更長的編碼程序之外，更長的輸入序列窗口還能為編碼大模型解鎖其他令人興奮的新用例。例如，用戶可以向模型輸入來自代碼庫的更多上下文信息，確保生成結(jié)果的相關(guān)性更強。這還有助于在體量更大的代碼庫中進行調(diào)試，幫助開發(fā)人員快速找到與特定問題相關(guān)的所有代碼。現(xiàn)在，開發(fā)人員可以將完整代碼直接提交至大模型，高效完成涉及大量代碼的調(diào)試任務(wù)。
此外，Meta 還進一步微調(diào)了 Code Llama 的兩個附加變體：Code Llama – Python 與 Code Llama – Instruct。
Code Llama – Python 是 Code Llama 的特定語言專用變體，使用 100B 個 Python 代碼 token 上接受了進一步微調(diào)。由于 Python 是代碼生成領(lǐng)域的基準(zhǔn)測試語言，并且通過 PyTorch 在 AI 社區(qū)中發(fā)揮著重要作用，所以 Meta 相信這套專用模型將提供更有針對性的實際功能。
Code Llama – Instruct 則是 Code Llama 的指令微調(diào)與對齊變體。指令微調(diào)同樣屬于繼續(xù)訓(xùn)練過程，能夠滿足其他特定目標(biāo)。該模型接受“自然語言指令”輸入與預(yù)期輸出組合的持續(xù)訓(xùn)練，因此能夠更好地理解人們對于提示詞的生成期望。由于 Code Llama – Instruct 專門就生成實用、安全的自然語言回答進行了微調(diào)，因此在使用 Code Llama 進行代碼生成時，Meta 建議開發(fā)者優(yōu)先選擇 Code Llama – Instruct。
Meta 并不建議開發(fā)者使用 Code Llama 或者 Code Llama – Python 執(zhí)行常規(guī)自然語言任務(wù)，因為這兩套模型并不是為遵循自然語言指令所設(shè)計。Code Llama 專門用于特定編碼任務(wù)，不適合作為其他通用任務(wù)的基礎(chǔ)模型。
另外，在使用 Code Llama 模型時，用戶須遵守 Meta 指定的許可證與可接受使用政策。
沒有意外，Code Llama 70B 贏得了開發(fā)者們的贊揚，甚至有人稱“Code Llama 70B 是代碼生成領(lǐng)域的游戲規(guī)則改變者。”
但有自稱使用過的開發(fā)者表示，“我使用 Ollama 嘗試了 70B 模型，即使經(jīng)過多次嘗試，它也無法編寫貪吃蛇游戲。而 ChatGPT 一次嘗試就給出了一款可以運行的游戲。”
另一方面，隨著模型參數(shù)的增加，開發(fā)者們也擔(dān)心自己手頭沒有足夠裝備來滿足運行 Code Llama 70B。有人指出，在 A100-80GB 上訓(xùn)練所有 12 個 Code Llama 模型需要 1400K GPU 小時。
運行大模型幾乎可以歸結(jié)為兩個因素：內(nèi)存帶寬和計算能力，足夠高的內(nèi)存帶寬才能“提供”計算，足夠強大的計算才能跟上內(nèi)存提供的數(shù)據(jù)。對于個人開發(fā)者來說，可能并沒有完美設(shè)備，因此很開發(fā)者也在尋求更容易配置的量化模型版本。
也有開發(fā)者支招：可以在 64GB RAM 的 Macbook M1/M2 上運行 70B 模型。
開發(fā)者“tinco”表示，“據(jù)我所知，市場上沒有其他筆記本電腦具有與 64GB MBP 一樣多的 VRAM。您可以使用兩個 3090 制成一臺 Linux 臺式計算機，將它們連接在一起提供 48GB 的 VRAM。這樣顯然可以運行 4 位量化的 6k 上下文 70B Llama 模型。”Tinco 進一步表示，人們推薦 Macbook 是因為它們是一種相對便宜且簡單的方法，可以將大量 RAM 連接到加速器上。
Tinco 提醒道，這些是模型的量化版本，因此它們不如原始 70B 模型好，盡管人們聲稱它們的性能非常接近原始性能。要在不進行量化的情況下運行，則需要大約 140GB 的 VRAM。這只有一臺 NVidia H100（不知道價格）或兩臺 A100（每臺 18,000 美元）才能實現(xiàn)。
也有開發(fā)者分析稱，理論上，單個 Nvidia 4090 能夠以“可用”速度運行量化的 70B 模型。Mac 硬件在人工智能方面如此強大的原因是因為統(tǒng)一的架構(gòu)，這意味著內(nèi)存在 GPU 和 CPU 之間共享。還有其他因素，但本質(zhì)上歸結(jié)為每秒代幣的優(yōu)勢。用戶可以在內(nèi)存帶寬較低的舊 GPU 上運行這些模型中的任何一個，但每秒的令牌速度對于大多數(shù)人認(rèn)為“可用”的速度來說太慢了，而且必要的量化可能會明顯影響質(zhì)量。
代碼生成一直既被開發(fā)者叫好又被吐槽，即使是 ChatGPT 和 Copilot，因為雖然可以提效，但是質(zhì)量問題一言難盡。
有開發(fā)者在 Hacker News 上表示，“兩個月后我取消了訂閱（Copilot），因為我花了太多的精力去檢查所有代碼并修復(fù)所有錯誤。當(dāng)嘗試處理任何不瑣碎的或與 SQL 有關(guān)的事情時（即使我用整個模式預(yù)先加載它），它基本上是無用的。自己編寫所有內(nèi)容要省力得多，因為我實際上知道自己想寫什么，并且修復(fù)自己的錯誤比修復(fù)機器人的錯誤更容易。”
使用 ChatGPT 的“ben_w”表示，“我對它（ ChatGPT）的功能感到驚訝，但即便如此，我也不會稱其為'好代碼’。我將它用于 JavaScript 編程，因為雖然我可以閱讀（大部分） JS 代碼，但過去 14 年我一直專業(yè)從事 iOS 工作，因此不知道什么是瀏覽器領(lǐng)域的最佳實踐。盡管如此，我得到工作代碼后，我也可以發(fā)現(xiàn)它產(chǎn)生了錯誤的選擇和（看起來）奇怪的東西。”
類似的問題我們也在之前的文章《代碼屎山噩夢加速來襲，都是 AI 生成代碼的鍋？》中討論過。最新研究也表示，GitHub Copilot “代碼質(zhì)量面臨下行壓力”，代碼可維護性的趨勢令人不安。
開源領(lǐng)域一直在進行生成更好代碼的研究。在 Hugging Face 的“Big Code Models Leaderboard”上，也有很多被開發(fā)者認(rèn)可的模型。
比如北京大學(xué)推出了?系列從 1.3B 到 33B 的 DeepSeek-Coder 開源代碼模型。DeepSeek-Coder 基于 2 萬億個代幣上從頭訓(xùn)練，都使用 16K 的窗口大小和額外的填空任務(wù)在項目級代碼語料庫上進行預(yù)訓(xùn)練，以支持項目級代碼補全和填充。測評結(jié)果表明，DeepSeek-Coder 不僅在多個基準(zhǔn)測試中實現(xiàn)了開源代碼模型中最先進的性能，?且還超越了 Codex 和 GPT-3.5 等現(xiàn)有的閉源模型。
對于有開發(fā)者提出“當(dāng)前 SOTA 本地代碼生成模型是什么”的問題，可能現(xiàn)在還沒有標(biāo)準(zhǔn)答案，大家還在努力想辦法優(yōu)化現(xiàn)在模型，現(xiàn)在遠(yuǎn)不是終點。
