模型概述
模型特點
模型能力
使用案例
🚀 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}
}



