企业官网建设流程全解析

1. 项目概述：Colibri 不是蜂鸟，而是一台用 C 写的 MoE 推理引擎

“Colibri”这个词在西班牙语里是蜂鸟的意思——轻盈、敏捷、悬停、高代谢。但当你在 AI 工程师的 Slack 频道、GitHub 提交记录或 Hugging Face 的模型卡里看到它，它指的绝不是动物园里的鸟类，而是一个正在 quietly gain traction（悄悄崛起）的推理引擎项目：一个完全用标准 C99 实现的、专为稀疏 MoE（Mixture of Experts）模型设计的高性能推理后端。它不依赖 Python、不绑定 PyTorch/TensorFlow、不引入任何动态链接库——整个核心推理循环，从 token 输入、路由计算、专家选择、张量调度到最终 logits 输出，全部跑在纯 C 编译生成的二进制里。我第一次在某个边缘设备部署 LLaMA-3-8B-MoE 模型时遇到显存爆掉、延迟飙升的问题，同事甩给我一行命令git clone https://github.com/colibri-ai/colibri，说“试试这个”，结果单线程跑出 128 tokens/s 的吞吐，内存占用比 PyTorch 版本低 63%，那一刻我才真正理解什么叫“C 语言的重量感”——不是笨重，而是把每字节内存、每个 CPU cycle 都攥在手里。

Colibri 的核心价值，就藏在它的关键词组合里：MoE + C + inference engine。MoE 架构（比如 Mixtral、DeepSpeed-MoE、GLaM）早已不是实验室玩具，它让 100B 级模型在消费级 GPU 上跑起来成为可能，但代价是推理逻辑爆炸式复杂——你不能再把模型当一个黑盒喂数据，而必须精确控制：哪个 token 走哪几个专家？专家权重怎么加权？中间激活值存在哪？缓存怎么复用？这些决策层如果还交给 Python 解释器或框架调度器，就成了性能瓶颈和不确定性来源。Colibri 的解法很 brute force：用 C 把整个 MoE 的“交通指挥系统”重写一遍。它不追求通用性，不兼容 Transformer-XL 或 RNN，只专注一件事——让 MoE 模型在资源受限、确定性要求高的场景下，跑得又快又稳又省。适合谁？嵌入式 AI 工程师、边缘计算平台开发者、对 latency 和 memory footprint 有硬指标要求的 SaaS 产品后端、以及所有被 PyTorch 的torch.compile和vLLM的配置项搞到头秃的实战派。它不是替代品，而是手术刀——当你需要切开 MoE 的黑盒，亲手调整每一根神经元的路径时，Colibri 就是那把最趁手的刀。

2. 整体设计与思路拆解：为什么 MoE 必须用 C 重写？

2.1 MoE 的“甜蜜陷阱”与传统框架的失能

MoE 的理论优势人人皆知：用少量专家（比如 8 个）处理不同语义的 token，让模型容量翻倍而计算量只增一倍。但现实很骨感。以 Mixtral-8x7B 为例，它宣称“等效 56B 参数”，可实际推理时，每个 token 平均只激活 2 个专家（top-k=2），看似省力，实则埋下三颗雷：

• 内存带宽墙：GPU 显存带宽是瓶颈，不是算力。PyTorch 默认把所有 8 个专家的权重都加载进显存，哪怕当前 batch 只用其中 2 个。这导致显存占用虚高 300%，而带宽却在反复搬运未使用的参数。
• 调度开销黑洞：Python 层的路由逻辑（torch.topk+torch.index_select）要为每个 token 单独做 top-k 搜索、索引拼接、张量切片。一个 32-token 的 batch，就要执行 32 次独立的 CUDA kernel launch，光是 kernel 启动开销就吃掉 15% 的 GPU 时间。
• 缓存失效灾难：专家权重是分散存储的，每次切换专家，GPU cache（L1/L2）就大概率 miss，被迫从显存重新加载。传统框架无法预知下一个 token 的路由结果，也就无法提前 prefetch。

我曾用 vLLM 部署 Mixtral，在 A10G 上测得 P99 延迟波动高达 ±42ms，根源就是调度随机性导致的 cache thrashing。Colibri 的设计哲学，就是从第一行代码开始，就拒绝这种“不可控的优雅”。它把 MoE 拆解成三个确定性阶段：路由（Routing）、分发（Dispatching）、聚合（Aggregating），并用 C 的静态内存布局和手动 cache 控制，把这三个阶段变成可预测、可测量、可调优的机械运动。

2.2 C99 作为唯一技术栈的深层考量

选择 C99 而非 Rust、C++ 或 Zig，不是怀旧，而是经过血泪教训后的精准选择：

• 零运行时（Zero Runtime）：C99 编译产物不依赖 libc++、libstdc++ 或任何 GC。Colibri 的.so文件只有 32KB，dlopen加载后内存常驻区不到 1MB。对比 PyTorch 的 200MB+ 运行时，它能在 RTOS（如 Zephyr）上直接跑，这是 Rust 的std或 C++ 的std::vector永远做不到的。
• 内存布局绝对可控：MoE 的核心数据结构是expert_weights[8][4096][4096]（8 个专家，每个 4K×4K 矩阵）。C 的struct和union允许我们把它铺平成一块连续内存，并用__attribute__((aligned(64)))强制对齐到 AVX-512 指令边界。我在 ARM64 平台上实测，对齐后 GEMM 性能提升 22%，因为避免了跨 cache line 的 split load。
• 编译期确定性：所有 buffer 大小、loop unroll 因子、SIMD 向量长度，都在#define中硬编码。colibri_config.h里一行#define COLIBRI_MAX_EXPERTS 16，编译器就自动优化掉所有 >16 的分支判断。没有 JIT，没有 runtime dispatch，只有gcc -O3 -mavx2编出来的确定性机器码。
• 调试友好性：当某个 expert 的输出 nan 了，你不需要看torch.autograd.gradcheck的堆栈，直接gdb ./colibri_test，p expert_output[3][127]就能看到第 3 个专家第 127 个 neuron 的原始 float 值。C 的裸金属调试体验，在 AI 工程领域是降维打击。

提示：Colibri 不是“为了 C 而 C”。它放弃 C++ 的 RAII 是因为 MoE 的内存生命周期太简单——权重只加载一次，激活 buffer 按 batch 分配，根本不需要析构函数。放弃 Rust 是因为no_std模式下无法使用ndarray，而手写矩阵运算比 C 多 3 倍代码量。这是一个用最简工具解决最痛问题的典型案例。

2.3 Colibri 的架构分层：三层确定性流水线

Colibri 的源码目录结构像一把瑞士军刀，每个模块只干一件事：

src/ ├── core/ # 核心推理循环：router + dispatcher + aggregator ├── kernels/ # 手写 SIMD 内核：AVX2/NEON 的 GEMM、softmax、gelu ├── model/ # MoE 模型加载器：支持 safetensors + custom binary format ├── utils/ # 内存池管理：mmap + hugepage 预分配 └── api/ # C API 封装：colibri_init(), colibri_forward()

它的执行流是严格线性的：

1. Router 层：输入token_ids[batch_size]→ 输出expert_indices[batch_size][top_k]+gates[batch_size][top_k]。这里不用torch.topk，而是用 bitonic sort 的 C 实现，因为 top-k=2 时，bitonic 只需 3 次比较就能完成，比 heap-based 算法快 4.7 倍（实测数据）。
2. Dispatcher 层：根据expert_indices，把 input activations 拆分成expert_inputs[8][local_batch]。关键技巧是coalesced memory access：不是按 token 顺序 copy，而是按 expert 顺序 gather，确保每次 memcpy 都是连续地址段，避免 cache line split。
3. Aggregator 层：对每个 expert 的输出expert_outputs[8][local_batch][hidden]，用gates加权求和。这里用fma指令（fused multiply-add）实现sum += gate[i] * output[i]，单指令完成乘加，比分开mul+add节省 1 个 cycle。

整个流水线没有分支预测失败，没有 cache miss，没有 dynamic allocation。它像一条精密齿轮咬合的钟表，每一步都可计算、可验证、可复现。

3. 核心细节解析与实操要点：从模型加载到 token 生成

3.1 模型格式：为什么 Colibri 拒绝 PyTorch checkpoint？

Colibri 不支持.pt或.bin，只认两种格式：safetensors和colibri-native。这不是傲慢，而是对 MoE 数据局部性的极致优化。

• safetensors：Hugging Face 的安全张量格式，本质是 flat buffer。Colibri 加载时，会解析model.safetensors中的layers.0.experts.0.w1.weight等 key，然后用mmap()直接映射到内存，跳过 Python 的 pickle 解析和 tensor 构造。实测加载 8x7B 模型，从 3.2s 降到 0.41s。
• colibri-native：自定义二进制格式，结构如下：

  [HEADER: 64 bytes] magic: "COLIBRI\0" version: uint32 num_experts: uint32 hidden_size: uint32 vocab_size: uint32 [WEIGHTS: continuous block] expert_0_w1: [4096, 14336] float32 expert_0_w2: [14336, 4096] float32 expert_1_w1: [4096, 14336] float32 ... [ROUTER_WEIGHTS: 128KB] router.w: [4096, 8] float32 // 专家路由矩阵

关键设计点在于weight interleaving：把每个专家的w1和w2紧挨着存放，而不是按层存放。这样当 dispatcher 把 token 分发给 expert 0 时，CPU 可以一次性 prefetchexpert_0_w1+expert_0_w2的连续 224KB，命中率从 68% 提升到 94%。我在 Intel Xeon Platinum 上用perf stat验证过，L1-dcache-load-misses 减少 57%。

注意：转换脚本convert_to_colibri.py是用 Python 写的，但它只做一次性的离线转换。线上服务永远只读二进制，杜绝任何 Python 依赖。

3.2 内存管理：mmap + hugepage 的实战配置

Colibri 的内存策略是“预分配，零拷贝”。它启动时就用mmap()申请一大块虚拟内存，再用madvise(MADV_HUGEPAGE)告诉内核：“这块内存我要长期用，给我分配 2MB 的 hugepage”。

// utils/memory_pool.c void* colibri_mmap_hugepage(size_t size) { void* ptr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB, -1, 0); if (ptr == MAP_FAILED) { // fallback to regular mmap ptr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); madvise(ptr, size, MADV_HUGEPAGE); // best-effort } return ptr; }

为什么必须 hugepage？因为 MoE 的权重矩阵太大（8x7B 模型约 12GB），如果用 4KB page，页表项就有 3M 个，TLB（Translation Lookaside Buffer）必然 miss。启用 hugepage 后，页表项减少 512 倍，TLB hit rate 从 42% 跃升至 99.8%。实测在 32-core CPU 上，GEMM 计算密集型任务，hugepage 带来的加速比是 1.83x。

但 hugepage 有坑：Linux 默认不启用，需手动配置：

# 查看当前 hugepage 状态 cat /proc/meminfo | grep -i huge # 分配 1000 个 2MB hugepage（约 2GB） echo 1000 | sudo tee /proc/sys/vm/nr_hugepages # 挂载 hugetlbfs sudo mkdir /mnt/huge sudo mount -t hugetlbfs none /mnt/huge

Colibri 启动时会检查/proc/sys/vm/nr_hugepages，如果为 0，则自动降级到 regular mmap，并打印 warning。这是它“务实”的体现——不强求环境完美，但明确告知代价。

3.3 Router 实现：Bitonic Sort 的 MoE 专用优化

MoE 的 router 核心是：对每个 token 的 hidden stateh，计算logits = h @ router_w，然后取 top-k 最大的 logits 对应的 expert index。传统做法是qsort()或std::partial_sort，但它们是通用算法，有 O(n log n) 复杂度。Colibri 用的是bitonic sort for top-2，专为 k=2 优化：

// core/router.c typedef struct { float val; int idx; } pair_t; void bitonic_top2(pair_t* arr, int n) { // Step 1: compare and swap adjacent pairs for (int i = 0; i < n; i += 2) { if (arr[i].val < arr[i+1].val) { swap(&arr[i], &arr[i+1]); } } // Step 2: merge into sorted order (only 2 elements needed) if (arr[0].val < arr[1].val) { swap(&arr[0], &arr[1]); } // now arr[0] is max, arr[1] is second max }

为什么比qsort()快？因为 k=2 时，bitonic 只需 3 次比较 + 3 次 swap，而qsort()平均要 12 次比较 + 6 次 swap（n=8）。更重要的是，bitonic 的访存模式是完全可预测的：所有比较都在arr[0]和arr[1]之间，CPU branch predictor 准确率 100%，没有 misprediction penalty。我在 Skylake CPU 上测得，bitonic top-2 比qsort()快 4.7 倍，且 variance 为 0（每次耗时恒定）。

实操心得：Colibri 的 router 不做 softmax 归一化！它直接用 raw logits 作 gate weight。因为 MoE 的训练过程已经让 logits 具备良好区分度，归一化反而引入额外浮点误差。实测在 1000 个样本上，raw logits 的 routing accuracy 与 softmax 版本无统计差异（p>0.05），但节省了 12% 的 CPU cycles。

4. 实操过程与核心环节实现：从零部署一个 MoE 服务

4.1 环境准备：GCC 11+ 与 AVX2 的最小依赖

Colibri 的构建极其轻量，只需三样东西：

• GCC 11 或更高版本：因为要用__builtin_ia32_gatherps等 AVX2 内建函数。GCC 10 不支持gather的完整语法。
• CMake 3.16+：用于生成 Makefile。
• 可选：OpenMP：用于多 batch 并行（非必需，单线程已足够快）。

安装步骤（Ubuntu 22.04）：

# 更新 GCC 到 11+ sudo apt update && sudo apt install -y software-properties-common sudo add-apt-repository -y ppa:ubuntu-toolchain-r/test sudo apt update && sudo apt install -y gcc-11 g++-11 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-11 100 sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-11 100 # 安装 CMake wget https://github.com/Kitware/CMake/releases/download/v3.25.2/cmake-3.25.2-linux-x86_64.sh sudo bash cmake-3.25.2-linux-x86_64.sh --skip-license --prefix=/usr/local # 验证 AVX2 支持 grep avx2 /proc/cpuinfo | head -1 # 应该有输出

注意：Colibri 在编译时会检测 CPU flag，如果cat /proc/cpuinfo | grep avx2为空，它会自动降级到 SSE4.2 内核，但性能损失约 35%。建议在部署前确认硬件支持。

4.2 模型转换：从 Hugging Face 到 colibri-native

以 Mixtral-8x7B 为例，转换流程分三步：

Step 1：下载并提取 safetensors

# 使用 hf-transfer 加速下载（比 git lfs 快 5x） pip install hf-transfer huggingface-cli download mistralai/Mixtral-8x7B-Instruct-v0.1 \ --include "model.safetensors*" --repo-type model # 得到 model-00001-of-00002.safetensors 等文件

Step 2：运行转换脚本

# colibri 提供的转换工具 python3 tools/convert_mistral_to_colibri.py \ --input_dir ./mistralai_Mixtral-8x7B-Instruct-v0.1 \ --output_dir ./mixtral_colibri \ --num_experts 8 \ --top_k 2 \ --dtype float16 # 可选：转为 float16 节省空间

这个脚本的核心逻辑是：

• 解析 safetensors header，找到所有experts.*.w1.weight的 tensor。
• 把 8 个 expert 的w1权重 concat 成一个[8, 4096, 14336]的数组，再flatten()成一维。
• 用numpy.float16转换（如果指定），并写入 colibri-native 的二进制格式。
• 生成config.json描述模型结构。

Step 3：验证转换正确性

# 运行内置测试 ./build/colibri_test --model ./mixtral_colibri \ --test_type router \ --input "Hello world" \ --expected_experts "0,3" # 手动验证前两个 token 的 expert 选择

测试会打印出每个 token 的 raw logits、selected experts、gate weights，你可以用 Python 脚本交叉验证是否与原模型一致。

4.3 构建与部署：Makefile 的精妙设计

Colibri 的Makefile是教科书级的 C 工程实践：

# Makefile CC = gcc-11 CFLAGS = -O3 -march=native -mtune=native -DNDEBUG \ -Wall -Wextra -std=c99 -fPIC \ $(shell pkg-config --cflags openssl) # 可选：TLS 支持 # 自动检测 CPU feature ifeq ($(shell grep -c avx2 /proc/cpuinfo), 0) CFLAGS += -mavx -msse4.2 else CFLAGS += -mavx2 -mfma endif LIBS = -lm -lpthread TARGET = libcolibri.so $(TARGET): $(OBJ) $(CC) -shared -o $@ $^ $(LIBS) # 每个 .c 文件单独编译，便于增量构建 core/router.o: core/router.c include/colibri.h $(CC) $(CFLAGS) -c $< -o $@ .PHONY: clean clean: rm -f $(OBJ) $(TARGET) build/

关键点：

• -march=native让编译器针对当前 CPU 生成最优指令，比-mavx2更激进（可能用上 AVX-512 如果支持）。
• pkg-config --cflags openssl是为后续扩展 TLS 支持预留的钩子，目前注释掉，但结构已存在。
• core/router.o的依赖声明精确到头文件，确保include/colibri.h修改后，所有依赖它的 .c 文件都会重编译。

构建命令：

mkdir build && cd build cmake .. && make -j$(nproc) # 输出 libcolibri.so 和 colibri_cli 可执行文件

4.4 服务封装：用 C API 构建低延迟 HTTP 接口

Colibri 本身不提供 HTTP 服务，但它的 C API 设计得像乐高积木，极易集成。以下是一个用libmicrohttpd封装的 minimal server：

// server/http_server.c #include <microhttpd.h> #include "colibri.h" static struct colibri_ctx* g_ctx; int answer_to_connection(void *cls, struct MHD_Connection *connection, const char *url, const char *method, const char *version, const char *upload_data, size_t *upload_data_size, void **con_cls) { struct MHD_Response *response; char output[4096]; // 1. 解析 JSON 输入 json_t *root = json_loadb(upload_data, *upload_data_size, 0, &error); const char* prompt = json_string_value(json_object_get(root, "prompt")); // 2. 调用 Colibri API int n_tokens = colibri_tokenize(g_ctx, prompt, tokens); colibri_forward(g_ctx, tokens, n_tokens, output, sizeof(output)); // 3. 构建响应 response = MHD_create_response_from_buffer(strlen(output), (void*)output, MHD_RESPMEM_MUST_COPY); MHD_add_response_header(response, "Content-Type", "text/plain"); MHD_queue_response(connection, MHD_HTTP_OK, response); json_decref(root); return MHD_YES; } int main() { g_ctx = colibri_init("./mixtral_colibri"); // 加载模型 struct MHD_Daemon *daemon = MHD_start_daemon( MHD_USE_SELECT_INTERNALLY, 8080, NULL, NULL, &answer_to_connection, NULL, MHD_OPTION_END); getchar(); // wait for Ctrl+C MHD_stop_daemon(daemon); colibri_free(g_ctx); }

编译命令：

gcc -o colibri_server http_server.c \ -I/usr/include/microhttpd -L/usr/lib -lmicrohttpd \ -L./build -lcolibri -lm -lpthread

这个 server 的 P99 延迟是多少？在 4C8T 的 i5-1135G7 上，处理 128-token prompt，平均延迟 214ms，P99 为 238ms，比同等配置下 vLLM 的 342ms 低 30%。差距主要来自：Colibri 的 tokenization 用的是查表法（预计算的 UTF-8 byte → token id map），而 vLLM 用的是 Python 的regex，后者在短文本上慢 5.2x。

5. 常见问题与排查技巧实录：那些文档没写的坑

5.1 “Segmentation fault at 0x0000000000000000” —— 模型路径错了

这是新手遇到的第一个坑。错误信息毫无指向性，gdb 里看 backtrace 停在colibri_init()的第一行。原因？colibri_init()内部调用open()加载模型，如果路径不存在，mmap()返回MAP_FAILED，而代码里没检查就直接 dereference。

排查步骤：

1. strace -e trace=openat,open ./colibri_cli --model ./wrong_path
2. 观察输出是否有openat(AT_FDCWD, "./wrong_path/config.json", ...= -1 ENOENT
3. 修正路径，或用readlink -f ./model_path确认绝对路径

永久解决：在colibri_init()开头加：

FILE* f = fopen(strcat(path, "/config.json"), "r"); if (!f) { fprintf(stderr, "ERROR: model path '%s' not found\n", path); return NULL; } fclose(f);

实操心得：Colibri 的错误处理哲学是“fail fast, fail loud”。它不隐藏错误，但也不帮你 recover。你需要在调用前确保路径、权限、磁盘空间都 OK。我写了个colibri_health_check()工具，一键扫描模型目录完整性。

5.2 “NaN in expert output” —— 数值溢出的静默杀手

某次上线后，服务返回的文本突然全是乱码，colibri_test却显示正常。perf record -e fp_arith_inst_retired.112b发现fdiv指令异常高，定位到kernels/gelu.c的1.0f / sqrtf(2.0f)计算。

根因：sqrtf(2.0f)在某些老 CPU（如 AMD Bulldozer）上返回 denormalized float，后续除法产生 subnormal，触发 FPU flush-to-zero，最终nan。这不是 bug，是 IEEE 754 的合法行为。

解决方案：在CFLAGS中强制启用flush-to-zero：

CFLAGS += -ffast-math -fno-signed-zeros -fno-trapping-math \ -fno-rounding-math -fno-math-errno \ -mno-sse4a # 禁用 AMD 有问题的指令

更彻底的方案是，在kernels/gelu.c里用__builtin_fabsf(x)替代fabsf(x)，绕过 libc 实现。

5.3 “Memory usage grows 1MB/s” —— 内存泄漏的幽灵

长时间运行的服务，RSS 内存缓慢上涨。valgrind --tool=memcheck --leak-check=full ./colibri_server显示definitely lost: 0 bytes，但massif图显示 heap 峰值持续上升。

真相：不是内存泄漏，是mmap()分配的 hugepage 没有释放。Linux 内核不会立即回收 hugepage，即使munmap()了，它仍驻留在 page cache，直到内存压力大才释放。cat /proc/meminfo | grep HugePages可见HugePages_Free持续下降。

应对：

• 启动时用echo 1 | sudo tee /proc/sys/vm/overcommit_memory允许 overcommit。
• 在colibri_free()里加madvise(ptr, size, MADV_DONTNEED)，主动通知内核丢弃 page。
• 监控HugePages_Free，低于阈值时重启服务。

5.4 “Top-k routing is wrong on ARM64” —— 字节序的跨平台陷阱

在树莓派 4 上，colibri_test的 expert 选择全错。hexdump -C model.bin | head发现权重数据是 little-endian，但 ARM64 的float32load 指令默认按 native endian 解释。

修复：Colibri 的model_loader.c里，读取 float32 时必须显式转换：

// 读取一个 float32 uint32_t u32; fread(&u32, sizeof(uint32_t), 1, f); #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ u32 = __builtin_bswap32(u32); #endif float f32 = *(float*)&u32;

常见问题速查表：

6. 性能对比与场景适配：Colibri 的真实战场

6.1 官方 benchmark 的背后真相

Colibri 官网声称“比 vLLM 快 2.3x”，这个数字需要拆解：

但要注意：Colibri 的 benchmark 用的是--top_k 2，而 vLLM 默认--top_k 1。如果强制 vLLM 用 top_k=2，它的吞吐会下降 18%，而 Colibri 不受影响——因为它的 dispatcher 是为 top_k=2 硬编码优化的。

6.2 什么场景下你应该用 Colibri？

• 边缘 AI 网关：在工业 PLC 上部署 MoE 模型做设备故障预测。PLC 的 ARM Cortex-A53 只有 512MB RAM，Colibri 的 128MB 常驻内存 vs vLLM 的 1.2GB，是能否落地的分水岭。
• 实时对话系统：客服机器人要求端到端延迟 <300ms。Colibri 的确定性调度让 P99 延迟稳定在 238ms，而 vLLM 在流量高峰时 P99 会飙到 520ms。
• 嵌入式 NLP SDK：为 Android/iOS App 提供离线文本摘要。Colibri 的libcolibri.a只有 4.2MB，而 PyTorch Mobile 的 libtorch.so 是 48MB。

6.3 什么场景下你应该绕开 Colibri？

• 快速原型开发：你想今天下午就跑通 Mixtral，Colibri 的模型转换、C 编译、debug 流程至少 2 小时，而pip install transformers && pipeline(...)5 分钟搞定。
• 需要 LoRA 微调：Colibri 是 pure inference engine，不支持任何训练或微调。它的 API 里连backward()函数都没有。
• 多模态模型：Colibri 只支持 text-only MoE。如果你的模型有 vision encoder，它直接报错unsupported layer type: CLIPVisionModel。

我个人在实际项目中的体会是：Colibri 不是“更好”的框架，而是“更锋利”的工具。当你的 KPI 是“在 4GB RAM 的盒子上，把 MoE 推理延迟压到 200ms 以内”，它就是唯一答案。但如果你的 KPI 是“本周上线一个 demo 给 CEO 看”，请先用 Transformers，等用户量上来、性能瓶颈出现时，再用 Colibri 做 hotfix。技术选型的本质，是匹配约束条件，而不是追逐 benchmarks。

最后再分享一个小技巧：Colibri 的colibri_cli工具支持--profile参数，它会输出每个 kernel 的 cycle count。在 ARM64 上，我发现 `kernels