Question 1

Inklingエンジンのクラッシュ "cache served expert X for requested expert Y" (exit status 1) を修正する方法は？

Accepted Answer

このクラッシュは、エキスパートピンが有効な状態（`.coli_usage`履歴ファイルから読み込まれた状態）で、プリフィル中に発生します。ピン留めされたスロットはevictionの対象からスキップされるため、あるラウンドの個別のキャッシュミスが`cap - npin`を超えると、エンジンはまだ使用中のスロットを再利用し、検証ガードがexit(1)を呼び出します。

回避策：
1. サーブ時に`PIN_N=0`（または`PIN=off`）を設定して、エキスパートピンを無効にしてください。
2. あるいは、`PIN_N`に小さい値を設定するか、`--cap`を増やして余裕を広げてください。

恒久修正：`dev`ブランチでPR #2145により修正されました（v2.0.0以降）。ピン留めされたスロットは、ラウンドが再利用可能なスロットとしてカウントされなくなりました。次のリリースに更新してください。この修正により`PIN_N=0`は不要です。

Question 2

アプリがApple M6でOpenMPスレッドを2つしか使用しないのはなぜですか？また、CPU推論が遅い問題を解決するにはどうすればよいですか？

Accepted Answer

Apple M6では、スレッド数を決定するコードが`hw.perflevel0.logicalcpu`を読み取りますが、M6の3ティアCPUではこれに2つの「Super」コアしか含まれないため、12スレッド中2スレッドしか使われません。回避策：起動前に`OMP_NUM_THREADS=6`を明示的に設定してください（Super 2 + Performance 4）。例：`OMP_NUM_THREADS=6 ./c/coli run --model <model> ...`。これによりCPUデコード速度が2倍になり、プリフィル時間が約1/3に短縮されます。恒久的な修正：`dev`ブランチ（v2.0.0以降）のPR #2199は、`resource_plan.py`と`omp_tune.h`の両方において、最後の（Efficiency）ティアを除くすべてのティアの`hw.perflevelN.logicalcpu`を合計し、M1–M4の動作を変更せずにM6では6を返します。この修正は次のリリースで提供されます。

Question 3

共有メモリが64 KiB未満のGPU(例: Quadro P2000)で発生するcolibri v2.0.0の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`）。これにより、48 KiBに収まる`chain_gemv.comp`にフォールバックします。恒久的な修正：devブランチのPR #2027では、chain_gemv2の共有バッファのサイズを`maxComputeSharedMemorySize`から決定し、32 KiBを超えるすべてのシェーダーをパイプライン作成前にデバイスの制限に対して検証します。この修正はv2.0.0の次のリリースで提供されます。devからビルド/実行することでも解決します。

Question 4

int4 モデルで CUDA と --auto-tier を使用した際に発生する 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 が必要になり、ウォームスタート中に OOM killer が発動します。

**恒久的な修正:** PR #2098（コミット 03429265 以降）を含む、v2.0.0 より後の 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 バックエンドを使用する: `--gpu` を付けずに `COLI_VULKAN=1` を指定 — int4 を RAM に保持したまま int4 エキスパートを VRAM にアップロードします（それぞれ 1.7 MB vs 3 MB、4 倍多く収容可能）。OOM は発生せず、ウォーム時で約 11.6 tok/s。RAM が限られたマシンではこちらがより良い選択肢です。

Question 5

DeepSeek V4をサービングする際に、--ram制限を設定しているにもかかわらずVulkanバックエンドがOOMキルされるのはなぜですか？また、どうすれば修正できますか？

Accepted Answer

原因: アップロードインポートが有効な場合(COLI_VK_UP_IMPORT=1、デフォルト)、アップローダーは各ティアテンソルのホストイメージをposix_memalignとmemsetで割り当てます。これらの大きなアライン済みアロケーションがglibcのmallocアリーナに蓄積され、計画メモリに加えて約5 GiBの匿名RSSが追加されます(例: 実測45.3-45.6 GiB vs 計画39.61 GiB)。そのため、起動時にMemAvailableからサイズが決定されるデフォルトのホストプールでは、カーネルがサーバーをOOMキルします。修正: PR #2402(#2412経由でdevにマージ済み、コミットc1c06ac6)を含むビルドに更新してください。これによりホストイメージのアロケーションがcallocに切り替わり、イメージ自身のページのみがインポートされるため、RSSが計画通りの水準に戻ります。古いビルドでの回避策: 1) ティアホストプールを縮小する、例えば `COLI_VK_TIER_HOST_GB=12`(実行は完了するものの、MemAvailableが1 GiBを下回る可能性は残る); 2) `COLI_VK_UP_IMPORT=0` でアップロードインポートを無効にする; 3) `GLIBC_TUNABLES=glibc.malloc.mmap_threshold=4194304` で各イメージを独自のmmapに強制する(RSSは計画近くに保てるが、アップロードとデコードが遅くなる)。

colibri

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト