下载量
0
参数
27B
上下文
未说明
架构 / 任务
未分类
许可证
apache-2.0
MODEL POSITIONING
这个模型解决什么问题？
模型本身是 empero-ai 推出的 Qwythos-27B-v1 的 GGUF 量化仓库，针对 llama.cpp、Ollama、LM Studio 等 GGUF 运行时优化。该模型基于 Qwen3.5-27B，采用混合架构（每四层含三层 Gated-DeltaNet 线性注意力），属于已完成 SFT、DPO、ESFT 的 v1 预 RL 检查点。仓库同时提供纯文本权重与带 MTP 的变体，以及独立的 mmproj 视觉编码器文件。MTP 推测需较新的 llama.cpp 构建支持 draft-mtp 模式。模型卡未说明具体的训练数据规模与学术评测分数。
更适合谁
- 有 24GB 及以上显存、追求本地 27B 推理体验的开发者
- 需要长上下文（数十万 token 级别）的文档分析、代码库理解任务
- 想要尝试多模态输入与工具调用工作流的研究者
- 偏好开源、未审查路线进行实验的用户
典型使用场景
- 长文档摘要、合同分析、学术论文阅读与跨章节问答
- 代码理解与跨文件重构，结合长上下文处理大型仓库
- 图像理解任务：截图分析、图表问答、视觉推理
- 工具增强型代理：调用外部 API、执行多步任务链
SOURCE-BASED CAPABILITIES
模型卡透露的核心特点
长上下文能力
原生支持 1,048,576 token 窗口，4× YaRN 扩展于 262K 原生窗口
多模态输入
视觉塔完整保留，下载 mmproj 即可配合文本量化进行图文输入
MTP 推测解码
内置原生 MTP 头，可在支持 draft-mtp 的运行时获得加速
工具调用与代理能力
继承 Qwen3.5 完整工具规范，配合 llama-server OpenAI 兼容端点
混合精度 K-quant
Gated-DeltaNet 张量在 Q4/Q5/Q6 中保留 Q8_0 以上精度，保护敏感状态
硬件怎么准备
- 24GB 显卡（如 RTX 4090/5090）可加载 Q4_K_M 权重，Q5_K_M 需谨慎分配 KV 缓存空间
- 48GB 显卡是 Q5/Q6 量化更舒适的起点，Q8_0 也可勉强容纳
- BF16 权重单独超过 50GB，建议 80GB 级显卡或多卡方案，并预留 KV 缓存与运行时开销
- 长上下文（512K 以上）即使 Q4_K_M 也需要激进 KV 卸载或多卡部署
量化版本怎么选
- 默认推荐 Q4_K_M：文件最小且为仓库推荐起点，单 24GB 显卡即可加载
- MTP-Q4_K_M 适合支持 draft-mtp 的最新 llama.cpp 构建，可获得推测解码加速
- Q5_K_M 与 Q6_K 适合显存更充裕、追求质量提升的部署
- BF16 仅在需要基准对照或具备 80GB 以上显存时考虑
GGUF VARIANTS
量化版本与硬件要求
HARDWARE MATCH
哪些显卡或设备更适合运行？
按当前最小量化文件估算，至少需要 14GB 显存；如果希望为运行框架和上下文保留余量，优先参考推荐显存 16GB。
阅读 24GB 显存选型指南 →可以怎样运行
- llama.cpp：通过 llama-cli 或 llama-server 直接加载 GGUF 文件
- Ollama：作为 GGUF 运行时直接导入模型
- LM Studio / jan / KoboldCpp：GUI 工具中加载 GGUF
- 多模态：配合 mmproj-Qwythos-27B-F16.gguf 使用 llama-mtmd-cli 或 llama-server 的视觉端点
采用前要知道的限制
- 仍为 v1 预 RL 检查点，作者明确说明尚未进行 RL 训练，v2 计划中
- 模型卡未提供标准化学术基准分数，建议用户自行验证相关任务表现
- MTP 推测解码依赖较新的 llama.cpp 构建，老版本运行时只能使用纯文本权重
- 未审查路线，部署到终端用户需自行加装应用层审核与安全控制