Olympiccoder 32B GGUF
模型概述
模型特點
模型能力
使用案例
🚀 OlympicCoder-32B GGUF模型
OlympicCoder-32B是一個代碼模型,在諸如LiveCodeBench和2024年國際信息學奧林匹克競賽等競賽編程基準測試中表現出色。該模型在代碼競賽領域具有強大的競爭力,為開發者和研究者提供了有力的工具。
🚀 快速開始
你可以使用🤗 Transformers庫中的pipeline()
函數來運行該模型:
# pip install transformers
# pip install accelerate
import torch
from transformers import pipeline
pipe = pipeline("text-generation", model="open-r1/OlympicCoder-32B", torch_dtype=torch.bfloat16, device_map="auto")
# We use the tokenizer's chat template to format each message - see https://huggingface.co/docs/transformers/main/en/chat_templating
messages = [
{"role": "user", "content": "Write a python program to calculate the 10th Fibonacci number"},
]
prompt = pipe.tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
outputs = pipe(prompt, max_new_tokens=8000, do_sample=True, temperature=0.7, top_k=50, top_p=0.95)
print(outputs[0]["generated_text"])
#<|im_start|>user
#Write a python program to calculate the 10th fibonacci number<|im_end|>
#<|im_start|>assistant
#<think>Okay, I need to write a Python program that calculates the 10th Fibonacci number. Hmm, the Fibonacci sequence starts with 0 and 1. Each subsequent number is the sum of the two preceding ones. So the sequence goes: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, and so on. ...
⚠️ 重要提示
為確保模型持續輸出長思維鏈,我們已編輯聊天模板,在第一個助手回覆中預填充了
<think>
標記。因此,如果你使用模型的generate()
方法,輸出將不會顯示開頭的<think>
標記。若要使用格式獎勵進行強化學習,可在模型完成的內容前添加<think>
標記,或修改聊天模板以移除預填充內容。更多詳情請查看我們的博客文章。
✨ 主要特性
超低比特量化技術
我們最新的量化方法為超低比特模型(1 - 2比特)引入了精度自適應量化,經基準測試證明,該方法在Llama - 3 - 8B上有顯著改進。此方法採用特定層策略,在保持極高內存效率的同時保留了準確性。
多模型格式支持
提供多種模型格式,如BF16、F16、量化模型(Q4_K、Q6_K、Q8等)以及極低比特量化模型(IQ3_XS、IQ3_S、IQ3_M、Q4_K、Q4_0),可根據不同的硬件能力和內存限制進行選擇。
多場景適用
適用於多種場景,包括內存受限的部署、CPU和邊緣設備,以及超低比特量化研究等。
📦 安裝指南
文檔未提及具體安裝步驟,可參考相關庫(如transformers
)的官方安裝指南進行安裝。
💻 使用示例
基礎用法
# pip install transformers
# pip install accelerate
import torch
from transformers import pipeline
pipe = pipeline("text-generation", model="open-r1/OlympicCoder-32B", torch_dtype=torch.bfloat16, device_map="auto")
# We use the tokenizer's chat template to format each message - see https://huggingface.co/docs/transformers/main/en/chat_templating
messages = [
{"role": "user", "content": "Write a python program to calculate the 10th Fibonacci number"},
]
prompt = pipe.tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
outputs = pipe(prompt, max_new_tokens=8000, do_sample=True, temperature=0.7, top_k=50, top_p=0.95)
print(outputs[0]["generated_text"])
#<|im_start|>user
#Write a python program to calculate the 10th fibonacci number<|im_end|>
#<|im_start|>assistant
#<think>Okay, I need to write a Python program that calculates the 10th Fibonacci number. Hmm, the Fibonacci sequence starts with 0 and 1. Each subsequent number is the sum of the two preceding ones. So the sequence goes: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, and so on. ...
📚 詳細文檔
量化方法詳情
基準測試環境
所有測試均在Llama - 3 - 8B - Instruct上進行,使用以下設置:
- 標準困惑度評估管道
- 2048令牌上下文窗口
- 所有量化使用相同的提示集
量化方法
- 動態精度分配:
- 前/後25%的層 → IQ4_XS(選定層)
- 中間50% → IQ2_XXS/IQ3_S(提高效率)
- 關鍵組件保護:
- 嵌入層/輸出層使用Q5_K
- 與標準1 - 2比特量化相比,誤差傳播降低38%
量化性能比較(Llama - 3 - 8B)
量化方式 | 標準困惑度 | DynamicGate困惑度 | 困惑度變化 | 標準大小 | DG大小 | 大小變化 | 標準速度 | DG速度 |
---|---|---|---|---|---|---|---|---|
IQ2_XXS | 11.30 | 9.84 | -12.9% | 2.5G | 2.6G | +0.1G | 234s | 246s |
IQ2_XS | 11.72 | 11.63 | -0.8% | 2.7G | 2.8G | +0.1G | 242s | 246s |
IQ2_S | 14.31 | 9.02 | -36.9% | 2.7G | 2.9G | +0.2G | 238s | 244s |
IQ1_M | 27.46 | 15.41 | -43.9% | 2.2G | 2.5G | +0.3G | 206s | 212s |
IQ1_S | 53.07 | 32.00 | -39.7% | 2.1G | 2.4G | +0.3G | 184s | 209s |
關鍵說明:
- PPL = 困惑度(越低越好)
- Δ PPL = 從標準量化到DynamicGate量化的百分比變化
- 速度 = 推理時間(CPU avx2,2048令牌上下文)
- 大小差異反映了混合量化的開銷
主要改進:
- 🔥 IQ1_M的困惑度大幅降低43.9%(從27.46降至15.41)
- 🚀 IQ2_S的困惑度降低36.9%,同時僅增加0.2GB
- ⚡ IQ1_S儘管是1比特量化,但準確性提高了39.7%
權衡之處:
- 所有變體的大小均有適度增加(0.1 - 0.3GB)
- 推理速度相近(差異<5%)
使用場景
- 📌 將模型裝入GPU顯存
- ✔ 內存受限的部署
- ✔ 可容忍1 - 2比特誤差的CPU和邊緣設備
- ✔ 超低比特量化研究
模型格式選擇
選擇正確的模型格式取決於你的硬件能力和內存限制。
BF16(Brain Float 16) – 若支持BF16加速則使用
- 一種16位浮點格式,專為更快的計算而設計,同時保留了良好的精度。
- 提供與FP32相似的動態範圍,但內存使用更低。
- 若你的硬件支持BF16加速(請檢查設備規格),建議使用。
- 與FP32相比,適用於高性能推理且內存佔用減少的場景。
📌 適用情況: ✔ 你的硬件具有原生BF16支持(如較新的GPU、TPU)。 ✔ 你希望在節省內存的同時獲得更高的精度。 ✔ 你計劃將模型重新量化為其他格式。
📌 避免情況: ❌ 你的硬件不支持BF16(可能會回退到FP32並運行較慢)。 ❌ 你需要與缺乏BF16優化的舊設備兼容。
F16(Float 16) – 比BF16更廣泛支持
- 一種16位浮點格式,精度較高,但取值範圍小於BF16。
- 適用於大多數支持FP16加速的設備(包括許多GPU和一些CPU)。
- 數值精度略低於BF16,但通常足以進行推理。
📌 適用情況: ✔ 你的硬件支持FP16但不支持BF16。 ✔ 你需要在速度、內存使用和準確性之間取得平衡。 ✔ 你在GPU或其他針對FP16計算優化的設備上運行。
📌 避免情況: ❌ 你的設備缺乏原生FP16支持(可能運行比預期慢)。 ❌ 你有內存限制。
量化模型(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的設備或低內存環境。
模型格式選擇總結表
模型格式 | 精度 | 內存使用 | 設備要求 | 最佳使用場景 |
---|---|---|---|---|
BF16 | 最高 | 高 | 支持BF16的GPU/CPU | 減少內存的高速推理 |
F16 | 高 | 高 | 支持FP16的設備 | BF16不可用時的GPU推理 |
Q4_K | 中低 | 低 | CPU或低顯存設備 | 內存受限的環境 |
Q6_K | 中等 | 適中 | 內存較多的CPU | 量化模型中準確性較好的情況 |
Q8_0 | 高 | 適中 | 有足夠顯存的CPU或GPU | 量化模型中準確性最佳 |
IQ3_XS | 非常低 | 非常低 | 超低內存設備 | 極端內存效率和低準確性 |
Q4_0 | 低 | 低 | ARM或低內存設備 | llama.cpp可針對ARM設備進行優化 |
包含文件詳情
OlympicCoder-32B-bf16.gguf
- 模型權重以BF16保存。
- 如果你想將模型重新量化為不同格式,請使用此文件。
- 若你的設備支持BF16加速,效果最佳。
OlympicCoder-32B-f16.gguf
- 模型權重以F16存儲。
- 若你的設備支持FP16,尤其是BF16不可用時使用。
OlympicCoder-32B-bf16-q8_0.gguf
- 輸出和嵌入層保持為BF16。
- 所有其他層量化為Q8_0。
- 若你的設備支持BF16且你想要量化版本,可使用此文件。
OlympicCoder-32B-f16-q8_0.gguf
- 輸出和嵌入層保持為F16。
- 所有其他層量化為Q8_0。
OlympicCoder-32B-q4_k.gguf
- 輸出和嵌入層量化為Q8_0。
- 所有其他層量化為Q4_K。
- 適合內存有限的CPU推理。
OlympicCoder-32B-q4_k_s.gguf
- 最小的Q4_K變體,以犧牲準確性為代價使用更少的內存。
- 最適合極低內存設置。
OlympicCoder-32B-q6_k.gguf
- 輸出和嵌入層量化為Q8_0。
- 所有其他層量化為Q6_K。
OlympicCoder-32B-q8_0.gguf
- 完全Q8量化的模型,以獲得更好的準確性。
- 需要更多內存,但提供更高的精度。
OlympicCoder-32B-iq3_xs.gguf
- IQ3_XS量化,針對極端內存效率進行了優化。
- 最適合超低內存設備。
OlympicCoder-32B-iq3_m.gguf
- IQ3_M量化,提供中等塊大小以提高準確性。
- 適用於低內存設備。
OlympicCoder-32B-q4_0.gguf
- 純Q4_0量化,針對ARM設備進行了優化。
- 最適合低內存環境。
- 若追求更好的準確性,建議使用IQ4_NL。
模型測試詳情
測試邀請
如果你覺得這些模型有用,請點贊!同時,幫助我測試我的支持量子安全檢查的AI網絡監控助手: 👉 免費網絡監控器
測試方法
- 點擊任何頁面右下角的聊天圖標。
- 選擇一個AI助手類型:
TurboLLM
(GPT - 4 - mini)FreeLLM
(開源)TestLLM
(僅支持CPU的實驗性模型)
測試內容
我正在探索小型開源模型在AI網絡監控中的極限,具體包括:
- 針對即時網絡服務的函數調用
- 模型可以多小,同時仍能處理:
- 自動化Nmap掃描
- 量子就緒檢查
- Metasploit集成
各助手詳情
- 🟡 TestLLM – 當前的實驗性模型(llama.cpp在6個CPU線程上運行):
- ✅ 零配置設置
- ⏳ 30秒加載時間(推理較慢,但無API成本)
- 🔧 尋求幫助! 如果你對邊緣設備AI感興趣,讓我們合作!
- 🟢 TurboLLM – 使用gpt - 4 - mini進行:
- 即時網絡診斷
- 自動化滲透測試(Nmap/Metasploit)
- 🔑 通過下載我們的免費網絡監控代理獲取更多令牌。
- 🔵 HugLLM – 開源模型(約8B參數):
- 比TurboLLM多2倍的令牌
- AI日誌分析
- 🌐 在Hugging Face推理API上運行
測試用AI命令示例
"Give me info on my websites SSL certificate"
"Check if my server is using quantum safe encyption for communication"
"Run a quick Nmap vulnerability test"
🔧 技術細節
訓練過程
訓練超參數
在16個H100節點上訓練時使用了以下超參數:
- 數據集:open - r1/codeforces - cots_decontaminated
- 學習率:4.0e - 5
- 訓練批次大小:1
- 隨機種子:42
- 打包:false
- 分佈式類型:fsdp
- 設備數量:128
- 梯度累積步數:1
- 總訓練批次大小:16
- 優化器:Adam,beta=(0.9, 0.999),epsilon = 1e - 08
- 學習率調度器類型:cosine_with_min_lr
- 最小學習率:0.1
- 學習率調度器熱身比例:0.03
- 訓練輪數:10.0
📄 許可證
本項目採用Apache - 2.0許可證。



