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?")
📚 详细文档
模型架构
正如博客文章中详细描述的,我们使用了:
我们还使用了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。
测试模型
如果您觉得这些模型有用,请点击“点赞”!同时,帮助我测试我的人工智能网络监控助手,它具备量子就绪安全检查功能: 👉 免费网络监控器
测试方法
- 点击任意页面右下角的聊天图标。
- 选择一个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测试命令
"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"
模型表现
最终,我们在博客文章中开始训练的模型终于完成了🎉
经过对生成数据的微调,它击败了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% |
引用说明
如果您使用此模型,请提供此页面的链接。



