RAM 64GBのノートPCで754B級AI「GLM-5.2」をローカルで動かしてみた

みなさん、こんにちは。フルエレです！

突然ですが、みなさん。「自分のノートPCで、大規模なローカルLLMを動かしてみたいなぁ」って思ったこと、ありませんか？

僕はあります。だって、誰しも自分専用の巨大なマシンや巨大なAIに憧れるじゃないですかッ！

一般的に、7540億パラメータ（754B）級の超巨大AIモデルを動かすには、数百万円するAI専用サーバーや、大容量メモリを積んだ特殊なマシンが必要です。個人のノートPC（RAM 64GB）で動かすなんて、少なくとも実用性を考えれば「無理でしょ」と言いたくなるような領域です。

(テロリン…！)そんななか電流が走ったんですね。

「無理って言われてるけど…Fable5が復活したし、なんとかやれば実は動かせるのでは？」となったわけです。(その当時)

というわけで今回は、RAM 64GBの個人用ノートPCの上で、7540億パラメータ（754B）の超巨大AIモデル「GLM-5.2」を力技で動かし、その内部構造を解剖し、6日間かけて物理の限界に挑んだ泥臭い全記録をお届けします！

1.マシン環境と「201.82GiB vs 64GB」の壁

まず、今回検証に使用したノートPCのスペックがこちらです。

• 機種：Lenovo Legion Pro

• CPU：Intel Core i9-13900HX

• GPU：NVIDIA GeForce RTX 4060 Laptop GPU（VRAM 8GB）

• RAM：64GB DDR5-5200

• ストレージ：1TB Gen4 NVMe SSD

普通のPCよりもスペックは高いです。あと、今回はGPUさんの出番はほぼ無いので、どのみち関係があるのはCPUとSSD、RAMくらいです。

そして、対するモデルは、Z.ai社が開発した 「GLM-5.2」。
総パラメータ数は驚異の 約754B（7540億）で極めて巨大なモデルです。

今回使用したのは、重みを平均約1.5bit相当まで削減した UD-IQ1_S という量子化モデルで、ファイルサイズは llama-bench 表示で201.82GiB（約217GB） あります。

と、ここでさっそくなんですが…「64GBのメモリ（RAM）に、217GBのモデルが入るわけがない」という初歩的な物理法則にぶち当たるわけなんですよね。

普通ならここで諦めるんですが、僕はこの程度では諦めません。
「メモリに入り切らないなら、SSD（NVMe）から必要な部分だけリアルタイムに流し込みながら計算させればいいじゃない！」

そこで今回は、llama.cpp の mmap機能とOSのページング／ファイルキャッシュを利用し、重みデータをNVMe上に残したまま、推論時に必要となったページを読み込ませながら動かす力技で挑むことにしました！

2.初点火：754Bが最初に語った言葉

217GBのモデルファイルをながーい時間をかけてダウンロードし、環境を整えていざ初点火！

タスクマネージャーを開くと、メモリ使用率は一瞬で 100%（63.5GB / 63.7GB、空き容量わずか230MB）に張り付き、ストレージアクセスも全開駆動。

ちなみに、実測の生成速度は 約0.3 tok/sでした。単純計算で1トークン生成するのに約3.3秒。日本語では1トークンが1文字や短い単語になることもあり、体感としては数秒ごとに少しずつ文章が表示される速度です。
（カタツムリくらい遅い…）

実行中に観測したNVMeの読み込み速度は約41MB/s前後になる場面が確認されました。SSDの公称シーケンシャル性能（7000MB/s級）とは大きな差がありますが、今回の処理では巨大なファイルを単純に連続して読むのではなく、必要なページへ細かくアクセスしていたと考えられます。そのため、CPUの計算能力だけでなく、ページングを含むストレージアクセスが強く影響していると判断しました。

思考モードをオフにし、「日本の個人開発者のノートPCの上で動いています。一言どうぞ」と入力したところ、初回の応答として返ってきた文章がこちらです。

※出力トークン上限に達したため、文章は途中で切れています。

……思わずグッときてしまいました😭

別の試行では、画面に表示された推論テキストを確認すると、「日本の個人開発者の創作活動を全力でサポートしたい」と推敲している様子も見られました。
（なんだよ！可愛いいいすぎだろ！！！いい子すぎだろ！！！）

もちろん、これはモデルがプロンプトに応じて生成した文章です。それでも、6日間にわたる検証の中で、この言葉が返ってきた瞬間は、僕にとって忘れられない出来事になりました。

1トークンに数秒。それでも、このノートPCの上で巨大なモデルが目を覚まし、言葉を紡ぎ始めたわけです。すごすぎィィィィー！！

3.内部を観測して見えた「MoE構造」の挙動

単に動かすだけじゃ面白くないので、llama.cpp のデバッグ機構を応用した自作の観測ツール（C++）を組み込み、このモデルの内部挙動を観測してみました！

公式設定によると、GLM-5.2の本体は78層で、最初の3層がDense層、残る75層がMoE（Mixture of Experts）層です。各MoE層には256個のルーテッド・エキスパートが存在し、トークンごとに8個が選択されます。単純計算では、75層×256個＝19,200個のエキスパート枠が存在するわけです。

ただし、モデル全体で実際に使われるパラメータはエキスパート部分だけではありません。Attentionや共有エキスパートなども含め、公開資料では約40Bパラメータがアクティブになるとされています。

この内部データを観測した結果、いくつかの面白い挙動が見えてきました！

① プロンプト処理より生成が速い「逆転現象」

通常の小型モデルでは、入力テキストを一括処理する「プロンプト処理（pp）」が速く、1トークンずつ出す「生成（tg）」が遅くなります。 しかし、今回の環境ではプロンプト処理が 0.20 tok/s、生成が 0.43 tok/s となり、通常とは逆の結果になりました。

原因としては、複数トークンをまとめて処理する際に必要となるエキスパートの集合が広がり、ストレージから読み込むページが増えた可能性があります。僕は便宜的に、とりあえずこの現象を「I/O律速なMoEの指紋」と呼ぶことにしました。適当です。（適当なんかい！）

② 呼び出し頻度と予測性能の関係（小型MoEでの検証）

小型MoEモデルを使い、各層で選択できるエキスパートを人気上位だけに制限する「仮想リストラ実験」を行いました。実際に重みを削除したのではなく、ルーターの出力をマスクする方式です。

独自の日本語評価データ15件で測定したところ、人気上位64エキスパート（人員にたとえるなら64人）まで許可した場合、Perplexity（次トークン予測の難しさを表す指標）の悪化は2.8％に収まりました。一方、上位32人だけに制限すると、Perplexityは81.5％増加しました。

これは「生成品質が81.5％低下した」という意味ではありません。ただ、モデルの予測性能が急激に悪化したことを示しています。

滅多に呼ばれないエキスパートは、暇な窓際族ではなく、出番は少ないけど代替できない専門医なのかもしれません笑

③ 「似たエキスパートをまとめる」アプローチの検証

次に、似たエキスパート同士で共通部分を持たせ、「共通の基底＋差分」のような形での保存を検討しました。

そこで小型MoEモデルの代表的な5層を対象に、エキスパート間の重みのコサイン類似度などを測定しました。しかし、平均的な類似度はほぼゼロで、今回設定した乱数基準と大きな差がありませんでした。

この結果から、少なくとも今回のモデルでは、エキスパートを「似た重みの集まり」とみなして単純に共通化する方法は難しいと判断しました。ただし、これはあらゆる圧縮が不可能だと証明したわけではなく、再学習や蒸留など別の方法には可能性が残されているというわけです。

4.速度向上への試行錯誤と観測結果

速度比較では、特に記載がない限り、同じGGUFを使用し、llama-benchでプロンプト32トークン・生成32トークンを処理する条件を基準としました。スレッド数など、変更した項目以外はできる限り同じ条件に揃えています。なお、探索を目的とした少数回の測定を含むため、以下の数値は厳密な統計的ベンチマークではなく、手元環境での傾向を示すものです。

どうにかして処理速度を向上させられないか、さまざまな構成を試して検証を行いました！

• スレッド数調整（8 / 16 / 24 / 32）：16〜24スレッド付近が最も速く、32スレッドでは逆に低下しました。ハイブリッドCPUでは、単純に全スレッドを使えば速くなるとは限らないようです。（※なお、小型MoEのGemma 4では8スレッドが最速でした）

• GPUへのオフロード（常勤パーツをVRAMへ）：この測定では、GPUオフロードによって生成速度が0.43 tok/sから0.30 tok/sへ低下しました。今回の配置では、CPU・GPU間のデータ転送や処理分割のオーバーヘッドが、GPUによる計算高速化の利益を上回ったと言ったところでしょうか。

• キャッシュ温め（人気エキスパートの先読み）：0.38 tok/s と改善せず。分析上は、キャッシュミスしたエキスパートの読み込み量が1トークンあたり約1.8GBに達する可能性があり、キャッシュの競合や追加のストレージアクセスが影響したのかもしれません。

• 物理メモリの施錠（VirtualLock）：この測定では、プロンプト処理が0.20 tok/sから0.27 tok/sへ向上した一方、生成速度はほぼ横ばいでした。

僕が「物理平衡点」と呼んでいた 0.41〜0.45 tok/s の帯域から大きく数値を伸ばすことは難しく、今回の構成とソフトウェアで観測された実効的な壁だと感じました。

ですが、別々のアプローチにより、2つの部分的な改善を達成できました！

改善①：プロンプト処理の高速化（ik_llama.cpp）

CPUおよびMoE処理の最適化が行われているフォーク版 ik_llama.cpp を使用したところ、プロンプト処理速度が 0.20 → 1.04 tok/s（約5.2倍） に向上しました。

改善②：生成速度の改善（投機デコード）

本家 llama.cpp の投機デコード機能（--spec-type ngram-mod：過去の文脈に現れたn-gramパターンから複数トークンの候補を作り、本体モデルでまとめて検証する手法）を適用。

これにより、生成速度は 0.43 → 0.50 tok/s へと向上！

※なお、ngram-mod の数値は対話実行（llama-cli）時に観測したものであり、llama-bench によるバッチ測定値とは実行条件が異なります。そのため、厳密な直接比較ではなく、同条件プロンプトでの相対的な変化の参考値として掲載しています。

5.まとめ：検証が教えてくれたこと

生成速度 0.50 tok/s。 正直に言えば、これは日常的に会話を楽しむための「実用」の速度ではないでしょう。

しかし、巨大なモデルが自分のPCでどんな形であれ、「動いた」という事実、それだけで十分。それが「ロマン」ってやつです。

実際にこうして動いてGLM-5.2がしゃべってくれたことはとても嬉しかったです。

推奨環境に遠く及ばないノートPCの上でモデルが返してくれた言葉や、内部の挙動を観察するプロセス、僕にとって最高の体験になりました。

やっぱり、技術の限界に挑む検証は楽しいィィィィー！！！！

というわけで、ここまでお読みいただきありがとうございました！ もし面白かったら、スキやX（@fluele_alpha）のフォローをぜひよろしくお願いします！前回の記事もぜひ読んでいってね！

↓前回の記事

最高で理想のAIパートナー環境を、これからも作っていきます！

フルエレ（@fluele_alpha）さん / X