Colibri：纯C实现的MoE推理引擎，面向边缘与裸金属部署

1. 项目概述：Colibri 是什么，它解决的到底是什么问题？

Colibri 这个名字乍一听像某种蜂鸟——轻盈、敏捷、高频振翅。但放在当前大模型推理的语境里，它指的是一套用纯 C 语言实现的、专为 MoE（Mixture of Experts，混合专家）架构设计的极简推理引擎。它不依赖 Python、不绑定 PyTorch 或 TensorFlow，甚至不引入 glibc 的复杂封装，而是直接操作内存布局、调度专家子网络、管理 token-level 路由决策，把“让 MoE 模型跑得快、跑得省、跑得稳”这件事，压缩到几千行可审计、可嵌入、可交叉编译的 C 代码里。

我第一次在 GitHub 上看到 Colibri 仓库时，第一反应是：这玩意儿真敢写。不是说它功能多炫，而是它反直觉地选择了最“古老”的技术栈——C 语言——去啃 MoE 这块公认最难啃的硬骨头。MoE 架构本身就不简单：一个输入 token 不是走完整个大模型，而是被动态路由到 Top-K 个专家子网络中（比如 Top-2），每个专家只负责局部计算；专家之间参数不共享，显存占用呈倍数级增长；路由逻辑必须低延迟、高吞吐，否则整个 pipeline 就卡在调度上。主流方案要么靠 CUDA kernel 手写调度（如 DeepSpeed-MoE），要么靠 Python + Triton 动态编译（如 vLLM 的 MoE 支持），但它们都绕不开运行时开销、ABI 兼容性、部署环境碎片化这些现实问题。而 Colibri 的解法很 brutal：把路由表预固化、把专家权重按 block 切片、把所有张量操作抽象成 strided memcpy + gemm kernel wrapper，最后用一个不到 200 行的router.c完成全部 token 分发逻辑。它不追求通用性，只服务一个目标——在边缘设备、嵌入式 NPU、或资源受限的云实例上，让一个 8B 参数、16 专家的 MoE 模型，以接近理论带宽的效率完成单次前向推理。

适合谁参考？如果你正在做以下几件事，Colibri 的设计思路比它的代码更值得你花时间细读：

• 为车载域控制器部署一个支持多任务意图识别的 MoE 小模型，但芯片只有 2GB DDR 和裸金属 RTOS；
• 在 FPGA 加速卡上做 MoE 推理卸载，需要确定 host 端调度器与硬件 accelerator 的 memory layout 对齐方式；
• 给国产 AI 芯片 SDK 写底层 inference runtime，客户明确要求“不能 link libtorch，不能调用 malloc”；
• 或者，你只是想搞清楚：当所有人用 Python 堆栈谈“MoE 优化”时，底层真正的瓶颈到底在哪儿——是矩阵乘法？是显存带宽？还是 cache line false sharing 导致的 L3 miss 率飙升？

Colibri 不提供 Web UI，不带量化工具链，也不生成 ONNX。它就干一件事：给你一份可执行、可调试、可单步 trace 的 C 源码，让你亲眼看见一个 token 从进入colibri_infer()函数，到被写入哪个专家的 input buffer，再到结果如何聚合回 output tensor 的全过程。这种“透明感”，恰恰是当前绝大多数 MoE 推理框架缺失的。

2. 核心设计哲学：为什么用 C？为什么放弃 Python 生态？

2.1 C 语言不是怀旧，而是对确定性的绝对掌控

很多人看到 Colibri 用 C，第一反应是“太原始”。但如果你拆开它的src/目录，会发现这种“原始”背后有非常精密的工程权衡。我们先看一组实测数据：在一台搭载 Intel Xeon Silver 4310（24 核）、64GB DDR4-3200 的服务器上，对比相同 MoE 模型（Qwen2-MoE-7B，Top-2，16 experts）在三种环境下的首 token 延迟（P99）：

关键差异不在算法，而在内存模型。PyTorch 的 eager mode 会在每次 forward 中动态分配 activation buffer，vLLM 虽用 PagedAttention 缓存 KV，但 MoE 的 expert output buffer 仍需 per-request malloc；而 Colibri 的做法是：在colibri_init()阶段，根据最大 batch size 和 max seq len，一次性 mmap 一块连续虚拟内存，然后用 arena allocator 划分出 input/output/expert_work buffers。所有 buffer 地址在初始化后即固定，后续推理全程 zero-allocation。这意味着：

• GC 压力归零（没有 Python 对象生命周期管理）；
• TLB miss 次数下降 67%（实测 perf report 数据）；
• 可预测的 cache line 占用——你可以精确算出第 3 个 token 的第 7 个 expert 的 output buffer 起始地址：base_addr + (batch_idx * max_seq_len + pos) * expert_out_size。

这种确定性，在实时性要求严苛的场景里就是命脉。比如工业质检场景中，一个 MoE 模型要同时处理缺陷分类（expert 0~3）、尺寸测量（expert 4~7）、材质识别（expert 8~11）三类任务，系统必须保证单帧处理延迟 ≤ 80ms。如果用 Python runtime，GC 暂停可能随机吃掉 15ms，导致整条产线节拍紊乱。Colibri 把这部分不确定性彻底抹掉。

2.2 MoE 架构的“本质瓶颈”被重新定义

MoE 的常见优化思路集中在两个方向：一是压缩专家参数（如量化、稀疏化），二是加速路由计算（如用 learned router 替代 top-k）。但 Colibri 的作者在 README 里写了一句很尖锐的话：“Most MoE overhead isn’t in computation — it’s in memory movement.”（MoE 的大部分开销不在计算，而在内存搬运。）这句话直指要害。

我们来算一笔账。假设一个 token 经过 routing 后被分发到 expert 5 和 expert 12，每个 expert 的 hidden size 是 4096，那么：

• 需要从 global input buffer 复制 4096×sizeof(float) = 16KB 数据到 expert 5 的 local input buffer；
• 同样复制 16KB 到 expert 12 的 local input buffer；
• expert 5 计算完，再复制 16KB 回 global output buffer；
• expert 12 同理，再复制 16KB；
• 最后还要做 weighted sum（假设 gating score 是 [0.6, 0.4]），又涉及 2×16KB 的 load + 16KB 的 store。

单个 token 就产生80KB 的内存搬运量。当 batch size=32、seq len=512 时，仅路由阶段的数据搬移就达 32×512×80KB ≈1.3GB。这还没算 gemm 计算本身的访存。Colibri 的应对策略不是“更快地搬”，而是“更聪明地不搬”：

• 它强制所有 expert 的 weight matrix 按 column-major 存储，并与 input buffer 的 stride 对齐；
• routing 后不 memcpy，而是通过input_ptr + offset直接传指针给 expert 的 gemm kernel；
• output buffer 采用 double-buffering 设计，当前 token 的 output 写入 buffer A，下一个 token 的 output 写入 buffer B，避免 bank conflict；
• gating score 计算与 gemm 重叠：在 expert 5 计算时，CPU 已提前把 expert 12 的 gating score 算好并写入寄存器，等 expert 5 结束立即 dispatch。

这种设计让实际内存带宽利用率从常规方案的 42% 提升到 89%（用 likwid-pin 测得）。它不改变 MoE 的数学本质，但把硬件资源的“水龙头”拧到了最大。

2.3 “Frontier Models” 的落地悖论：越大越难用

“Frontier Models”这个词最近频繁出现在论文和发布会中，指代那些参数量突破传统训练范式的模型（如 Mixtral 8x7B、DeepSeek-MoE-16B）。但前沿不等于可用。一个典型的矛盾是：这些模型在 H100 集群上跑 demo 很炫，但一旦要部署到客户现场，立刻暴露三个断层：

1. 软件栈断层：客户机房可能只有 CentOS 7 + GCC 4.8，不支持 C++17 的 std::optional，更别说 CUDA 12.x；
2. 硬件断层：客户采购的推理服务器用的是 AMD MI250X，驱动栈对 PyTorch 的 MoE 支持不完整；
3. 运维断层：SRE 团队拒绝给生产环境装 Python 包管理器，要求所有二进制必须 static linked。

Colibri 的存在，就是为填平这三条断层。它只依赖 POSIX syscall（open/mmap/read/write）和基础 math.h，连 pthread 都不用——所有并发靠用户传入的 thread pool handle 实现。编译只需gcc -O3 -march=native -DNDEBUG src/*.c -o colibri，输出一个 1.2MB 的静态可执行文件，扔进任何 Linux x86_64 环境都能跑。它甚至提供了colibri_minimal.c版本：删掉所有日志、错误检查、配置解析，只剩核心 infer loop，代码不足 500 行，可直接嵌入到客户定制的 C++ 主程序中。

这不是“为了 C 而 C”，而是当“前沿”撞上“现实”，必须有人把模型能力翻译成 bare-metal 可执行的指令流。Colibri 做的，就是这份翻译工作里的词典编纂者。

3. 核心模块拆解：从路由到专家执行的每一步细节

3.1 Router 模块：轻量但绝不妥协的 Top-K 实现

MoE 的灵魂在 router。Colibri 的 router 实现看似简单，实则处处是坑。我们来看src/router.c的核心函数：

void colibri_route_topk(const float* gating_logits, int* topk_experts, float* topk_weights, int batch_size, int seq_len, int num_experts, int top_k) { // Step 1: Softmax over experts dimension float* softmax_buf = alloca(num_experts * sizeof(float)); for (int i = 0; i < batch_size * seq_len; i++) { softmax(softmax_buf, gating_logits + i * num_experts, num_experts); // Step 2: Partial sort to get top-k indices & weights partial_sort_topk(softmax_buf, topk_experts + i * top_k, topk_weights + i * top_k, num_experts, top_k); } }

这里有两个关键点必须深挖：
第一，为什么用 alloca 而不是 malloc？
因为gating_logits的 shape 是[batch_size * seq_len, num_experts]，当 batch_size=1、seq_len=2048、num_experts=16 时，softmax buffer 只需 16×4=64 字节。alloca 在 stack 上分配，无锁、无 syscall、无 fragment，且 lifetime 与函数调用严格绑定。如果用 malloc，每次 forward 都要 malloc/free 2048 次 64B buffer，glibc 的 ptmalloc 在小内存分配上会有明显 contention（实测在 32 线程下 malloc latency 达 120ns，alloca 仅 3ns）。Colibri 用空间换时间，把 softmax buffer size 控制在 L1 cache 容量内（通常 32KB），确保每次访问都是 cache hit。

第二，partial_sort_topk 的实现为何不用 std::nth_element？
因为 C 标准库不提供稳定、高效的 partial sort。Colibri 自研了一个双 pivot quickselect 变种，核心逻辑如下：

• 对 gating score 数组，随机选两个 pivot（避免 worst-case O(n²)）；
• 一次遍历将数组划分为<p1,∈[p1,p2],>p2三段；
• 如果∈[p1,p2]段长度 ≥ top_k，递归处理该段；否则根据 top_k 位置决定继续处理<p1或>p2段；
• 最终返回的 top_k indices 严格按 score 降序排列，weights 直接取对应值。

这个实现比 glibc 的 qsort + memcpy 快 3.2 倍（perf benchmark），且内存访问 pattern 可预测——所有操作都在 contiguous array 上进行，无 pointer chasing，L3 cache miss rate 低于 0.8%。

提示：Colibri 的 router 不支持动态 top_k（如 per-token 可变 K）。这是刻意为之的设计约束。作者认为，在绝大多数 MoE 应用中，top_k=2 是精度与效率的最佳平衡点，硬编码可省去分支预测失败带来的 pipeline stall。如果你真需要 top_k=1 或 4，修改#define TOP_K 2并重新编译即可，无需改算法逻辑。

3.2 Expert Dispatch 模块：内存布局即 API

dispatch 模块是 Colibri 最体现“C 思维”的部分。它不抽象出“Expert”类，而是用纯数据结构描述专家行为：

typedef struct { const float* weight; // [out_dim, in_dim] const float* bias; // [out_dim] int in_dim; int out_dim; int stride; // weight matrix leading dimension } colibri_expert_t; void colibri_dispatch_expert(const colibri_expert_t* expert, const float* input, float* output, int batch_size, int seq_len) { // Gemv: output = input * weight^T + bias for (int i = 0; i < batch_size * seq_len; i++) { gemv(expert->weight, expert->bias, input + i * expert->in_dim, output + i * expert->out_dim, expert->in_dim, expert->out_dim, expert->stride); } }

注意colibri_expert_t的字段设计：

• weight是 const 指针，意味着专家权重在推理期间绝不修改，可 mmap 到 read-only memory，防止 accidental overwrite；
• stride字段显式暴露 weight matrix 的 leading dimension，这是为兼容不同存储格式（如 row-major vs column-major）预留的接口。Colibri 默认 expect column-major，因为 gemv 在 column-major 下 cache locality 更优；
• gemv函数不是调用 BLAS，而是 Colibri 自带的 hand-written kernel（见src/gemv.c），针对 x86-64 AVX2 指令集深度优化：
  • 使用_mm256_load_ps一次加载 8 个 float；
  • 用_mm256_dp_ps做 dot product（比 mul+add 快 2.1 倍）；
  • 对 bias 做 prefetch，避免 store-forwarding stall。

这种设计让 expert 成为一个“纯函数”：输入 buffer 地址 + 输出 buffer 地址 + expert descriptor，就能确定全部行为。没有隐藏状态，没有 side effect，可任意顺序 dispatch，天然支持 pipeline parallelism。

3.3 Memory Management：Arena Allocator 的实战细节

Colibri 的内存管理是教科书级的 arena allocator 实践。它在src/memory.c中定义：

typedef struct { uint8_t* base; size_t capacity; size_t offset; } colibri_arena_t; static colibri_arena_t g_arena; void* colibri_arena_alloc(size_t size) { size_t aligned_size = (size + 15) & ~15; // 16-byte align if (g_arena.offset + aligned_size > g_arena.capacity) { return NULL; // OOM } void* ptr = g_arena.base + g_arena.offset; g_arena.offset += aligned_size; return ptr; } void colibri_arena_reset() { g_arena.offset = 0; }

关键细节在于colibri_init()如何规划 arena：

• input_buffer: size =max_batch_size * max_seq_len * hidden_size * sizeof(float)；
• output_buffer: same size as input；
• expert_work_buffers: one per expert, size =max_batch_size * max_seq_len * expert_out_size * sizeof(float)；
• temp_buffers: for softmax, routing temp storage, sized conservatively。

所有 buffer 在 arena 中 contiguous layout，例如：

[ input_buffer ][ output_buffer ][ expert0_work ][ expert1_work ]...[ temp ]

这种 layout 带来两个巨大优势：

1. DMA 友好：如果后续要移植到支持 DMA 的硬件（如 NPU），整个 arena 可以一次 map 到 device memory，无需 scatter-gather；
2. cache warmup 可控：在colibri_infer()开头，Colibri 会用__builtin_prefetch预取 input_buffer 的前 4KB 到 L1 cache，因为这是所有计算的起点。实测 prefetch 使 L1 miss rate 从 12.3% 降至 2.1%。

注意：arena allocator 不提供 free()。这是 deliberate choice。Colibri 假设一次 infer call 处理一个 batch，call 结束后调用colibri_arena_reset()归零 offset，相当于“一次分配，批量复用”。这比 per-object malloc/free 快一个数量级，且彻底消除 memory fragmentation。

4. 实操指南：从零构建你的第一个 Colibri MoE 推理流程

4.1 环境准备与最小依赖确认

Colibri 的构建哲学是“最小可行依赖”。它不依赖任何第三方库，但对编译器和系统有明确要求。以下是我在三类典型环境中的验证清单：

特别注意：不要用 Clang 编译。Colibri 的 hand-written AVX2 kernel（src/avx2.c）大量使用 GCC intrinsic（如__builtin_ia32_vmovaps256），Clang 对这些 intrinsic 的支持不一致，会导致 runtime segfault。如果你必须用 Clang，需注释掉#include "avx2.c"并启用 fallback scalar kernel（性能下降约 40%）。

构建步骤极简：

# 克隆仓库（注意：官方 repo 已 archive，需 fork 后维护） git clone https://github.com/yourname/colibri.git cd colibri # 编译（默认启用 AVX2，如需 SSE4.1，加 -DUSE_SSE41） make clean && make # 生成可执行文件 ls -lh build/colibri # -rwxr-xr-x 1 user user 1.2M Jan 1 10:00 build/colibri

make背后执行的是：

CC = gcc CFLAGS = -O3 -march=native -DNDEBUG -std=c11 -Wall -Wextra LDFLAGS = -static SRC = $(wildcard src/*.c) $(EXEC): $(SRC) $(CC) $(CFLAGS) $(SRC) $(LDFLAGS) -o $@

-static是关键。它确保生成的二进制不依赖系统 glibc 版本，可 copy 到任意 Linux x86_64 环境直接运行。实测在 CentOS 7（glibc 2.17）上运行 Ubuntu 22.04 编译的 binary，零报错。

4.2 模型权重转换：从 PyTorch checkpoint 到 Colibri binary format

Colibri 不接受 PyTorch.pt或 Safetensors，它定义了自己的二进制格式colibri_model.bin，结构如下：

[HEADER: 32 bytes] magic: "COLIBRI\0" version: uint32 (1) num_experts: uint32 hidden_size: uint32 vocab_size: uint32 max_seq_len: uint32 ... [EMBEDDING_WEIGHTS: vocab_size * hidden_size * 4 bytes] [ROUTER_WEIGHTS: hidden_size * num_experts * 4 bytes] [EXPERT_WEIGHTS: num_experts * (expert_in_dim * expert_out_dim * 4) bytes] [EXPERT_BIAS: num_experts * expert_out_dim * 4 bytes]

转换脚本tools/convert_pt_to_colibri.py是 Python 写的（仅用于转换，不参与推理），核心逻辑：

import torch import numpy as np def convert_model(pt_path, output_path): state_dict = torch.load(pt_path, map_location="cpu") # Extract and reorder weights embed_weight = state_dict["model.embed_tokens.weight"].numpy().astype(np.float32) router_weight = state_dict["model.layers.0.block_sparse_moe.gate.weight"].numpy().astype(np.float32) # Experts: PyTorch stores as list of dicts, Colibri needs flat concat expert_weights = [] expert_biases = [] for i in range(NUM_EXPERTS): w = state_dict[f"model.layers.0.block_sparse_moe.experts.{i}.w1.weight"].numpy() b = state_dict[f"model.layers.0.block_sparse_moe.experts.{i}.w1.bias"].numpy() # Convert to column-major for Colibri's gemv w_colmajor = w.T.astype(np.float32) # transpose! expert_weights.append(w_colmajor) expert_biases.append(b.astype(np.float32)) # Write binary file with open(output_path, "wb") as f: f.write(b"COLIBRI\0" + struct.pack("<IIIII", 1, NUM_EXPERTS, HIDDEN_SIZE, VOCAB_SIZE, MAX_SEQ_LEN)) f.write(embed_weight.tobytes()) f.write(router_weight.tobytes()) for w in expert_weights: f.write(w.tobytes()) for b in expert_biases: f.write(b.tobytes())

关键转换技巧：

• 权重转置：PyTorch 的 Linear layer 权重是 row-major（[out_dim, in_dim]），Colibri 的 gemv kernel 期望 column-major（[in_dim, out_dim]），所以必须w.T；
• 数据类型：必须用np.float32，Colibri 不支持 FP16 或 BF16，量化需在转换前完成（如用torch.quantization.convert）；
• 专家顺序：必须严格按 index 0,1,2,...,15 存储，Colibri 的 router 用expert_id直接索引，不查 hash table。

转换完成后，用xxd -l 64 colibri_model.bin检查 header 是否正确：

00000000: 434f 4c49 4252 4900 0000 0001 0000 0010 COLIBRI......... 00000010: 0000 0800 0000 0000 0000 0000 0000 0000 ................

前 8 字节434f 4c49 4252 4900是 ASCII "COLIBRI" + null，第 12 字节0000 0010是 little-endian 的 16（num_experts），验证通过。

4.3 首次推理：命令行参数详解与调试技巧

运行 Colibri 的命令极其简洁：

./build/colibri \ --model models/qwen2-moe-7b.colibri.bin \ --tokenizer tokenizer.json \ --prompt "The capital of France is" \ --max-new-tokens 32 \ --temperature 0.7 \ --top-p 0.9

各参数含义及底层影响：

• --model: 指向转换好的.colibri.bin文件，Colibri 用mmap(2)加载，只读，不 copy 到 RAM；
• --tokenizer: JSON 格式 tokenizer，必须包含vocab（list of strings）和merges（for BPE），Colibri 自带 minimal tokenizer parser，不依赖 tiktoken；
• --prompt: UTF-8 编码字符串，Colibri 内部用iconv转为 UTF-32 处理，避免 surrogate pair 错误；
• --max-new-tokens: 控制生成长度，Colibri 的 decoding loop 是标准 autoregressive，每次生成一个 token 后更新 KV cache（存储在 arena 中）；
• --temperature/--top-p: 采样参数，Colibri 的 logits sampling 在 CPU 上完成，用 Marsaglia polar method 生成正态分布随机数，比 rand() 更均匀。

调试时最关键的 flag 是--verbose：

./build/colibri --model ... --prompt "hello" --verbose

输出类似：

[INFO] Loaded model: 7.2B params, 16 experts, hidden_size=4096 [INFO] Tokenized prompt: [1, 3242, 234, 567] (len=4) [DEBUG] Routing: token[0] -> experts [5,12] (weights [0.62,0.38]) [DEBUG] Dispatching expert 5: input[0x7f8a12345000] -> output[0x7f8a12346000] [DEBUG] Expert 5 gemv: 4096x4096 matmul, 128 cycles/tile [DEBUG] Routing: token[1] -> experts [3,8] (weights [0.55,0.45]) ... [INFO] Generated 32 tokens in 142ms (225.4 tok/s)

--verbose不仅打印日志，还注入 cycle counter（rdtscinstruction），让你精确知道每个 expert dispatch 花了多少 CPU cycles。这是定位性能瓶颈的黄金 flag。

实操心得：首次运行若卡住，90% 是 tokenizer.json 格式错误。Colibri 的 tokenizer parser 非常 strict：vocab必须是 list of strings，不能有 None；merges必须是 list of two-element lists，不能是 tuple。用python -m json.tool tokenizer.json格式化后肉眼检查，比 debug 代码快得多。

5. 常见问题排查与性能调优实战记录

5.1 典型问题速查表

其中最隐蔽的问题是arena overflow。Colibri 的 arena size 在colibri_init()中硬编码计算，公式为：

arena_size = (max_batch_size * max_seq_len * hidden_size * 4) * 3 // input/output/work + (num_experts * max_batch_size * max_seq_len * expert_out_size * 4) + 1024*1024 // temp buffers

如果实际推理时batch_size或seq_len超过初始化值，colibri_arena_alloc()返回 NULL，后续memcpy或gemv传入空指针，导致 segfault。但错误不会立刻出现，可能在第 100 个 batch 的某个 expert dispatch 时才 crash。我的避坑技巧是：在colibri_infer()开头加一行 assert：

assert(input_buffer != NULL && "Arena overflow: input_buffer alloc failed");

编译时加-DDEBUG，让问题在源头暴露。

5.2 性能调优三板斧：从 baseline 到极限

在一台 32 核 AMD EPYC 7742 上，Colibri 的 baseline 性能（Qwen2-MoE-7B, batch=1, seq_len=512）是 189 tok/s。通过以下三步调优，提升到 312 tok/s：

第一斧：CPU 绑核与频率锁定
默认情况下，Linux scheduler 会把 Colibri 线程在不同 core 间迁移，导致 cache warmup 失效。用taskset固定到物理 core：

# 查看物理 core topology lscpu \| grep "Core(s) per socket" # 假设是 64 cores, 绑定到 core 0-15（同一 NUMA node） taskset -c 0-15 ./build/colibri --model ... --batch-size 16

更进一步，关闭 turbo boost 并锁定频率，消除 frequency scaling 带来的性能抖动：

echo "performance" | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor sudo cpupower frequency-set -g performance -u 2.8GHz -d 2.8GHz

这一步提升 12% 吞吐，因为 gemv kernel 的 IPC（instructions per cycle）更稳定。

第二斧：内存通道优化
Colibri 的 arena 是大块连续内存，其性能受内存 channel 数量影响极大。用dmidecode -t memory查看：

Memory Device Size: 128 GB Type: DDR4 Speed: 3200 MT/s Configured Clock Speed: 3200 MT/s Total Width: 72 bits Data Width: 64 bits

确认是 dual-channel（72-bit width 表明有 ECC，但 data width 64-bit 是标准 dual-channel）。然后用numactl --membind=0 --cpunodebind=0 ./colibri ...强制 arena 分配在 node 0 的内存上，避免跨 NUMA 访问。实测 latency 降低 23%。

第三斧：AVX2 kernel 深度定制
Colibri 的src/avx2.c是通用 AVX2 实现。针对 EPYC 7742（Zen2 架构），我把 gemv kernel 中的vdpbf16ps指令（BF16 support）替换为vpmaddwd（integer multiply-add），因为 Zen2 的 BF16 单元较弱。修改后：

• 每次 gemv 的 cycle count 从 128 降至 92；
• L2 cache miss rate 从 8.7% 降至 3.2%；
• 整体吞吐再 +18%。

注意：这种定制必须测试 correctness。我写了test/gemv_correctness.c，用随机数据跑 10000 次，对比 AVX2 kernel 与 scalar reference 的输出，diff < 1e-5 才 merge。永远记住：性能优化的前提是数值正确。

5.3 与主流框架的实测对比：不只是数字的游戏

最后，放一组在相同硬件（H100 PCIe 80GB）上的公平对比，所有测试均用 Qwen2-MoE-7B 模型，batch_size=8，input_length=512，output_length=32：