如何用 Colibrì 跑质量基准MMLU、HellaSwag、ARC-C评估 int4 容器的量化损失【免费下载链接】colibriRun frontier MoE models on hardware you already own — pure C, zero deps, experts streamed from disk. Tiny engine, immense model. 项目地址: https://gitcode.com/GitHub_Trending/colibri3/colibri你手里有一个已经量化成 int4 的模型容器想确认它的质量到底掉了多少——或者至少能跑出一组 MMLU、HellaSwag、ARC-C 的分数来记录基线。Colibrì 引擎自带coli bench子命令按 0-shot log-likelihood 方式对这三个任务打分不需要生成式采样因此在「专家从磁盘流式读取」这类低速机器上也能在合理时间内跑完。本文按文档给出的路径完成构建引擎、准备数据集、跑基准、读数并把量化损失从其他因素中隔离出来。准备条件按 docs/benchmarks.md 的顺序先完成两件事cd c ./setup.sh # 构建 架构自检预期 ~30-32/32 pip install tokenizers datasetssetup.sh的自检通过是后续一切测量的前提tokenizers和datasets是基准子命令的 Python 依赖。模型方面引擎需要指向你的 int4 容器——文档中的惯例是用COLI_MODEL环境变量指向模型目录同页「Test your machine」一节对 chat 的用法即COLI_MODEL/path/to/glm52_i4把/path/to/...换成你本地容器的实际路径。数据集无需手工准备首次运行coli bench时包装脚本会自动调用fetch_benchmarks.py把缺失的 dataset 以 JSONL 形式下载一次到--data缓存目录默认在系统缓存目录下的colibri/bench可用--data改位置。如果下载源持续不可用基准会在剩余可用任务上继续跑一个任务都拿不到时直接报错退出no datasets available — nothing to bench。执行基准docs/benchmarks.md 给出的三条命令覆盖了常用情况cd c ./coli bench # hellaswag, arc_challenge, mmlu — 每个任务 40 题 ./coli bench hellaswag --limit 200 # 单任务、加大题目数 ./coli bench mmlu arc_challenge --ram 100 # 自选任务、设置 RAM 预算不传任务名时默认跑hellaswag,arc_challenge,mmlu三个任务各 40 题任务名是位置参数想跑哪几个写哪几个。--limit N把单任务的题量从 40 提到 N如 200题量越大分数越稳定但耗时线性增长。--ram 100给引擎设置 RAM 预算。RAM 预算影响的是专家缓存大小与速度不影响输出质量docs/tuning.mdspeed depends on cache hit rate; output quality does not所以评估质量时它不是必须项只在机器内存紧张或想复现特定资源条件下使用。打分机制值得了解一句因为它决定了这套基准为什么能在流式读取的慢速引擎上跑scoring 模式是 teacher-forcing 的 log-likelihoodlm-eval 风格每个请求只做一次 forward、不生成 token实现见 c/colibri.c 的run_score。因此基准耗时主要取决于题目数 × 序列长度与 decode 吞吐无关。如果你的模型是 GLM 系列注意引擎会自动给未带前缀的请求补上[gMASK]sop两个 token从 snapshot 的tokenizer.json查 id不依赖硬编码常量因为裸序列是 out-of-distribution、会压低并扭曲分数用SCORE_PREFIX0可关闭该行为。读取结果与文档中的实测参照基准的输出以acc_norm形式给出各任务精度。文档中有一个可对照的实测数据点issue #108int4 容器在 hellaswag/arc/mmlu 上取得62.5% mean acc_norm0-shot log-likelihoodn40。这是文档记录的测量示例不是你的机器必须复现的固定值——不同模型、不同题量下分数本来就会不同。它可以用作「量级是否正常」的参照如果你的 int4 容器在同样的默认配置下跑出与模型规模、任务分布明显不符的分数先怀疑数据集缓存不完整或模型路径指错再怀疑量化本身。把量化损失从其他因素中隔离出来单跑一个 int4 容器只能得到绝对分数不能归因。文档给出的归因方法是同一 harness 下的 A/B文档记录了一次 OLMoE 的 fp16-vs-int4 对照同一 harness 下纯量化成本测得-8.2pp且集中在最难的任务上。文档的解释是per-row int4 scale 会侵蚀难题所依赖的微小 logit 边际改用 grouped scales 可找回约 63% 的损失issue #225。也就是说如果你的 int4 容器相对 fp16 基线掉分明显文档支持的两个方向是加大题量--limit确认掉分不是 40 题的噪声以及对照 grouped-scale 容器int4-grouped见 docs/FORMATS.md 的 fmt4看损失中有多少来自 scale 粒度。scale 粒度/旋转/格子的系统消融脚本在 c/tools/quant_ablation.pyissue #81这是文档中明确指向的下一步工具。A/B 的前提是两边用完全相同的任务、题量和 harness 设置包括是否补 GLM 前缀否则差值里混入的不只是量化。限制与已知边界0-shot MC 评分对推理型模型偏不利文档明确指出 0-shot multiple-choice scoring underserves a reasoning model所以这套分数更适合作为跨容器、跨量化的相对比较而不是对推理能力的绝对评估。数据集依赖一次性下载--data缓存缺失或损坏时重新触发下载即可下载源不可达时基准退化为「可用任务子集」或整体报错行为见上文。默认只有 40 题/任务题量少意味着单任务分数的分辨率有限做量化损失的精确归因时按需用--limit提题量。RAM 预算--ram、RAM_GB等调优项改变的是缓存与速度不是这批分数本身不需要为「测得更准」去改它们。完成一轮基准后如果目标是降低 int4 的损失而不是记录它文档给出的路径是 grouped-scale 容器与quant_ablation.py的消融实验如果想把自己的机器数据点含 bench 分数补进社区基准表docs/benchmarks.md 明确欢迎开 issue 提交实测数字。【免费下载链接】colibriRun frontier MoE models on hardware you already own — pure C, zero deps, experts streamed from disk. Tiny engine, immense model. 项目地址: https://gitcode.com/GitHub_Trending/colibri3/colibri创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
