下载量
0
参数
2.6B
上下文
未说明
架构 / 任务
未分类
许可证
other
MODEL POSITIONING
这个模型解决什么问题？
本仓库定位为 LiquidAI/LFM2.5-2.6B-DSpark 的 GGUF 量化打包，对应 base_model 名称中标注的 2.6B 目标，是 llama.cpp 投机解码体系的草稿侧车，必须与 LFM2.5-2.6B-GGUF 目标模型配对。模型卡未说明基座能力评测细节、未说明上下文长度、未说明训练数据来源；能力层面仅声明草稿含 5 层注意力、rank-256 Markov 头、置信头、块大小 9，并由目标逐 token 验证，贪心输出与目标单独推理一致。量化仓库提供 F16、Q8_0、Q4_K_M 三档，模型卡指出低于 4 位会同时损伤接受长度与吞吐。运行工具覆盖 llama.cpp、Ollama、LM Studio。
更适合谁
- 已在使用 LFM2.5-2.6B-GGUF 目标、希望启用投机解码降低生成时延的本地部署者
- 持有 llama.cpp、Ollama 或 LM Studio 之一并愿意配置 draft/target 配对的高级用户
- 关注边缘设备推理效率、要求输出与目标模型完全等价的工程师
- 需要在草稿档位上做量化与吞吐实验的研究与开发人员
典型使用场景
- 给本地 LFM2.5-2.6B 目标 GGUF 启用投机解码以减少平均生成 token 耗时
- 在边缘或端侧设备上以更小代价得到与目标一致的文本生成结果
- 评测 F16、Q8_0、Q4_K_M 各档对草稿接受长度与吞吐的影响
- 作为 DSpark 草稿结构与投机解码流程的工程参考样例
SOURCE-BASED CAPABILITIES
模型卡透露的核心特点
精确投机解码
目标逐 token 验证草稿提案，贪心输出与目标单独运行等价
极小草稿体量
仅 5 层注意力与小型 Markov/置信头，块大小 9
共享嵌入与 LM 头
草稿不重复保存目标的大权重表，节省存储与加载时间
三档量化可调
F16、Q8_0、Q4_K_M 按内存预算挑选，量化对速度影响有限
运行时覆盖面广
同时支持 llama.cpp、Ollama、LM Studio 加载
硬件怎么准备
- Q4_K_M 文件按提供数据估算，最低 4GB 内存或 1.5GB 显存，推荐 8GB 内存或 2.5GB 显存
- F16 最低 4GB 内存或 2GB 显存，推荐 8GB 内存或 3GB 显存
- Q8_0 最低 4GB 内存或 3GB 显存，推荐 8GB 内存或 4GB 显存
- 以上仅为草稿侧车估算，实际部署必须额外为 LFM2.5-2.6B-GGUF 目标模型预留内存或显存
量化版本怎么选
- Q4_K_M 为官方推荐最小档，接受长度比 F16 低约 3%
- Q8_0 接受长度比 F16 低约 2%，是体积与质量的折中
- F16 在内存允许时接受长度最佳
- 不建议使用低于 Q4 的量化，模型卡明确指出会同时损伤接受长度与吞吐
GGUF VARIANTS
量化版本与硬件要求
HARDWARE MATCH
哪些显卡或设备更适合运行？
按当前最小量化文件估算，至少需要 1.5GB 显存；如果希望为运行框架和上下文保留余量，优先参考推荐显存 2.5GB。
阅读 4GB 显存选型指南 →可以怎样运行
- llama.cpp 加载草稿侧车并通过 speculative decoding 选项与目标模型配对
- Ollama 中以 draft 模型形式搭配 LFM2.5-2.6B 目标 GGUF 启动
- LM Studio 加载草稿并启用投机解码设置
- 参考 llama.cpp timings 中的 draft_n 与 draft_n_accepted 字段观察接受率
采用前要知道的限制
- 不能独立推理，必须与 LFM2.5-2.6B-GGUF 目标文件配对使用
- 模型卡未说明上下文长度、未提供训练数据说明、未给出独立基准跑分
- 草稿自身仅 5 层注意力，能力上限受目标模型绑定
- 模型卡未承诺具体加速比，速度收益取决于目标硬件与解码配置