模型简介
模型特点
模型能力
使用案例
base_model: LGAI-EXAONE/EXAONE-3.5-2.4B-Instruct
language:
- en
- ko
library_name: transformers
license: other
license_name: exaone
license_link: LICENSE
pipeline_tag: text-generation
tags: - lg-ai
- exaone
- exaone-deep
base_model_relation: finetune
EXAONE-Deep-2.4B 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和低VRAM推理
量化减少了模型大小和内存占用,同时尽可能保持准确性。
- 低比特模型(Q4_K) → 最适合最小内存占用,但精度可能较低。
- 高比特模型(Q6_K、Q8_0) → 更好的准确性,但需要更多内存。
📌 使用量化模型如果:
✔ 您在CPU上运行推理并需要优化模型。
✔ 您的设备VRAM较低,无法加载全精度模型。
✔ 您希望减少内存占用,同时保持合理的准确性。
📌 避免使用量化模型如果:
❌ 您需要最高精度(全精度模型更适合)。
❌ 您的硬件有足够的VRAM支持更高精度格式(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的设备 | GPU推理,当BF16不可用时 |
Q4_K | 中低 | 低 | CPU或低VRAM设备 | 最适合内存受限环境 |
Q6_K | 中 | 中等 | 内存较多的CPU | 更好的准确性,同时保持量化 |
Q8_0 | 高 | 中等 | 有足够VRAM的CPU或GPU | 量化模型中最佳准确性 |
IQ3_XS | 极低 | 极低 | 超低内存设备 | 极致内存效率和低准确性 |
Q4_0 | 低 | 低 | ARM或低内存设备 | llama.cpp可针对ARM设备优化 |
包含文件及详情
EXAONE-Deep-2.4B-bf16.gguf
- 模型权重以BF16保存。
- 如果您想将模型重新量化为其他格式,请使用此文件。
- 如果您的设备支持BF16加速,则最佳选择。
EXAONE-Deep-2.4B-f16.gguf
- 模型权重以F16存储。
- 如果您的设备支持FP16,尤其是BF16不可用时使用。
EXAONE-Deep-2.4B-bf16-q8_0.gguf
- 输出和嵌入保持为BF16。
- 其他所有层量化为Q8_0。
- 如果您的设备支持BF16且您需要量化版本,请使用此文件。
EXAONE-Deep-2.4B-f16-q8_0.gguf
- 输出和嵌入保持为F16。
- 其他所有层量化为Q8_0。
EXAONE-Deep-2.4B-q4_k.gguf
- 输出和嵌入量化为Q8_0。
- 其他所有层量化为Q4_K。
- 适合内存有限的CPU推理。
EXAONE-Deep-2.4B-q4_k_s.gguf
- 最小的Q4_K变体,以牺牲准确性为代价减少内存占用。
- 最适合极低内存配置。
EXAONE-Deep-2.4B-q6_k.gguf
- 输出和嵌入量化为Q8_0。
- 其他所有层量化为Q6_K。
EXAONE-Deep-2.4B-q8_0.gguf
- 完全Q8量化模型,提供更好的准确性。
- 需要更多内存,但精度更高。
EXAONE-Deep-2.4B-iq3_xs.gguf
- IQ3_XS量化,针对极致内存效率优化。
- 最适合超低内存设备。
EXAONE-Deep-2.4B-iq3_m.gguf
- IQ3_M量化,提供中等块大小以提高准确性。
- 适合低内存设备。
EXAONE-Deep-2.4B-q4_0.gguf
- 纯Q4_0量化,针对ARM设备优化。
- 最适合低内存环境。
- 如需更高准确性,推荐使用IQ4_NL。
🚀 如果您觉得这些模型有用
请点赞 ❤。同时,如果您能测试我的网络监控助手,我将非常感激 👉 网络监控助手。
💬 点击聊天图标(主页面和仪表板页面右下角)。选择一个LLM;在LLM类型之间切换:TurboLLM -> FreeLLM -> TestLLM。
我正在测试的内容
我正在尝试对我的网络监控服务进行函数调用。使用小型开源模型。我正在研究的问题是“模型可以小到什么程度,同时仍能正常工作”。
🟡 TestLLM – 在6个CPU线程的虚拟机(VM)上使用llama.cpp运行当前测试模型(加载大约需要15秒。推理速度较慢,且一次只能处理一个用户提示——仍在扩展中!)。如果您感兴趣,我很乐意分享它的工作原理!
其他可用的AI助手
🟢 TurboLLM – 使用gpt-4o-mini,速度快!注意:由于OpenAI模型价格昂贵,令牌有限,但您可以登录或下载免费的网络监控代理以获取更多令牌,或者使用TestLLM。
🔵 HugLLM – 运行开源Hugging Face模型,速度快,运行小型模型(≈8B),因此质量较低,获取2倍更多令牌(受Hugging Face API可用性限制)。
EXAONE-Deep-2.4B
简介
我们推出EXAONE Deep,该模型在包括数学和编程基准在内的各种推理任务中表现出卓越能力,参数规模从2.4B到32B,由LG AI Research开发和发布。该模型在论文EXAONE Deep: Reasoning Enhanced Language Models中描述,代码可在此处获取。评估结果显示:1) EXAONE Deep 2.4B在同等规模模型中表现优异;2) EXAONE Deep 7.8B不仅优于同等规模的开源模型,还优于专有推理模型OpenAI o1-mini;3) EXAONE Deep 32B在与领先的开源模型竞争中表现出色。
本仓库包含具有以下特点的2.4B推理语言模型:
- 参数数量(不含嵌入):2.14B
- 层数:30
- 注意力头数:GQA,32个Q头和8个KV头
- 词汇量:102,400
- 上下文长度:32,768个令牌
- 绑定词嵌入:True(与7.8B和32B模型不同)
注意
EXAONE Deep模型采用优化配置训练,因此建议遵循使用指南部分以实现最佳性能。
评估
下表展示了数学和编程等推理任务的评估结果。完整评估结果可在文档中找到。