模型概述
模型特點
模型能力
使用案例
🚀 Seed-Coder-8B-Reasoning GGUF模型
Seed-Coder-8B-Reasoning GGUF模型是基於Transformer架構的代碼生成模型,能夠實現高性能的代碼生成和推理任務。該模型具有強大的推理能力,適用於多種編碼任務,在同規模的開源模型中表現出色。
🚀 快速開始
你需要安裝最新版本的transformers
和accelerate
:
pip install -U transformers accelerate
以下是一個簡單的示例,展示瞭如何使用Hugging Face的pipeline
API加載模型並進行代碼生成:
from transformers import AutoTokenizer, AutoModelForCausalLM
import torch
model_id = "ByteDance-Seed/Seed-Coder-8B-Reasoning"
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(model_id, torch_dtype=torch.bfloat16, device_map="auto", trust_remote_code=True)
messages = [
{"role": "user", "content": "Write a quick sort algorithm."},
]
input_ids = tokenizer.apply_chat_template(
messages,
tokenize=True,
return_tensors="pt",
add_generation_prompt=True,
).to(model.device)
outputs = model.generate(input_ids, max_new_tokens=16384)
response = tokenizer.decode(outputs[0][input_ids.shape[-1]:], skip_special_tokens=True)
print(response)
✨ 主要特性
Seed-Coder模型亮點
- 以模型為中心:Seed-Coder主要利用大語言模型(LLMs)而非手工規則進行代碼數據過濾,減少了預訓練數據構建中的人工工作量。
- 透明性:公開分享了以模型為中心的數據處理流程的詳細信息,包括GitHub數據、提交數據和代碼相關網絡數據的整理方法。
- 強大性能:在各種編碼任務中,Seed-Coder在同規模的開源模型中達到了最先進的性能。
Seed-Coder-8B-Reasoning模型特性
- 類型:因果語言模型
- 訓練階段:預訓練和後訓練
- 數據源:公共數據集
- 上下文長度:65,536
📦 安裝指南
安裝最新版本的transformers
和accelerate
:
pip install -U transformers accelerate
💻 使用示例
基礎用法
from transformers import AutoTokenizer, AutoModelForCausalLM
import torch
model_id = "ByteDance-Seed/Seed-Coder-8B-Reasoning"
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(model_id, torch_dtype=torch.bfloat16, device_map="auto", trust_remote_code=True)
messages = [
{"role": "user", "content": "Write a quick sort algorithm."},
]
input_ids = tokenizer.apply_chat_template(
messages,
tokenize=True,
return_tensors="pt",
add_generation_prompt=True,
).to(model.device)
outputs = model.generate(input_ids, max_new_tokens=16384)
response = tokenizer.decode(outputs[0][input_ids.shape[-1]:], skip_special_tokens=True)
print(response)
📚 詳細文檔
模型生成細節
該模型使用llama.cpp在提交版本5787b5da
生成。
超越IMatrix的量化方法
測試了一種新的量化方法,使用規則將重要層的量化提升到標準IMatrix之上。標準IMatrix在低比特量化和混合專家(MOE)模型中表現不佳,因此使用llama.cpp的--tensor-type
來提升選定層的量化。詳情見使用llama.cpp進行層提升。這種方法會生成更大的模型文件,但在給定模型大小的情況下提高了精度。
選擇合適的模型格式
選擇正確的模型格式取決於你的硬件能力和內存限制。
BF16(腦浮點16)——如果有BF16加速則使用
- 一種16位浮點格式,旨在實現更快的計算,同時保持良好的精度。
- 提供與FP32相似的動態範圍,但內存使用更低。
- 如果你的硬件支持BF16加速(檢查設備規格),建議使用。
- 與FP32相比,適用於高性能推理且內存佔用減少的場景。
適用情況:
- 你的硬件具有原生BF16支持(如較新的GPU、TPU)。
- 你希望在節省內存的同時獲得更高的精度。
- 你計劃將模型重新量化為其他格式。
避免情況:
- 你的硬件不支持BF16(可能會回退到FP32並運行較慢)。
- 你需要與缺乏BF16優化的舊設備兼容。
F16(浮點16)——比BF16更廣泛支持
- 一種16位浮點格式,精度較高,但動態範圍比BF16小。
- 適用於大多數支持FP16加速的設備(包括許多GPU和一些CPU)。
- 數值精度略低於BF16,但通常足以進行推理。
適用情況:
- 你的硬件支持FP16但不支持BF16。
- 你需要在速度、內存使用和準確性之間取得平衡。
- 你在GPU或其他針對FP16計算優化的設備上運行。
避免情況:
- 你的設備缺乏原生FP16支持(可能運行比預期慢)。
- 你有內存限制。
混合精度模型(如bf16_q8_0
、f16_q4_K
)——兩全其美
這些格式選擇性地量化非關鍵層,同時保持關鍵層的全精度(如注意力層和輸出層)。
- 命名方式如
bf16_q8_0
(表示全精度BF16核心層 + 量化Q8_0其他層)。 - 在內存效率和準確性之間取得平衡,比全量化模型有所改進,且不需要BF16/F16的全部內存。
適用情況:
- 你需要比僅量化模型更高的準確性,但無法承受全BF16/F16的內存開銷。
- 你的設備支持混合精度推理。
- 你希望在受限硬件上為生產級模型優化權衡。
避免情況:
- 你的目標設備不支持混合或全精度加速。
- 你在超嚴格的內存限制下操作(這種情況下使用全量化格式)。
量化模型(Q4_K、Q6_K、Q8等)——適用於CPU和低顯存推理
量化在儘可能保持準確性的同時減小模型大小和內存使用。
- 低比特模型(Q4_K):最適合最小內存使用,可能精度較低。
- 高比特模型(Q6_K、Q8_0):準確性更好,但需要更多內存。
適用情況:
- 你在CPU上運行推理,需要優化模型。
- 你的設備顯存較低,無法加載全精度模型。
- 你希望在保持合理準確性的同時減少內存佔用。
避免情況:
- 你需要最高的準確性(全精度模型更適合)。
- 你的硬件有足夠的顯存用於更高精度的格式(BF16/F16)。
極低比特量化(IQ3_XS、IQ3_S、IQ3_M、Q4_K、Q4_0)
這些模型針對非常高的內存效率進行了優化,適用於低功耗設備或大規模部署,其中內存是關鍵限制因素。
- IQ3_XS:超低比特量化(3位),具有非常高的內存效率。
- 用例:最適合超低內存設備,即使Q4_K也太大的情況。
- 權衡:與高比特量化相比,準確性較低。
- IQ3_S:小塊大小,實現最大內存效率。
- 用例:最適合低內存設備,當IQ3_XS過於激進時使用。
- IQ3_M:中等塊大小,比IQ3_S準確性更好。
- 用例:適用於低內存設備,當IQ3_S限制過大時使用。
- Q4_K:4位量化,具有逐塊優化以提高準確性。
- 用例:最適合低內存設備,當Q6_K太大時使用。
- Q4_0:純4位量化,針對ARM設備優化。
- 用例:最適合基於ARM的設備或低內存環境。
超低比特量化(IQ1_S、IQ1_M、IQ2_S、IQ2_M、IQ2_XS、IQ2_XSS)
- 超低比特量化(1 - 2位),具有極高的內存效率。
- 用例:最適合模型必須適應非常受限內存的情況。
- 權衡:準確性非常低,可能無法按預期工作。使用前請充分測試。
模型格式選擇總結表
模型格式 | 精度 | 內存使用 | 設備要求 | 最佳用例 |
---|---|---|---|---|
BF16 | 非常高 | 高 | 支持BF16的GPU/CPU | 高速推理且內存減少 |
F16 | 高 | 高 | 支持FP16的GPU/CPU | 當BF16不可用時進行推理 |
Q4_K | 中 - 低 | 低 | CPU或低顯存設備 | 內存受限的推理 |
Q6_K | 中 | 中等 | 內存較多的CPU | 量化下更好的準確性 |
Q8_0 | 高 | 中等 | 具有中等顯存的GPU/CPU | 量化模型中最高的準確性 |
IQ3_XS | 低 | 非常低 | 超低內存設備 | 最大內存效率,低準確性 |
IQ3_S | 低 | 非常低 | 低內存設備 | 比IQ3_XS略可用 |
IQ3_M | 低 - 中 | 低 | 低內存設備 | 比IQ3_S準確性更好 |
Q4_0 | 低 | 低 | 基於ARM/嵌入式設備 | Llama.cpp自動優化ARM推理 |
超低比特(IQ1/2_*) | 非常低 | 極低 | 小型邊緣/嵌入式設備 | 將模型放入極緊的內存中;低準確性 |
混合(如bf16_q8_0 ) |
中 - 高 | 中等 | 支持混合精度的硬件 | 平衡性能和內存,關鍵層接近FP準確性 |
模型下載
模型名稱 | 長度 | 下載 | 備註 |
---|---|---|---|
Seed-Coder-8B-Base | 32K | 🔗 模型 | 在以模型為中心的代碼數據上預訓練。 |
Seed-Coder-8B-Instruct | 32K | 🔗 模型 | 進行指令微調以與用戶意圖對齊。 |
Seed-Coder-8B-Reasoning | 64K | 🔗 模型 | 經過強化學習訓練以增強推理能力。 |
Seed-Coder-8B-Reasoning-bf16 | 64K | 🔗 模型 | 經過強化學習訓練以增強推理能力。 |
評估
Seed-Coder-8B-Reasoning在競賽編程中表現出色,證明了較小的大語言模型也能勝任複雜的推理任務。我們的模型在IOI'2024上超越了QwQ-32B和DeepSeek-R1,並在Codeforces競賽中達到了與o1-mini相當的ELO評級。
詳細的基準測試性能請參考我們的技術報告。
免費網絡監控助手測試
如果你覺得這些模型有用,可以幫助測試由AI驅動的免費網絡監控助手,該助手具備量子就緒安全檢查功能。
免費網絡監控服務的完整開源代碼可在GitHub倉庫(名稱中包含NetworkMonitor的倉庫)找到:免費網絡監控源代碼。如果你想自己進行模型量化,也可以找到相關代碼GGUFModelBuilder。
測試方法
選擇一種AI助手類型:
TurboLLM
(GPT-4.1-mini)HugLLM
(Hugging Face開源模型)TestLLM
(僅支持CPU的實驗性模型)
測試內容
正在挑戰小型開源模型在AI網絡監控中的極限,具體包括:
- 針對即時網絡服務的函數調用。
- 模型可以多小,同時仍能處理:
- 自動化Nmap安全掃描。
- 量子就緒檢查。
- 網絡監控任務。
各助手特點
- TestLLM —— 當前的實驗性模型(在Hugging Face Docker空間的2個CPU線程上運行llama.cpp):
- 零配置設置。
- 加載時間約30秒(推理慢,但無API成本),由於成本低,無令牌限制。
- 尋求幫助!如果你對邊緣設備AI感興趣,讓我們合作!
- TurboLLM —— 使用gpt-4.1-mini:
- 性能非常好,但不幸的是OpenAI按令牌收費,因此令牌使用受限。
- 創建自定義命令處理器,在免費網絡監控代理上運行.NET代碼。
- 即時網絡診斷和監控。
- 安全審計。
- 滲透測試(Nmap/Metasploit)。
- HugLLM —— 最新的開源模型:
- 在Hugging Face推理API上運行,使用Novita託管的最新模型表現良好。
示例測試命令
"Give me info on my websites SSL certificate"
"Check if my server is using quantum safe encyption for communication"
"Run a comprehensive security audit on my server"
"Create a cmd processor to .. (what ever you want)"
注意,你需要安裝免費網絡監控代理才能運行.NET代碼。這是一個非常靈活和強大的功能,請謹慎使用!
🔧 技術細節
暫未提供相關技術細節,後續可進一步補充。
📄 許可證
本項目遵循MIT許可證。詳情見LICENSE文件。
引用
如果你覺得我們的工作有幫助,請引用:
@misc{seed2025seedcoderletcodemodel,
title={{Seed-Coder}: Let the Code Model Curate Data for Itself},
author={{ByteDance Seed} and Yuyu Zhang and Jing Su and Yifan Sun and Chenguang Xi and Xia Xiao and Shen Zheng and Anxiang Zhang and Kaibo Liu and Daoguang Zan and Tao Sun and Jinhua Zhu and Shulin Xin and Dong Huang and Yetao Bai and Lixin Dong and Chao Li and Jianchong Chen and Hanzhi Zhou and Yifan Huang and Guanghan Ning and Xierui Song and Jiaze Chen and Siyao Liu and Kai Shen and Liang Xiang and Yonghui Wu},
year={2025},
eprint={2506.03524},
archivePrefix={arXiv},
primaryClass={cs.CL},
url={https://arxiv.org/abs/2506.03524},
}



