ハクソク

世界を動かす技術を、日本語で。

Show HN: 低速のコンピュータでGLM 5.2を動かす方法

2026年7月9日原文(github.com)

概要

  • Colibrì は、消費者向けPC（約25GB RAM）で GLM-5.2（744BパラメータMoE） を動作させるための純C言語エンジン
  • 専門家（experts）をディスクからストリーミング し、RAM消費を最小限に抑える設計
  • 依存ゼロ・GPU不要・Python不要、実行時はC言語のみで動作
  • int4量子化 でモデル容量とメモリ要件を劇的に削減
  • GLM-5.2の品質・性能を家庭用PCで体験可能 に

Colibrì: 消費者PCで744BパラメータGLM-5.2を動かす革新的エンジン

  • GLM-5.2（744B Mixture-of-Expertsモデル） を、約25GBのRAMで動作可能にするC言語エンジン
  • 約40Bパラメータのみが1トークンごとに活性化、そのうち約11GB分のルーティング専門家のみがトークンごとに変動
  • 密な部分（attention・共有専門家・埋め込み層、約17Bパラメータ）はint4で常駐（約9.9GB）
  • 21,504のルーティング専門家（75 MoE層 × 256専門家 + MTPヘッド、各約19MB）はディスク上に保存（約370GB）し、必要に応じてストリーミング
  • 各層ごとにLRUキャッシュ、オプションのピン留めホットストア、OSページキャッシュをL2キャッシュとして活用
  • エンジン本体は約1,300行の単一Cファイル（c/glm.c）と小規模なヘッダーのみ
  • BLAS不要・Python不要・GPU不要 で実行可能

実装済み機能

  • GLM-5.2（glm_moe_dsa）正確なフォワードパス （transformersによるトークン単位の検証済み）
  • MLA attention （q/kv-LoRA、部分的RoPE）、圧縮KVキャッシュ（1トークンあたり576 float、従来の57分の1）
  • DeepSeek-V3風シグモイドルーター、共有専門家、最初の3つの密層
  • MTP（multi-token-prediction）推測デコーディング 搭載、int8ヘッドで約2.2–2.8トークン/フォワード
  • 温度・nucleusサンプリング （int4に最適化されたデフォルト値）
  • 整数ドット積カーネル（AVX2対応）、int8で1.4–2.5倍、int4で1.8倍高速化
  • MLA重み吸収（DeepSeek技術） でデコード時のk/v再構築不要
  • 非同期専門家プリフェッチ （次ブロックの読み込みを並列実行）
  • int8/int4/int2量子化カーネル、行ごとのスケール、AVX2デコンバート
  • DSAスパースattention は開発中（現在は2048トークンまでdense・正確attention）
  • バッチ単位のMoEユニオン、バッチ内のユニーク専門家は一度だけ読み込んで全ポジションに適用
  • C言語製byte-level BPEトークナイザー （GPT-2スタイル、Unicode対応）
  • RAM安全性 ：起動時にMemAvailableから専門家キャッシュを自動調整、OOM回避
  • FP8→int4オフライン変換ツール （c/convert_fp8_to_int4.py）、シャード単位で変換・削除、HDD容量節約

性能・要件

  • int4モデルのディスク容量：約370GB、常駐RAM 9.9GB、起動約30秒
  • チャット時のピークRSS：約20GB（自動上限）
  • コールドデコード時のディスク読み出し：約11GB/トークン（75層×8専門家）
  • NVMe SSD推奨、ランダムリード1GB/sで約0.05–0.1トークン/秒（コールド時）
  • MTP推測有効化でキャッシュが温まれば2.2–2.8トークン/フォワードに加速
  • RAM容量によって専門家キャッシュ数が自動調整されるため、小RAM環境ではディスクI/Oがボトルネック
  • SSDのウェア注意：ランダムリードが多いため、安価なSSDでは寿命短縮リスクあり。使用時はディスクヘルス監視推奨

モデル・リポジトリ・セットアップ

  • Hugging Faceでint4変換済みGLM-5.2モデル配布 https://huggingface.co/jlnsrk/GLM-5.2-colibri-int4
  • リポジトリダウンロード後、COLI_MODEL環境変数でパス指定し実行
  • 初回セットアップはCディレクトリで./setup.sh実行 gcc/OpenMPチェック・ビルド・自己テスト・モデルダウンロード・変換を一括実行
  • 変換のみ必要な場合はPython環境（torch, safetensors, huggingface_hub, numpy）が必要

実行・チューニングパラメータ

  • --temp T ：サンプリング温度（デフォルト0.7 + nucleus 0.90、0はgreedy）
  • --topp 0.7 ：適応的専門家top-p（ディスクI/O約30–40%削減）
  • --ngen N ：最大出力トークン数
  • AUTOPIN=0 ：自動ピン留めキャッシュ無効化
  • THINK=1 ：GLM-5.2の推論ブロック有効化
  • DRAFT=n ：MTPドラフト深度
  • TF=1 ：teacher-forcing検証

学習キャッシュとパフォーマンス向上

  • エンジンは実際にルーティングされた専門家情報（.coli_usage）を記録
  • 起動時に最も頻繁に使われた専門家を余剰RAMに自動ピン留め、使うほど高速化
  • 高性能マシンでは、より多くの専門家をRAMにキャッシュすることで速度向上可能

ベンチマーク・実測値

  • 24GB RAM・WSL2環境 ：デフォルト0.07 tok/s、--topp 0.7で0.11 tok/s
  • Apple M5 Max（128GB RAM, 内蔵SSD） ：1.06 tok/s（MTPオフ）
  • 小RAM環境ではRAMキャップがボトルネック、ディスクI/O速度よりRAM容量が重要
  • 高RAM・高速SSD環境ではキャッシュヒット率向上で大幅な高速化が期待できる

品質ベンチマークと課題

  • int4量子化による精度低下は未検証 （ベンチマークハーネスは用意済み、実行には高速な環境が必要）
  • 精度測定に協力できる方を募集中 ：コマンド一発で全ベンチマーク実行可能

コミュニティ・サポート

  • Colibrìは個人開発プロジェクト、12コア・25GB RAMノートPCで開発・検証
  • フィードバック・ベンチマーク結果・ハードウェア協力者募集中
  • GitHubリポジトリ ：https://github.com/JustVugg/colibri

ディレクトリ構成

  • c/glm.c ：エンジン本体（GLM-5.2前向き伝播、MoEストリーミング、MTP、サーブモード）
  • c/st.h ：safetensorsリーダー（pread + fadvise、mmap未使用）
  • c/tok.h ：BPEトークナイザー
  • c/coli ：CLI（chat / run / bench / convert / info）
  • c/iobench.c ：ディスクI/Oベンチマーク
  • c/convert_fp8_to_int4.py ：FP8→int4変換ツール
  • c/make_glm_oracle.py ：検証用小型ランダムオラクル生成
  • c/olmoe.c ：OLMoEエンジン（検証用）

Colibrìの由来

  • Colibrì（ハチドリ） は、わずか数グラムで1日に千の花を訪れる
  • 本エンジンも、わずかなRAM（25GB）で744Bパラメータの巨人を動かすことを目指す

体験・フィードバックの呼びかけ

  • GLM-5.2の高い能力と安全性を、ClaudeやGPT並みに感じた体験談
  • 「普通のPCで動かせるのか？」という疑問から開発を開始
  • int4変換・MTP活用・DSA実装・長文コンテキスト対応等、試行錯誤の記録
  • 32GB RAMのPCで、冷却時0.1 tok/sでも十分満足、動作すること自体が重要
  • Colibrìは「動かすこと」にこだわったシンプルかつ徹底検証型プロジェクト
  • 個人開発・家庭用PCでの限界挑戦、誰でも参加・フィードバック歓迎

Colibrìは「手の届くAIフロンティア」を実現するための挑戦的プロジェクトです。どんなマシンでも、巨大モデルの力を身近に感じてみませんか？

Hackerたちの意見

これがハッカーの精神だね。

└

ありがとう、ほんとそうだよ！この精神から始まったんだ！

俺の主な疑問は、実際に使ったときにトークン/秒で測れるのか、それとも1分に1トークンくらいなのかってことだな。ローカルでホストされたLLMが1トークン/秒の遅さでも、何かプロジェクトを任せて一晩放置して、6時間か8時間後にチェックするとすごく役立つことがあるのは見たことある。だけど、URLで報告されてるように、最低クラスのハードウェアで0.05から0.1トークン/秒だと、あんまり使い物にならないよね。編集：全体的なコンセプトとしては素晴らしいプロジェクトだと思うし、350Bから900Bサイズのモデルをローカルで動かせるようになる努力がもっと見られるのを楽しみにしてる。たとえ1トークン/秒でも、普通の人が手に入れられるハードウェアでね。「速い読み取りができるNVME SSDストレージがあって、大きなモデルをローカルディスクに置いて、必要なときに11GB/トークンで読み込む」っていう一般的なコンセプトに沿ったものがあればいいな。

└

READMEには、みんなが異なるハードウェアでColibrìを動かしているベンチマークが見えるけど、素晴らしい結果を見たよ！俺は常に改善に取り組んでる！

すごいね！今週はGLM 5.2で遊んでたけど、同じくらい感心したよ。仕事では、別のプロジェクトを始める前にテストとしてすごく高価なハードウェアでローカルに動かしてるから、普通のマシンでこの大規模なFOSSモデルを動かしてる人たちを見るのは素晴らしいことだね。実用的じゃないかもしれないけど、いい仕事だ！

└

本当にありがとう！！

MoEのことが完全には理解できてないから、もしバカな質問だったらごめんだけど、小さなクラスターでMPIを使って負荷を分散させることは可能なのかな？

└

いい質問だね。理論的には、MPIはノード間でエキスパートを分散できる。実際には、小さなクラスターでは追加のネットワーク遅延が助けるよりも悪影響を及ぼすことが多いんだ。速いインターコネクトを持つ大きなクラスターに向いてる。今のところ、我々はシングルマシンの速度（キャッシング、GPUハイブリッドなど）に焦点を当ててるよ。

実は、これと同じことに取り組んでたんだけど、余分なRAMの使用を避けるために、モデル全体をメモリにmmappingする方向に進んだんだ。それから、ClaudeにモデルにMedusaを実装させて、追加のモデルをメモリに読み込まずにMTPの利点を得ようとしたんだ。今、信号待ち中だから全部は書けないし、君の投稿もまだ全部読めてないんだ。家に帰ってきたばかりだから詳しく説明すると、llama.cppに全ての修正を加えてるところで、最終的には何らかのSBCにこれを載せて、mmappedファイルを扱うためにnvmeを使う予定なんだ。現在のセットアップの理論的な限界は、以前のテストに基づくと約1.8トークン/秒なんだけど、追加のMedusaヘッドが完全にトレーニングされてないから、生成されたトークンをカウントしてるかどうかは正直わからない。結局、私たちの考えは似たようなもので、ただ私はまだllmパーサー/ランナーをゼロから書く方法がわからなくて、メモリに残すべきものを指定する代わりに、Linuxカーネルに任せてるんだ。あ、最後に、llama.cppの使用を32GBのうち16GBに制限してるから、もっと低くすることもできるかもしれない。

└

もしよければ、Colibrìは常に改善が必要だから、アイデアや何かあればプルリクエストや問題提起は大歓迎だよ！ベンチマークもね！

俺も画像/動画生成で似たような戦略を取ったよ。https://github.com/cretz/thinfer（動画ブランチにたくさんの作業があるよ）。基本的に、必要に応じて重みをLRU方式でストリーミングできる推論エンジンが必要だったんだ。だから、--vram-budgetを受け入れて、それを下回るようにするものを作ったんだ（ほとんど）。mmappedされたバイトをVRAMに出し入れするのは、計算に比べてかなり安いことがわかったよ。パイプライン処理やダブルバッファリングと組み合わせると、ほとんどいつも計算がボトルネックになって、メモリがボトルネックになることはないんだ。まぁ、俺はかなり小さいモデルを使ってるけどね、へへ。

└

わお、たくさんのモデル（krea、wan、hunyanなど）をうまく組み込んだね。全てを動かすための共通のハーネスを作れたの？どのモデルがVRAM予算をより一貫して下回るの？

Hacker Newsで議論の続きを見る