ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF
摘要
ISTA-DASLab 发布了 Qwen3.8-Flash-Next 的能力目标压缩版本,该版本剪掉一半路由专家,并以 3.5 bpw 存储剩余权重,将 354 GB 的模型压缩至 29.6 GB,使一个 176.9B 参数的模型能够放入单个 32 GB 加速器中,同时在 LiveCodeBench v6 上保留 98.7%、在 SWE-bench Verified 上保留 91.3% 的得分。
查看缓存全文
缓存时间: 2026/10/01 09:35
ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF · Hugging Face 来源: https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF 代码基准测试:50% 专家剪枝后 (https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF/blob/main/assets/plots/Qwen3.8-Flash-Next-Coder-coding_benchmarks.png) — ## https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF#overview概述 本次发布是对 Qwen3.8-Flash-Next 的面向能力的压缩版本。模型中一半的路由专家被直接移除而非量化,其余权重以 3.5 bpw 存储。基础模型拥有 176.9B 参数,BF16 精度下占用 354 GB。压缩后的模型仅缩减到 29.6 GB,且必须驻留在内存中:n-gram 分片是一个查找表,可以从磁盘直接加载服务。因此,一个 176.9B 参数模型的常驻工作集仅需一块 32 GB 加速器即可容纳。在 Transformer 层面取平均后,这相当于原始模型的每参数 1.89 比特。该数字是一个等效速率:它将被移除的专家摊销到原始参数总量上,因此反映的是剪枝与量化的综合效果。没有任何单一权重是以 1.89 比特存储的。保留的权重以 3.5 bpw 存储,不受剪枝影响;专家数量减半则解释了剩余的压缩幅度。按照配套发布版本的惯例,该数字在 Transformer 层面统计,并排除固定精度的 n-gram 分片。 移除模型一半的专家必然会降低其能力。本次发布的贡献在于,压缩是有方向性的,目标指向代码、agentic 工具使用、视觉与空间推理,因此保留下来的正是支撑这些领域能力的专家。在这些领域之外的能力退化,是该方法可接受的代价。若面向通用用途,未剪枝的 GSQ-RCO 发布版本 (https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF) 是更合适的选择。 SWE-bench VerifiedLiveCodeBench v6BF16 基础模型 (354 GB)82.8087.43GSQ-RCO Coder (58.4 GB)75.6086.28保留比例91.3%98.7% 本模型卡中的所有数字均在 xhigh 推理强度 (reasoning effort) 下测得。这是一个实验性发布,欢迎反馈,尤其是关于校准数据混合中未覆盖的能力。LiveCodeBench v6 的能力基本得以保留,达到基础分数的 98.7%。而 SWE-bench Verified 评估的是在真实代码仓库上进行的长时程 agentic 轨迹,其保留比例为 91.3%。两者之间的差距符合预期:持续的多步任务会在各轮交互中累积误差,因此相比单题代码生成,更能容忍容量上的削减。 — ## https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF#what-expert-pruning-is什么是专家剪枝 混合专家(Mixture-of-Experts)层包含许多独立的前馈块和一个小型路由器,后者为每个 token 选出少数几个专家。Flash-Next 在 48 层中每层拥有 512 个专家,每个 token 激活 10 个,因此绝大多数参数由专家承载,但在任意给定 token 上只有一小部分专家被激活。 专家剪枝是从模型中直接移除整个专家。它与量化不同——量化保留全部参数,只降低其存储精度。剪枝则直接从模型中删除参数,既减小文件大小也降低常驻内存,并将路由器的候选池限制得更小。两种技术是互补的,在此结合使用:移除 50% 的专家,并将剩余权重量化到 3.5 bpw。 核心问题在于移除哪些专家。由于专家是专门化的,重要性并非专家的内在属性,而是相对于某一输入分布来定义的。这个分布由校准数据提供,因此校准数据决定了哪些能力能在压缩后得以保留。 — ## https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF#how-the-experts-are-chosen专家是如何被选择的选择过程使用 RCO(论文 (https://arxiv.org/abs/2605.00649),代码 (https://github.com/IST-DASLab/RCO))完成,优化目标是剪枝模型与未剪枝模型在校准数据上的 KL 散度,而不是依据启发式重要性得分对专家进行排序。 GGUF 格式以特定方式约束了这个问题。它为整个模型只存储一个专家数量,因此每一层必须保留相同数量的专家。单一的全局预算允许搜索从不敏感的层移除更多专家、从敏感的层移除更少专家,这通常能产生更好的模型,但由此得出的每层计数是该格式无法表示的——除非通过填充来规避,而这会损失本已节省的内存。 RCO 通过将可行集视为光滑流形来精确地执行预算约束,并支持多个同时存在的预算。用每层一个预算取代全局预算,就将格式的结构性需求直接表达为约束条件。这些约束彼此独立(因为没有专家属于多个层),因此投影与回缩步骤可分解为逐层操作,开销仍然很低。 约束可以分解,但目标函数不行:损失是整个模型的 KL 散度,因此任何一层的梯度都反映了其他所有层的状态;各层是联合优化的,只有预算执行是逐层进行的。这使该方法有别于常见的替代方案——后者在启发式重要性得分下为每层固定保留排名最高的专家,不做联合搜索。基于惩罚项的公式化方案还需要为每层引入一个系数,且这些系数之间相互影响;而 RCO 不需要任何此类系数。 — ## https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF#vision-capability视觉能力 初始搜索仅使用了代码和 agentic 校准数据。结果移除了视觉通路所依赖的专家,图像能力显著下降,而代码分数不受影响。这是方法的预期行为而非失败:在没有涉及视觉的校准数据时,搜索正确地判定这些专家对被测目标函数没有贡献。 发布的模型是在校准数据混合中包含视觉的情况下进行搜索的,因此保留了视觉能力。作为非正式的定性检查,这里使用了 “pelican riding a bicycle”(鹈鹕骑自行车)提示词,它同时需要物体知识、空间构图和正确的 SVG 语法:由剪枝后模型绘制的 SVG:一只鹈鹕骑着一辆自行车 — ## https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF#available-files可用文件 两个分片,二者都必需。llama.cpp 在指定第一个文件时会自动加载整组文件。 文件大小必须驻留内存备注...-00001-of-00002.gguf29.6 GB是Transformer 权重,每层保留 512 个专家中的 256 个,相对原始参数为 1.89 bpw...-00002-of-00002.gguf28.8 GB否逐层 n-gram 表(IQ4_NL,4.5 bpw),既未剪枝也未参与搜索总计58.4 GB29.6 GB对照:BF16 为 354 GB 且需 354 GB 常驻 n-gram 表是查找表而非矩阵乘法权重,因此保持固定的 4.5 bpw,既不参与量化搜索,也不参与剪枝。 ### https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF#llamacppllama.cpp hf download --local-dir . llama-cli -m IQ1_M/Qwen3.8-Flash-Next-GSQ-RCO-IQ1_M-00001-of-00002.gguf \ -p "Refactor this function to be iterative." -ngl 99 ### https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF#strata-engineStrata Engine 许多用户反馈使用 Strata (https://github.com/Niko1221/Strata) 效果很好,这是一个第三方引擎,可在一块 8 GB 显存的 NVIDIA GPU 上运行这些 GGUF 模型,提供一键安装程序和本地 OpenAI 兼容端点。 — ## https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF#method方法 GSQ(论文 (https://arxiv.org/abs/2604.18556),代码 (https://github.com/IST-DASLab/GSQ))训练后的标量量化方法,联合学习网格分配与分组缩放,在低比特位宽下大幅缩小了与向量量化的差距,同时仍可部署为标准 GGUF 类型。RCO(论文 (https://arxiv.org/abs/2605.00649),代码 (https://github.com/IST-DASLab/RCO))黎曼流形上的带预算约束优化。在此用于在每层精确预算下决定移除哪些专家,并在基础发布版本中用于分配逐张量的量化类型。 二者均由奥地利科技学院深度算法与系统实验室(DASLab) (https://github.com/IST-DASLab) 开发。 — ## https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF#citation引用 @article{gsq2026, title = {GSQ: Highly-Accurate Low-Precision Scalar Quantization for LLMs via Gumbel-Softmax Sampling}, author = {Dadgarnia, Alireza and Tabesh, Soroush and Nikdan, Mahdi and Helcig, Michael and Kurtic, Eldar and Kleinegger, Maximilian and Alistarh, Dan}, journal= {arXiv preprint arXiv:2604.18556}, year = {2026} } @article{rco2026, title = {Model Compression with Exact Budget Constraints via Riemannian Manifolds}, author = {Helcig, Michael and Alistarh, Dan}, journal= {arXiv preprint arXiv:2605.00649}, year = {2026} } — ## https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF#acknowledgements致谢 我们感谢 Verda (https://verda.com/) 以及奥地利科技学院科学计算部门为生成这些模型所提供的算力支持。 ## https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF#license许可证 这些权重继承自基础模型(Qwen3.8-Flash-Next)的许可证。GSQ-RCO 工具链由深度算法与系统实验室按其仓库许可证发布。
相似文章
Qwen3.8-Flash-Next @ 1.66bpw-exl3 在 36GB 显存下稳定运行
Qwen3.8-Flash-Next 以 1.66bpw EXL3 量化版本发布,可完全装入一张 36GB 的 RTX 5090 中,无需卸载专家模块,实现 200-300 t/s 的稳定推理,且不会陷入思考循环。
ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF
本仓库提供使用基于梯度的 GSQ 和 RCO 方法对 Qwen3.8-Flash-Next 模型进行的 GGUF 量化,以优化低比特表示,从而实现在标准工具中的高效部署。
SC117/Qwen3.8-Flash-Next-GSQ-RCO-abliterated-GGUF
发布了一个基于 ISTA-DASLab GSQ-RCO 量化版 Qwen3.8-Flash-Next 的「消融版」(abliterated) GGUF 模型,通过在已量化张量中直接移植 144 个去除拒答方向的张量,完整保留 GSQ 学到的量化参数,提供 IQ3_S/IQ3_XXS/IQ2_XS/Q2_0 等量化档位。
[发布] 适用于 Qwen3.8-Flash-Next 的 GSQ-RCO GGUF 量化文件,以及一个50%专家剪枝的 Coder 版本,平均比特率约1.89 bpw
发布了 Qwen3.8-Flash-Next 的 GSQ-RCO 量化和专家剪枝版本,在降低比特率的同时达到 BF16 级别的性能,并支持在更小硬件上部署。
AtomicChat/Qwen3.8-Flash-Next-GGUF 真的非常好
AtomicChat 对 Qwen3.8-Flash-Next-GGUF 的量化显著降低了内存使用,从 106GB 减少到 65GB,同时保持了良好的推理性能,使其在硬件受限的环境中更高效。