技術 約9分で読めます

AMD公式のローカルAIサーバーLemonade、GPU+NPUを束ねてLLM・画像・音声を一元提供

AMD ローカルLLM NPU GPU llama.cpp 推論最適化 ROCm Vulkan

AMDがLemonade（公式サイト、GitHub）というローカルAIサーバーを公開している。LLMだけでなく画像生成（Stable Diffusion）、音声認識（Whisper）、音声合成（Kokoro TTS）を1つのサーバーに束ね、OpenAI互換のAPIで提供する。Hacker Newsで518ポイント・107コメントを集め、特にStrix Haloユーザーから「AMD環境でのローカル推論がようやくまともに動くようになった」と好評だった。

自分もEVO-X2（Strix Halo）でローカルLLM環境を構築してから、ドライバ問題やVRAM配分の罠、Vulkanのリグレッションと格闘してきた。Lemonadeはまさにこういう面倒を吸収する立ち位置にある。

Lemonadeの位置づけ

Lemonadeは推論エンジンそのものではない。内部でllama.cpp、FastFlowLM、whisper.cpp、stable-diffusion.cpp、Kokorosといった既存のバックエンドを束ね、ハードウェアに応じた最適な構成を自動選択する管理レイヤーだ。LM StudioやOllamaに近いが、テキスト生成以外のモダリティ（画像・音声）まで一元化している点が異なる。

HNのコメントで開発者のsawansriが「Lemonade is designed as a turnkey (optimized for AMD Hardware) for local AI models」と説明しており、パフォーマンス自体は素のllama.cppと同等だがセットアップの手間を大幅に削減する方向性だとわかる。

連携アプリも幅広い。VS Code Copilot、Open WebUI、n8n、Dify、OpenHands、Continue、GitHub Copilotなどに対応しており、OpenAI/Ollama/Anthropic互換のエンドポイントを通じて既存ツールをそのまま接続できる。

対応バックエンドとハードウェア

テキスト生成だけでも以下のバックエンドが使える。

バックエンドAPI対応デバイスOS
llama.cpp (Vulkan)汎用GPUAMD iGPU/dGPU、x86_64 CPUWindows, Linux
llama.cpp (ROCm)ROCmRDNA3/RDNA4/Strix HaloWindows, Linux
llama.cpp (Metal)MetalApple Silicon GPUmacOS (beta)
llama.cpp (CPU)CPU命令x86_64Windows, Linux
FastFlowLM (FLM)NPUXDNA2 NPUWindows, Linux
ryzenai-llmNPUXDNA2 NPUWindows

これに加えてwhisper.cpp（音声認識）、stable-diffusion.cpp（画像生成）、Kokoro（音声合成）がそれぞれ独立したバックエンドとして動く。lemonade recipes コマンドを叩けば、自分のマシンで使える組み合わせが一覧表示される。

ROCm対応のGPUは以下のとおり。

アーキテクチャGPUモデル例
gfx1151 (Strix Halo)Ryzen AI MAX+ Pro 395
gfx120X (RDNA4)Radeon AI PRO R9700、RX 9070 XT/9070、RX 9060 XT
gfx110X (RDNA3)Radeon PRO W7900/W7800、RX 7900 XTX/XT/GRE、RX 7800 XT

NPUの実態

HNのコメント欄で最も議論が白熱していたのがNPU（Neural Processing Unit）の有用性だ。現時点ではNPUはメインの推論用途には力不足で、低消費電力の小型モデル向けという位置づけだった。

AMD Ryzen AIシリーズに搭載されるXDNA2アーキテクチャのNPUは最大60 TOPS（AMD公式）を謳うが、Microsoftが Copilot+ PC認定に要求する40 TOPSをRTX 3050単体で超えてしまう程度の性能でもある。

cpburns2009:
The NPU is entirely useless for the Framework Desktop,
and really all Strix Halo devices. Where it could be useful
is cell phones.

NPUが有効なケース

ただし全く無用というわけでもない。

1つは、Qwen3のTTSモデル（2B未満）やWhisperの音声認識モデル（1B未満）のような小型モデルを常時稼働させるケース。音声入出力をNPUに任せ、GPUのVRAMをLLM推論に集中させるという分担が考えられる。

もう1つは、プリフィル（プロンプトの初回処理）のオフロードだ。長いコンテキストのプリフィルは計算コストが高く、GPUが電力制限に引っかかることがある。NPU側でプリフィルの一部を処理し、トークン生成はGPUに任せる「ハイブリッド実行」モードをLemonadeは提供している。AMD公式のテクニカル記事によると、Ryzen AI 300シリーズでNPU+iGPUのハイブリッド実行により電力効率を最適化できるとしている。

FastFlowLMのNPUカーネルは独自バイナリ

NPU推論の実体はFastFlowLMが担っている。FastFlowLMはOllama的な使い勝手を目指しつつAMD NPU専用に最適化したランタイムで、2026年3月にLinux対応（v0.9.35）を果たし、コンテキスト長256kトークンまでサポートしている。

ただしNPUアクセラレーションカーネルは プロプライエタリバイナリ だ。非商用利用は無償だが、ソースコードは公開されていない。HNコメントでzozbot234が指摘しているように、AMD/Xilinx側のNPUソフトウェアスタック自体（iron、mlir-aie、RyzenAI-SW）はオープンソースだが、FastFlowLMのモデル実行部分だけが閉じている。Vulkan Computeを使ってオープンなNPUカーネルを開発できないかという議論も出ていた。

graph TD
    A[Lemonade Server] --> B[llama.cpp]
    A --> C[FastFlowLM]
    A --> D[whisper.cpp]
    A --> E[stable-diffusion.cpp]
    A --> F[Kokoro TTS]
    B --> G[Vulkan GPU]
    B --> H[ROCm GPU]
    B --> I[Metal GPU]
    B --> J[CPU]
    C --> K[XDNA2 NPU]
    C --> L["NPUカーネル<br/>(プロプライエタリ)"]
    D --> M[NPU / Vulkan / CPU]
    E --> N[ROCm / CPU]

ROCm vs Vulkan問題

AMD環境でのローカルLLMで避けて通れないのがROCmとVulkanの性能差問題だ。自分の環境でもVulkanドライバのリグレッションに悩まされたが、HNでも同じ話題が繰り返されていた。

現状の傾向をまとめると以下のようになる。

項目ROCmVulkan
トークン生成速度 (tg)GPU依存で互角〜やや劣るRDNA2以降で高速、AMD公式もVulkanの数値をマーケティングに使用
プロンプト処理速度 (pp)Vulkanより高速ROCmに大きく劣る
安定性7.x系でリグレッション多発比較的安定
ドライバ管理デスクトップGPU対応が手薄OS標準ドライバで動く

lrvickというユーザーが「Vulkan + kernel 7.0.0で20%以上の高速化を確認した」と報告しており、特にStrix HaloではVulkanが有利な状況が続いている。ただしプリフィル速度（time-to-first-token）を重視する用途ではROCmのほうが依然として速い。

OllamaがMLXバックエンドに移行したようにApple Silicon側は推論基盤が整理されつつあるが、AMD側はROCm/Vulkan/NPUの三つ巴で、Lemonadeのような統合レイヤーが必要になる理由がよくわかる。

実際のパフォーマンス

HNコメントから拾った実測値を並べてみる。

ユーザーハードウェアモデル量子化速度バックエンド
lrvickStrix Halo 128GBQwen3.5-122B不明35 t/sVulkan
cpburns2009Framework Desktop 128GBQwen3-Coder-NextQ443 t/s不明
cpburns2009Framework Desktop 128GBQwen3.5-35B-A3BQ455 t/s不明
rpdillonStrix HaloGPT OSS 120B不明50 t/sROCm (llamacpp-rocm)
lrvickRadeon 6900 XTQwen3.5-32B不明60+ t/s不明

Strix Halo 128GB環境でQwen3.5-122Bが35 t/sというのは、自分のEVO-X2（64GB）でQwen3.5-35B-A3BのQ6_Kが53 t/s出ているのと比較すると、モデルサイズの違いを考慮すれば妥当な数字だ。Framework Desktop（128GB）のユーザーが多いのも印象的で、Strix Haloはローカル推論のメインターゲットになりつつある。

CLIの使い方

インストール後のワークフローは単純だ。

# 利用可能なモデルの一覧
lemonade list

# モデルのダウンロード
lemonade pull Gemma-3-4b-it-GGUF

# モデルの起動（チャット）
lemonade run Gemma-3-4b-it-GGUF

# 画像生成
lemonade run SDXL-Turbo

# 音声合成
lemonade run kokoro-v1

# 音声認識
lemonade run Whisper-Large-v3-Turbo

# 自分のハードウェアで使えるバックエンド確認
lemonade recipes

APIエンドポイントは http://localhost:13305/api/v1 で、OpenAI互換のクライアントライブラリをそのまま使える。Python、Node.js、Go、Rust、Java、C#、Ruby、PHPの各言語で対応ライブラリがリストされている。

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:13305/api/v1",
    api_key="lemonade"  # 必須だが使われない
)

completion = client.chat.completions.create(
    model="Llama-3.2-1B-Instruct-Hybrid",
    messages=[{"role": "user", "content": "Hello"}]
)

Ollamaとの違い

OllamaやLM Studioとの比較が気になるところだが、最大の差別化ポイントはマルチモダリティの統合だ。テキスト・画像・音声の3つを1つのサーバーで扱えるローカルツールは他にほぼない。通常、ローカルで画像生成と音声認識とLLMを同時に動かそうとすると、3つの別々のサービスを立てて3つのAPIを管理することになる。Lemonadeはそれを1つのデーモンに統合した。

もう1つはAMDハードウェアへの最適化で、ROCmビルドやNPU対応をLemonade側が面倒を見てくれる。NVIDIA環境では正直あまり恩恵がない（CUDAサポートは公式にはないが、llama.cppのバージョンを手動で差し替えることで動かせるらしい）。

逆にOllamaやLM Studioのほうが優れている部分もある。モデルのエコシステムの広さ、GGUFのプルダウン体験の手軽さ、そしてコミュニティの規模。Lemonadeは2.1k GitHub starに対してOllamaは桁違いの規模感だ。AMD環境で「全部入り」が欲しい人にはLemonade、プラットフォーム非依存で手軽に使いたい人にはOllamaという棲み分けになる。

ロードマップ

開発中検討中最近完了
MLXサポートvLLMサポートmacOS (beta)
whisper.cppの追加バックエンドカスタムモデルの拡充画像生成
SD.cppの追加バックエンド音声認識・音声合成
アプリマーケットプレイス

MLXサポートが開発中なのも気になる。OllamaがMLXに移行したことを考えると、macOS betaの現状（llama.cpp Metal）からMLXバックエンドに移行すれば、Apple Silicon環境でもLemonadeが本格的な選択肢になる。vLLMサポートが入ればバッチ推論やOpenAI API完全互換の本番デプロイにも使えるようになる。

モバイルアプリ（iOS/Android）も既に公開されており、ローカルサーバーとの連携が可能。ソースコードもGitHubで公開されている。