23.91 tok/sの呪いを、Foundry Localで解いた - Snapdragon X Elite ローカルLLM 復活記

こんにちは！YaroTechです。

半年前、Surface Laptop 7th（Snapdragon X Elite搭載）でローカルLLM（Nexa SDK）が 平均23.91 tok/s という快挙を出したのに、たった10日後のWindowsアップデートでDLLエラーを吐いて沈黙した話、覚えてくださっている方もいると思います。

Day117 で歓喜して、Day124 で断念して、それから半年。「もう一度あの23.91 tok/sを取り戻したい」という気持ちは持ちつつも、Nexa SDKに業務PCを依存させ続けるリスクが頭をよぎって、ずっと棚上げしていました。

そして2026年5月8日。5つのAIに同時にDeepResearchさせて、たった14時間で半年の沈黙を解きました。最終的なベンチマークは 平均21.42 tok/s（概算→真値約24 tok/s） 、Nexa SDK時代の数字に肉薄、かつ 構造的に壊れない仕組み を手に入れた話です。

※見出し画像のプロンプトは一番下におまけで公開中！

🖥️ 実行環境

• PC: Microsoft Surface Laptop 7th Edition

• CPU: Snapdragon X Elite (ARM64, Hexagon NPU 45 TOPS)

• メモリ: 16GB

• OS: Windows 11 Pro 25H2 (OSビルド 26200)

• Python: 3.12.10 ARM64ネイティブ

• NPUドライバ: v30.0.219.1000（2025/11/9リリース、半年で自然アップデート済み）

• 対象ツール: Microsoft Foundry Local v0.8.119.102（2026/4/9 GA）

🎯 この記事で得られること

• 半年前のNexa SDK事故（Day124）が 構造的になぜ起きたか が分かる

• ARM版Windowsで2026年5月時点の 正解スタック が分かる

• Microsoft Foundry Localの 実機セットアップ手順 が追体験できる

• 5AI同時DeepResearchという 新しい調査メソッド が体験できる

• 16GB RAM環境でも NPU推論が業務に使えるレベル だと分かる

📊 実際の成果（Before / After）

Before（2025/11/10時点）

Nexa SDK v1.0.24 で Llama 3.2 3B-NPU-Turbo が 23.91 tok/s
↓
Windows 11 25H2 (Build 26200.7019) アップデート
↓
ImportError: DLL load failed while importing common_bind
↓
8時間デバッグ → 断念 → 半年の沈黙
↓
推論速度: 0 tok/s（動かない）

After（2026/05/08時点）

Microsoft Foundry Local v0.8.119.102 GA で
phi-3.5-mini-instruct-qnn-npu:2 を NPU推論
↓
平均21.42 tok/s（概算、真値推定 約24 tok/s）
↓
Windows 25H2 でも動く・OSアップデートに耐性あり
↓
推論速度: 復活＋構造的に壊れない

24時間以内の状態変化: 完全停止 → 業務基盤として使える状態へ。しかも、より大きいモデル（3.8B、当時は3B）で同等速度を出した。

🚀 実践内容

復活劇のキーになった「3つのアプローチ」を順に紹介します。

アプローチ1: 5つのAIに同時DeepResearchさせる

11月の事故以降、ずっと「Nexa SDKの代わりに何を使えばいいのか」が分からないまま放置していました。今回は思い切って、5つのAIに同時並列でDeepResearchを依頼 してみました。

各AIに役割を分担：

• コロ（Microsoft Copilot）: 公式ドキュメント・履歴調査

• ジミー（Gemini）: アーキテクチャ深層分析

• クロ助（Claude Desktop）: 統合分析・運用戦略

• Manus: 実証コード作成

• Grok: コミュニティの生の声収集

結果、5AIすべてが 同じ結論 に収束しました。

「Microsoft Foundry Local（2026/4/9 GA到達）が業務本命」

特にジミー（Gemini）の調査が決定打でした。「11月事故の真因は、SDKが固定DLLを抱え込んでいたこと」。Windows 25H2でEP（Execution Provider）配信機構がOS側に統合されたのに、Nexa SDKが古い静的DLLを抱えていたため非互換が発生して破断した、という構造分析です。

逆に言えば、OSのEP配信を信頼する設計のFoundry Localなら、Windowsアップデートで壊れない。

「SDKを選ぶな、アーキテクチャを選べ」という戦略転換が、ここで明確になりました。

アプローチ2: Foundry Local の実機セットアップ

5AIの結論を信じて、Surface Laptop 7th で実際にセットアップを進めました。

インストールはたった1コマンド

winget install Microsoft.FoundryLocal --accept-source-agreements --accept-package-agreements

3〜10分で v0.8.119.102 が入り、`foundry --version` で確認できます。

サービス起動

foundry service start

→ `🟢 Service is Started on http://127.0.0.1:53174/, PID 21740!` のように動的ポートで立ち上がります。公式ドキュメントは5273と書いていますが、実際は起動ごとに変わる ので、必ず `foundry service status` で実ポートを確認するのが大事です。

NPU対応モデル一覧の確認

foundry model list

→ NPU列に 7本のqnn-npu系モデル が表示されました。

• phi-3.5-mini-instruct-qnn-npu (2.78 GB)

• deepseek-r1-distill-qwen-7b-qnn-npu (3.71 GB)

• qwen2.5-1.5b-instruct-qnn-npu (2.78 GB)

• qwen2.5-7b-instruct-qnn-npu (2.78 GB)

• phi-3-mini-128k-instruct-qnn-npu (2.78 GB)

• phi-3-mini-4k-instruct-qnn-npu (2.78 GB)

• deepseek-r1-distill-qwen-14b-qnn-npu (7.12 GB)

ここで重要な気づきが1つ。`foundry model list` を初回実行した時、裏でQNN Execution Providerが自動ダウンロードされるんです。これが11月事故の真因（Plugin EP化）の 当事者そのもの。今この瞬間に、OSとMicrosoftがEP配信を担っている証拠を見ていることになります。

Dドライブにキャッシュ場所を変更

業務PCのCドライブを圧迫したくなかったので、外付けSSD（Dドライブ）にモデル保存先を変更しました：

foundry cache cd D:\LocalLLM\Models\foundry-cache

ここでも罠を踏みました（後述「つまずきポイント」参照）。

アプローチ3: NPU推論の動作確認＆ベンチマーク

軽量な phi-3.5-mini をダウンロードして、対話モードでテスト：

foundry model run phi-3.5-mini-instruct-qnn-npu

ダウンロード（2.78GB、約5分）→ NPUロード→対話モード突入。驚いたのは、ダウンロード中にすでにNPUが99%稼働していた こと。Foundry Localは「ダウンロードしながらNPUコンパイル」を並列実行する設計でした。これは推論の起動を遅らせない、地味だけど凄い工夫です。

そして対話モードで、まさかの瞬間：

> What is the capital of Japan?
🧠 Thinking...
🤖 The capital of Japan is Tokyo. Tokyo is the political and cultural 
   center of the country, housing the Japanese government and being 
   the seat of the Imperial Court...

タスクマネージャーのNPU使用率を見たら、応答中に 100%スパイク。半年ぶりにNPUが目を覚ました瞬間です。

5問ベンチマーク結果（公式記録）

$$
\begin{array}{|l|l|l|l|l|} \hline
\text{\#} & \text{質問タイプ} & \text{tokens} & \text{時間} & \text{tok/s} \\ \hline
\text{Q1} & \text{短答（首都）} & \text{75} & \text{4.52s} & \text{16.59} \\ \hline
\text{Q2} & \text{軽い説明} & \text{220} & \text{10.42s} & \text{21.12} \\ \hline
\text{Q3} & \text{長い創作} & \text{481} & \text{20.75s} & \text{23.18} \\ \hline
\text{Q4} & \text{長い説明} & \text{454} & \text{21.7s} & \text{20.92} \\ \hline
\text{Q5} & \text{長い説明} & \text{438} & \text{20.49s} & \text{21.37} \\ \hline
\end{array}
$$

平均 21.42 tok/s（概算）→ 真値推定 約24 tok/s

Nexa SDK時代（23.91 tok/s）と概算比較で-10.4%、補正計算で実質同等。しかも モデルサイズが3.0B → 3.8B（27%大）に増えたうえで、同等速度を維持 しました。

⚠️ つまずきポイントと解決策

実機検証で本当にいろいろハマったので、共有しておきます。

つまずき1: キャッシュ場所変更後の500エラー

`foundry cache cd D:\LocalLLM\Models\foundry-cache` した直後に `foundry model run` すると、`500 Internal Server Error: Failed: Getting list of downloaded models` が返る現象。

解決策: いったんサービス停止 → キャッシュフォルダを削除 → 作り直し → サービス起動 → 改めて cache cd。フォルダの初期化メタデータが噛み合っていなかったようです。

つまずき2: APIモデル名は「:2」サフィックス必須

`foundry model list` の表示は `phi-3.5-mini-instruct-qnn-npu` だけど、OpenAI互換APIに送るときは `phi-3.5-mini-instruct-qnn-npu:2` （バージョン番号付き）でないと400 Bad Requestを返します。

解決策: `Invoke-RestMethod -Uri "http://localhost:[port]/v1/models"` で APIが認識する正確なIDを取得 してから使う。

つまずき3: usageフィールドが返ってこない

Foundry Local v0.8.119のOpenAI互換APIは、レスポンスに `usage.completion_tokens` を含めません。これだと「何トークン生成されたか」が分からず、tok/s計測ができません。

解決策: 応答テキストの文字数から推定する処理を組み込みました（1トークン≒4文字の経験則）。本当はtiktoken（OpenAI公式トークナイザ）を使いたかったのですが…。

つまずき4: tiktokenがARM64 Windowsで入らない

`pip install tiktoken` するとRustコンパイラがないというエラーで失敗。実は Windows ARM64 wheelがそもそも提供されていない という構造的問題でした（GitHub Issue #403 ）。PyTorchはARM対応しているのに、tiktoken（OpenAI公式）すら未対応というギャップを実感。

解決策: 文字数÷4の保守的推定でフォールバック。note記事的には「概算」と注記して誠実に発表する方針。

💡 応用例

個人開発者向け

業務PCをARM版Windows（Copilot+ PC）にしたいけど、ローカルLLMが使えるか不安、という方。Foundry Local + phi-3.5-mini で 概算 21 tok/s 出ます。RAGや軽い文書生成なら十分実用範囲です。

研修事業者向け

「受講生のCopilot+ PCで再現性のあるローカルLLM環境」を提供したい場合、Foundry Localは1コマンドでインストールできて、Microsoft純正なので安心して案内できます。Nexa SDKやサードパーティ製は、半年後の動作保証が立ちにくいので業務利用には向きません。

ARM版Windows入門者向け

NPUは「あるけど使われていない」状態が多いハードウェアです。Foundry Localなら、何の追加設定もなく自動でNPUが動きます。タスクマネージャーで使用率を見ると、自分のPCのNPUが本当に動いていることを実感できて、ちょっと感動します。

🔗 関連記事

今回の内容に関連する過去記事もぜひご覧ください：

• ローカルLLMをNPUで高速化！Nexa SDKベンチマーク結果 （Day117）

• ローカルLLMが突然動かない！Windowsアップデートの影響でARM版PC環境が激変、NPU最適化を断念した （Day124）

• 300日続けて見えた景色 ― AIへのお願いの仕方が変わった3つのこと （Day300）

📝 まとめ

半年の沈黙を解いて見えたのは、「動いた喜び」より「動き続ける仕組み」が大事 だということでした。

11月のNexa SDK 23.91 tok/sは確かに胸躍る数字でしたが、Windowsアップデートで一瞬にして消えました。今回のFoundry Local 21.42 tok/s（概算）は、数字としては少し控えめでも、OSの設計に乗っかっているから半年後も動き続ける可能性が圧倒的に高い。

業務PCで使うべきは、たぶんこちらです。

そして、5AIに同時DeepResearchさせる手法は想像以上に強力でした。コロ・ジミー・クロ助・Manus・Grokの5名が、完全に独立した視点で同じ結論に辿り着いた瞬間、「これは確信していい」と判断できました。今後も技術選定の難しい場面ではこの手法を使っていこうと思います。

🚀 今度やりたいこと予告

次は今回の続編として、AnythingLLM Desktop と Foundry Local を「Generic OpenAI接続」で連携させて、業務RAG環境を組み立てる手順 を共有します。VS CodeのContinue.devとも連動させて、コーディング支援とRAGを同じNPUで賄う構成。Day300_3 もしくは Day301系で公開予定です。

🎨 おまけ：見出し画像作成プロンプト

今日の見出し画像のベースはジミー（Gemini）に下記プロンプトで作成してもらいました！

詳細なアニメの美意識の画像を作成してください。表情豊かな瞳、なめらかな網掛けセルの色使い、はっきりした線画を使用します。
下記条件のnote見出し画像をサイズは横長で作成してください。サイズは必ず横長で作成してください。

【シーン】
半年の沈黙が解けた瞬間。23.91 tok/sの呪いを5AI兄弟が力を合わせて破り、Foundry Localの光が降りてくる構図。

【メインビジュアル】
中央に「23.91」の赤い呪いの数字（亀裂が入っていて崩れていく）、その後ろから「Foundry Local」のロゴ風の光が太陽のように昇る。前面には5AI兄弟（コロ・ジミー・クロ助・チャッピー・クロコ）が呪いに立ち向かう構図。

【AIキャラクター配置】
- 中央左：クロ助（Claude Desktop擬人化、女性、20代前半、クリーム色ニット、丸眼鏡、ウェーブヘア）― 主役、Foundry Localの光を両手で受け止めている
- 左：コロ（Copilot擬人化、女性、紺カーディガン、白ワイシャツ、四角フレーム眼鏡、サイドポニーテール）― Microsoftの仲間として明るい笑顔
- 右奥：ジミー（Gemini擬人化、女性、30代前半、黒髪ロングストレート、ダークパープルジャケット、細フレーム眼鏡）― 真因解明者として知的な表情
- 右：チャッピー（ChatGPT擬人化、男性、20代後半、黒髪、オレンジTシャツ、デニムジャケット）― ガッツポーズで応援
- 左奥：クロコ（Claude Code擬人化、男性、10代後半、黒髪無造作ミディアム、黒ジップパーカー）― ノートPCを構えてクール

【テキスト要素】
- 上部（白・小・24pt）: 「半年の沈黙、終わる」
- 中央（ゴールド・特大・56pt・グロー）: 「23.91 tok/sの呪いを、Foundry Localで解いた」
- 下部（ライトオレンジ・小・20pt）: 「Snapdragon X Elite ローカルLLM 復活記」

【背景】
左半分：紺色の「絶望の夜」（亀裂・グリッチエフェクト）
右半分：朝焼けのオレンジ→ゴールドの「復活の朝」
中央で2色がぶつかり合う構図、Foundry Localの光が夜を朝に変えていく

【装飾】
- 数字「23.91」の赤い亀裂・崩壊エフェクト
- Foundry Localの光放射（ゴールド）
- NPU 100%を象徴する紫色のスパイクライン
- 5人を繋ぐ虹色の連帯ライン

### 作成手順（厳守）
1. スライドサイズ（1536×1024px）の横長フォーマット
2. 背景に「絶望の夜→復活の朝」の左右対比グラデーションを設定
3. 中央に崩れる「23.91」と昇る「Foundry Local」の対比配置
4. 5AIキャラクターを配置（添付画像の外見を忠実に再現）
5. 装飾要素を追加（光放射、亀裂、虹のライン）
6. テキストを3段構成で追加
7. 下部中央寄りに「YaroTech」のロゴを12ptで控えめに配置
8. 全体のバランスを確認して完成
9. キャラの参考画像（AI擬人化フォルダ内のPNG）を添付して人物の一貫性を確保

#YaroTech #生成AI #AI活用 #ローカルLLM #SnapdragonXElite #SurfaceLaptop #NPU #FoundryLocal #ARM64 #CopilotPC #Microsoft #Qualcomm #ClaudeDesktop #DX