メインコンテンツへスキップ
推奨されないハードウェア Tokiosでは、AMD Strix Halo（Ryzen AI Max+ 395）を主要な推論用プラットフォームとして推奨していません。このハードウェアはコミュニティによって試行錯誤されている段階であり、ドライバーのサポートが不安定で、ROCmの安定性もカーネルやファームウェアのバージョンに依存します。またVulkanが唯一信頼できるバックエンドです。本格的な運用や日常的な推論用途には、Mac Studio、DGX Spark、またはRTXワークステーションの利用を推奨します。本ページは既にStrix Haloのハードウェアを所有しており、それを最大限活用したいユーザー向けに作成されています。
The AMD Ryzen AI Max+ 395 (“Strix Halo”) ships with up to 128GB of unified memory shared between the CPU and the Radeon 8060S iGPU. That pool is large enough to load models that would need a $2,000+ discrete GPU — but the 215 GB/s memory bandwidth and the MoE-vs-dense distinction decide whether you get 2 tok/s or 30 tok/s. This page tells you exactly what fits and what to expect.

​
簡単な結論：MoEモデルが最も有利

Strix Halo環境下では、MoE（ミックスド・オブ・エキスパーツ）モデルは同じ総パラメータ数を持つ非MoEモデルに比べて3～14倍高速に動作します。その理由はメモリ帯域幅にあります。MoEモデルでは各トークン生成時にメモリから読み込まれるのはアクティブなパラメータのみであるため、122B個のパラメータを持ち10B個がアクティブなMoEモデルは、10B個のパラメータを持つ非MoEモデルとほぼ同等の速度でトークンを生成できます。122B個のパラメータを持つ非MoEモデルほどの速度は得られません。 日常利用向けのモデルを選ぶ際は、35Bから122Bの範囲にあるMoEモデルから始めることをお勧めする

​
128GBの統合メモリについて説明する

Strix Haloには独立したVRAMは存在しない。iGPUはCPUと同じDDR5メモリプールからメモリを利用する。初期状態ではBIOSおよびOSがその128GBの一部を予約している：

​
Linux上でBIOSのメモリ設定を行う方法

Linuxではカーネルが自動的にメモリ割り当てを行う。起動後は通常95～110ギガバイトがGPU処理用に利用可能となる。ほとんどの場合、BIOS側での手動変更は不要だ。

​
Windows上でメモリ設定を行う方法

Windowsでは2項目を設定する必要がある：
  1. BIOS → UMA Frame Buffer — 利用可能な中で最も大きい値に設定すること（通常は「自動」または固定値）。
  2. AMD Adrenalin → VRAM allocation — AMD Software: Adrenalin Editionを開き、Settings → Graphics → Advancedへ移動してVRAMスライダーを96GBに設定してください。
Windows上でAdrenalinによるVRAM割り当てを行わない場合、iGPUが認識できる容量は15.5GB程度に留まり、大規模モデルには到底足りません。30Bパラメータを超えるモデルを利用する際は、BIOS設定とAdrenalinのスライダー設定の両方を行う必要があります。

​
ディンクスモデルの互換性について

ディンクスモデルでは各トークンごとに全パラメータが有効化されるため、各ステップでメモリから完全な重みテンソルを読み込む必要があります。215GB/sという速度ではトークン生成速度に明確な上限が生じます。
Strix Halo上でコーディングエージェント（Cline、Aider、OpenCodeなど）向けに、Qwen3-Coder-30BのQ4_K_M版がコミュニティで最も利用されている高密度型モデルだ。容易に収容でき、10～15トークン/秒の速度を実現する

​
MoEモデルの互換性

MoEモデルでは全パラメータ数は多いものの、各トークン処理時に活性化するのはごく一部にすぎない。そのため各ステップでのメモリ帯域消費が大幅に減少し、生成速度も著しく向上する アクティブなパラメータ数が3から12B程度のMoEモデルが最適な選択肢です。これらは最先端レベルの品質を提供しつつ、チャットやコーディングの際にもスムーズなレスポンス速度を実現します。
GLM-4.6 （総パラメータ数357B／アクティブパラメータ数32B）はStrix Haloでは利用できません。Q4_K_M量子化時には約178 GBのメモリが必要となり、これは128 GBの統合メモリプールをはるかに超えています。たとえ2ノードによるRDMAクラスタリング（総容量256 GB）を利用しても同様です。Strix Haloでは代わりにGLM-4.5-Airをご利用ください。各バリエーションの比較については GLMファミリー をご覧ください。

​
Kimi K3 on Strix Halo

Kimi K3 does not fit Strix Halo. The model’s 2.8T total parameters (~50B active per token through Stable LatentMoE) need about 1.4 TB at the native MXFP4 precision. Strix Halo’s full 128 GB pool — roughly 90–110 GB after OS overhead — is about 1.27 TB short of the raw weight floor. Moonshot recommends serving K3 on a supernode with 64 or more accelerators. For the full memory calculation, see the Kimi K3 hardware deep dive. For Strix Halo today, the models that fit are in the tables above — up to ~122B MoE at Q4 on a single node. See what to run instead of Kimi K3 for the best pick at 128 GB.

​
Qwen3.8 on Strix Halo

The Qwen3.8 flagship shipped in August 2026 as Qwen3.8-2.4T-A95B: a Mixture-of-Experts model with 2.4 trillion total parameters and 95B active per token, text-only, released under Qwen’s custom qwen3.8-max license. The generation also includes Qwen3.8-27B (released 2026-08-14, Apache-2.0), a dense vision-language model that does fit Strix Halo — see below.

​
各量子化レベルにおける重みデータ専用メモリ容量

Even at the most aggressive quantization, Strix Halo cannot run Qwen3.8-2.4T-A95B. This is a multi-node cluster model that requires at least 5 DGX Sparks (or equivalent) at Q2 — and realistically 10+ nodes at Q4 for reasonable KV cache headroom. For full cluster sizing, see the Qwen3.8 model page.
MoE models load all expert weights into memory even though only a subset activates per token. Qwen3.8-2.4T-A95B activates 95B of its 2.4T, but the 1.2 TB at Q4 is a hard floor regardless. The MoE advantage is in compute (fewer FLOPs per token), not in memory.

​
Strix Halo向けのQwen3.8モデル

Qwen3.8-27Bはこのシリーズにおけるシングルマシン用モデルであり、密度の高い27Bビジョン言語モデルです。このモデルは2026年08月14日にApache2.0ライセンスの下で公開されました。公式の30.9GB FP8版は96GBのGPUメモリでも余裕を持って動作しますし、55.6GB BF16版も同様です。ただし実際には、このハードウェア上でllama.cppやVulkanを利用する際にはQ4_K_M形式のGGUF版（容量は約17GBで、現時点では公開されていません）が最適な選択肢となります。詳細な仕様はQwen3.8モデルページをご覧ください。検証済みの構成情報も確認次第ここに追加される予定です。

​
ROCmとVulkanバックエンドの比較

Strix Haloに搭載されたRadeon 8060S iGPU（gfx1151）では2種類のバックエンドを通じて推論処理が可能です。それぞれに長所と短所があります。 Vulkanを利用してください。ただし、ファインチューニングの評価においてBF16精度が必要など、ROCmを使うべき明確な理由がある場合はこの限りではありません。
llama.cpp VulkanやOllamaを含む実行時オプションについては、Strix HaloにおけるvLLMおよび代替品 をご覧ください。

​
帯域幅の制約

Strix HaloのDDR5メモリは理論上 215 GB/s の帯域幅を提供します。これが性能を理解する上で最も重要な数値です：
  • トークン生成 はメモリ帯域幅に依存します。各トークン生成にはモデルの有効な重みをメモリから読み出す必要があります。
  • A 70B dense model at Q4 (~40GB) needs 40GB ÷ 215 GB/s ≈ 186ms per token → ~5 tok/s.
  • A 122B MoE model with 10B active at Q4 (~7GB active weights) needs 7GB ÷ 215 GB/s ≈ 33ms per token → ~30 tok/s.
プロンプト処理（プリフィル）は計算能力に依存し、トークン生成よりも速く実行されます。長いプロンプトでも素早く処理され、その後は帯域幅に制限された速度で生成が進む様子が確認できます。

​
用途別の性能目安

​
RDMAを利用した実験的な2ノードクラスタリング

2 Strix Halo nodes can provide 256 GB of aggregate unified memory through llama.cpp RPC, but this is a proof-of-concept path, not a production configuration.
llama.cppではRPCは不安定で安全性に欠け、概念実証用の機能だと説明されている。RPCワーカーを信頼できないネットワークに公開したり、本番環境のエンドポイントとして利用したりしてはならない。ネットワーク設定やモデル対応性、コンテキスト容量、パフォーマンスなどはすべて現地で検証する必要がある
単一ノードではモデルを収容できない場合に限り、この手法を制御された実験目的で用いるべきだ。DeepSeek V4 Flashローカルハードウェアでは、損失のないGGUF形式がなぜ複数ノードの合計メモリ領域に収まるのか、またなぜこれが実験段階のStrix Haloデプロイに留まるのかが説明されている

​
メモリ使用量を確認すること

モデルを読み込む前に、利用可能なGPUメモリ容量を確認しておくこと
Subtract OS overhead (~4GB) and leave 2–4GB for KV cache at your target context length. A 70GB model in Q4 leaves roughly 20GB for KV cache on a 96GB allocation — enough for 8K–16K context on most models.

​
次に行うべき手順

ストリクス・ハローの利用事例

リモートアクセス用にストリクス・ハローのボックス上で Tokios コネクターを設定する。

ストリクス・ハロー上で利用可能な vLLM およびその他のツール

llama.cpp Vulkan や Ollama を含む実行時オプションについて

量子化設定の手順ガイド

GGUF の量子化レベルと品質面でのトレードオフを理解する。