Flint 开源才几天社区先做的不是评测而是量化【免费下载链接】flint-GGUF项目地址: https://ai.gitcode.com/hf_mirrors/unsloth/flint-GGUFRecursive Flint 在 10 月 20 日挂上模型仓库官方介绍文章 10 月 23 日才发出到今天也不过五天。按常规节奏一个 39.8B 总参、2.5B 激活的 MoE 编码模型发布后社区第一波内容应该是它到底行不行——跑 Terminal-Bench、跑 SWE-bench、和 Qwen 3.8 对打。但实际发生的是另一件事在第一篇像样的第三方评测出现之前量化档位已经铺满了整条产品线从 1-bit 到 Q8_0 一共九个档外加一份 225MB 的校准 imatrix 和一份 79.58GB 的 BF16 分片。这不是社区不关心质量而是本地模型生态的一条隐含优先级在本地能不能跑起来是根问题跑得好不好是枝问题。本文用这个量化仓库里的元数据、文件尺寸、模板和图表做证据还原这个顺序是怎么形成的它在哪些地方已经开始反噬以及下一波内容的真空到底在评测侧还是适配侧。一、五天里的三个时间戳和一条没删干净的旧规则模型仓库的元数据给出了三个时间点把它们和官方发布节奏对齐顺序就出来了事件时间UTC量化仓库创建2026-10-20 03:26量化仓库最后一次修改2026-10-21 23:54官方介绍文章发布2026-10-23 20:37也就是说GGUF 仓库在官方博客发布之前三天就已经建好并完成了最后一轮改动。这本身不算异常——量化工作当然要提前准备——但仓库里留下的痕迹说明这次准备是先按预览名跑通再改名为正式版的抢跑式流程。打开 .gitattributes你会看到一批已经不存在的文件名规则被原样保留着BF16/flint-preview-BF16-00001-of-00003.gguf filterlfs ... flint-preview-UD-Q4_K_XL.gguf filterlfs ... flint-preview-Q8_0.gguf filterlfs ...数一下flint-preview-*一共 12 条规则正好等于现在正式仓库的 12 个工件——3 个 BF16 分片、1 个 Q8_0、8 个 UD 档位。预览版和正式版的文件结构是一一对应的改名只是把preview-这一段删掉。仓库里现在一个preview文件都没有但 LFS 规则一条没清。更能说明问题的是模型卡里那个字段。仓库元数据中的gguf.quantize_imatrix_file至今仍然写着flint-preview-GGUF/imatrix_unsloth.gguf_file一个已经不存在的目录名被固化在了给下游工具读取的元数据里。这不是什么严重 bug但它是很典型的流水线先跑起来、收尾留到后面的痕迹。顺带说明一个观察边界本文所依据的本地仓库是从镜像拉取的浅克隆git log只有 1 条提交记录无法据此判断真实的提交历史长度。上面关于先预览后改名的结论来自.gitattributes的残留规则和元数据字段而不是提交数。二、这个仓库里有什么9 个权重、1 个 imatrix、0 个评测脚本把 12 个工件的真实字节数拉出来按实际比特率文件字节 × 8 ÷ 39.8e9 参数重算一遍得到的是一张比2-bit / 3-bit / 4-bit这套口头标签精确得多的地图档位文件大小 (GB)换算 (GiB)实际 bpw相对 BF16BF163 分片79.5874.1116.0100%Q8_042.3039.408.5053.2%UD-Q6_K_XL36.3233.837.3045.6%UD-Q5_K_XL29.9227.866.0137.6%UD-Q4_K_XL25.0523.335.0431.5%UD-Q3_K_XL18.4917.223.7223.2%UD-IQ3_XXS14.5413.542.9218.3%UD-Q2_K_XL13.5612.632.7317.0%UD-IQ2_XXS11.8611.042.3814.9%UD-IQ1_M11.3510.572.2814.3%有几个数字值得停一下。Q8_0 是 8.50 bpw 而不是 8说明嵌入层、部分归一化参数和输出头都留在了更高精度上——名义档位从来不等于实际比特率。BF16 全量 79.58GB 分布在三个分片里第一个分片只有 5.4MB是典型的按张量切分后首片极小的结果下载时必须三片齐取只下第一片是跑不起来的。整个仓库占用存储约 283.2GB而按仓库接口统计的下载计数已经到 78,891这个口径是文件级累计不能直接当作独立用户数点赞 215。五天。然后是那个更要紧的零这个仓库里没有任何评测脚本、harness 配置、prompt 集或复现日志。它提供的全部是让模型动起来的东西——权重、分片、模板、imatrix。唯一一份非权重工件是 225MB 的imatrix_unsloth.gguf_file也就是公开给社区自行复现量化的校准数据。这是一个很干净的物证结构如果发布方的第一优先级是证明这个量化版没退步仓库里该有的是评测如果第一优先级是让别人在自己的机器上跑起来并且能自己再量化一遍仓库里该有的是 imatrix。实际拿到的是后者。三、先能跑不是态度问题是三道硬门槛3.1 架构太新官方指南直接要求换分支模型卡里的general.architecture是flint不是任何已有的llama/qwen变体。结构上它是 49 层2 层 dense 47 层 MoE、256 个路由专家取 6、35 层滑动窗口513 token 14 层全注意力、4 个 KV head、词表 150,144。这是全新的组合上游推理栈不可能瞬间支持。于是运行指南给出的第一步不是下载 llama.cpp而是git clone --branch iq1-narrow https://github.com/unslothai/llama.cpp cmake llama.cpp -B llama.cpp/build \ -DBUILD_SHARED_LIBSOFF -DGGML_CUDAON cmake --build llama.cpp/build --config Release -j --clean-first \ --target llama-cli llama-mtmd-cli llama-server llama-gguf-split注意--branch iq1-narrow。这意味着在这批量化上线的时间点默认分支不能保证完整支持这套 1-bit 窄量化格式。对一个想先跑起来的用户这就是第一道墙编译分支、装 CUDA toolkit、等构建而不是打开一个 app。3.2 聊天模板是 XML 风格的工具调用不是 JSON从仓库元数据里取出 GGUF 内嵌的 chat template能看到 Flint 用的是这套标记|system| / |user| / |assistant| / |observation| think.../think tool_call{function-name}arg_key{k}/arg_keyarg_value{v}/arg_value/tool_call工具调用的参数被包在arg_key/arg_value里而不是大家习惯的 JSON 对象。模板还做了一件很关键的事读取 assistant 消息的reasoning_content并渲染进think块。这带来两个非常具体的落地要求。第一llama-cli/llama-server必须带--jinja否则模板不生效模型会对着原始文本自己瞎猜格式。第二多轮客户端必须把上一轮返回的reasoning_content存回历史并原样回传否则推理链在第二轮就断了——这是很多接上之后越聊越傻的真实原因跟量化档位无关。3.3 显存要自己算官方只给区间官方给的硬件表是区间制的2-bit 13–15GB、3-bit 16–20GB、4-bit 26GB、6-bit 38GB、8-bit 44GB。区间之所以宽是因为一个3-bit档里塞了从 14.54GB 到 18.49GB 的四个文件。而 4-bit 要求 26GB 却只有 25.05GB 的文件——多出来的部分就是 KV cache 和运行时开销。这笔开销可以按模型卡算清楚。Flint 只有 14 层是全注意力每层 4 个 KV head、head_dim 128F16 精度下每 token 每层是4 × 128 × 2 字节 × 2K 和 V 2 KiB# 全注意力层 KV cache 估算F16 full_layers 14 kv_bytes_per_token_per_layer 4 * 128 * 2 * 2 # 2048 B per_token full_layers * kv_bytes_per_token_per_layer # 28 KiB for ctx in (32768, 131072, 262144): print(ctx, f{ctx * per_token / 2**30:.2f} GiB) # 32768 0.88 GiB / 131072 3.50 GiB / 262144 7.00 GiB滑动窗口层的缓存被压在 513 token量级可以忽略真正吃掉显存的是那 14 层全注意力。于是 24GB 显卡上的两难变得非常具体UD-Q3_K_XL17.22 GiB 权重加 32K 上下文约 0.88 GiB加计算缓冲落在 19–20 GiB24GB 卡能跑短上下文下 24GB 统一内存的机器也能跑。UD-Q4_K_XL23.33 GiB 权重光权重就 23.33 GiB加 32K KV 立刻越过 24 GiB。想在 24GB 卡上用要么把上下文压到 8K 左右要么部分层 offload 到 CPU 吃带宽。这就是为什么24GB 该选哪个会成为社区讨论的第一高频问题它不是偏好问题是算术问题。而官方表格给的是26GB不落在任何一张具体的卡上。四、档位标签在这台模型上会骗人仓库自带两张图KLD 曲线和 top-1 准确率曲线。它们本意是证明 Dynamic 量化在同等体积下更准但把两图叠起来看会得出一个比我们的量化更好更实用的结论在这台模型上按档位名称排序会做出错误选择。三个反直觉的点都能直接从图里读出来数值为读图近似第一IQ2_XXS 在 KLD 上比 IQ1_M 更差同时还大 0.5GB。11.86GB 的UD-IQ2_XXS在通用 KLD 上约 1.0而 11.35GB 的UD-IQ1_M约 0.75但 top-1 上 IQ2_XXS 反而更高约 70.5% vs 69.6%。两个指标直接打架。这种情况下的正确做法不是取个平均而是看你实际要什么如果下游任务对分布偏移敏感长上下文、稀有 token、工具调用语法KLD 更重要如果是短问答式的 argmax 命中top-1 更贴近。2-bit 比 1-bit 好这条经验在 Flint 上不成立。第二Q2_K_XL 比 IQ3_XXS 更小、KLD 更好。13.56GB 对 14.54GB通用 KLD 约 0.55 对 0.65top-1 则是 73.4% 对 74.0%。也就是说在 13–15GB 这个最卷的区间里Q2K和IQ3XXS各有胜负体积小的那个在分布层面更接近原模型。真要二选一得看你更怕输出漂移还是更怕答错。第三Q3_K_XL 到 Q4_K_XL 是全表最陡的一段。体积从 18.49GB 涨到 25.05GB6.56GB通用 KLD 从约 0.37 掉到约 0.15降幅近六成top-1 从约 80.5% 跳到约 88.1%7.6 个百分点。而 Q5 到 Q8_0 加起来涨了 12.4GBtop-1 只多 2 个百分点。从边际收益看Q4_K_XL 是这张图上的拐点从显存可行性看Q3_K_XL 是 24GB 卡的拐点。两个拐点不重合这就是所有纠结的来源。顺带一个可以直接用的检查方式与其相信标签不如自己把元数据读出来确认手上这个文件到底是什么结构、什么上下文配置。from gguf import GGUFReader r GGUFReader(flint-UD-Q4_K_XL.gguf) for key in (general.architecture, general.name, flint.context_length, flint.block_count, flint.expert_count, flint.expert_used_count): field r.get_field(key) if field is not None: print(f{key} {field.contents()})五、厂商自己也在先量化把这件事完全归因于社区抢跑是不准确的。Recursive 在发布文章里把量化放在了相当靠前的位置而且做了一件反常规的事把输出层lm_head量化到了 4 bit。理由写得很直白——Flint 每 token 只激活 2.5B 参数输出层在每 token 需要读取的权重里占了很大比重不动它量化的带宽收益就被吃掉一大块。代价是精度补偿手段是离线蒸馏让量化模型在自己采样的 coreset 上、以 16-bit 模型为 teacher 重新训练训练步数比常规 QAT 基线少了近一半最终 NVFP4 版本在各项基准上与 16-bit 的差距收在 0.7 分以内。配套的还有内核层为 Apple Silicon 和 RTX Spark 生成针对低比特投影、MoE、注意力和 prompt 处理的专用 kernel在 M4/M5 上做了一个融合整个 decode 前向的 Metal megakernel。官方口径是 M4 Pro MacBook Pro 上 125 tok/s、64GB RTX Spark 上 150 tok/s短上下文。这条信息很关键因为它改变了先量化的性质量化不是社区在官方评测之外的自选动作而是这个模型发布叙事的一部分。一个卖点是本地 125 tok/s的模型如果只发 BF16卖点根本立不住。所以量化必须先到位评测可以后补——厂商和社区在这个顺序上是同向的。也正因为如此Unsloth 这边给出的不是下载即用而是一条直通编码 agent 的命令unsloth start claude \ --model unsloth/flint-GGUF:UD-Q4_K_XL \ --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0采样参数不是随便写的官方推荐temperature 1.0 / top-p 0.95 / top-k 20难任务至少留 32768 token 的输出预算含推理。这也是先能跑的具体形态——不是跑一个 benchmark 数字而是把模型接到 Claude Code 或 opencode 这种真实工具链上先让它在你的仓库里改一个文件。六、这个顺序的收益和它已经开始付出的代价先说收益它是实打实的。五天 78,891 次下载、215 个赞九个档位覆盖 10.57 GiB 到 39.40 GiB24GB 统一内存的笔记本能跑 3-bit16GB 的机器有 2-bit 兜底。一个标榜本地编码 agent的模型如果首发只有 79.58GB 的 BF16绝大多数目标用户在第一分钟就流失了。量化档位在这里承担的不是压缩功能而是分发功能——它决定了这个模型能触达多少台机器。从传播角度看MacBook Pro 上能跑这句话的穿透力远高于SWE-bench Verified 74.2。再说代价它也已经出现了而且有两个层次。第一层是归因错位。KLD 和 top-1 衡量的是像不像 BF16不是能不能干活。一个 2-bit 量化版可以在闲聊里表现正常但在需要连续十几轮工具调用、维持 XML 标签闭合、记住 256K 上下文里某个函数签名的场景下崩溃。用户第一次接触 Flint 很可能就是从最小的档位开始试——毕竟下载快——一旦工具调用失败他归因的对象会是Flint 不行而不是我用了 IQ1_M。这个风险在同类模型上已经被量化方自己写进过文档。Unsloth 在 Dynamic 3.0 的说明里明确警告1-bit 档位在 32-token 的 Divergence 测试上会从约 25% 掉到 8–10%工具调用基本不可用会出现循环、空回复建议至少用 2-bit 的Q2_K_XL起步。需要强调的是那组数据是针对另一个模型的不能直接搬到 Flint 上但这条方法论警告完全适用在 Flint 这个 2.5B 激活的 MoE 上输出层占比更重低比特对工具调用链路的影响只会更敏感不会更钝。上文 IQ2_XXS 与 IQ1_M 的指标倒挂已经是一个信号。第二层是内容供给的偏斜。中文社区这几天围绕 Flint 的讨论主流形态是发布消息 参数表而围绕量化的内容清一色是通用教程显存换算、档位对照、把 GGUF 丢进桌面客户端。这类内容的范式高度统一——列二十个档位、给出 8GB 到 48GB 的适配表、再算一笔带宽账。它解决的是我该下哪个文件没有解决下完之后它在我这个任务上还剩下几成能力。换句话说评测侧的内容供给是空的而适配侧的内容已经在同质化。七、下一波的机会在适配侧的收尾和评测侧的开荒如果按还有多少硬活没干完来判断两边的成色完全不同。适配侧不是没有活但活已经变小、变具体。剩下的是三件收尾工作让iq1-narrow这类分支的能力回灌上游使默认构建也能正确加载把 XML 风格tool_call的解析和reasoning_content的回传做成客户端 SDK 的默认行为而不是让每个接入方自己踩以及把 KV cache 量化真正打开——256K 上下文在 F16 下要 7.0 GiBQ8_0 KV 能砍到 3.5 GiB这一项对 24GB 档位的用户比任何权重档位都值钱。这些是工程活产出的是能跑得更久不是能跑得更准。评测侧才是真空但门槛明显更高。复现 Flint 的 agentic 成绩不是跑个 MMLU 就完事Terminal-Bench 2.1 用的是 Terminus 2单任务超时长达 5 小时SWE-bench 用 mini-swe-agent且明确不联网agentic 分数要求至少 5 次尝试的 pass1 平均Terminal-Bench 里通过检索拿到的解还要算作失败。这套约束意味着一次完整评测是几十小时机时 一套能稳定跑的 harness不是一篇当天能出的稿子。这也解释了为什么内容供给会先涌向量化量化的门槛是下载带宽评测的门槛是机时和工程。所以更现实的判断是适配侧的机会在于把最后 10% 的坑填平评测侧的机会在于用可复现的方式回答一个更窄的问题。后者不需要复刻全部榜单只需要回答对本地用户真正重要的那一个在你的硬件、你的量化档位、你的上下文长度下这个模型还能不能完成一次多轮工具调用。这件事有低成本的做法而且不需要等别人# 1) 拉一个档位 hf download unsloth/flint-GGUF flint-UD-Q3_K_XL.gguf --local-dir models/flint # 2) 用 --jinja 让内嵌模板生效短上下文先把显存余量留出来 ./llama.cpp/llama-cli \ --model models/flint/flint-UD-Q3_K_XL.gguf \ --ctx-size 16384 --n-gpu-layers 99 --jinja \ --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0配合一个固定的小任务集——同一段仓库、同一个 bug、同一个改完跑测试的流程——分别记录 Q3_K_XL 与 Q4_K_XL 的成功轮次、工具调用格式错误次数、以及在多少轮之后开始丢失reasoning_content。这类数据比再抄一遍显存对照表有价值得多因为它回答的是量化之后还剩多少干活能力而这恰恰是这一轮抢跑里唯一没人交付的东西。回头看这五天先量化是理性的。一个新架构、一个需要换 llama.cpp 分支、一个 24GB 卡要精算 KV cache 的模型如果首发只给 BF16它连被评价的资格都拿不到。但先能跑只是入场券不是结论。当 78,891 次下载已经发生、九个档位已经摊在面前下一个决定口碑的问题就不再是我该下哪个而是我下的这个到底还能不能干活——而这个问题的答案目前仓库里一个字节都没有。【免费下载链接】flint-GGUF项目地址: https://ai.gitcode.com/hf_mirrors/unsloth/flint-GGUF创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考