Kache：二つ目の worktree で、CPU と disk をもう一度燃やさず最初の build を再利用する
branch を切り替え、二つ目の worktree を開き、CI で同じ dependency をもう一度走らせる。結果はたいてい同じだ。compiler が既に計算したものを、もう一度計算する。target/ や build directory は disk を使う一方、path、working directory、job が違うため共有しにくい。cache tool は多いが、日常で効くのは「hit rate があるか」だけではない。二つ目の worktree にどれだけ data が増えるのか、miss を説明できるか、既存 build を黙って変えないか、が重要になる。
今日見る kunobi-ninja/kache は、Rust、C/C++、CUDA 向けの compiler cache だ。compiler invocation ごとに input content から key を作り、output を local の content-addressed store に置く。対応 filesystem では copy-on-write clone で restore する。同じ byte は一度だけ保持され、同じ machine で同じ key に到達した concurrent build は一回の compile に合流する。machine をまたぐ必要が出た時だけ、S3-compatible または filesystem remote を選べる。
GitHub repository、README、LICENSE、main の最新 commit、Releases を 2026-09-20 18:02 Asia/Shanghai 時点で確認すると、kunobi-ninja/kache は 899 stars、49 forks。主要 language は Rust、license は Apache-2.0。repository は 2026-02-15 19:43:57 UTC に作成された。main の最新 HEAD は a980a3b、latest push/commit は 2026-09-20 09:56:34 UTC で、daemon shutdown 時の prefetch summary の完全性と lock release を扱う。最新 GitHub Release は v0.26.0、published at は 2026-09-19 17:59:56 UTC。まだ速く進化している project なので、team での導入はまず release を固定し、自分たちの project で hit rate と disk behavior を測りたい。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | kunobi-ninja/kache |
| 位置づけ | Rust、C/C++、CUDA 向け content-addressed compiler cache |
| Stars / Forks | 899 / 49 |
| 主要 language | Rust |
| ライセンス | Apache-2.0 |
| 作成日 | 2026-02-15 19:43:57 UTC |
| Latest push / main HEAD | 2026-09-20 09:56:34 UTC / a980a3b |
| 最新 Release | v0.26.0、2026-09-19 17:59:56 UTC |
| remote cache | optional の S3-compatible（AWS S3、MinIO、Cloudflare R2 を含む）または filesystem remote |
解いているのは worktree の重複作業
README の中心となる design は単純だ。wrapper が rustc、cc、c++、nvcc の invocation を解析し、output に影響する input を hash し、machine-local な path を normalize する。そのため、同じ revision の二つの worktree は同じ key を作れる。restore 時は compiler をもう一度走らせず、cache 済み output を新しい directory に戻す。
これは Rust repository で issue、review、実験 branch を並行して扱う時に特に合う。各 worktree は自分の target directory を保てるので、互いに壊しやすい shared directory に頼って speed を得る必要がない。Kache は hit、miss、passthrough を unit ごとに記録し、kache why-miss <crate> はある unit が再利用されなかった理由を説明する。ぼんやりした percentage だけより、feature、environment variable、build script、compiler argument のどれが cache を崩したかを調べやすい。
Cargo だけを包むものでもない。C と C++ は compiler-name shims を通して Make、CMake、autotools、Arch PKGBUILD に入れられる。CUDA は single-source の nvcc -c と -dc を support する。README の support scope も明確だ。Rust library と build script は supported、Rust executable は Linux/macOS で supported で Windows では default で disabled。不対応または unsafe な invocation は、誤った output を無理に再利用せず passthrough する。
まず config change を見えるものにする
最小の Rust path は次の通りだ。
cargo install kache
kache init --check # 書き込む Cargo config を先に preview
kache initkache init は Cargo の rustc-wrapper を設定する。Unix では build-script 用 C/C++ environment の key も追加する。README によれば kache init --no-service で OS service を飛ばせ、kache doctor で installation state を確認できる。この preview は大切だ。build cache は global または user-level config に触れがちなので、「入れたら全 project が wrapper を通っていた」となる前に diff を見たほうが安全だ。
remote sharing も default で有効にすべきではない。local cache の有効性を確認してから、team は S3-compatible bucket を設定するか filesystem remote で CI volume を再利用できる。remote credential は standard AWS environment variable または credential chain を使う。bucket の access scope、retention、build output に sensitive information が入り得るかは、team の supply-chain policy に沿って先に review したい。
すべての cache を置き換える魔法の switch ではない
Kache の zero-copy experience は filesystem が copy-on-write clone を提供することに依存する。そうでない環境では space saving は同じにならない。README にある Firefox/APFS の measurement は、各 machine への約束ではなく method の参考として扱うべきだ。実際の利益は language、compiler、feature matrix、container layer、remote network によって変わる。
cache correctness は hit rate より優先する。project は unsafe invocation を passthrough すると説明しているが、wrapper を導入した後は release branch ではない一つの branch と二、三の worktree から始め、kache report --last-build を見て、KACHE_DISABLED=1 を一回だけの bypass として残したい。CI でも、まず official action を一つの job に入れ、artifact、compile time、remote permission を確認してから、全 pipeline を移すのがよい。
まとめ
kache の面白さは、単に「より速い compiler cache」を作っていることではない。worktree 間の再利用を first-class にしている点だ。input content が key を決め、同じ output は一度だけ保存され、miss には説明があり、remote sharing は optional layer になっている。Rust branch を頻繁に作り、C/C++ や CUDA build も混ざり、繰り返す cold build に困っている team なら、まず preview できる kache init --check を local で走らせ、二つ目の worktree で hit を確かめるほうが、最初から複雑な shared target directory を設計するより価値がありそうだ。