16GBのM2 MacBook Airで、Microsoft Learn検索、Edge0ストリーミング、文単位の韓国語翻訳を接続したエージェントを実行しました。2026年9月13日に確認したサンプルGistには、コード全体とともにTTFTが53.47秒だった実行結果を公開しています。
最終回では、計測に使った質問、検索と最初の応答までの時間、生成回答の根拠、出力速度の解釈、今後の最適化、社内PoCへ拡張する条件を扱います。第4回で説明したクライアント側の計測を基準に結果を読みます。
実行ログと計測値から説明します。各段階の時間を比較し、現在の結果から判断できる範囲と、追加実験が必要な範囲を分けて扱います。
数値を比較する際は、次の基準を適用します。
文書は2026年9月13日に確認しました。以下の数値は、特定の質問と検索結果を使用した一度の実行記録です。当時のすべてのバージョン、キャッシュ状態、反復計測の結果は、この記録だけでは確認できません。
tok/sと表示した値は、コンテンツを含むSSEイベント数から計算しています。
Native AOTの質問を使った単一実行
実験にはM2 MacBook Air 16GBとEdge0-35B-A3B-previewを使用しました。PythonホストがMicrosoft Learnを検索し、Apple Translationで入出力を翻訳する構成は、Gistの実行手順と同じです。
質問は次のように入力しました。
NativeAOT에서 Reflection.Emit을 사용할 수 있는지도 설명해주세요.
モデルの一般知識を評価するよりも、検索した公式文書を読み、実行時コード生成の対応有無を判定できるかを確認しました。この一度の結果を、機器の平均性能や別の質問の回答品質へ一般化してはいません。
検索完了から最初の応答までの待ち時間
サンプルコードの状態メッセージは、入力処理の開始を基準に経過時間を表示します。TTFTは、Edge0リクエストの開始時に記録する別の時刻を基準に計算します。
質問変換と検索にかかった約2.6秒
韓国語の案内を使った実験ログでは、次の順序で検索を完了しました。現在のGistは同じ種類の案内を英語で表示します。
[ 0.0s] 한국어 질문 정규화
[ 1.3s] 영어 검색 질의 생성 완료
[ 1.3s] Microsoft Learn 검색
[ 2.6s] 관련 문서 3개 검색 완료
근거 자료
[1] Native AOT deployment
[2] Introduction to AOT warnings
[3] ASP.NET Core support for Native AOT
約2.6秒には、韓国語の質問の正規化、英語クエリの生成、Microsoft Learn検索が含まれます。この実行では、その区間は後続の最初の応答までの待ち時間より短くなりました。
Edge0要求後に記録したTTFT 53.47秒
検索結果を渡した後は、最初のコンテンツを受信するまで待機状態を表示しました。
[ 2.6s] Edge0-35B에 요청 전달
[ 7.6s] Edge0 처리 중, 첫 토큰 대기 5초
[ 12.6s] Edge0 처리 중, 첫 토큰 대기 10초
[ 17.7s] Edge0 처리 중, 첫 토큰 대기 15초
[ 22.7s] Edge0 처리 중, 첫 토큰 대기 20초
[ 27.7s] Edge0 처리 중, 첫 토큰 대기 25초
[ 32.7s] Edge0 처리 중, 첫 토큰 대기 30초
[ 37.7s] Edge0 처리 중, 첫 토큰 대기 35초
[ 42.8s] Edge0 처리 중, 첫 토큰 대기 40초
[ 47.8s] Edge0 처리 중, 첫 토큰 대기 45초
[ 52.8s] Edge0 처리 중, 첫 토큰 대기 50초
[ 56.1s] 첫 토큰 수신 (TTFT 53.5초)
入力処理の開始から最初のコンテンツ受信までは約56.1秒、Edge0リクエストを基準にしたTTFTは53.47秒でした。二つの値は開始時点が異なります。
TTFTには、クライアント処理、サーバーのキュー待ち、トークン化、プリフィル、最初の生成ステップが含まれる場合があります。サーバー内部の計測がないため、53.47秒全体をプリフィル時間とは解釈しません。この記録では、Edge0要求後に最初のコンテンツを待つ区間が最長でした。
公式文書と照合した生成回答
最初の英語コンテンツを受信した後、ホストは文を蓄積して翻訳し、韓国語の回答を表示しました。実験時の生成結果を、次にそのまま示します。
전문가> 아니요, 네이티브 AOT 애플리케이션에서는
`System.Reflection.Emit`를 사용할 수 없습니다.
네이티브 AOT는 `System.Reflection.Emit`를 포함하는
런타임 코드 생성을 명시적으로 금지합니다 [1].
컴파일러는 `RequiresDynamicCodeAttribute`를 사용하는
메서드에 대해 네이티브 코드를 생성할 수 없습니다.
이러한 경고는 해당 멤버가 AOT와 근본적으로 호환되지
않음을 나타냅니다.
가장 좋은 해결 방법은 네이티브 AOT로 빌드할 때 메서드를
호출하지 않고 AOT와 호환되는 다른 것을 사용하는 것입니다 [2].
中心となる判定であるSystem.Reflection.Emitの非対応は、Native AOTの制限事項と一致します。個々のAOT警告の意味や対処は、AOT警告の文書を基準に該当する呼び出し箇所を確認できます。この一つの判定だけで、生成回答に含まれる他の説明まで検証したとは扱いません。
ホストはこの二つの文書と、ASP.NET CoreのNative AOT対応文書を一緒に表示しました。読者は回答の出典番号を各文書と照合できます。
コンテンツイベントから計算した出力速度
実行ログの計測値を計測コードの実際の計算基準に従って解釈すると、次のようになります。
質問処理と検索、約2.6秒：入力処理の開始から資料の選択までの時間を記録しました。
TTFT、53.47秒：Edge0リクエストの基準時刻から最初のコンテンツを受信するまでの時間を記録しました。
総生成時間、82.11秒：Edge0リクエストの基準時刻からストリームの受信終了までの時間を記録しました。
コンテンツイベント数、119個：サンプルの
completion_tokensフィールドで、コンテンツを含むイベントを数えました。最初の応答後の時間、28.64秒：最初のコンテンツを受信してからストリームの受信が終わるまでの時間を記録しました。
イベント単位の出力速度、約4.15回/秒：コンテンツイベント数119を最初の応答後の時間28.64秒で割って計算しました。元のログでは、この値を
tok/sと表示しています。
最初の応答が始まると、翻訳した文が順に表示されました。ただし、TTFTは最初の英語コンテンツを受信するまでの時間であり、最初の韓国語文を画面に表示するには、文の完成と翻訳の時間が加わります。総生成時間も、韓国語の翻訳と出力がすべて終わる時点までを測る指標ではありません。
この計測は同じ構成の変化を比較するために使えます。他のモデルやサーバーとトークン処理率を比較する場合は、実際のトークン数と計測区間を揃えます。現在の数値だけで、サーバーの純粋なデコード性能は断定しません。
グラウンディングの長さとキャッシュ状態の後続比較
別の実験では、グラウンディングを約6.7KBから約1.7KBへ減らすと、全体の処理時間が約94秒から約48秒へ短縮し、中心となる回答を維持できました。第1回の比較記録とGistの入力制限を合わせると、後続実験の変数を決められます。
長い入力の処理コストは待ち時間に影響する可能性がありますが、前の比較ではキャッシュ状態や試行回数を統制していません。原因をさらに絞るには、次の条件で比較できます。
- 同じ質問と検索結果を固定し、基準の実行を記録します。
- 資料を再ランキングしてグラウンディングを縮小し、回答の主要な根拠を比較します。
- プリフィックスキャッシュの対応有無と適用条件を確認し、適用前後を計測します。
- プロセス起動直後と反復リクエストで、キャッシュ状態を分けて記録します。
- 同一の入力と生成長を使い、別のApple Silicon機器で反復計測します。
- 追加のバックエンドが公開されたら、同じリクエストと計測基準で比較します。
この順序は今後比較する項目を示しています。現在のサンプルに再ランキングモデルやプリフィックスキャッシュを実装したという意味ではありません。まずは入力資料を減らした際に回答の根拠を維持できるか、最初の応答までの待ち時間がどう変わるかを併せて観察できます。
社内PoCと別のバックエンドへの拡張条件
M2 MacBook Airでの実験は、一人のユーザーの質問が検索、推論、翻訳を経て最後まで処理されるかを確認しました。Edge0のアーキテクチャは推論コアとバックエンドを分離していますが、複数ユーザーのセッションを運用するサービス層は別途構成できます。
Mac miniとMac Studioでのリクエスト制御
別の機器で行う後続PoCでは、クライアントと推論サーバーの間に、認証、セッション、検索、ポリシーを管理するホストを配置できます。次の構造は拡張案であり、現在のCLIに実装済みの機能を示してはいません。
사내 클라이언트
↓
사용자 인터페이스와 API 어댑터
↓
에이전트 호스트
├─ 인증과 세션
├─ 문서 검색과 접근 권한
├─ 요청 수 제한과 대기열
└─ 상태 및 응답 이벤트
↓
Edge0 서버
現在の35Bサーバー文書は、生成リクエストをFIFOキューから一つずつ処理すると説明しています。この動作と、複数セッションのトークン生成をまとめて処理する連続バッチングを区別すると、同時要求数と応答待ち時間を判断しやすくなります。
社内の技術文書検索、製品マニュアルの質疑応答、運用手順の案内など、範囲を定めた業務を後続実験に選べます。現在のCLIは認証、文書単位の権限フィルター、複数ユーザーのセッションを実装していないため、社内サービスではその層を別途扱います。Responses API形式やAG-UIを提供するアダプターも、同じ後続範囲に含みます。
CUDAバックエンド公開後の比較
Edge0の公開対応範囲はMLXベースのApple Siliconを対象とし、CUDAバックエンドはロードマップに含まれています。そのため、NVIDIA GPUで同じ結果を得たとは解釈できません。
追加のバックエンドが公開され、互換APIを提供する場合は、Pythonホストの検索と翻訳の流れを再利用する方向で検討できます。同じ質問、グラウンディング資料、生成長、計測基準を維持すると、機器とバックエンドの違いによる結果を比較しやすくなります。
限定した業務で確認したローカルエージェントの範囲
16GBのノートPCで35Bクラスのモデル、公式文書検索、オンデバイス翻訳を接続し、一つのリクエストを最後まで処理できました。モデルに文書の解釈と回答生成を任せ、ホストに検索と状態管理を任せる構成が成立しました。
現在の機器で記録した53.47秒のTTFTは、対話的な利用に直接影響します。入力資料の縮小やキャッシュ状態を分けた計測を先に比較でき、複数ユーザーの運用と別のバックエンドは後続の検証範囲に残ります。速い応答が重要なサービスと、待ち時間を許容できる技術文書の実験は、異なる基準で評価できます。
実行コード全体と導入手順は連載Gistにあります。質問と根拠資料の範囲を絞って再現を始めると、モデルのサイズに加えて、回答の出典、最初の出力までの時間、運用範囲も評価できます。
連載は次の順序で構成しています。
