小GPU与小RAM用户的优秀编码器!

Reddit r/LocalLLaMA 模型

摘要

新量化AI模型Sharp-Spark-X2.5-4B-GGUF发布,针对小GPU和有限内存优化代理编码能力,提升资源有限用户的本地编码体验。

我一直致力于提升小模型在代理编码和任务中的能力,因为全球大多数人并不具备运行3.8-27B、甚至35B-A3B或9B密集模型所需的硬件条件。我希望将本地代理编码能力普及到资源有限的用户手中。这个量化版本能在智能手机或旧款游戏笔记本上运行,并能以我前所未见或测量过的方式自主解决真实编码难题。Spark-X2.5-4B在其体积内已接近同类最佳,我认为这些改进让它展现出最佳性能。希望这种在小模型能力和现实编码速度上的微小进步,能为那些在AI前沿竞赛中被遗忘的旧硬件注入新生命。SharpSpark对Spark-4B的修改分为三个部分:首先,它修复了聊天模板的问题,并替换为一个能提升代理编码行为、令牌效率和准确性的系统提示。接着,为模型校准了一个自定义重要性矩阵,该矩阵将张量内的比特精度重新分配到对代理编码工作至关重要的部分。imatrix语料库高度加权代理编码和网络安全,这两者共同保护了用于发现和解决复杂错误的认知核心。然后,Spark使用优化的非标准量化策略进行处理,与标准llama.cpp GGUF量化不同,它为每个张量分配不同的比特位。我开发了一个工具来探索和测试不同的每张量分配,以优化KL散度和长上下文检索,但最终手动调整了一些设置,这些调整更注重SWE-bench-Live性能,而非传统保真度指标如KL散度——有研究表明,在复杂任务中低于某个阈值时,KL散度实际上是性能的差代理。如果您拥有小GPU和/或小于等于16GB内存,且无法运行35B-a3b基于混合专家的模型配合部分GPU卸载,那么这可能是您当前进行长上下文代理软件开发的最佳选项。选择SWE-bench-Live作为指标,是因为它具有真正困难的真实代码库问题集。我只是一个志愿者,将此作为非营利副项目进行,因此请对我基准测试不够全面的现状予以理解。这些测试是我能在兼顾其他项目的同时承担时间和精力完成的,我认为它们刚好足以证明此量化版本针对特定工作类型所做的改进。 https://huggingface.co/peculiar-ragdoll/Sharp-Spark-X2.5-4B-GGUF
查看原文

相似文章

在12GB显存预算下实现真正的本地代理编码。

Reddit r/LocalLLaMA

本文描述了一个实用的设置,用于在12GB显存GPU上运行本地代理编码,使用量化后的Qwen 3.8 27B模型,并通过OpenCode和Magic Context等工具进行上下文管理,实现高效性能。

新型模型:Spark-X2.5-4B, Spark-X2.5-1.7B

Reddit r/LocalLLaMA

推出Spark-X2.5-4B和Spark-X2.5-1.7B,这两款紧凑型通用语言模型原生支持百万token上下文,具备强大的编码与智能体能力,并提供广泛的硬件兼容性。