Olympiccoder 7B GGUF

🚀 OlympicCoder-7B GGUF 模型

OlympicCoder-7B 是一個代碼模型，在諸如 LiveCodeBench 和 2024 年國際信息學奧林匹克競賽等競賽編程基準測試中表現出色。它能幫助開發者在代碼編寫和競賽編程場景中獲得更好的效果。

🚀 快速開始

模型使用示例

以下是如何使用 🤗 Transformers 的 pipeline() 函數運行該模型的示例：

# pip install transformers
# pip install accelerate

import torch
from transformers import pipeline

pipe = pipeline("text-generation", model="open-r1/OlympicCoder-7B", 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> 標記，要麼修改聊天模板以移除預填充內容。

✨ 主要特性

超低比特量化與 IQ-DynamicGate (1 - 2 比特)

我們最新的量化方法為超低比特模型（1 - 2 比特）引入了精度自適應量化，經基準測試證明，在 Llama - 3 - 8B 上有顯著改進。這種方法採用特定層策略，在保持極高內存效率的同時保留準確性。

基準測試背景

所有測試均在 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 的情況： ✔ 硬件具有原生 BF16 支持（如較新的 GPU、TPU）。 ✔ 希望在節省內存的同時獲得更高精度。 ✔ 計劃將模型重新量化為其他格式。

📌 避免使用 BF16 的情況： ❌ 硬件不支持 BF16（可能會回退到 FP32 並運行較慢）。 ❌ 需要與缺乏 BF16 優化的舊設備兼容。

F16 (Float 16) – 比 BF16 更廣泛支持

• 一種 16 位浮點格式，精度較高，但取值範圍小於 BF16。
• 適用於大多數支持 FP16 加速的設備（包括許多 GPU 和一些 CPU）。
• 數值精度略低於 BF16，但通常足以用於推理。

📌 使用 F16 的情況： ✔ 硬件支持 FP16 但不支持 BF16。 ✔ 需要在速度、內存使用和準確性之間取得平衡。 ✔ 在GPU或其他針對 FP16 計算優化的設備上運行。

📌 避免使用 F16 的情況： ❌ 設備缺乏原生 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-7B-bf16.gguf

• 模型權重以 BF16 格式保存。
• 若要將模型重新量化為其他格式，可使用此文件。
• 若設備支持 BF16 加速，使用效果最佳。

OlympicCoder-7B-f16.gguf

• 模型權重以 F16 格式存儲。
• 若設備支持 FP16，尤其是在 BF16 不可用時，可使用此文件。

OlympicCoder-7B-bf16-q8_0.gguf

• 輸出層和嵌入層保持為 BF16 格式。
• 所有其他層量化為 Q8_0。
• 若設備支持 BF16 且需要量化版本，可使用此文件。

OlympicCoder-7B-f16-q8_0.gguf

• 輸出層和嵌入層保持為 F16 格式。
• 所有其他層量化為 Q8_0。

OlympicCoder-7B-q4_k.gguf

• 輸出層和嵌入層量化為 Q8_0。
• 所有其他層量化為 Q4_K。
• 適合內存有限的 CPU 推理。

OlympicCoder-7B-q4_k_s.gguf

• 最小的 Q4_K 變體，以犧牲準確性為代價減少內存使用。
• 最適合極低內存設置。

OlympicCoder-7B-q6_k.gguf

• 輸出層和嵌入層量化為 Q8_0。
• 所有其他層量化為 Q6_K。

OlympicCoder-7B-q8_0.gguf

• 完全 Q8 量化的模型，準確性更好。
• 需要更多內存，但提供更高的精度。

OlympicCoder-7B-iq3_xs.gguf

• IQ3_XS 量化，針對極致內存效率進行了優化。
• 最適合超低內存設備。

OlympicCoder-7B-iq3_m.gguf

• IQ3_M 量化，提供中等塊大小以提高準確性。
• 適用於低內存設備。

OlympicCoder-7B-q4_0.gguf

• 純 Q4_0 量化，針對 ARM 設備進行了優化。
• 最適合低內存環境。
• 若追求更好的準確性，建議使用 IQ4_NL。

模型測試相關

測試邀請

如果您覺得這些模型有用，請點贊支持！同時，幫助我測試我的支持量子安全檢查的 AI 網絡監控助手： 👉 免費網絡監控器

測試方法

1. 點擊聊天圖標（任意頁面右下角）
2. 選擇一個 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 – 開源模型（約 80 億參數）：
  • 令牌數量是 TurboLLM 的 2 倍
  • AI 日誌分析
  • 🌐 在 Hugging Face 推理 API 上運行

測試用的 AI 命令示例

1. "Give me info on my websites SSL certificate"
2. "Check if my server is using quantum safe encyption for communication"
3. "Run a quick Nmap vulnerability test"

🔧 技術細節

訓練過程

訓練超參數

訓練過程中使用了以下超參數：

• 數據集：open - r1/codeforces - cots
• 學習率：4.0e - 5
• 訓練批次大小：2
• 隨機種子：42
• 打包：false
• 分佈式類型：deepspeed - zero - 3
• 設備數量：8
• 梯度累積步數：8
• 總訓練批次大小：16
• 優化器：Adam，β=(0.9, 0.999)，ε = 1e - 08
• 學習率調度器類型：cosine_with_min_lr
• 最小學習率：0.1
• 學習率調度器熱身比例：0.03
• 訓練輪數：10.0

📄 許可證

本項目採用 Apache - 2.0 許可證。

📚 模型卡片信息

屬性	詳情
模型類型	一個在經過淨化的 Codeforces 數據集上微調的 70 億參數模型
訓練數據	open - r1/codeforces - cots
語言	主要為英語
許可證	Apache - 2.0
基礎模型	[Qwen/Qwen2.5 - Coder - 7B - Instruct](https://huggingface.co/Qwen/Qwen2.5 - Coder - 7B - Instruct)
倉庫地址	https://github.com/huggingface/open - r1
博客文章	https://huggingface.co/blog/open - r1/update - 3

評估指標

我們在兩個主要的競賽編程基準測試中比較了 OlympicCoder 模型的性能：

• IOI'2024：2024 年國際信息學奧林匹克競賽的 6 個極具挑戰性的問題。每個問題允許模型最多提交 50 次。
• LiveCodeBench：來自 CodeForces 和 LeetCoder 等平臺的 Python 編程問題。我們使用了 livecodebench/code_generation_lite 中的 v4_v5 子集，對應 268 個問題。使用 lighteval 按照[此處](https://github.com/huggingface/open - r1?tab=readme - ov - file#livecodebench)描述的採樣參數在 LiveCodeBench 上評估模型。

⚠️ 重要提示

OlympicCoder 模型僅在 DeepSeek - R1 生成的 C++ 解決方案上進行了後續訓練。因此，在 LiveCodeBench 上的性能應被視為部分域外表現，因為該基準測試期望模型輸出 Python 解決方案。

評估結果展示

• IOI'24：
• LiveCodeBench：