colibri 开发演进实录从 CHANGELOG 看多引擎 MoE 推理框架的工程迭代脉络【免费下载链接】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导读本文以 colibri 项目仓库根目录的 CHANGELOG.md 为骨架系统梳理这款纯 C 实现、零外部依赖、专家权重视流式从磁盘加载的 MoE 推理引擎从 v1.0.0 到 v1.7.0 的核心演进脉络。你将了解到第六个模型家族 Qwen3.6-35B-A3B 的 CPU/CUDA 双端实现、专家矩阵乘路径IDOT/VNNI 整数点积、K2 union tile的重建细节、DeepSeek V4 的加载管线与 CUDA tier、共享 serve 帧编解码器的统一迁移以及贯穿所有版本的内存安全加固与跨架构ARM/AMD/HIP正确性保障。通过阅读本文你既能获得 CHANGELOG 的完整事实时间线又能通过源码级证据路径与行号深入理解每一项变更背后的实现原理。一、从 CHANGELOG 理解 colibri 的整体架构演进CHANGELOG 采用 Keep a Changelog 格式记录了 2026-07-19 首个正式标签 v1.0.0 以来的每次发布。核心主线是一个纯 C 引擎同时承载多个 MoE 模型家族通过 route → place → overlap → learn路由→放置→重叠→学习的放置理念将专家权重分层放在 VRAM热/ RAM温/ NVMe/NVMe冷三级存储中并在运行时按路由热度自动学习、固定最热专家。从代码结构看这一架构在仓库中落地为多个平行的引擎源文件c/colibri.c — 主引擎原glm.cv1.1.0 #391 重命名承载 GLM 家族c/kimi_k3.c — Kimi K32.8T/104B 激活参数c/deepseek_v4.c — DeepSeek V4 Flashc/qwen36.c — Qwen3.6-35B-A3Bv1.7.0 新增c/olmoe.c — OLMoEc/inkling.c — Inkling含音频扩展CHANGELOG v1.0.0 的 Highlights 已经勾勒出这个框架的基础能力GLM-5.2744B MoE在约 25 GB RAM 上以纯 C 运行、三 tier 放置、CUDA 多卡专家 tier、MetalApple Silicon、MTP 投机解码、OpenAI 兼容 APIcoli serve与 Web UI。后续版本则是在此基础上逐步把每个家族补齐、把性能与正确性做深。二、v1.7.0第六个引擎 Qwen3.6-35B-A3B 与专家 matmul 路径重建v1.7.02026-08-19自 v1.6.2 起 71 个 PR是 CHANGELOG 中信息量最大的版本核心是两大主题新增第六个模型家族与专家矩阵乘路径的全部位级一致重建。2.1 Qwen3.6-35B-A3B混合门控注意力引擎#712/#713CHANGELOG 记录该引擎位于 c/qwen36.c是Gated Attention Gated DeltaNet streaming MoE的混合结构。源码头注释印证了这一点Qwen3.6-35B-A3B inference engine in pure C, Phase 2: Gated Attention Gated DeltaNet (recurrent linear attention) streaming MoE. The full model is a hybrid: 10 × (3 × Gated DeltaNet - MoE, 1 × Gated Attention - MoE).c/qwen36.c 显示Phase 2 实现了两种层Gated AttentionGQA、每头 q/k RMSNorm、部分 RoPE、输出门Gated DeltaNet因果 depthwise conv1d 循环门控 delta rule携带 conv ring 与状态S[h][kdim,vdim]每头 Gated RMSNormDense 部分embed、投影、router gate、共享 expert、lm_head 等常驻 RAMfloat32专家权重通过pread posix_fadvise(DONTNEED)按需从磁盘读取每层 LRU 缓存并有 PILOT 预取线程——这正是让 GLM-5.2 塞进 15 GB 的同款机制。上下文方面c/qwen36.c 定义了QWEN36_ATTN_MAX_CTX 262144硬上限与QWEN36_DEFAULT_MAX_CTX 8192默认并可通过Q36_MAXT环境变量覆盖注释明确说明上下文每 token 消耗 40 KB KV10 个 attention 层f32128k 需要 5.0 GiB这也是默认值远低于硬上限的原因。CHANGELOG 还记录了两个关键事实预转换容器发布推荐 int4-gs64 格式相对 per-row 量化余弦相似度相对 int8 anchor 从 0.98777 提升到 0.99313KL 从 0.109 降到 0.080。KAT-Coder v2.5 兼容引擎接受任何架构一致的 checkpoint无需专属代码路径。CUDA VRAM 专家 tier#713基于热度的跨 GPU 放置。CHANGELOG 给出实测数据——2× 8 GB 显卡上从 1.44 到 10.05 tok/s7.0× 提升输出与 CPU 端位级一致对完整 200-token 生成做cmp验证冷启动无热度表测量。源码层在 c/qwen36_tier.h 中有完整实现每个专家有唯一 home 设备eid % n_gpus无重复路由热度决定谁能进 VRAMLFRU 语义 滞回有持久化热度表HEAT_FILE时可 warmstart 预填预算上传在后台线程经 staging 拷贝完成decode 永不阻塞在放置上VRAM miss 回退到 CPU int8 路径并与在途 GPU group 重叠启用方式来自 c/qwen36_tier.hCOLI_CUDA1 [COLI_GPUS0,1] [CUDA_EXPERT_GBG|auto] [HEAT_FILEpath] [QT_NO_WARMSTART1]只有在构建时定义了-DCOLI_CUDA才编译 tier 代码否则 c/qwen36_tier.h 中的内联 stub 让引擎保持纯 CPU 且零开销。qt_ready()门控CHANGELOG #713则让纯 CPU 构建不再分配那些永远不会读取的打包 int4 缓冲区CHANGELOG 记录此举节省7.33 GB。2.2 专家 matmul 路径重建K1/K2/K1b 与 FUSED3#1071–#1094v1.7.0 对 GLM、Kimi K3、DeepSeek V4 的激活量化做了layer 级上提#1071/#1075/#1076/#1077此前同一向量每层被串行重复量化约 16 次重建后热路径上消除了约 5.2 ms/token 的串行时间与所有 per-callmalloc。K1plane-nibble int4 布局 无符号 VNNI 点积#1079/#1086。核心技巧是把元素k与k32存进一个字节免去解包由于 nibble 按无符号存储dot(v,x) dot(u,x) − 8·Σx可直接喂给vpdpbusd。结果是每个 64 MAC 只需 8 uops原来 32 个IDOT 内核提速1.45–2.65×且零额外字节。该布局在 c/colibri.c 有注释印证K1 planar gate. MoE tensors only; GPU builds, XEXP and AVX-512F builds。K21×4 union tile#1088。prefill union 让每个 expert 拿到 2–16 行权重块的 loadmask 从每行付一次改为每 4 行付一次S4 时提速2.67–3.10×峰值 253 GMAC/s。K1bgs64 容器的分组平面 IDOT#1094通过IDOT_GS1显式开启——此前推荐的 gs64 容器格式在任何 batch size 下都到不了整数内核。源码在 c/colibri.c 确认IDOT_GS环境变量默认关闭g_idot_gs由atoi决定。FUSED3#1082outtodata可选的融合 AVX2 专家矩阵乘实现在 c/fused_simd.h 与 c/olmoe.cFUSED31: AVX2 activation quant gate/up pair matmul并有配套微基准 c/tests/bench_fused3.c。需要特别注意的是IDOT 是 opt-in 而非默认开启。原因记录在 CHANGELOG #1044/#1080该快速路径仅限 x86且会量化激活导致同一模型在 x86 与 ARM 上默认产生不同 token。在 c/qwen36.c 中同样看到IDOT环境变量 opt-in 的处理。K1 平面门在 c/colibri.c 同样对 GPU 构建与 AVX-512F 构建做了约束。2.3 Streaming 与 I/OV4 加载池、DeepGEMM、双 SSD#1097DeepSeek V4 专家加载池默认 3 → 9 lanes真实 V4-Flash checkpoint 上 decode 提速 1.41×8 次交错运行安静 25 GB 机器。V4_LOADER_LANES仍可覆盖。源码在 c/deepseek_v4.c 确认该变量是默认 lane 数的唯一覆盖。#1056首次构建时在 pinned commit 拉取 DeepGEMM sm120 头文件sm120 上 prefill 提速 2.5×且树内零 vendored 内容。#988/#1054/#1055DeepSeek V4 CUDA tier 与双 SSD mirror。2.4 Correctness 与 CIARM 可见性修复#1083新增ubuntu-24.04-armCI job 与整数内核位级精确门控暴露了此前 NEON 分歧路径不可见的问题这正是 IDOT 默认值意外发布的原因。#1109SebaWag则通过编译内建函数来探测 ARM64 dotprod——因为 GCC 11 对某个无法发出vdotq_s32的基础架构也会定义__ARM_FEATURE_DOTPROD。c/Makefile 中的注释与编译探测逻辑印证了这一坑对 armv8-adotprodGCC 11 定义了该宏但生成不了指令因此 Makefile 偏好以 dotprod 为一等 ISA 特性的 armv8.2-a 基础。#1111在grouped_s4_wmma的 store 后补了__syncwarp()monotophic 用 compute-sanitizer 证据报告。2.5 Apple SiliconKimi K3 的 Metal 后端#790 → #1113RDouglasSharp 贡献的 Metal 后端是 Kimi K3 的第一个 GPU 后端KDA 状态与 window buffer 对齐、wrap-once buffer cache、CPU 侧 MLA KV cache。KDA attention 与投影 dispatch 到 GPU 后计算密集阶段提速 1.7×/2.4×MoE 专家仍留在 CPU。这与框架的一贯设计一致——GPU 只加速 compute-bound 部分流式专家留在 CPU 端。2.6 更多正确性修复与 Interfacesv1.7.0 的修复清单包括absorb softmax reduction 缺失的__syncthreads()#1098附确定性测试checkpoint-load 路径的 allocation/snprintf结果检查#1101fmt8/fmt6 scale-byte 记账与weights_owned在 host-to-device 拷贝前设置#1100/#1108USAGE_SAVE0在所有引擎中被尊重#1122——此前历史被加载后仍会写回悄悄污染共享同一 usage 文件的 A/B 对照LRU victim 选择尊重降低后的ecap#1121跨索引分片重名 tensor 现在被拒绝而非静默解析#1106针对不可信容器。Interfaces 方面coli serve暴露 GPU-vs-fallback 计数与 chat 状态#829OLMoE/Kimi K3/Inkling/DeepSeek V4 的 planner geometry adapter#1095/#110323 个测试coli plan不再猜测DeepSeek V4 serve framing 迁移到共享 codec#1096模型家族 registry 化#1063/#1068coli/gateway/doctor/planner 读同一描述表以及#1036lineape的分布式专家 workerLANCLUSTER_WORKERSopt-inc/colibri.c 有对应解析。三、共享 serve 帧编解码器五份重复实现的统一v1.7.0 #1087/#1090/#1096/#1116这是 v1.7.0 工程化味道最浓的一项字节级 framing 此前在 OLMoE、Kimi K3、DeepSeek V4、Inkling 中重复了五份——这正是 Windows 二进制模式从兄弟引擎中静默消失#748的温床。共享 codec 落地为 c/serve_codec.h头文件自述Transport only: parse and emit frames. Admission, queueing, cancellation, KV ownership, scheduling, and generation remain with each family engine.——即每个家族的调度与生成逻辑仍留在引擎内codec 只负责线上帧的编解码。从 c/serve_codec.h 可以看出其设计三种命令SUBMIT/STOP/CANCELColiServeWireProfile控制头/负载/扩展字节上限、max_tokens、是否要求精确 LF、是否允许扩展字节与前缀提示行首命令按空格分隔的字段解析含id、slot、payload_bytes、max_tokens、temperature、top_p及可选的extension_bytes/prefix_bytes输出侧c/serve_codec.h提供READY/STAT、ACCEPT、DATA、TOOL、ERROR、DONE帧的写函数其中TOOL帧是引擎鉴权的结构化工具输出零字节帧声明 sideband 对请求有权威性防止普通 DATA 被误提升为工具调用。配套测试 c/tests/test_serve_codec.c 对该 codec 的解析、帧边界、扩展字节与错误路径做了覆盖。CHANGELOG 特别强调每次迁移都落在 byte-exact wire-transcript freeze 之后因此 gateway 契约被证明未变。四、v1.6.x安全加固与 Anthropic Messages API4.1 v1.6.2六个内存安全问题2026-08-14这是一个安全发布六个私下报告的、可从攻击者可控输入触发的内存安全问题全部修复。威胁来源包括恶意模型文件/config.json以及 kimi_k3 的 SERVE stdin。所有修复都在信任边界做校验对格式良好的模型/请求无行为变化。CHANGELOG 列出的 advisory 包括GHSA-gf38-c8fx-ppvvkimi_k3 SERVE OOB writeGHSA-2qrj-xjmh-mv74json.h OOB readGHSA-w696-h9p7-6rgcinkling audio OOBGHSA-7654-r78q-vc3rdeepseek_v4 indexer OOB R/W同类的另外两个这与 v1.1.0 中确立的威胁模型一致见下文第五节Security——模型文件来自不可信镜像。4.2 v1.6.1/v1.6.0公开绑定与关键回归修复v1.6.1--allowed-host *允许运维人员刻意公开绑定#990/#993OLMoE 流式不再把答案丢进 reasoning channel#984/#985。v1.6.0建议 v1.5.0 用户升级——v1.5.0 在 GLM-5.2 上有性能回归#856、遗留约 60 GB RAM 闲置且专家命中率损失 13 个点#885、在某些机器上直接弄坏 Kimi K3#888。v1.6.0 还修复了 planner 按容器最宽宽度定价每个专家行#869导致混合宽度容器缓存被静默减半的问题并让 prefill batch-union 对每个不同专家每 chunk 只读一次#914/#union。4.3 v1.1.0 的 Anthropic Messages API#343/#525虽然不是 v1.6.x但作为服务端接口演进的重要节点值得并置v1.1.0 在/v1/messages上实现了 Anthropic Messages API。它是对同一 generation 路径的翻译层非第二引擎路径因此工具、流式与 KV cache 行为与/v1/chat/completions完全一致。覆盖面包括系统提示、text/tool_use/tool_result块、input_schema工具、所有tool_choice模式、带pingkeepalive 的完整命名事件 SSE 序列、stop_reason映射、扩展思考以及x-api-key认证Bearer仍可用。stop_sequences、top_k与非文本块被显式拒绝而非静默忽略。源码位置在 c/openai_server.pyAnthropic /v1/messages (#343)x-api-key认证在 c/openai_server.py 有对应处理hmac.compare_digest对比防时序侧信道。五、v1.5.0第五个引擎 DeepSeek V4 Flash 与多引擎归档v1.5.02026-08-0551 个 PR / 15 位贡献者的核心是DeepSeek V4 FlashDrewZt#165MLA DSA 稀疏注意力43 层256 个 routed experts 1 个 sharedtop-6官方 checkpoint 无需转换即可流式加载fp4 experts、带 UE8M0 block scale 的 fp8-e4m3 dense配置结构见 c/deepseek_v4.hn_routed_experts、num_experts_per_tok、n_shared_experts、index_topk、sliding_window、dspark_block_size等字段完整描述了该家族的稀疏注意力索引与 DSPark 投机机制。引擎 APIc/deepseek_v4.h提供了ColiV4EngineOpenOptions支持memory_limit_bytes、context_tokens、pin_slots_per_layer等配置。v1.5.0 的另一项是rows16 fp4 快速路径不再要求 AVX-512#839Alder Lake 之后的消费级 Intel/AMD CPU 都能走上该快速路径——这对此前只有 AVX-512F 才能吃到快速路径的限制是一大解绑。另外值得注意 v1.4.02026-08-01发布归档开始包含每个引擎——v1.3.0 归档只装了c/colibri而 README 承诺了四个家族inkling与kimi_k3现在按平台构建、打包并做 smoke test。v1.4.0 也是第三个 GPU 后端落地的版本。六、v1.3.0 / v1.2.0Kimi K3 与多平台修复v1.3.02026-07-29三个 MoE 家族跑在一个引擎上744B → 2.8T。Kimi K3#676为 2.8T/104B 激活KDA gated-NoPE-MLA AttnRes LatentMoE直接从原始 HF shards 流式加载 Moonshot 的 QAT MXFP4 专家。Inkling975B在 25 GB 机器上应答。v1.2.02026-07-28GB10/DGX Spark 统一内存 OOM 修复#653doctor/resource_plan识别 AMD/ROCm#662/#663matmul_e8的 AVX2 实现——fmt6 在标量内核上占 decode 的 92%#654原生 SIMD fmt6 编码器比 numpy 快 15×chat stop-set 修复#633/#381、异步 packed-int4 对齐#632、每会话稳定 KV slot#634/#639。七、v1.1.1107 KB 的教训与二进制瘦身-22.5%v1.1.1 是一个同日落地的补丁发布起因非常值得工程借鉴Windows 用户的 Microsoft Defender 标记 v1.1.0 二进制而根因在项目自身。CHANGELOG 还原了完整链条static GrDraft g_grd{.max24};看起来无害但GrDraft约 107 KBgrammar 的 1024 条静态规则 PDA walker任何初始化器都会把整个结构体从.bss移到.data向文件中写入 106,848 字节的近零熵数据且位于可写段——这正是打包载荷解包缓冲区的经典形态。对照 v1.0.0在相同 Defender 定义下干净做段取证同样工具链、同样 PE 布局.data从 1,840 涨到 108,752 字节。修复后 Windows 构建扫描干净且所有平台的二进制都变小Linux 引擎 474,904 → 368,016 字节-22.5%。该版本还修复了python3 openai_server.py在干净 checkout 上的损坏#526——gateway 在 #391 重命名后仍寻找名为glm的引擎现在优先解析colibri/colibri.exe对旧树回退到glm。同时每次发布都发布SHA256SUMS.txt#530Windows 引擎作为 CI artifact 上传#532使杀毒报告可在 PR 上验证而非只在发布后。文档侧#521README 的 Get started 改为先获取程序再获取模型顺序为 获取 colibri预构建归档或源码构建→ 获取模型372 GB 明确写在前→ 运行废弃了把引擎改名为glm.exe的过时步骤#508 起归档直接提供colibri.exe四种语言同步应用。八、v1.1.0AMD/HIP、双 SSD、新量化格式与工具调用修复v1.1.0 是一个社区发布27 个 PR、20 贡献者、v1.0.0 以来 216 次提交。8.1 AMD GPU 支持HIP/ROCm#339单一代码源 c/backend_gpu_compat.h 让同一份后端代码同时构建 CUDA 与 HIP。该头文件的设计原则c/backend_gpu_compat.hevery platform difference lives in this header and backend_cuda.cu stays untouched. Compiled by nvcc this is a pass-through to the CUDA runtime; compiled by hipcc (ROCm, HIP1) it maps the CUDA runtime surface backend_cuda.cu uses onto HIP 1:1.WMMA tensor-core 内核由COLI_GPU_HAS_WMMA与__CUDA_ARCH__ 700双门控HIP 下__CUDA_ARCH__被显式定义为 700 以激活 WMMA 内核体。注意grouped_s4_wmma有更严格的__CUDA_ARCH__ 750门控因此在 HIP 下保持 no-op见 HIP-KNOWN-BUGS BUG-002此外 rocWMMA 没有wmma::experimental::precision::s44-bit的对应物该内核在 HIP 下回退到quant_matmul。CHANGELOG 记录其已在 RX 9070 XTRDNA4ROCm 7.2上验证对真实 fmt4 gs64 容器与 CPU token 精确一致dense 常驻与 routed experts 进 VRAM 两种情形都覆盖并有 fail-injection 控制证明 GPU 确实执行了工作。8.2 双 SSD 与 N 盘分片COLI_MODEL_MIRROR#421同时从两块盘读模型磁盘绑定主机的流式带宽约翻倍。源码在 c/colibri.cregisters additional read-only copiesc/deepseek_v4.c 有其移植版本。COLI_MODEL_DIRS#469容量聚合——运行单个盘放不下的容器跨多盘分布且无重复。解析见 c/colibri.c。8.3 新量化格式fmt5 与 fmt6fmt5int3-g64#1683-bit 权重 每 64 组 scale实测比 per-row int4 的 outlier-row 误差低 3.3×字节数少 25%。fmt6E8/IQ3 lattice#465CPU decode 内核与 dispatch配套索引 codec 工具#458。8.4 工具调用修复#401 的根因CHANGELOG 把编码类客户端工具调用失败拆成三个根因#506——引擎把 prompt 编码封顶在CTX-2而 tokenizer 到上限就静默停止且不报告。长 prompt 因此被静默截断到前CTX-2个 token 后照常作答默认 4096 时就是 4094——与现场报告的prefill 4094完全吻合。被丢弃的尾部正是工具指令与用户实际请求所以模型吐出裸就停了又因为客户端往尾部追加而截断保留头部每次重试都重发字节相同的 prompt。现在改为拒绝并返回 400context_length_exceeded。#505——闭合/tool_call从未到达的工具调用被整体丢弃解析器要求两个标签都存在现在在流式与非流式路径上都可无歧义恢复。#437——非 EOS 的角色标记在 serve 模式被武装为硬停止工具块一开始生成就被切断。另有 fmt4 在CUDA_DENSE1下产生垃圾输出#298dense/attention 内核把 per-group scale 当 per-row 用硬件验证OpenMP 调优重执行保留 CPU affinity mask#476导致OMP_PROC_BIND/OMP_PLACES下约 20× 慢pilot eviction guard 在缓存填满后丢弃约 100% 的投机#497静默 budget clamp 把 CUDA 专家 tier 封在约 109 个专家#495COLI_CUDA_MTP1与COLI_CUDA0现在覆盖隐式默认#468。8.5 性能全部 byte-identical#481MLA-absorb score 与 value-mix reduction 4.7×#477AVX-512 上qt_addrow/qt_matvec_rowsdecode 13%#475opt-inXEXP1S1 全常驻时每专家块一个 OpenMP region11.6%#473AVX-512 VNNI 上 int4 IDOT 在 S1 5.5%XEXP在 c/colibri.c 与 c/colibri.c 中有对应读取逻辑。8.6 升级注意CTX 默认仍是 4096CTX仍默认 4096。编码类客户端在单个 system prompt 里发送的内容远超此值。请使用CTX32768。此版本之前超长 prompt 被静默截断现在你会得到清晰的 400。九、v1.0.0基线能力的全景回顾首个正式标签2026-07-19确立了语义版本基线其 Highlights 可作为理解整个框架能力边界的索引GLM-5.2744B MoE纯 C、约 25 GB RAM、专家从磁盘流式加载三 tier 放置VRAM热/ RAM温/ NVMe冷学习型缓存自动固定工作负载最热专家CUDA 后端多卡专家 tier、dense tensor 分布、batched ragged attention、常驻管线COLI_CUDA_PIPE2Metal 后端Apple Silicon统一内存 GPU 上的 batched expert SwiGLU 融合 decode attentionMTP 投机原生 GLM-5.2 draft heads、grammar-forced drafts、内核钉扎验证SPEC_PIN1OpenAI 兼容 APIcoli serveSSE 流式、KV slots、有界队列、Web dashboardcoli web跨平台Linux、macOS、Windows 11原生 MinGW、PowerPC三平台 CIEngine 层面值得记住的基线能力对transformersoracle 的 token 精确验证teacher-forcing 32/32压缩 MLA KV cache576 floats/token比原始小 57×跨重启持久化.coli_kv零 re-prefillDSA 稀疏注意力lightning indexerrouter-lookahead 预取PILOT1预测率 71.6%异步专家 I/O 池PIPE1 io_uring 批处理URING1NUMA 感知专家放置COLI_NUMA1多 socket 13–40%AVX2 / AVX-512 / AVX-VNNI / ARM NEON / NEON-i8mm / POWER VSX 内核int4 / int8 / int2 / grouped-int4fmt4量化格式。Tools 侧coli convertFP8→int4 逐分片转换、coli doctor只读诊断、coli plan资源规划 auto-tune 处方、coli benchMMLU / HellaSwag / ARC 质量基准、专家 atlastools/analyze.py --web19,456 个专家的实测主题亲和度。这些工具的实际实现分布在 c/tools/ 目录中例如 c/tools/analyze.pyexpert atlas与 c/tools/datapoint.py基准 datapoint 采集。十、贯穿版本的方法论为何位级一致反复出现通读 CHANGELOG 会发现一个高频词bit-identical / byte-exact。这不是偶然而是项目正确性工程的核心纪律至少体现在四个层面性能优化必须可证明不改结果v1.1.0 的 4.7×、13% decode 均标注全部 byte-identicalv1.7.0 的 CUDA tier 用cmp对比完整 200-token 生成。跨架构一致性有门控v1.7.0 的 ARM CI 让整数内核做双 ISA 位级精确门控正是这套门控暴露出 IDOT 默认开启导致 x86/ARM 产生不同 token 的问题#1044/#1080随后把 IDOT 改为 opt-in。协议迁移有 wire-transcript freeze共享 serve codec 的每次引擎迁移都落在 byte-exact wire 录音冻结之后gateway 契约被证明不变。信任边界校验不改变合法输入行为v1.6.2 的六个安全修复对格式良好的模型或请求无行为变化。这套方法论对应的测试资产散落在仓库中例如 c/tests/ 下的 segment/glm52 replay fixtureglm52_replay_smoke.json、glm52_replay_python.json、kimi_chat_wire.txt与ssd_cache_vectors.txtwire 与缓存向量的 byte-exact 回归样本、c/tests/test_serve_codec.ccodec 解析测试以及 c/tests/README_efficiency.md 对测试效率的说明。这些 fixture 正是wire-transcript freeze与回归测试随每个修复落地的具体载体。结语从 v1.0.0 到 v1.7.0CHANGELOG 勾勒的不仅是一份版本列表更是一部多引擎、多后端、多精度的 MoE 推理框架工程史第六个家族 Qwen3.6-35B-A3B 让引擎矩阵再次扩大专家 matmul 路径的 K1/K2/K1b 重建把整数计算性能推向新的数量级共享 serve codec 终结了五份重复实现而安全、跨架构一致性与位级可复现性始终是每一次性能提升的前置条件。如果你想从代码层面继续深入最值得读的入口依次是 c/qwen36.c最新引擎、c/serve_codec.h统一线上协议、c/backend_gpu_compat.hCUDA/HIP 单一代码源与 c/qwen36_tier.hCUDA VRAM 专家 tier 的设计注释。【免费下载链接】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），仅供参考 colibri 开发演进实录：从 CHANGELOG 看多引擎 MoE 推理框架的工程迭代脉络
colibri 开发演进实录从 CHANGELOG 看多引擎 MoE 推理框架的工程迭代脉络【免费下载链接】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导读本文以 colibri 项目仓库根目录的 CHANGELOG.md 为骨架系统梳理这款纯 C 实现、零外部依赖、专家权重视流式从磁盘加载的 MoE 推理引擎从 v1.0.0 到 v1.7.0 的核心演进脉络。你将了解到第六个模型家族 Qwen3.6-35B-A3B 的 CPU/CUDA 双端实现、专家矩阵乘路径IDOT/VNNI 整数点积、K2 union tile的重建细节、DeepSeek V4 的加载管线与 CUDA tier、共享 serve 帧编解码器的统一迁移以及贯穿所有版本的内存安全加固与跨架构ARM/AMD/HIP正确性保障。通过阅读本文你既能获得 CHANGELOG 的完整事实时间线又能通过源码级证据路径与行号深入理解每一项变更背后的实现原理。一、从 CHANGELOG 理解 colibri 的整体架构演进CHANGELOG 采用 Keep a Changelog 格式记录了 2026-07-19 首个正式标签 v1.0.0 以来的每次发布。核心主线是一个纯 C 引擎同时承载多个 MoE 模型家族通过 route → place → overlap → learn路由→放置→重叠→学习的放置理念将专家权重分层放在 VRAM热/ RAM温/ NVMe/NVMe冷三级存储中并在运行时按路由热度自动学习、固定最热专家。从代码结构看这一架构在仓库中落地为多个平行的引擎源文件c/colibri.c — 主引擎原glm.cv1.1.0 #391 重命名承载 GLM 家族c/kimi_k3.c — Kimi K32.8T/104B 激活参数c/deepseek_v4.c — DeepSeek V4 Flashc/qwen36.c — Qwen3.6-35B-A3Bv1.7.0 新增c/olmoe.c — OLMoEc/inkling.c — Inkling含音频扩展CHANGELOG v1.0.0 的 Highlights 已经勾勒出这个框架的基础能力GLM-5.2744B MoE在约 25 GB RAM 上以纯 C 运行、三 tier 放置、CUDA 多卡专家 tier、MetalApple Silicon、MTP 投机解码、OpenAI 兼容 APIcoli serve与 Web UI。后续版本则是在此基础上逐步把每个家族补齐、把性能与正确性做深。二、v1.7.0第六个引擎 Qwen3.6-35B-A3B 与专家 matmul 路径重建v1.7.02026-08-19自 v1.6.2 起 71 个 PR是 CHANGELOG 中信息量最大的版本核心是两大主题新增第六个模型家族与专家矩阵乘路径的全部位级一致重建。2.1 Qwen3.6-35B-A3B混合门控注意力引擎#712/#713CHANGELOG 记录该引擎位于 c/qwen36.c是Gated Attention Gated DeltaNet streaming MoE的混合结构。源码头注释印证了这一点Qwen3.6-35B-A3B inference engine in pure C, Phase 2: Gated Attention Gated DeltaNet (recurrent linear attention) streaming MoE. The full model is a hybrid: 10 × (3 × Gated DeltaNet - MoE, 1 × Gated Attention - MoE).c/qwen36.c 显示Phase 2 实现了两种层Gated AttentionGQA、每头 q/k RMSNorm、部分 RoPE、输出门Gated DeltaNet因果 depthwise conv1d 循环门控 delta rule携带 conv ring 与状态S[h][kdim,vdim]每头 Gated RMSNormDense 部分embed、投影、router gate、共享 expert、lm_head 等常驻 RAMfloat32专家权重通过pread posix_fadvise(DONTNEED)按需从磁盘读取每层 LRU 缓存并有 PILOT 预取线程——这正是让 GLM-5.2 塞进 15 GB 的同款机制。上下文方面c/qwen36.c 定义了QWEN36_ATTN_MAX_CTX 262144硬上限与QWEN36_DEFAULT_MAX_CTX 8192默认并可通过Q36_MAXT环境变量覆盖注释明确说明上下文每 token 消耗 40 KB KV10 个 attention 层f32128k 需要 5.0 GiB这也是默认值远低于硬上限的原因。CHANGELOG 还记录了两个关键事实预转换容器发布推荐 int4-gs64 格式相对 per-row 量化余弦相似度相对 int8 anchor 从 0.98777 提升到 0.99313KL 从 0.109 降到 0.080。KAT-Coder v2.5 兼容引擎接受任何架构一致的 checkpoint无需专属代码路径。CUDA VRAM 专家 tier#713基于热度的跨 GPU 放置。CHANGELOG 给出实测数据——2× 8 GB 显卡上从 1.44 到 10.05 tok/s7.0× 提升输出与 CPU 端位级一致对完整 200-token 生成做cmp验证冷启动无热度表测量。源码层在 c/qwen36_tier.h 中有完整实现每个专家有唯一 home 设备eid % n_gpus无重复路由热度决定谁能进 VRAMLFRU 语义 滞回有持久化热度表HEAT_FILE时可 warmstart 预填预算上传在后台线程经 staging 拷贝完成decode 永不阻塞在放置上VRAM miss 回退到 CPU int8 路径并与在途 GPU group 重叠启用方式来自 c/qwen36_tier.hCOLI_CUDA1 [COLI_GPUS0,1] [CUDA_EXPERT_GBG|auto] [HEAT_FILEpath] [QT_NO_WARMSTART1]只有在构建时定义了-DCOLI_CUDA才编译 tier 代码否则 c/qwen36_tier.h 中的内联 stub 让引擎保持纯 CPU 且零开销。qt_ready()门控CHANGELOG #713则让纯 CPU 构建不再分配那些永远不会读取的打包 int4 缓冲区CHANGELOG 记录此举节省7.33 GB。2.2 专家 matmul 路径重建K1/K2/K1b 与 FUSED3#1071–#1094v1.7.0 对 GLM、Kimi K3、DeepSeek V4 的激活量化做了layer 级上提#1071/#1075/#1076/#1077此前同一向量每层被串行重复量化约 16 次重建后热路径上消除了约 5.2 ms/token 的串行时间与所有 per-callmalloc。K1plane-nibble int4 布局 无符号 VNNI 点积#1079/#1086。核心技巧是把元素k与k32存进一个字节免去解包由于 nibble 按无符号存储dot(v,x) dot(u,x) − 8·Σx可直接喂给vpdpbusd。结果是每个 64 MAC 只需 8 uops原来 32 个IDOT 内核提速1.45–2.65×且零额外字节。该布局在 c/colibri.c 有注释印证K1 planar gate. MoE tensors only; GPU builds, XEXP and AVX-512F builds。K21×4 union tile#1088。prefill union 让每个 expert 拿到 2–16 行权重块的 loadmask 从每行付一次改为每 4 行付一次S4 时提速2.67–3.10×峰值 253 GMAC/s。K1bgs64 容器的分组平面 IDOT#1094通过IDOT_GS1显式开启——此前推荐的 gs64 容器格式在任何 batch size 下都到不了整数内核。源码在 c/colibri.c 确认IDOT_GS环境变量默认关闭g_idot_gs由atoi决定。FUSED3#1082outtodata可选的融合 AVX2 专家矩阵乘实现在 c/fused_simd.h 与 c/olmoe.cFUSED31: AVX2 activation quant gate/up pair matmul并有配套微基准 c/tests/bench_fused3.c。需要特别注意的是IDOT 是 opt-in 而非默认开启。原因记录在 CHANGELOG #1044/#1080该快速路径仅限 x86且会量化激活导致同一模型在 x86 与 ARM 上默认产生不同 token。在 c/qwen36.c 中同样看到IDOT环境变量 opt-in 的处理。K1 平面门在 c/colibri.c 同样对 GPU 构建与 AVX-512F 构建做了约束。2.3 Streaming 与 I/OV4 加载池、DeepGEMM、双 SSD#1097DeepSeek V4 专家加载池默认 3 → 9 lanes真实 V4-Flash checkpoint 上 decode 提速 1.41×8 次交错运行安静 25 GB 机器。V4_LOADER_LANES仍可覆盖。源码在 c/deepseek_v4.c 确认该变量是默认 lane 数的唯一覆盖。#1056首次构建时在 pinned commit 拉取 DeepGEMM sm120 头文件sm120 上 prefill 提速 2.5×且树内零 vendored 内容。#988/#1054/#1055DeepSeek V4 CUDA tier 与双 SSD mirror。2.4 Correctness 与 CIARM 可见性修复#1083新增ubuntu-24.04-armCI job 与整数内核位级精确门控暴露了此前 NEON 分歧路径不可见的问题这正是 IDOT 默认值意外发布的原因。#1109SebaWag则通过编译内建函数来探测 ARM64 dotprod——因为 GCC 11 对某个无法发出vdotq_s32的基础架构也会定义__ARM_FEATURE_DOTPROD。c/Makefile 中的注释与编译探测逻辑印证了这一坑对 armv8-adotprodGCC 11 定义了该宏但生成不了指令因此 Makefile 偏好以 dotprod 为一等 ISA 特性的 armv8.2-a 基础。#1111在grouped_s4_wmma的 store 后补了__syncwarp()monotophic 用 compute-sanitizer 证据报告。2.5 Apple SiliconKimi K3 的 Metal 后端#790 → #1113RDouglasSharp 贡献的 Metal 后端是 Kimi K3 的第一个 GPU 后端KDA 状态与 window buffer 对齐、wrap-once buffer cache、CPU 侧 MLA KV cache。KDA attention 与投影 dispatch 到 GPU 后计算密集阶段提速 1.7×/2.4×MoE 专家仍留在 CPU。这与框架的一贯设计一致——GPU 只加速 compute-bound 部分流式专家留在 CPU 端。2.6 更多正确性修复与 Interfacesv1.7.0 的修复清单包括absorb softmax reduction 缺失的__syncthreads()#1098附确定性测试checkpoint-load 路径的 allocation/snprintf结果检查#1101fmt8/fmt6 scale-byte 记账与weights_owned在 host-to-device 拷贝前设置#1100/#1108USAGE_SAVE0在所有引擎中被尊重#1122——此前历史被加载后仍会写回悄悄污染共享同一 usage 文件的 A/B 对照LRU victim 选择尊重降低后的ecap#1121跨索引分片重名 tensor 现在被拒绝而非静默解析#1106针对不可信容器。Interfaces 方面coli serve暴露 GPU-vs-fallback 计数与 chat 状态#829OLMoE/Kimi K3/Inkling/DeepSeek V4 的 planner geometry adapter#1095/#110323 个测试coli plan不再猜测DeepSeek V4 serve framing 迁移到共享 codec#1096模型家族 registry 化#1063/#1068coli/gateway/doctor/planner 读同一描述表以及#1036lineape的分布式专家 workerLANCLUSTER_WORKERSopt-inc/colibri.c 有对应解析。三、共享 serve 帧编解码器五份重复实现的统一v1.7.0 #1087/#1090/#1096/#1116这是 v1.7.0 工程化味道最浓的一项字节级 framing 此前在 OLMoE、Kimi K3、DeepSeek V4、Inkling 中重复了五份——这正是 Windows 二进制模式从兄弟引擎中静默消失#748的温床。共享 codec 落地为 c/serve_codec.h头文件自述Transport only: parse and emit frames. Admission, queueing, cancellation, KV ownership, scheduling, and generation remain with each family engine.——即每个家族的调度与生成逻辑仍留在引擎内codec 只负责线上帧的编解码。从 c/serve_codec.h 可以看出其设计三种命令SUBMIT/STOP/CANCELColiServeWireProfile控制头/负载/扩展字节上限、max_tokens、是否要求精确 LF、是否允许扩展字节与前缀提示行首命令按空格分隔的字段解析含id、slot、payload_bytes、max_tokens、temperature、top_p及可选的extension_bytes/prefix_bytes输出侧c/serve_codec.h提供READY/STAT、ACCEPT、DATA、TOOL、ERROR、DONE帧的写函数其中TOOL帧是引擎鉴权的结构化工具输出零字节帧声明 sideband 对请求有权威性防止普通 DATA 被误提升为工具调用。配套测试 c/tests/test_serve_codec.c 对该 codec 的解析、帧边界、扩展字节与错误路径做了覆盖。CHANGELOG 特别强调每次迁移都落在 byte-exact wire-transcript freeze 之后因此 gateway 契约被证明未变。四、v1.6.x安全加固与 Anthropic Messages API4.1 v1.6.2六个内存安全问题2026-08-14这是一个安全发布六个私下报告的、可从攻击者可控输入触发的内存安全问题全部修复。威胁来源包括恶意模型文件/config.json以及 kimi_k3 的 SERVE stdin。所有修复都在信任边界做校验对格式良好的模型/请求无行为变化。CHANGELOG 列出的 advisory 包括GHSA-gf38-c8fx-ppvvkimi_k3 SERVE OOB writeGHSA-2qrj-xjmh-mv74json.h OOB readGHSA-w696-h9p7-6rgcinkling audio OOBGHSA-7654-r78q-vc3rdeepseek_v4 indexer OOB R/W同类的另外两个这与 v1.1.0 中确立的威胁模型一致见下文第五节Security——模型文件来自不可信镜像。4.2 v1.6.1/v1.6.0公开绑定与关键回归修复v1.6.1--allowed-host *允许运维人员刻意公开绑定#990/#993OLMoE 流式不再把答案丢进 reasoning channel#984/#985。v1.6.0建议 v1.5.0 用户升级——v1.5.0 在 GLM-5.2 上有性能回归#856、遗留约 60 GB RAM 闲置且专家命中率损失 13 个点#885、在某些机器上直接弄坏 Kimi K3#888。v1.6.0 还修复了 planner 按容器最宽宽度定价每个专家行#869导致混合宽度容器缓存被静默减半的问题并让 prefill batch-union 对每个不同专家每 chunk 只读一次#914/#union。4.3 v1.1.0 的 Anthropic Messages API#343/#525虽然不是 v1.6.x但作为服务端接口演进的重要节点值得并置v1.1.0 在/v1/messages上实现了 Anthropic Messages API。它是对同一 generation 路径的翻译层非第二引擎路径因此工具、流式与 KV cache 行为与/v1/chat/completions完全一致。覆盖面包括系统提示、text/tool_use/tool_result块、input_schema工具、所有tool_choice模式、带pingkeepalive 的完整命名事件 SSE 序列、stop_reason映射、扩展思考以及x-api-key认证Bearer仍可用。stop_sequences、top_k与非文本块被显式拒绝而非静默忽略。源码位置在 c/openai_server.pyAnthropic /v1/messages (#343)x-api-key认证在 c/openai_server.py 有对应处理hmac.compare_digest对比防时序侧信道。五、v1.5.0第五个引擎 DeepSeek V4 Flash 与多引擎归档v1.5.02026-08-0551 个 PR / 15 位贡献者的核心是DeepSeek V4 FlashDrewZt#165MLA DSA 稀疏注意力43 层256 个 routed experts 1 个 sharedtop-6官方 checkpoint 无需转换即可流式加载fp4 experts、带 UE8M0 block scale 的 fp8-e4m3 dense配置结构见 c/deepseek_v4.hn_routed_experts、num_experts_per_tok、n_shared_experts、index_topk、sliding_window、dspark_block_size等字段完整描述了该家族的稀疏注意力索引与 DSPark 投机机制。引擎 APIc/deepseek_v4.h提供了ColiV4EngineOpenOptions支持memory_limit_bytes、context_tokens、pin_slots_per_layer等配置。v1.5.0 的另一项是rows16 fp4 快速路径不再要求 AVX-512#839Alder Lake 之后的消费级 Intel/AMD CPU 都能走上该快速路径——这对此前只有 AVX-512F 才能吃到快速路径的限制是一大解绑。另外值得注意 v1.4.02026-08-01发布归档开始包含每个引擎——v1.3.0 归档只装了c/colibri而 README 承诺了四个家族inkling与kimi_k3现在按平台构建、打包并做 smoke test。v1.4.0 也是第三个 GPU 后端落地的版本。六、v1.3.0 / v1.2.0Kimi K3 与多平台修复v1.3.02026-07-29三个 MoE 家族跑在一个引擎上744B → 2.8T。Kimi K3#676为 2.8T/104B 激活KDA gated-NoPE-MLA AttnRes LatentMoE直接从原始 HF shards 流式加载 Moonshot 的 QAT MXFP4 专家。Inkling975B在 25 GB 机器上应答。v1.2.02026-07-28GB10/DGX Spark 统一内存 OOM 修复#653doctor/resource_plan识别 AMD/ROCm#662/#663matmul_e8的 AVX2 实现——fmt6 在标量内核上占 decode 的 92%#654原生 SIMD fmt6 编码器比 numpy 快 15×chat stop-set 修复#633/#381、异步 packed-int4 对齐#632、每会话稳定 KV slot#634/#639。七、v1.1.1107 KB 的教训与二进制瘦身-22.5%v1.1.1 是一个同日落地的补丁发布起因非常值得工程借鉴Windows 用户的 Microsoft Defender 标记 v1.1.0 二进制而根因在项目自身。CHANGELOG 还原了完整链条static GrDraft g_grd{.max24};看起来无害但GrDraft约 107 KBgrammar 的 1024 条静态规则 PDA walker任何初始化器都会把整个结构体从.bss移到.data向文件中写入 106,848 字节的近零熵数据且位于可写段——这正是打包载荷解包缓冲区的经典形态。对照 v1.0.0在相同 Defender 定义下干净做段取证同样工具链、同样 PE 布局.data从 1,840 涨到 108,752 字节。修复后 Windows 构建扫描干净且所有平台的二进制都变小Linux 引擎 474,904 → 368,016 字节-22.5%。该版本还修复了python3 openai_server.py在干净 checkout 上的损坏#526——gateway 在 #391 重命名后仍寻找名为glm的引擎现在优先解析colibri/colibri.exe对旧树回退到glm。同时每次发布都发布SHA256SUMS.txt#530Windows 引擎作为 CI artifact 上传#532使杀毒报告可在 PR 上验证而非只在发布后。文档侧#521README 的 Get started 改为先获取程序再获取模型顺序为 获取 colibri预构建归档或源码构建→ 获取模型372 GB 明确写在前→ 运行废弃了把引擎改名为glm.exe的过时步骤#508 起归档直接提供colibri.exe四种语言同步应用。八、v1.1.0AMD/HIP、双 SSD、新量化格式与工具调用修复v1.1.0 是一个社区发布27 个 PR、20 贡献者、v1.0.0 以来 216 次提交。8.1 AMD GPU 支持HIP/ROCm#339单一代码源 c/backend_gpu_compat.h 让同一份后端代码同时构建 CUDA 与 HIP。该头文件的设计原则c/backend_gpu_compat.hevery platform difference lives in this header and backend_cuda.cu stays untouched. Compiled by nvcc this is a pass-through to the CUDA runtime; compiled by hipcc (ROCm, HIP1) it maps the CUDA runtime surface backend_cuda.cu uses onto HIP 1:1.WMMA tensor-core 内核由COLI_GPU_HAS_WMMA与__CUDA_ARCH__ 700双门控HIP 下__CUDA_ARCH__被显式定义为 700 以激活 WMMA 内核体。注意grouped_s4_wmma有更严格的__CUDA_ARCH__ 750门控因此在 HIP 下保持 no-op见 HIP-KNOWN-BUGS BUG-002此外 rocWMMA 没有wmma::experimental::precision::s44-bit的对应物该内核在 HIP 下回退到quant_matmul。CHANGELOG 记录其已在 RX 9070 XTRDNA4ROCm 7.2上验证对真实 fmt4 gs64 容器与 CPU token 精确一致dense 常驻与 routed experts 进 VRAM 两种情形都覆盖并有 fail-injection 控制证明 GPU 确实执行了工作。8.2 双 SSD 与 N 盘分片COLI_MODEL_MIRROR#421同时从两块盘读模型磁盘绑定主机的流式带宽约翻倍。源码在 c/colibri.cregisters additional read-only copiesc/deepseek_v4.c 有其移植版本。COLI_MODEL_DIRS#469容量聚合——运行单个盘放不下的容器跨多盘分布且无重复。解析见 c/colibri.c。8.3 新量化格式fmt5 与 fmt6fmt5int3-g64#1683-bit 权重 每 64 组 scale实测比 per-row int4 的 outlier-row 误差低 3.3×字节数少 25%。fmt6E8/IQ3 lattice#465CPU decode 内核与 dispatch配套索引 codec 工具#458。8.4 工具调用修复#401 的根因CHANGELOG 把编码类客户端工具调用失败拆成三个根因#506——引擎把 prompt 编码封顶在CTX-2而 tokenizer 到上限就静默停止且不报告。长 prompt 因此被静默截断到前CTX-2个 token 后照常作答默认 4096 时就是 4094——与现场报告的prefill 4094完全吻合。被丢弃的尾部正是工具指令与用户实际请求所以模型吐出裸就停了又因为客户端往尾部追加而截断保留头部每次重试都重发字节相同的 prompt。现在改为拒绝并返回 400context_length_exceeded。#505——闭合/tool_call从未到达的工具调用被整体丢弃解析器要求两个标签都存在现在在流式与非流式路径上都可无歧义恢复。#437——非 EOS 的角色标记在 serve 模式被武装为硬停止工具块一开始生成就被切断。另有 fmt4 在CUDA_DENSE1下产生垃圾输出#298dense/attention 内核把 per-group scale 当 per-row 用硬件验证OpenMP 调优重执行保留 CPU affinity mask#476导致OMP_PROC_BIND/OMP_PLACES下约 20× 慢pilot eviction guard 在缓存填满后丢弃约 100% 的投机#497静默 budget clamp 把 CUDA 专家 tier 封在约 109 个专家#495COLI_CUDA_MTP1与COLI_CUDA0现在覆盖隐式默认#468。8.5 性能全部 byte-identical#481MLA-absorb score 与 value-mix reduction 4.7×#477AVX-512 上qt_addrow/qt_matvec_rowsdecode 13%#475opt-inXEXP1S1 全常驻时每专家块一个 OpenMP region11.6%#473AVX-512 VNNI 上 int4 IDOT 在 S1 5.5%XEXP在 c/colibri.c 与 c/colibri.c 中有对应读取逻辑。8.6 升级注意CTX 默认仍是 4096CTX仍默认 4096。编码类客户端在单个 system prompt 里发送的内容远超此值。请使用CTX32768。此版本之前超长 prompt 被静默截断现在你会得到清晰的 400。九、v1.0.0基线能力的全景回顾首个正式标签2026-07-19确立了语义版本基线其 Highlights 可作为理解整个框架能力边界的索引GLM-5.2744B MoE纯 C、约 25 GB RAM、专家从磁盘流式加载三 tier 放置VRAM热/ RAM温/ NVMe冷学习型缓存自动固定工作负载最热专家CUDA 后端多卡专家 tier、dense tensor 分布、batched ragged attention、常驻管线COLI_CUDA_PIPE2Metal 后端Apple Silicon统一内存 GPU 上的 batched expert SwiGLU 融合 decode attentionMTP 投机原生 GLM-5.2 draft heads、grammar-forced drafts、内核钉扎验证SPEC_PIN1OpenAI 兼容 APIcoli serveSSE 流式、KV slots、有界队列、Web dashboardcoli web跨平台Linux、macOS、Windows 11原生 MinGW、PowerPC三平台 CIEngine 层面值得记住的基线能力对transformersoracle 的 token 精确验证teacher-forcing 32/32压缩 MLA KV cache576 floats/token比原始小 57×跨重启持久化.coli_kv零 re-prefillDSA 稀疏注意力lightning indexerrouter-lookahead 预取PILOT1预测率 71.6%异步专家 I/O 池PIPE1 io_uring 批处理URING1NUMA 感知专家放置COLI_NUMA1多 socket 13–40%AVX2 / AVX-512 / AVX-VNNI / ARM NEON / NEON-i8mm / POWER VSX 内核int4 / int8 / int2 / grouped-int4fmt4量化格式。Tools 侧coli convertFP8→int4 逐分片转换、coli doctor只读诊断、coli plan资源规划 auto-tune 处方、coli benchMMLU / HellaSwag / ARC 质量基准、专家 atlastools/analyze.py --web19,456 个专家的实测主题亲和度。这些工具的实际实现分布在 c/tools/ 目录中例如 c/tools/analyze.pyexpert atlas与 c/tools/datapoint.py基准 datapoint 采集。十、贯穿版本的方法论为何位级一致反复出现通读 CHANGELOG 会发现一个高频词bit-identical / byte-exact。这不是偶然而是项目正确性工程的核心纪律至少体现在四个层面性能优化必须可证明不改结果v1.1.0 的 4.7×、13% decode 均标注全部 byte-identicalv1.7.0 的 CUDA tier 用cmp对比完整 200-token 生成。跨架构一致性有门控v1.7.0 的 ARM CI 让整数内核做双 ISA 位级精确门控正是这套门控暴露出 IDOT 默认开启导致 x86/ARM 产生不同 token 的问题#1044/#1080随后把 IDOT 改为 opt-in。协议迁移有 wire-transcript freeze共享 serve codec 的每次引擎迁移都落在 byte-exact wire 录音冻结之后gateway 契约被证明不变。信任边界校验不改变合法输入行为v1.6.2 的六个安全修复对格式良好的模型或请求无行为变化。这套方法论对应的测试资产散落在仓库中例如 c/tests/ 下的 segment/glm52 replay fixtureglm52_replay_smoke.json、glm52_replay_python.json、kimi_chat_wire.txt与ssd_cache_vectors.txtwire 与缓存向量的 byte-exact 回归样本、c/tests/test_serve_codec.ccodec 解析测试以及 c/tests/README_efficiency.md 对测试效率的说明。这些 fixture 正是wire-transcript freeze与回归测试随每个修复落地的具体载体。结语从 v1.0.0 到 v1.7.0CHANGELOG 勾勒的不仅是一份版本列表更是一部多引擎、多后端、多精度的 MoE 推理框架工程史第六个家族 Qwen3.6-35B-A3B 让引擎矩阵再次扩大专家 matmul 路径的 K1/K2/K1b 重建把整数计算性能推向新的数量级共享 serve codec 终结了五份重复实现而安全、跨架构一致性与位级可复现性始终是每一次性能提升的前置条件。如果你想从代码层面继续深入最值得读的入口依次是 c/qwen36.c最新引擎、c/serve_codec.h统一线上协议、c/backend_gpu_compat.hCUDA/HIP 单一代码源与 c/qwen36_tier.hCUDA VRAM 专家 tier 的设计注释。【免费下载链接】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），仅供参考