測(cè))
DeepSeek-Coder 1B到33B怎么選四檔模型的顯存、速度與代碼能力實(shí)測(cè)【免費(fèi)下載鏈接】DeepSeek-CoderDeepSeek Coder: Let the Code Write Itself項(xiàng)目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-CoderDeepSeek-Coder 是深度求索開(kāi)源的代碼大語(yǔ)言模型系列1.3B / 5.7B / 6.7B / 33B 四檔全在 2T token 代碼語(yǔ)料上從頭訓(xùn)練16K 上下文、87 種語(yǔ)言并且內(nèi)置了填空f(shuō)ill-in-the-blank任務(wù)。同一套技術(shù)底座、四檔參數(shù)選型時(shí)的真實(shí)糾結(jié)點(diǎn)只有三個(gè)你的顯存是多少、要跑多少并發(fā)、代碼質(zhì)量底線(xiàn)劃在哪里。這篇文章把我們壓測(cè)下來(lái)的規(guī)格賬和官方基準(zhǔn)讀數(shù)放在一起按顯存檔位給到可直接抄走的結(jié)論。先對(duì)號(hào)入座四檔規(guī)格的顯存賬先把參數(shù)表和顯存賬擺出來(lái)BF16 權(quán)重近似值未計(jì) KV cache版本BF16 權(quán)重顯存4-bit 量化后約單卡可跑方案1.3B~2.6GB~1.2GB8GB 以下消費(fèi)級(jí)卡4-bit 留足并發(fā)余量5.7B~11.4GB~5.2GB16GB 卡 BF16 直跑或 12GB 卡跑量化6.7B~13.4GB~6.1GB16GB 卡量化24GB 卡 BF1633B~66GB~20GB4-bit 單張 A100 80GBBF16 需多卡5.7B 這一檔官方叫 5.7B模型名里寫(xiě)作 6.7B-MQA 系列是整張表里最關(guān)鍵的取舍點(diǎn)BF16 約 11.4GB16GB 卡剛好裝下還能留出 KV cache 給 16K 上下文。雷達(dá)圖能一眼看出兩件事6.7B 的輪廓幾乎貼著 CodeLlama-34BREADME 里也寫(xiě)了 6.7B 達(dá)到 CodeLlama-34B 水平33B 則在 8 個(gè)語(yǔ)言維度上全部外擴(kuò)。這意味著能力上 6.7B 已經(jīng)是夠用檔從 6.7B 往 33B 升主要買(mǎi)的是絕對(duì)精度平均 5.6 個(gè)百分點(diǎn)而不是質(zhì)變所以選檔先看顯存預(yù)算再看是否值得為這幾個(gè)點(diǎn)付出 5 倍顯存。四個(gè)官方基準(zhǔn)到底讀出什么四個(gè)基準(zhǔn)HumanEval 多語(yǔ)言、MBPP、DS-1000、PAL-Math的完整結(jié)果在倉(cāng)庫(kù)Evaluation/目錄里可復(fù)現(xiàn)這里只留結(jié)論行和關(guān)鍵讀數(shù)。先看信息量最大的 HumanEval 多語(yǔ)言版本PythonCJavaPHPTSC#BashJS平均1.3B34.8%31.1%32.3%24.2%28.9%36.7%10.1%28.6%28.3%5.7B48.7%45.3%41.1%39.7%44.7%41.1%27.8%42.2%41.3%6.7B49.4%50.3%43.0%38.5%49.7%50.0%28.5%48.4%44.7%33B56.1%58.4%51.9%44.1%52.8%51.3%32.3%55.3%50.3%33B 的 Bash 只有 32.3%1.3B 更是 10.1%腳本類(lèi)任務(wù)最大檔也三分之一都解不對(duì)意味著它不適合放進(jìn)無(wú)人值守的自動(dòng)化流水線(xiàn)shell 場(chǎng)景建議人工過(guò)一遍再合。Instruct 版把 Python 從 56.1% 拉到 79.3%33B 檔比 Base 高 23 個(gè)百分點(diǎn)。如果你的產(chǎn)品形態(tài)是對(duì)話(huà)式寫(xiě)代碼Instruct 的收益遠(yuǎn)大于 Base 之間的參數(shù)差距純補(bǔ)全場(chǎng)景則繼續(xù)用 Base。1.3B 平均 28.3%在 PHP、JS 上只有 24%~29%。這意味著 1.3B 只適合做低延遲的輕量提示獨(dú)立解題能力到不了生產(chǎn)線(xiàn)。MBPP基礎(chǔ) Python 題的關(guān)鍵發(fā)現(xiàn)5.7B 的 57.2% 已經(jīng)超過(guò) CodeLlama-34B 的 55.2%6.7B 60.6%、33B 66.0%。如果你的業(yè)務(wù)以基礎(chǔ) Python 題為主5.7B 就是性?xún)r(jià)比拐點(diǎn)——多花 33B 的錢(qián)MBPP 只多拿 9.8 個(gè)百分點(diǎn)。DS-1000數(shù)據(jù)科學(xué)庫(kù)補(bǔ)全33B 平均 40.2%其中 Tensorflow 46.7% 比 5.7B 的 15.6% 高出 31 個(gè)百分點(diǎn)是四檔里差異最大的一項(xiàng)但 Pandas 上 33B 也才 25.8%。這意味著數(shù)據(jù)管道類(lèi)補(bǔ)全pandas 清洗、轉(zhuǎn)換即使最大檔也遠(yuǎn)不可靠這類(lèi)位置建議保留人工兜底。PAL-Math程序輔助數(shù)學(xué)推理7 數(shù)據(jù)集33B 在 SVAMP 71.6%、GSM8k 60.7%、MAWPS 93.3%但 MATH 只有 29.1%。它的強(qiáng)項(xiàng)是小學(xué)應(yīng)用題級(jí)別的程序驗(yàn)證推理競(jìng)賽級(jí)題目仍會(huì)大量失手別拿它做自動(dòng)判題。官方匯總表里還有一個(gè)值得劃線(xiàn)的點(diǎn)DeepSeek-Coder-Base-7B即 6.7B在 HumanEval Python 上 49.4%反超 CodeLlama-34B 的 48.2%。用六成的參數(shù)打平 34B是這個(gè)系列最實(shí)打?qū)嵉馁u(mài)點(diǎn)。顯存、量化與推理服務(wù)的配置坑推理服務(wù)我們統(tǒng)一用 vLLM 拉起按檔位的參數(shù)如下倉(cāng)庫(kù)Evaluation/LeetCode/vllm_inference.py有現(xiàn)成寫(xiě)法可參照參數(shù)1.3B5.7B / 6.7B33Btensor_parallel_size114或按卡數(shù)上調(diào)gpu_memory_utilization0.90.90.9采樣建議temperature 0.7 / top_p 0.9同左同左量化部署只留一段 4-bit 配置其余檔位換模型名即可from transformers import AutoTokenizer, AutoModelForCausalLM, BitsAndBytesConfig import torch quantization_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_compute_dtypetorch.float16, bnb_4bit_quant_typenf4, ) model AutoModelForCausalLM.from_pretrained( deepseek-ai/deepseek-coder-33b-base, quantization_configquantization_config, trust_remote_codeTrue, device_mapauto, )踩過(guò)的坑有兩個(gè)README 的 QA 里有原文tokenizer 是 Bytelevel-BPE不是 SentencePieceGGUF 路線(xiàn)需要帶 PR 補(bǔ)丁的 llama.cppconvert-hf-to-gguf.py之后quantize ... q4_0直接轉(zhuǎn)標(biāo)準(zhǔn)版會(huì)掛。exllamav2 路線(xiàn)要把 RoPE scaling 設(shè)成 4否則輸出直接亂。我們當(dāng)時(shí)沒(méi)設(shè)33B 生成的代碼看著像能跑單測(cè)全掛查了半天是這里。還有一個(gè)容易被忽略的開(kāi)關(guān)Instruct 模型如果要做代碼補(bǔ)全而不是對(duì)話(huà)要把eos_token_id從默認(rèn) 32021 改成 32014否則補(bǔ)全模式不會(huì)正常停。按顯存檔位抄結(jié)論 顯存 ≤ 8GB跑 1.3B 4-bit權(quán)重約 1.2GB把顯存留給 KV cache 換并發(fā)。它的 MBPP 46.2% 意味著差不多一半的基礎(chǔ)題解不對(duì)定位只能是編輯器里的低延遲輕量提示不要指望它獨(dú)立交付函數(shù)。顯存 16GB這是最典型的檔位兩條路。要吞吐就 5.7B BF16約 11.4GB余量夠 16K 上下文HumanEval 平均 41.3%、MBPP 57.2%日常補(bǔ)全夠用要精度就 6.7B 4-bit約 6.1GB精度到 44.7% / 60.6%且單卡能同時(shí)開(kāi)更多副本。16GB 以?xún)?nèi)5.7B 是目前最不容易后悔的選擇。單卡 A100 80GB33B 4-bit 量化約 20GB放得下把它當(dāng)離線(xiàn)審查 復(fù)雜任務(wù)用代碼審查、跨文件重構(gòu)建議、難題解題。在線(xiàn)實(shí)時(shí)補(bǔ)全仍然交給 5.7B/6.7B混合部署的實(shí)測(cè)體驗(yàn)比全量上 33B好很多——33B 解碼慢串在實(shí)時(shí)路徑上會(huì)把 P95 延遲拖到用戶(hù)可感知的程度。腳本自動(dòng)化場(chǎng)景四檔里 Bash 最高的 33B 也只有 32.3%這條沒(méi)有選大模型的解法shell 代碼生成環(huán)節(jié)必須留人工 review。最后說(shuō)一個(gè)項(xiàng)目級(jí)補(bǔ)全的實(shí)測(cè)倉(cāng)庫(kù)里demo/app.py演示的 repo 級(jí)場(chǎng)景中6.7B 在 16K 窗口內(nèi)能跨文件調(diào)用model.py里定義的類(lèi)來(lái)補(bǔ)全main.py。這個(gè)能力是 16K 窗口 填空任務(wù)帶來(lái)的1.3B 上下文內(nèi)文件一多就容易丟依賴(lài)倉(cāng)庫(kù)級(jí)任務(wù)建議直接從 6.7B 起步。還有一句話(huà)留給最后上線(xiàn)前榜單數(shù)據(jù)和你的業(yè)務(wù)語(yǔ)言棧分布不一致壓測(cè)時(shí)拿自己倉(cāng)庫(kù)切一個(gè) DS-1000 子集跑一遍再定檔。在 16GB 預(yù)算以?xún)?nèi)5.7B 依然是那個(gè)最不容易后悔的答案?！久赓M(fèi)下載鏈接】DeepSeek-CoderDeepSeek Coder: Let the Code Write Itself項(xiàng)目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-Coder創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 DeepSeek-Coder 1B到33B怎么選：四檔模型的顯存、速度與代碼能力實(shí)測(cè)
DeepSeek-Coder 1B到33B怎么選四檔模型的顯存、速度與代碼能力實(shí)測(cè)【免費(fèi)下載鏈接】DeepSeek-CoderDeepSeek Coder: Let the Code Write Itself項(xiàng)目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-CoderDeepSeek-Coder 是深度求索開(kāi)源的代碼大語(yǔ)言模型系列1.3B / 5.7B / 6.7B / 33B 四檔全在 2T token 代碼語(yǔ)料上從頭訓(xùn)練16K 上下文、87 種語(yǔ)言并且內(nèi)置了填空f(shuō)ill-in-the-blank任務(wù)。同一套技術(shù)底座、四檔參數(shù)選型時(shí)的真實(shí)糾結(jié)點(diǎn)只有三個(gè)你的顯存是多少、要跑多少并發(fā)、代碼質(zhì)量底線(xiàn)劃在哪里。這篇文章把我們壓測(cè)下來(lái)的規(guī)格賬和官方基準(zhǔn)讀數(shù)放在一起按顯存檔位給到可直接抄走的結(jié)論。先對(duì)號(hào)入座四檔規(guī)格的顯存賬先把參數(shù)表和顯存賬擺出來(lái)BF16 權(quán)重近似值未計(jì) KV cache版本BF16 權(quán)重顯存4-bit 量化后約單卡可跑方案1.3B~2.6GB~1.2GB8GB 以下消費(fèi)級(jí)卡4-bit 留足并發(fā)余量5.7B~11.4GB~5.2GB16GB 卡 BF16 直跑或 12GB 卡跑量化6.7B~13.4GB~6.1GB16GB 卡量化24GB 卡 BF1633B~66GB~20GB4-bit 單張 A100 80GBBF16 需多卡5.7B 這一檔官方叫 5.7B模型名里寫(xiě)作 6.7B-MQA 系列是整張表里最關(guān)鍵的取舍點(diǎn)BF16 約 11.4GB16GB 卡剛好裝下還能留出 KV cache 給 16K 上下文。雷達(dá)圖能一眼看出兩件事6.7B 的輪廓幾乎貼著 CodeLlama-34BREADME 里也寫(xiě)了 6.7B 達(dá)到 CodeLlama-34B 水平33B 則在 8 個(gè)語(yǔ)言維度上全部外擴(kuò)。這意味著能力上 6.7B 已經(jīng)是夠用檔從 6.7B 往 33B 升主要買(mǎi)的是絕對(duì)精度平均 5.6 個(gè)百分點(diǎn)而不是質(zhì)變所以選檔先看顯存預(yù)算再看是否值得為這幾個(gè)點(diǎn)付出 5 倍顯存。四個(gè)官方基準(zhǔn)到底讀出什么四個(gè)基準(zhǔn)HumanEval 多語(yǔ)言、MBPP、DS-1000、PAL-Math的完整結(jié)果在倉(cāng)庫(kù)Evaluation/目錄里可復(fù)現(xiàn)這里只留結(jié)論行和關(guān)鍵讀數(shù)。先看信息量最大的 HumanEval 多語(yǔ)言版本PythonCJavaPHPTSC#BashJS平均1.3B34.8%31.1%32.3%24.2%28.9%36.7%10.1%28.6%28.3%5.7B48.7%45.3%41.1%39.7%44.7%41.1%27.8%42.2%41.3%6.7B49.4%50.3%43.0%38.5%49.7%50.0%28.5%48.4%44.7%33B56.1%58.4%51.9%44.1%52.8%51.3%32.3%55.3%50.3%33B 的 Bash 只有 32.3%1.3B 更是 10.1%腳本類(lèi)任務(wù)最大檔也三分之一都解不對(duì)意味著它不適合放進(jìn)無(wú)人值守的自動(dòng)化流水線(xiàn)shell 場(chǎng)景建議人工過(guò)一遍再合。Instruct 版把 Python 從 56.1% 拉到 79.3%33B 檔比 Base 高 23 個(gè)百分點(diǎn)。如果你的產(chǎn)品形態(tài)是對(duì)話(huà)式寫(xiě)代碼Instruct 的收益遠(yuǎn)大于 Base 之間的參數(shù)差距純補(bǔ)全場(chǎng)景則繼續(xù)用 Base。1.3B 平均 28.3%在 PHP、JS 上只有 24%~29%。這意味著 1.3B 只適合做低延遲的輕量提示獨(dú)立解題能力到不了生產(chǎn)線(xiàn)。MBPP基礎(chǔ) Python 題的關(guān)鍵發(fā)現(xiàn)5.7B 的 57.2% 已經(jīng)超過(guò) CodeLlama-34B 的 55.2%6.7B 60.6%、33B 66.0%。如果你的業(yè)務(wù)以基礎(chǔ) Python 題為主5.7B 就是性?xún)r(jià)比拐點(diǎn)——多花 33B 的錢(qián)MBPP 只多拿 9.8 個(gè)百分點(diǎn)。DS-1000數(shù)據(jù)科學(xué)庫(kù)補(bǔ)全33B 平均 40.2%其中 Tensorflow 46.7% 比 5.7B 的 15.6% 高出 31 個(gè)百分點(diǎn)是四檔里差異最大的一項(xiàng)但 Pandas 上 33B 也才 25.8%。這意味著數(shù)據(jù)管道類(lèi)補(bǔ)全pandas 清洗、轉(zhuǎn)換即使最大檔也遠(yuǎn)不可靠這類(lèi)位置建議保留人工兜底。PAL-Math程序輔助數(shù)學(xué)推理7 數(shù)據(jù)集33B 在 SVAMP 71.6%、GSM8k 60.7%、MAWPS 93.3%但 MATH 只有 29.1%。它的強(qiáng)項(xiàng)是小學(xué)應(yīng)用題級(jí)別的程序驗(yàn)證推理競(jìng)賽級(jí)題目仍會(huì)大量失手別拿它做自動(dòng)判題。官方匯總表里還有一個(gè)值得劃線(xiàn)的點(diǎn)DeepSeek-Coder-Base-7B即 6.7B在 HumanEval Python 上 49.4%反超 CodeLlama-34B 的 48.2%。用六成的參數(shù)打平 34B是這個(gè)系列最實(shí)打?qū)嵉馁u(mài)點(diǎn)。顯存、量化與推理服務(wù)的配置坑推理服務(wù)我們統(tǒng)一用 vLLM 拉起按檔位的參數(shù)如下倉(cāng)庫(kù)Evaluation/LeetCode/vllm_inference.py有現(xiàn)成寫(xiě)法可參照參數(shù)1.3B5.7B / 6.7B33Btensor_parallel_size114或按卡數(shù)上調(diào)gpu_memory_utilization0.90.90.9采樣建議temperature 0.7 / top_p 0.9同左同左量化部署只留一段 4-bit 配置其余檔位換模型名即可from transformers import AutoTokenizer, AutoModelForCausalLM, BitsAndBytesConfig import torch quantization_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_compute_dtypetorch.float16, bnb_4bit_quant_typenf4, ) model AutoModelForCausalLM.from_pretrained( deepseek-ai/deepseek-coder-33b-base, quantization_configquantization_config, trust_remote_codeTrue, device_mapauto, )踩過(guò)的坑有兩個(gè)README 的 QA 里有原文tokenizer 是 Bytelevel-BPE不是 SentencePieceGGUF 路線(xiàn)需要帶 PR 補(bǔ)丁的 llama.cppconvert-hf-to-gguf.py之后quantize ... q4_0直接轉(zhuǎn)標(biāo)準(zhǔn)版會(huì)掛。exllamav2 路線(xiàn)要把 RoPE scaling 設(shè)成 4否則輸出直接亂。我們當(dāng)時(shí)沒(méi)設(shè)33B 生成的代碼看著像能跑單測(cè)全掛查了半天是這里。還有一個(gè)容易被忽略的開(kāi)關(guān)Instruct 模型如果要做代碼補(bǔ)全而不是對(duì)話(huà)要把eos_token_id從默認(rèn) 32021 改成 32014否則補(bǔ)全模式不會(huì)正常停。按顯存檔位抄結(jié)論 顯存 ≤ 8GB跑 1.3B 4-bit權(quán)重約 1.2GB把顯存留給 KV cache 換并發(fā)。它的 MBPP 46.2% 意味著差不多一半的基礎(chǔ)題解不對(duì)定位只能是編輯器里的低延遲輕量提示不要指望它獨(dú)立交付函數(shù)。顯存 16GB這是最典型的檔位兩條路。要吞吐就 5.7B BF16約 11.4GB余量夠 16K 上下文HumanEval 平均 41.3%、MBPP 57.2%日常補(bǔ)全夠用要精度就 6.7B 4-bit約 6.1GB精度到 44.7% / 60.6%且單卡能同時(shí)開(kāi)更多副本。16GB 以?xún)?nèi)5.7B 是目前最不容易后悔的選擇。單卡 A100 80GB33B 4-bit 量化約 20GB放得下把它當(dāng)離線(xiàn)審查 復(fù)雜任務(wù)用代碼審查、跨文件重構(gòu)建議、難題解題。在線(xiàn)實(shí)時(shí)補(bǔ)全仍然交給 5.7B/6.7B混合部署的實(shí)測(cè)體驗(yàn)比全量上 33B好很多——33B 解碼慢串在實(shí)時(shí)路徑上會(huì)把 P95 延遲拖到用戶(hù)可感知的程度。腳本自動(dòng)化場(chǎng)景四檔里 Bash 最高的 33B 也只有 32.3%這條沒(méi)有選大模型的解法shell 代碼生成環(huán)節(jié)必須留人工 review。最后說(shuō)一個(gè)項(xiàng)目級(jí)補(bǔ)全的實(shí)測(cè)倉(cāng)庫(kù)里demo/app.py演示的 repo 級(jí)場(chǎng)景中6.7B 在 16K 窗口內(nèi)能跨文件調(diào)用model.py里定義的類(lèi)來(lái)補(bǔ)全main.py。這個(gè)能力是 16K 窗口 填空任務(wù)帶來(lái)的1.3B 上下文內(nèi)文件一多就容易丟依賴(lài)倉(cāng)庫(kù)級(jí)任務(wù)建議直接從 6.7B 起步。還有一句話(huà)留給最后上線(xiàn)前榜單數(shù)據(jù)和你的業(yè)務(wù)語(yǔ)言棧分布不一致壓測(cè)時(shí)拿自己倉(cāng)庫(kù)切一個(gè) DS-1000 子集跑一遍再定檔。在 16GB 預(yù)算以?xún)?nèi)5.7B 依然是那個(gè)最不容易后悔的答案?！久赓M(fèi)下載鏈接】DeepSeek-CoderDeepSeek Coder: Let the Code Write Itself項(xiàng)目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-Coder創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考