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%

引用说明

如果您使用此模型，请提供此页面的链接。