「35B級モデルが3GBで動く」と聞くと、8GBメモリのMacでも余裕で使えるように感じます。
しかし、Edge0-35B-A3Bの公式情報を読むと、この理解は正確ではありません。
Edge0が公表している約2.9GiBは、Mac全体の必要メモリではなく、短いコンテキスト条件で測ったピークアクティブメモリです。
モデル本体は4bit量子化されていても約23GBあり、SSD上に置かれた専門家重みを必要なときだけ読み込む設計によって、推論中に常駐させる量を小さくしています。
つまり、注目すべきなのは「35Bを3GBに圧縮した」ことではありません。
従来はRAMやVRAMへ載せていた重みの一部をストレージ側へ逃がし、MoEの疎性を利用して必要な専門家だけを動かす実行方式にあります。
この仕組みは、Apple SiliconでローカルLLMを試したい人にとって興味深い一方、SSD速度、KVキャッシュ、OSの使用メモリ、モデル品質といった別の制約を増やします。
ここでは公式の数値と未確認事項を分けながら、手元のMacで試す意味があるかを判断できるところまで整理します。
Edge0-35B-A3B-previewは、Qwen3.6-35B-A3Bをベースにした35B級のスパースMoEモデルです。
40層、256のルーティング専門家を持ち、1トークンあたり4つの専門家を使うK=4構成になっています。
量子化は4bitで、Edge0独自のprerouterとRecover-LoRAを組み合わせています。
一般的な「35Bモデル」という表現だけを見ると、35B分の重みをすべて推論時に高速メモリへ置く必要があるように見えます。
しかしMoEでは、各トークンで全専門家を実行するわけではありません。
Edge0はこの特徴をさらに押し進め、使わない専門家の重みをSSD側に残し、実行対象になったものだけを読み込む構成を採っています。
公式READMEでは、35B版の4bitチェックポイントを約23GBとしています。
Hugging Faceのファイル表示ではモデルサイズとして19.6GBと見える箇所もありますが、実際に取得する配布物にはベースの量子化重みに加えてLoRAやprerouterなどが含まれます。
そのため、記事内では「保存領域として約23GBを見込む」と考える方が安全です。
ここで区別したいのは、保存容量と推論中のアクティブメモリです。
SSDに23GB前後のファイルがあっても、その全量を同時にユニファイドメモリへ載せる必要がない。
それがEdge0の設計上の狙いです。
Edge0の中核は、SSD expert offloadです。
専門家の重みをsafetensorsとしてSSD上に置き、mmapを使って必要な範囲を遅延読み込みします。
さらにLRUキャッシュ、プリフェッチ、固定スロットを組み合わせ、毎ステップ大量のデータ転送が発生しないようにしています。
MoEでは次に使う専門家を予測できれば、計算と並行して重みを先読みできます。
Edge0のprerouterは、そのための予測ヘッドです。
公式モデルカードでは、prerouterによってストレージ待ちを重ね合わせ、デコード性能を改善する設計だと説明されています。
この方式で小さくなるのは「その瞬間に実行へ必要な重みの量」です。
OS、Python、MLX、tokenizer、アプリ側のバッファまで2.9GiBに含まれるわけではありません。
また、入力が長くなるほどKVキャッシュは増えます。
したがって「3GBメモリの端末で35Bが動く」と読み替えるのは危険です。
公式自身も、2.9GiBはshort contextsでの値で、OSやtokenizer、長文時のKV growthに余裕を残すよう明記しています。
以下の表は、混同しやすい数字を分けたものです。
本文で同じ数値を繰り返すのではなく、何を表す数字なのかを確認するために使ってください。
一般的なローカルLLMでは、量子化した重みをRAMやVRAMへできるだけ載せ、そこから高速に計算します。
メモリに収まるかどうかが最初の大きな壁になるため、「VRAM 8GBならこのモデル」「24GBならこの量子化」といった選び方が広まりました。
Edge0は、その前提を変えます。
重みの全部を常駐させず、必要な専門家だけをストレージから供給するため、メモリ容量の壁を低くできます。
その代わり、ストレージI/Oが性能要因に入ります。
この差は、GPUのVRAM不足をCPU RAMへ逃がす一般的なオフロードとも少し違います。
Edge0ではMoEの専門家単位でSSDへ置き、ルーティング予測を使ってロード待ちを隠すことが設計の中心です。
一方で、SSDはユニファイドメモリより遅いため、どんな条件でも有利になるわけではありません。
モデルが十分小さく、全重みが余裕でメモリに収まる環境なら、常駐させた方が単純で速い場合があります。
Edge0が効いてくるのは「モデルの総サイズは大きいが、各トークンで使う専門家は限られる」というMoEの特徴を活かせる場面です。
Edge0公式ベンチマークでは：
・Mac mini M4 Pro・24GBで35B版を測定
・デコード14.9〜17.7 tok/s
・約3,300トークンのプロンプトでプリフィル113 tok/s（cold）・140 tok/s（warm）
・ピークアクティブメモリ2.9GiBとしています。
対話用途で15 tok/s前後なら、文字が出てくるのを待ち続ける感覚は比較的小さく、ローカル推論としては実用圏に入る場面があります。
ただし、この数字はM4 Pro・24GBでの公式測定です。
M1、M2、M3の無印モデルや、8GB・16GB構成で同じ速度が出るとは言えません。
coldとwarmの差も重要です。
最初のリクエストではSSDから専門家重みがページキャッシュへ入るため、後続リクエストより条件が悪くなります。
ストレージ帯域やキャッシュ状態によって、体感は変わり得ます。
また、公式ベンチマークはモデル提供者自身による測定です。
再現用スクリプトが公開されている点は検証しやすい一方、異なるMacや外付けSSDを含む独立検証は別に必要です。
現時点で公式に示されている35B版のベンチマーク機は24GBのM4 Proです。
8GBや16GBのMacについて、公式の速度・長文安定性・同時利用時のメモリ圧迫を示す十分なデータは確認できません。
そのため、容量別に「動く・動かない」と断定するより、次の条件で考える方が現実的です。
8GB構成では、2.9GiBというアクティブメモリ値だけを根拠に余裕があるとは判断できません。
macOSや他アプリが同じユニファイドメモリを使い、長文ではKVキャッシュも増えます。
動作確認が取れたとしても、ブラウザや動画編集などを同時に使う環境では圧迫が起きる可能性があります。
16GB構成は試しやすくなるものの、公式ベンチマーク外です。
短い会話と長文処理では必要量が違うため、想定するコンテキスト長で確認する必要があります。
24GB構成は、少なくとも公式のM4 Proベンチマークに近い条件を作りやすい容量です。
ただしM4 Proと無印M4ではCPU/GPU性能やメモリ帯域が異なるため、「24GBなら公式速度が出る」とは限りません。
Macを新規購入する判断では、Edge0ひとつだけを基準にせず、他のローカルLLM、画像生成、動画編集、通常業務との同時利用まで考えるべきです。
最初の注意点はKVキャッシュです。
Transformer系モデルは、コンテキストが伸びるほど過去トークンの情報を保持するメモリが増えます。
Edge0の2.9GiBは短文脈の測定値なので、数万トークンを扱う用途では別のメモリ余裕が必要です。
次にSSDです。専門家重みをオンデマンドで読む以上、ストレージ速度は推論性能へ影響します。
公式はMac mini M4 Pro環境で速度を示していますが、内蔵SSDと各種外付けSSDの差を網羅した公式比較は確認できません。
外付けSSDを使う場合は、インターフェース、ケース、実効帯域まで含めて見る必要があります。
SSD消耗についても、現時点の公式資料だけで「問題ない」「寿命が大きく縮む」と断定できる情報はありません。
読み込み中心のワークロードである点は踏まえつつ、利用頻度とストレージの状態を確認するのが安全です。
品質面では、公式がOpenCompassでfp16ベースと比較しており、35B版は5指標平均で79.2、fp16ベースは83.2と報告しています。
差は平均3.9ポイントです。AIME 2026、HumanEval、GPQA-Diamondなど個別指標でも差があるため、「同じ35Bだから品質も同じ」と考えない方がよいでしょう。
一方でMMLU-ProはEdge0版81.0、fp16ベース84.6です。
実利用では、自分の用途に近い日本語指示、コード、長文要約などで確認する必要があります。
現行のEdge0はMLXバックエンドを使い、対応ハードウェアとしてApple SiliconのM1/M2/M3/M4を挙げています。
CUDAバックエンドはロードマップ上で、Windows/NVIDIAを同じ手順で使える状態ではありません。
Pythonは3.10以上、公式READMEでは3.12推奨です。
MLXについても指定バージョンがあり、READMEはmlx 0.30.6、mlx-metal 0.30.6、mlx-lm 0.31.0を案内しています。
公開直前にはバージョンが更新されていないか確認してください。
また、LM Studioで一般的なGGUFモデルをクリックして動かす体験とは異なります。
公式の基本手順はEdge0のCLIと専用チェックポイントを使う方法です。
LM Studio対応を前提に記事化する場合は、その時点の正式対応を別途確認する必要があります。
初回は短いプロンプトから始め、アクティビティモニタでメモリ圧力を確認し、その後に普段使う長さへ伸ばすと挙動を把握しやすくなります。
ベンチマーク値よりも、自分のワークロードで安定するかを優先してください。
Edge0-35B-A3Bが向きやすいのは、Apple Silicon上で大きめのMoEをローカル実行したいものの、全重みを常駐させるメモリを用意したくないケースです。
ローカル処理によるプライバシー、オフライン利用、推論コストの固定化を重視する人にとって、検証する価値があります。
逆に、長いコンテキストを常用する人、安定した高スループットを最優先する人、Windows/NVIDIA環境で使いたい人には、現時点のプレビュー版は条件が合わない可能性があります。
また、エージェント用途について、公式モデルカードはこのプレビューをtool useや長期的な自律タスクへ最適化した版ではないとしています。
ローカルの大型モデルだからといって、業務エージェント用途まで強いとは限りません。
試す価値を判断するときは、「35Bが3GB」というキャッチコピーではなく、保存容量、短文時のアクティブメモリ、長文時のKVキャッシュ、SSD I/O、品質差の5点を分けて考えると誤解が減ります。
Edge0-35B-A3Bの面白さは、35B級モデルを3GBへ縮めたことではなく、MoEの専門家重みをSSDから必要時に読み込み、推論中に常駐させる重みを小さくした点にあります。
公式値の2.9GiBはその効果を示す数字ですが、Mac全体の必要メモリではありません。
現時点で信頼できる基準は、Mac mini M4 Pro・24GBで14.9〜17.7 tok/sという公式実測です。
8GB・16GB Macについては、公式データなしに実用性まで一般化すべきではありません。
ローカルLLM選びでは、モデル名のパラメータ数だけでなく「重みをどこに置き、何をいつ読み込むのか」が性能を左右します。
試すなら、まず短文でメモリ圧力と速度を確認し、自分が本当に使う長さと作業内容まで広げて判断するのが現実的です。
.png){kind=logo}
