Refact 1 6B Fim GGUF

🚀 Refact-1.6B-fim GGUF模型

Refact-1.6B-fim GGUF模型是一款具有創新性的模型，它採用了最新的超低比特量化方法，在保持高精度的同時，實現了極致的內存效率。該模型適用於多種硬件環境，能滿足不同用戶在代碼生成、網絡監控等方面的需求。

🚀 快速開始

超低比特量化與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支持（例如，較新的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設備進行優化

📦 安裝指南

文檔未提及安裝步驟，故跳過此章節。

💻 使用示例

基礎用法

# pip install -q transformers
from transformers import AutoModelForCausalLM, AutoTokenizer

checkpoint = "smallcloudai/Refact-1_6B-fim"
device = "cuda" # for GPU usage or "cpu" for CPU usage

tokenizer = AutoTokenizer.from_pretrained(checkpoint)
model = AutoModelForCausalLM.from_pretrained(checkpoint, trust_remote_code=True).to(device)

prompt = '<fim_prefix>def print_hello_world():\n    """<fim_suffix>\n    print("Hello world!")<fim_middle>'

inputs = tokenizer.encode(prompt, return_tensors="pt").to(device)
outputs = model.generate(inputs, max_length=100, temperature=0.2)
print("-"*80)
print(tokenizer.decode(outputs[0]))

高級用法

prompt_template = "<empty_output>SYSTEM {system}\n" \
                  "<empty_output>USER {query}\n" \
                  "<empty_output>ASSISTANT"
prompt = prompt_template.format(system="You are a programming assistant",
                                query="How do I sort a list in Python?")

📚 詳細文檔

模型架構

正如博客文章中詳細描述的，我們使用了：

• ALiBi基於注意力機制
• LayerNorm而非RMSNorm
• 多查詢注意力

我們還使用了LiON、閃存注意力、早期丟棄。實際上，您可以運行該模型，以下是一個示例。

預訓練

對於基礎模型，我們使用了自己的數據集，其中僅包含具有寬鬆許可證的代碼和開放文本數據集。過濾是該模型成功的關鍵：

• 我們僅使用英語文本
• 僅使用與計算機科學相關的主題
• 進行了大量去重

文本與代碼的比例為50:50，模型訓練了1.2T令牌。

我們不發佈基礎模型，因為其填充中間（FIM）能力容易重複，因此其實際用途有限。但如果您仍然需要，請在Discord上給我們留言。

微調

我們測試了一個假設，即聊天數據可以提升基礎模型在FIM和常規從左到右代碼完成方面的性能。我們發現，僅使用經過質量過濾的15%的開放代碼指令跟隨數據集，就可以提高几乎所有指標。

此外，為了改進FIM，我們觀察了常見的失敗模式，並基於The Stack dedup v1.1準備了一個合成數據集來解決這些問題。

互聯網上的典型代碼與您在IDE中編寫的代碼之間存在分佈差異。前者可能已經完成，因此模型會嘗試提出一個使代碼完整的建議。而您在編寫代碼時可能只完成了一半，沒有單一的補充可以完全修復它。

實際上，模型需要有在添加幾行後停止的傾向，有時甚至不輸出任何內容。我們發現，為其提供空完成、單行完成、以較小文本縮進或至少換行符結尾的多行完成，會使其更易於使用。這些數據構成了微調數據集的其餘85%。

最終模型是多次嘗試的結果，旨在使其在代碼完成方面儘可能表現出色，並在廣泛的指標上取得良好性能。最佳嘗試使用了40B令牌。

侷限性和偏差

Refact - 1.6B模型是在英語文本上訓練的。但它在代碼註釋中接觸到了更多語言。可以肯定的是，它在非英語語言上的性能較低。

模型統計信息

屬性	詳情
模型類型	LLAMA-like模型，具有多查詢注意力
目標任務	填充中間、聊天
令牌上下文	4096
預訓練令牌	1.2T
微調令牌	40B
精度	bfloat16
GPU數量	64塊NVidia A5000
訓練時間	28天

🔧 技術細節

文檔未提供超過50字的具體技術說明，故跳過此章節。

📄 許可證

該模型遵循BigScience OpenRAIL - M v1許可協議。

其他信息

包含的文件及詳情

Refact-1_6B-fim-bf16.gguf

• 模型權重以BF16格式保存。
• 如果您想將模型重新量化為其他格式，請使用此文件。
• 如果您的設備支持BF16加速，此文件為最佳選擇。

Refact-1_6B-fim-f16.gguf

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

Refact-1_6B-fim-bf16-q8_0.gguf

• 輸出和嵌入層保持為BF16。
• 所有其他層量化為Q8_0。
• 如果您的設備支持BF16，並且您想要一個量化版本，請使用此文件。

Refact-1_6B-fim-f16-q8_0.gguf

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

Refact-1_6B-fim-q4_k.gguf

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

Refact-1_6B-fim-q4_k_s.gguf

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

Refact-1_6B-fim-q6_k.gguf

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

Refact-1_6B-fim-q8_0.gguf

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

Refact-1_6B-fim-iq3_xs.gguf

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

Refact-1_6B-fim-iq3_m.gguf

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

Refact-1_6B-fim-q4_0.gguf

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

測試模型

如果您覺得這些模型有用，請點擊“點贊”！同時，幫助我測試我的人工智能網絡監控助手，它具備量子就緒安全檢查功能： 👉 免費網絡監控器

測試方法

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 – 開源模型（約8B參數）：

• 比TurboLLM多2倍令牌
• 人工智能日誌分析
• 🌐 在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"

模型表現

最終，我們在博客文章中開始訓練的模型終於完成了🎉

經過對生成數據的微調，它擊敗了Replit 3b、Stability Code 3b等許多模型。它幾乎擊敗了大小是其十倍的StarCoder！

模型	大小	HumanEval pass@1	HumanEval pass@10
DeciCoder - 1b	1b	19.1%
Refact - 1.6 - fim	1.6b	32.0%	53.0%
StableCode	3b	20.2%	33.8%
ReplitCode v1	3b	21.9%
CodeGen2.5 - multi	7b	28.4%	47.5%
CodeLlama	7b	33.5%	59.6%
StarCoder	15b	33.6%

很可能，它是您在IDE中進行代碼完成的最佳實用模型，因為它既智能又快速！您現在就可以通過下載Refact插件開始使用它。您也可以使用開源Docker容器自行託管該模型。

並且它支持多語言（請參閱下面的MultiPL - HumanEval和其他指標），還可以作為聊天模型使用（請參閱以下部分）。

作為聊天模型使用

該模型的主要應用是在多種編程語言中進行代碼完成（填充）。但它作為聊天模型也表現出色。

與專門的聊天模型相比，使用指令跟隨（聊天）格式的HumanEval結果：

模型	大小	pass@1	pass@10
Refact - 1.6 - fim	1.6b	38.4%	55.6%
StableCode - instruct	3b	26.9%	36.2%
OctoGeeX	6b	44.7%
CodeLlama - instruct	7b	34.8%	64.3%
CodeGen2.5 - instruct	7b	36.2%	60.87
CodeLlama - instruct	13b	42.7%	71.6%
StarChat - β	15b	33.5%
OctoCoder	15b	46.2%

引用說明

如果您使用此模型，請提供此頁面的鏈接。