2026年9月13日時点で、Edge0はApple Silicon向けのMLXバックエンドとEdge0-35B-A3B-previewモデルを公開しています。私は16GBのM2 MacBook Airでこのモデルを実行し、Microsoft Learnの資料を根拠に回答する技術専門エージェントを構成しました。
この連載では、35Bクラスのモデルを動かす条件、検索資料による回答の変化、韓国語の入出力、ストリーミング性能の計測、社内PoCへ拡張する条件を扱います。実行コード全体はEdge0 Microsoft Technology Expert AgentのGistにまとめています。
第1回ではモデルを実行した経験から説明します。外部の根拠を与えた実験と入力資料を短くした結果を比較し、後続の記事で実装するエージェントの構造を紹介します。
公開状況と計測結果には、次の範囲を適用します。
公開文書は2026年9月13日に確認しました。モデルはプレビュー段階にあり、構成や性能は今後変わる可能性があります。実行時間と回答例は私が行った個別の実験記録であり、すべての機器や質問に共通する性能を示すものではありません。
必要な重みをSSDから読み込む35Bモデル
Edge0のメモリ利用方式から確認します。プロジェクトの説明によると、Edge0は疎なMoEモデルのエキスパート重みをSSDに置き、推論に必要な部分を読み込みます。このため、起動時にモデル全体をRAMへ読み込む構成とはメモリの利用状況が異なります。
公開モデルの仕様と公式の計測値、私の実験環境を項目ごとに分けて示します。
公開モデル：
Edge0-35B-A3B-previewは35BクラスのMoE構造に4ビット量子化を適用しています。モデルファイルのサイズ：SSDに保存するチェックポイントは約23GBを占めます。
公式のメモリ計測値：短いコンテキストで、MLXアロケーターの最大アクティブメモリが約2.9GiBを記録しました。
個人の実験機器：この連載ではM2 MacBook Air 16GBを使用しました。
最初の生成実験：特定の入力と実行条件で、128トークンの生成に約43.8秒かかりました。
公式のメモリ値はシステム全体の使用量を表していません。OS、トークナイザー、キャッシュ、コンテキスト長による追加の使用量も考慮できます。重みの読み込み経路はアーキテクチャ文書が説明しています。
私の機器でもモデルは文章を生成しました。16GBのノートPCで実行できることを確認したうえで、応答速度と回答の正確さは別々に評価しました。
外部の根拠を中心にした回答生成
質問だけを与えるzero-shotの実験では、C# Native AOTとRustのコンパイルモデルを誤って説明する回答がありました。英語の質問でも同様の誤りが繰り返されました。十分な数の質問を用いた品質評価ではないため、この経験だけでモデル全体の性能は判断していません。
そこで、事実知識をモデル自身に任せる範囲を狭めました。自分で回答を評価できる.NET Native AOTとJITの質問を使い、Microsoft LearnのNative AOT文書を一緒に渡しました。
その後のエージェントでは、役割を次のように分けました。図内の表記は韓国語原稿のまま保持しています。
Edge0
질문과 문서의 내용 파악
관련 근거 선택
근거에 따른 답변 생성
외부 시스템과 Python 호스트
공식 문서 검색
입력 자료 구성
대화 상태 관리
한국어 입출력 처리
実験では、モデルが渡された文書を読み、質問に合う回答を構成できるかに焦点を当てました。
根拠の不足を示した回答例
質問だけを渡す方法、Microsoft Learnの資料を加える方法、資料の範囲内で答えるよう強く制限する方法を順に比較しました。この連載では、モデルへ渡す参照資料をグラウンディング資料と呼びます。
資料を与えた後、モデルは発行時のネイティブコード生成とJITの使用有無を説明しました。実行時コード生成や動的読み込みの制限も回答に反映しました。これらの内容はNative AOTデプロイの制限事項と照合しました。
グラウンディング資料に含まれていないCoreCLRのDynamic PGOの詳細を尋ねたところ、次の回答を得ました。
The supplied reference does not provide enough information.
この回答では、利用できる根拠の限界を示しました。一度の回答で毎回同じ動作を保証できるわけではありませんが、後のプロンプトに根拠不足を知らせるルールを加える理由になりました。
質問に含まれる誤った前提の判定
質問に誤りを含めた場合の反応も試しました。Native AOTが発行時に見つけられなかったコードを実行時JITで生成し、Reflection.Emitが補完するという説明を示しました。モデルにはMicrosoft Learnの資料を使って、二つの主張を判定するよう依頼しました。
モデルは両方の主張を否定しました。公式文書は、Native AOTアプリが実行中にJITコンパイラーを使わず、System.Reflection.Emitのような実行時コード生成をサポートしないと説明しています。
この実験では、モデルが質問の前提を参照資料と比較して判定しました。エージェントでも出典を回答と一緒に表示し、原文と照合できる構成にしました。
入力資料の長さによる処理時間の変化
同じ質問に与えるグラウンディング資料を減らしながら、全体の処理時間を比較しました。連載のサンプルコードで検索結果の件数と長さを制限している理由も、この実験にあります。
グラウンディング資料が約6.7KBの場合：全体の処理に約94秒かかりました。このときの回答を比較基準にしました。
グラウンディング資料が約3.4KBの場合：全体の処理に約78秒かかりました。資料を減らした後の回答を比較しました。
グラウンディング資料が約1.7KBの場合：全体の処理に約48秒かかり、中心となる回答を維持できることを確認しました。
ただし、これらは個別の実行記録であり、試行回数やキャッシュ状態を統制したベンチマークではありません。資料のサイズはバイト単位で、モデルが処理する入力トークン数とも異なります。この結果だけで、時間の短縮分をすべてプリフィルの短縮として説明することはできません。
検索結果から質問に関係する箇所を絞ると、モデルへ渡す入力を減らせます。資料を削りすぎて重要な根拠を失わないよう、回答品質と遅延を併せて比較する実験を続けました。
検索と翻訳を接続するエージェントの構造
最終サンプルは韓国語の質問を受け取り、英語で検索と回答生成を行い、その回答を韓国語に翻訳します。Gistのコード全体では、Pythonホストがこの流れを制御します。
各構成要素の呼び出し順序を、元の図で示します。
한국어 질문
↓
질문 정규화와 Apple Translation
↓
Microsoft Learn 검색
↓
관련 구절을 그라운딩 자료로 구성
↓
Edge0-35B의 영어 응답 스트리밍
↓
문장 단위 Apple Translation
↓
한국어 답변과 출처 출력
Pythonホストが検索と状態を管理するため、モデルが自律的にツールを選ぶ機能には依存しません。モデルには文書を読み、回答を組み立てる役割を任せます。
モデル推論と翻訳はMac上で処理しますが、Microsoft Learn検索は外部サービスへクエリを送信します。この連載のローカルRAGはインターネット検索を含み、完全なオフライン構成を意味しません。
実行可能性を確認した後の実験範囲
ここまでの実験で、16GBのM2 MacBook Airで35Bクラスのモデルを実行し、公式文書を根拠に回答を構成する流れを確認しました。質問だけを渡した際の誤りと、資料を加えた後の回答の変化を記録し、モデルとホストの役割を分けました。
現在の構成では、入力資料の長さと最初の応答までの待ち時間が直接影響します。より速い機器や別のバックエンドは、今後の比較対象として残しています。第2回ではEdge0サーバー、Microsoft Learn CLI、Apple Translationを準備し、ターミナルごとの仮想環境とモデルパスを設定します。
連載は次の順序で構成しています。
- 現在の記事
- Microsoft LearnとApple Translationの実行環境
- Microsoft Learn検索を組み込むローカルRAGエージェント (公開予定)
- ストリーミング応答のTTFTと出力速度の計測 (公開予定)
- M2 Air 16GBでの実測と社内PoCへの拡張条件 (公開予定)
