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.c，v1.1.0 #391 重命名），承载 GLM 家族
c/kimi_k3.c — Kimi K3（2.8T/104B 激活参数）
c/deepseek_v4.c — DeepSeek V4 Flash
c/qwen36.c — Qwen3.6-35B-A3B（v1.7.0 新增）
c/olmoe.c — OLMoE
c/inkling.c — Inkling（含音频扩展）

CHANGELOG v1.0.0 的 Highlights 已经勾勒出这个框架的基础能力：GLM-5.2（744B MoE）在约 25 GB RAM 上以纯 C 运行、三 tier 放置、CUDA 多卡专家 tier、Metal（Apple Silicon）、MTP 投机解码、OpenAI 兼容 API（coli serve）与 Web UI。后续版本则是在此基础上逐步把每个家族补齐、把性能与正确性做深。

二、v1.7.0：第六个引擎 Qwen3.6-35B-A3B 与专家 matmul 路径重建

v1.7.0（2026-08-19，自 v1.6.2 起 71 个 PR）是 CHANGELOG 中信息量最大的版本，核心是两大主题：新增第六个模型家族与专家矩阵乘路径的全部位级一致重建。

2.1 Qwen3.6-35B-A3B：混合门控注意力引擎（#712/#713）

CHANGELOG 记录该引擎位于 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 Attention：GQA、每头 q/k RMSNorm、部分 RoPE、输出门
Gated DeltaNet：因果 depthwise conv1d + 循环门控 delta rule，携带 conv ring 与状态S[h]=[kdim,vdim]，每头 Gated RMSNorm

Dense 部分（embed、投影、router gate、共享 expert、lm_head 等）常驻 RAM（float32）；专家权重通过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 KV（10 个 attention 层，f32），128k 需要 5.0 GiB"，这也是默认值远低于硬上限的原因。

CHANGELOG 还记录了两个关键事实：

预转换容器发布：推荐 int4-gs64 格式，相对 per-row 量化，余弦相似度相对 int8 anchor 从 0.98777 提升到 0.99313，KL 从 0.109 降到 0.080。
KAT-Coder v2.5 兼容：引擎接受任何架构一致的 checkpoint，无需专属代码路径。

CUDA VRAM 专家 tier（#713）：基于热度的跨 GPU 放置。CHANGELOG 给出实测数据——2× 8 GB 显卡上从 1.44 到 10.05 tok/s（7.0× 提升），输出与 CPU 端位级一致（对完整 200-token 生成做cmp验证），冷启动（无热度表）测量。源码层在 c/qwen36_tier.h 中有完整实现：

每个专家有唯一 home 设备（eid % n_gpus），无重复
路由热度决定谁能进 VRAM（LFRU 语义 + 滞回）
有持久化热度表（HEAT_FILE）时可 warmstart 预填预算
上传在后台线程经 staging 拷贝完成，decode 永不阻塞在放置上；VRAM miss 回退到 CPU int8 路径并与在途 GPU group 重叠

启用方式（来自 c/qwen36_tier.h）：

COLI_CUDA=1 [COLI_GPUS=0,1] [CUDA_EXPERT_GB=<G>|auto] [HEAT_FILE=<path>] [QT_NO_WARMSTART=1]

只有在构建时定义了-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–#1094）

v1.7.0 对 GLM、Kimi K3、DeepSeek V4 的激活量化做了layer 级上提（#1071/#1075/#1076/#1077）：此前同一向量每层被串行重复量化约 16 次，重建后热路径上消除了约 5.2 ms/token 的串行时间与所有 per-callmalloc。

K1：plane-nibble int4 布局 + 无符号 VNNI 点积（#1079/#1086）。核心技巧是把元素k与k+32存进一个字节，免去解包；由于 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"。

K2：1×4 union tile（#1088）。prefill union 让每个 expert 拿到 2–16 行；权重块的 load+mask 从每行付一次改为每 4 行付一次，S=4 时提速2.67–3.10×（峰值 253 GMAC/s）。

K1b：gs64 容器的分组平面 IDOT（#1094），通过IDOT_GS=1显式开启——此前推荐的 gs64 容器格式在任何 batch size 下都到不了整数内核。源码在 c/colibri.c 确认：IDOT_GS环境变量默认关闭，g_idot_gs由atoi决定。

FUSED3（#1082，@outtodata）：可选的融合 AVX2 专家矩阵乘，实现在 c/fused_simd.h 与 c/olmoe.c（"FUSED3=1: 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/O：V4 加载池、DeepGEMM、双 SSD

#1097：DeepSeek 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/#1055：DeepSeek V4 CUDA tier 与双 SSD mirror。

2.4 Correctness 与 CI：ARM 可见性修复

#1083新增ubuntu-24.04-armCI job 与整数内核位级精确门控，暴露了此前 NEON 分歧路径不可见的问题（这正是 IDOT 默认值意外发布的原因）。#1109（@SebaWag）则通过编译内建函数来探测 ARM64 dotprod——因为 GCC 11 对某个无法发出vdotq_s32的基础架构也会定义__ARM_FEATURE_DOTPROD。c/Makefile 中的注释与编译探测逻辑印证了这一坑：对 armv8-a+dotprod，GCC 11 定义了该宏但生成不了指令，因此 Makefile 偏好以 dotprod 为一等 ISA 特性的 armv8.2-a 基础。#1111在grouped_s4_wmma的 store 后补了__syncwarp()（@monotophic 用 compute-sanitizer 证据报告）。

2.5 Apple Silicon：Kimi K3 的 Metal 后端（#790 → #1113）

@RDouglasSharp 贡献的 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 更多正确性修复与 Interfaces

v1.7.0 的修复清单包括：absorb softmax reduction 缺失的__syncthreads()（#1098，附确定性测试）；checkpoint-load 路径的 allocation/snprintf结果检查（#1101）；fmt=8/fmt=6 scale-byte 记账与weights_owned在 host-to-device 拷贝前设置（#1100/#1108）；USAGE_SAVE=0在所有引擎中被尊重（#1122）——此前历史被加载后仍会写回，悄悄污染共享同一 usage 文件的 A/B 对照；LRU victim 选择尊重降低后的ecap（#1121）；跨索引分片重名 tensor 现在被拒绝而非静默解析（#1106，针对不可信容器）。

Interfaces 方面：coli serve暴露 GPU-vs-fallback 计数与 chat 状态（#829）；OLMoE/Kimi K3/Inkling/DeepSeek V4 的 planner geometry adapter（#1095/#1103，23 个测试，coli plan不再猜测）；DeepSeek V4 serve framing 迁移到共享 codec（#1096）；模型家族 registry 化（#1063/#1068，coli/gateway/doctor/planner 读同一描述表）；以及#1036（@lineape）的分布式专家 worker（LAN，CLUSTER_WORKERSopt-in，c/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/CANCEL
ColiServeWireProfile控制头/负载/扩展字节上限、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 API

4.1 v1.6.2：六个内存安全问题（2026-08-14）

这是一个安全发布：六个私下报告的、可从攻击者可控输入触发的内存安全问题全部修复。威胁来源包括恶意模型文件/config.json，以及 kimi_k3 的 SERVE stdin。所有修复都在信任边界做校验，对格式良好的模型/请求无行为变化。CHANGELOG 列出的 advisory 包括：

GHSA-gf38-c8fx-ppvv：kimi_k3 SERVE OOB write
GHSA-2qrj-xjmh-mv74：json.h OOB read
GHSA-w696-h9p7-6rgc：inkling audio OOB
GHSA-7654-r78q-vc3r：deepseek_v4 indexer OOB R/W
同类的另外两个

这与 v1.1.0 中确立的威胁模型一致（见下文第五节"Security"）——模型文件来自不可信镜像。

4.2 v1.6.1/v1.6.0：公开绑定与关键回归修复

v1.6.1：--allowed-host '*'允许运维人员刻意公开绑定（#990/#993）；OLMoE 流式不再把答案丢进 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.py（"Anthropic /v1/messages (#343)"），x-api-key认证在 c/openai_server.py 有对应处理（hmac.compare_digest对比，防时序侧信道）。

五、v1.5.0：第五个引擎 DeepSeek V4 Flash 与多引擎归档

v1.5.0（2026-08-05，51 个 PR / 15 位贡献者）的核心是DeepSeek V4 Flash（@DrewZt，#165）：

MLA + DSA 稀疏注意力
43 层，256 个 routed experts + 1 个 shared，top-6
官方 checkpoint 无需转换即可流式加载（fp4 experts、带 UE8M0 block scale 的 fp8-e4m3 dense）

配置结构见 c/deepseek_v4.h：n_routed_experts、num_experts_per_tok、n_shared_experts、index_topk、sliding_window、dspark_block_size等字段完整描述了该家族的稀疏注意力索引与 DSPark 投机机制。引擎 API（c/deepseek_v4.h）提供了ColiV4EngineOpenOptions，支持memory_limit_bytes、context_tokens、pin_slots_per_layer等配置。

v1.5.0 的另一项是rows16 fp4 快速路径不再要求 AVX-512（#839）：Alder Lake 之后的消费级 Intel/AMD CPU 都能走上该快速路径——这对此前"只有 AVX-512F 才能吃到快速路径"的限制是一大解绑。

另外值得注意 v1.4.0（2026-08-01）：发布归档开始包含每个引擎——v1.3.0 归档只装了c/colibri而 README 承诺了四个家族；inkling与kimi_k3现在按平台构建、打包并做 smoke test。v1.4.0 也是第三个 GPU 后端落地的版本。

六、v1.3.0 / v1.2.0：Kimi K3 与多平台修复

v1.3.0（2026-07-29）：三个 MoE 家族跑在一个引擎上，744B → 2.8T。Kimi K3（#676）为 2.8T/104B 激活：KDA + gated-NoPE-MLA + AttnRes + LatentMoE，直接从原始 HF shards 流式加载 Moonshot 的 QAT MXFP4 专家。Inkling（975B）在 25 GB 机器上应答。
v1.2.0（2026-07-28）：GB10/DGX Spark 统一内存 OOM 修复（#653）；doctor/resource_plan识别 AMD/ROCm（#662/#663）；matmul_e8的 AVX2 实现——fmt=6 在标量内核上占 decode 的 92%（#654），原生 SIMD fmt=6 编码器比 numpy 快 15×；chat stop-set 修复（#633/#381）、异步 packed-int4 对齐（#632）、每会话稳定 KV slot（#634/#639）。

七、v1.1.1：107 KB 的教训与二进制瘦身（-22.5%）

v1.1.1 是一个同日落地的补丁发布，起因非常值得工程借鉴：Windows 用户的 Microsoft Defender 标记 v1.1.0 二进制，而根因在项目自身。

CHANGELOG 还原了完整链条：static GrDraft g_grd={.max=24};看起来无害，但GrDraft约 107 KB（grammar 的 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（#530），Windows 引擎作为 CI artifact 上传（#532），使杀毒报告可在 PR 上验证而非只在发布后。

文档侧（#521）：README 的 "Get started" 改为先获取程序再获取模型，顺序为获取 colibri（预构建归档或源码构建）→ 获取模型（372 GB 明确写在前）→ 运行；废弃了"把引擎改名为glm.exe"的过时步骤（#508 起归档直接提供colibri.exe），四种语言同步应用。

八、v1.1.0：AMD/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.h）：

"every 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, HIP=1) 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::s4（4-bit）的对应物，该内核在 HIP 下回退到quant_matmul。CHANGELOG 记录其已在 RX 9070 XT（RDNA4，ROCm 7.2）上验证：对真实 fmt=4 gs64 容器与 CPU token 精确一致，dense 常驻与 routed experts 进 VRAM 两种情形都覆盖，并有 fail-injection 控制证明 GPU 确实执行了工作。

8.2 双 SSD 与 N 盘分片

COLI_MODEL_MIRROR（#421）：同时从两块盘读模型，磁盘绑定主机的流式带宽约翻倍。源码在 c/colibri.c（"registers additional read-only copies"），c/deepseek_v4.c 有其移植版本。
COLI_MODEL_DIRS（#469）：容量聚合——运行单个盘放不下的容器，跨多盘分布且无重复。解析见 c/colibri.c。

8.3 新量化格式：fmt=5 与 fmt=6

fmt=5（int3-g64，#168）：3-bit 权重 + 每 64 组 scale，实测比 per-row int4 的 outlier-row 误差低 3.3×，字节数少 25%。
fmt=6（E8/IQ3 lattice，#465）：CPU 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 模式被武装为硬停止，工具块一开始生成就被切断。

另有 fmt=4 在CUDA_DENSE=1下产生垃圾输出（#298，dense/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 个专家（#495）；COLI_CUDA_MTP=1与COLI_CUDA=0现在覆盖隐式默认（#468）。

8.5 性能（全部 byte-identical）

#481：MLA-absorb score 与 value-mix reduction +4.7×
#477：AVX-512 上qt_addrow/qt_matvec_rowsdecode +13%
#475：opt-inXEXP=1（S=1 全常驻时每专家块一个 OpenMP region）+11.6%
#473：AVX-512 VNNI 上 int4 IDOT 在 S=1 +5.5%

XEXP在 c/colibri.c 与 c/colibri.c 中有对应读取逻辑。

8.6 升级注意：CTX 默认仍是 4096

CTX仍默认 4096。编码类客户端在单个 system prompt 里发送的内容远超此值。请使用CTX=32768。此版本之前，超长 prompt 被静默截断；现在你会得到清晰的 400。

九、v1.0.0：基线能力的全景回顾

首个正式标签（2026-07-19）确立了语义版本基线，其 Highlights 可作为理解整个框架能力边界的索引：

GLM-5.2（744B MoE）纯 C、约 25 GB RAM、专家从磁盘流式加载
三 tier 放置：VRAM（热）/ RAM（温）/ NVMe（冷），学习型缓存自动固定工作负载最热专家
CUDA 后端：多卡专家 tier、dense tensor 分布、batched ragged attention、常驻管线（COLI_CUDA_PIPE=2）
Metal 后端（Apple Silicon）：统一内存 GPU 上的 batched expert SwiGLU + 融合 decode attention
MTP 投机：原生 GLM-5.2 draft heads、grammar-forced drafts、内核钉扎验证（SPEC_PIN=1）
OpenAI 兼容 API：coli serve（SSE 流式、KV slots、有界队列）、Web dashboard（coli web）
跨平台：Linux、macOS、Windows 11（原生 MinGW）、PowerPC；三平台 CI

Engine 层面值得记住的基线能力：对transformersoracle 的 token 精确验证（teacher-forcing 32/32）；压缩 MLA KV cache（576 floats/token，比原始小 57×），跨重启持久化（.coli_kv，零 re-prefill）；DSA 稀疏注意力（lightning indexer）；router-lookahead 预取（PILOT=1，预测率 71.6%）；异步专家 I/O 池（PIPE=1）+ io_uring 批处理（URING=1）；NUMA 感知专家放置（COLI_NUMA=1，多 socket +13–40%）；AVX2 / AVX-512 / AVX-VNNI / ARM NEON / NEON-i8mm / POWER VSX 内核；int4 / int8 / int2 / grouped-int4（fmt=4）量化格式。

Tools 侧：coli convert（FP8→int4 逐分片转换）、coli doctor（只读诊断）、coli plan（资源规划 + auto-tune 处方）、coli bench（MMLU / HellaSwag / ARC 质量基准）、专家 atlas（tools/analyze.py --web，19,456 个专家的实测主题亲和度）。这些工具的实际实现分布在 c/tools/ 目录中，例如 c/tools/analyze.py（expert atlas）与 c/tools/datapoint.py（基准 datapoint 采集）。

十、贯穿版本的方法论：为何"位级一致"反复出现

通读 CHANGELOG 会发现一个高频词：bit-identical / byte-exact。这不是偶然，而是项目正确性工程的核心纪律，至少体现在四个层面：

性能优化必须可证明不改结果：v1.1.0 的 "+4.7×"、"13% decode" 均标注"全部 byte-identical"；v1.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 fixture（glm52_replay_smoke.json、glm52_replay_python.json）、kimi_chat_wire.txt与ssd_cache_vectors.txt（wire 与缓存向量的 byte-exact 回归样本）、c/tests/test_serve_codec.c（codec 解析测试），以及 c/tests/README_efficiency.md 对测试效率的说明。这些 fixture 正是"wire-transcript freeze"与"回归测试随每个修复落地"的具体载体。

结语

从 v1.0.0 到 v1.7.0，CHANGELOG 勾勒的不仅是一份版本列表，更是一部多引擎、多后端、多精度的 MoE 推理框架工程史：第六个家族 Qwen3.6-35B-A3B 让引擎矩阵再次扩大；专家 matmul 路径的 K1/K2/K1b 重建把整数计算性能推向新的数量级；共享 serve codec 终结了五份重复实现；而安全、跨架构一致性与位级可复现性，始终是每一次性能提升的前置条件。如果你想从代码层面继续深入，最值得读的入口依次是 c/qwen36.c（最新引擎）、c/serve_codec.h（统一线上协议）、c/backend_gpu_compat.h（CUDA/HIP 单一代码源）与 c/qwen36_tier.h（CUDA VRAM 专家 tier 的设计注释）。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

colibri 开发演进实录：从 CHANGELOG 看多引擎 MoE 推理框架的工程迭代脉络