模型简介
模型特点
模型能力
使用案例
🚀 Qwen2.5-1.5B-Instruct GGUF模型
Qwen2.5-1.5B-Instruct GGUF模型为不同硬件和应用场景提供了多样化的选择。它能帮助用户根据自身需求,在精度、内存使用和设备要求之间找到最佳平衡,以实现高效的文本生成任务。
🚀 快速开始
选择合适的模型格式
选择正确的模型格式取决于您的硬件能力和内存限制。
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设备进行优化 |
📦 安装指南
文档未提及安装步骤相关内容,故跳过此章节。
💻 使用示例
基础用法
from transformers import AutoModelForCausalLM, AutoTokenizer
model_name = "Qwen/Qwen2.5-1.5B-Instruct"
model = AutoModelForCausalLM.from_pretrained(
model_name,
torch_dtype="auto",
device_map="auto"
)
tokenizer = AutoTokenizer.from_pretrained(model_name)
prompt = "Give me a short introduction to large language model."
messages = [
{"role": "system", "content": "You are Qwen, created by Alibaba Cloud. You are a helpful assistant."},
{"role": "user", "content": prompt}
]
text = tokenizer.apply_chat_template(
messages,
tokenize=False,
add_generation_prompt=True
)
model_inputs = tokenizer([text], return_tensors="pt").to(model.device)
generated_ids = model.generate(
**model_inputs,
max_new_tokens=512
)
generated_ids = [
output_ids[len(input_ids):] for input_ids, output_ids in zip(model_inputs.input_ids, generated_ids)
]
response = tokenizer.batch_decode(generated_ids, skip_special_tokens=True)[0]
📚 详细文档
包含的文件及详情
Qwen2.5-1.5B-Instruct-bf16.gguf
- 模型权重以BF16格式保存。
- 如果您想将模型重新量化为其他格式,请使用此文件。
- 如果您的设备支持BF16加速,这是最佳选择。
Qwen2.5-1.5B-Instruct-f16.gguf
- 模型权重以F16格式存储。
- 如果您的设备支持FP16,尤其是在BF16不可用时,请使用此文件。
Qwen2.5-1.5B-Instruct-bf16-q8_0.gguf
- 输出和嵌入保持为BF16。
- 所有其他层量化为Q8_0。
- 如果您的设备支持BF16,并且您想要一个量化版本,请使用此文件。
Qwen2.5-1.5B-Instruct-f16-q8_0.gguf
- 输出和嵌入保持为F16。
- 所有其他层量化为Q8_0。
Qwen2.5-1.5B-Instruct-q4_k.gguf
- 输出和嵌入量化为Q8_0。
- 所有其他层量化为Q4_K。
- 适用于内存有限的CPU推理。
Qwen2.5-1.5B-Instruct-q4_k_s.gguf
- 最小的Q4_K变体,以牺牲准确性为代价减少内存使用。
- 最适合极低内存设置。
Qwen2.5-1.5B-Instruct-q6_k.gguf
- 输出和嵌入量化为Q8_0。
- 所有其他层量化为Q6_K。
Qwen2.5-1.5B-Instruct-q8_0.gguf
- 完全Q8量化的模型,以提高准确性。
- 需要更多内存,但提供更高的精度。
Qwen2.5-1.5B-Instruct-iq3_xs.gguf
- IQ3_XS量化,针对极端内存效率进行了优化。
- 最适合超低内存设备。
Qwen2.5-1.5B-Instruct-iq3_m.gguf
- IQ3_M量化,提供中等块大小以提高准确性。
- 适用于低内存设备。
Qwen2.5-1.5B-Instruct-q4_0.gguf
- 纯Q4_0量化,针对ARM设备进行了优化。
- 最适合低内存环境。
- 若追求更高准确性,建议使用IQ4_NL。
测试模型
如果您觉得这些模型有用,请点击“点赞”!同时,帮助我测试我的支持量子安全检查的AI网络监控助手: 👉 免费网络监控器
💬 测试方法:
- 点击聊天图标(任何页面的右下角)。
- 选择一种AI助手类型:
TurboLLM
(GPT - 4 - mini)FreeLLM
(开源)TestLLM
(仅支持CPU的实验性模型)
测试内容
我正在挑战用于AI网络监控的小型开源模型的极限,具体包括:
- 针对实时网络服务进行函数调用。
- 探索模型在处理以下任务时可以达到多小的规模:
- 自动化Nmap扫描
- 量子就绪性检查
- Metasploit集成
🟡 TestLLM – 当前的实验性模型(在6个CPU线程上运行llama.cpp):
- ✅ 零配置设置
- ⏳ 30秒加载时间(推理速度慢,但无API成本)
- 🔧 寻求帮助! 如果您对边缘设备AI感兴趣,让我们一起合作!
其他助手
🟢 TurboLLM – 使用gpt - 4 - mini进行:
- 实时网络诊断
- 自动化渗透测试(Nmap/Metasploit)
- 🔑 通过下载我们的免费网络监控代理获取更多令牌。
🔵 HugLLM – 开源模型(约80亿参数):
- 令牌数量是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"
🔧 技术细节
Qwen2.5-1.5B-Instruct介绍
Qwen2.5是Qwen大语言模型的最新系列。对于Qwen2.5,我们发布了一系列参数从5亿到720亿的基础语言模型和指令调优语言模型。Qwen2.5在Qwen2的基础上带来了以下改进:
- 由于我们在这些领域的专业专家模型,它拥有显著更多的知识,并在编码和数学方面的能力有了极大提升。
- 在遵循指令、生成长文本(超过8K令牌)、理解结构化数据(例如表格)和生成结构化输出(尤其是JSON)方面有了显著改进。对系统提示的多样性更具鲁棒性,增强了聊天机器人的角色扮演实现和条件设置。
- 支持长达128K令牌的长上下文,并能生成多达8K令牌。
- 支持超过29种语言,包括中文、英语、法语、西班牙语、葡萄牙语、德语、意大利语、俄语、日语、韩语、越南语、泰语、阿拉伯语等。
本仓库包含经过指令调优的15亿参数Qwen2.5模型,具有以下特点:
属性 | 详情 |
---|---|
模型类型 | 因果语言模型 |
训练阶段 | 预训练和后训练 |
架构 | 带有RoPE、SwiGLU、RMSNorm、注意力QKV偏置和绑定词嵌入的transformers架构 |
参数数量 | 15.4亿 |
非嵌入参数数量 | 13.1亿 |
层数 | 28 |
注意力头数量(GQA) | Q为12,KV为2 |
上下文长度 | 完整32,768令牌,生成8192令牌 |
评估与性能
详细的评估结果在这篇📑 博客中报告。关于GPU内存要求和相应的吞吐量,请查看此处的结果。
📄 许可证
本项目采用Apache - 2.0许可证。
引用
如果您觉得我们的工作有帮助,请随意引用:
@misc{qwen2.5,
title = {Qwen2.5: A Party of Foundation Models},
url = {https://qwenlm.github.io/blog/qwen2.5/},
author = {Qwen Team},
month = {September},
year = {2024}
}
@article{qwen2,
title={Qwen2 Technical Report},
author={An Yang and Baosong Yang and Binyuan Hui and Bo Zheng and Bowen Yu and Chang Zhou and Chengpeng Li and Chengyuan Li and Dayiheng Liu and Fei Huang and Guanting Dong and Haoran Wei and Huan Lin and Jialong Tang and Jialin Wang and Jian Yang and Jianhong Tu and Jianwei Zhang and Jianxin Ma and Jin Xu and Jingren Zhou and Jinze Bai and Jinzheng He and Junyang Lin and Kai Dang and Keming Lu and Keqin Chen and Kexin Yang and Mei Li and Mingfeng Xue and Na Ni and Pei Zhang and Peng Wang and Ru Peng and Rui Men and Ruize Gao and Runji Lin and Shijie Wang and Shuai Bai and Sinan Tan and Tianhang Zhu and Tianhao Li and Tianyu Liu and Wenbin Ge and Xiaodong Deng and Xiaohuan Zhou and Xingzhang Ren and Xinyu Zhang and Xipin Wei and Xuancheng Ren and Yang Fan and Yang Yao and Yichang Zhang and Yu Wan and Yunfei Chu and Yuqiong Liu and Zeyu Cui and Zhenru Zhang and Zhihao Fan},
journal={arXiv preprint arXiv:2407.10671},
year={2024}
}



