Question 1

如何修复 Inkling 引擎崩溃错误 "cache served expert X for requested expert Y"(exit status 1)?

Accepted Answer

此崩溃发生在 prefill 阶段，当 expert pins 处于激活状态时（从 `.coli_usage` 历史文件加载）。被固定的槽位会被驱逐机制跳过，因此当一轮中不同的缓存未命中数超过 `cap - npin` 时，引擎会回收一个仍在使用中的槽位，验证保护程序随即调用 exit(1)。

临时解决方法：
1. 在提供服务时设置 `PIN_N=0`（或 `PIN=off`）以禁用 expert pins。
2. 或者，将 `PIN_N` 设置为较小的值，或增大 `--cap` 以扩大余量。

永久修复：已通过 PR #2145 在 `dev` 分支上修复（在 v2.0.0 之后）。被固定的槽位不再计入一轮可回收的槽位。请更新到下一个版本——应用此修复后无需再设置 `PIN_N=0`。

Question 2

为什么应用在 Apple M6 上只使用 2 个 OpenMP 线程，以及如何修复 CPU 推理缓慢的问题？

Accepted Answer

在 Apple M6 上,线程数量计算代码会读取 `hw.perflevel0.logicalcpu`,而在 M6 的三层 CPU 架构中,该项仅包含 2 个 'Super' 核心,因此实际只能使用 12 个线程中的 2 个。临时解决方案:在启动前显式设置 `OMP_NUM_THREADS=6`(2 个 Super 核心 + 4 个 Performance 核心),例如 `OMP_NUM_THREADS=6 ./c/coli run --model <model> ...`。这可以将 CPU 解码速度提升一倍,并将 prefill 时间缩短约 3 倍。永久修复:`dev` 分支(v2.0.0 之后)上的 PR #2199 会在 `resource_plan.py` 和 `omp_tune.h` 中对除最后一层(Efficiency 层)以外所有层级的 `hw.perflevelN.logicalcpu` 求和,在 M6 上返回 6,同时保持 M1–M4 的行为不变;该修复将随下一个版本发布。

Question 3

如何修复 colibri v2.0.0 在共享内存小于 64 KiB 的 GPU(如 Quadro P2000)上出现的 Vulkan 'device lost' 崩溃问题?

Accepted Answer

原因：chain_gemv2 着色器声明了 64 KiB（65,536 字节）的共享内存，但 v2.0.0 从未检查 maxComputeSharedMemorySize。共享内存上限为 48 KiB 的 GPU（例如 NVIDIA Quadro P2000，Pascal 架构）会在第一次推理请求时丢失设备。临时解决方法：在启动前设置环境变量 COLI_VK_CHAIN_GEMV2=0 以禁用 gemv2（Windows：set COLI_VK_CHAIN_GEMV2=0）。这样会回退到 chain_gemv.comp，它可以容纳在 48 KiB 以内。永久修复：dev 分支中的 PR #2027 会根据 maxComputeSharedMemorySize 来确定 chain_gemv2 共享缓冲区的大小，并在创建管线之前对照设备限制验证所有超过 32 KiB 的着色器；该修复将随 v2.0.0 之后的版本一起发布。从 dev 分支构建/运行也可以解决此问题。

Question 4

如何修复在 int4 模型上使用 --auto-tier 搭配 CUDA 时发生的 colibri OOM 崩溃（SIGKILL exit 137）？

Accepted Answer

在 colibri v2.0.0 上，`--auto-tier --gpu auto` 会设置 cap=256（完全驻留 RAM），但 CUDA 层会为每个专家槽位同时保留一个 int8 解包副本和打包的 int4 副本（约 4.5 MB/专家），导致一个 23 GB 的 int4 gs64 模型需要约 69 GB RAM——从而在 warmstart 期间触发 OOM killer。

**永久修复：** 升级到 v2.0.0 之后包含 PR #2098（commit 03429265+）的 dev 构建版本。该版本移除了 int4 group-64 容器的双副本路径，在 CUDA 专家层处于激活状态时让 planar int4 保留在 RAM 中，使 `--auto-tier` 能够在 RAM 容量内运行。在日志中验证：`[qwen36] expert kernel: planar int4 in RAM`。

**v2.0.0 上的临时解决方案：**
1. 设置 `QT_NO_WARMSTART=1`——跳过批量加载；专家按需惰性加载。可行，但冷启动较慢（首次请求约 1.3 tok/s，预热后约 10 tok/s）。
2. 改用 Vulkan 后端：使用 `COLI_VULKAN=1` 且不指定 `--gpu`——将 int4 保留在 RAM 中，并将 int4 专家上传至 VRAM（每个 1.7 MB，而非 3 MB，可多容纳 4 倍）。不会发生 OOM，预热后约 11.6 tok/s。在 RAM 受限的机器上是更好的选择。

Question 5

为什么在为 DeepSeek V4 提供服务时，尽管设置了 --ram 限制，Vulkan 后端仍会被 OOM-killed？如何修复？

Accepted Answer

原因：在启用 upload imports 的情况下（COLI_VK_UP_IMPORT=1，为默认值），上传器使用 posix_memalign 加 memset 为每个层级张量的主机镜像分配内存。这些大型对齐分配堆积在 glibc 的 malloc arenas 中，在计划内存之上额外增加了约 5 GiB 的匿名 RSS（例如，实际为 45.3-45.6 GiB 而计划为 39.61 GiB），因此当默认主机池在启动时根据 MemAvailable 确定大小时，内核会 OOM 杀掉服务器。修复：更新到包含 PR #2402 的构建版本（已通过 #2412 合并到 dev，commit c1c06ac6），该版本将主机镜像分配切换为 calloc，并且只导入镜像自身的页面，使 RSS 恢复到与计划一致的水平。旧版本上的变通方法：1) 缩小层级主机池，例如 `COLI_VK_TIER_HOST_GB=12`（任务可以完成，但 MemAvailable 仍可能降至 1 GiB 以下）；2) 使用 `COLI_VK_UP_IMPORT=0` 禁用 upload imports；3) 使用 `GLIBC_TUNABLES=glibc.malloc.mmap_threshold=4194304` 强制每个镜像使用独立的 mmap（可使 RSS 保持在计划值附近，但会使上传和解码变慢）。

colibri

核心功能

避坑指南

适用场景

标签

快速上手

相似推荐