AI Navigate
インサイト最新記事一覧AI大全

Apple Silicon と AMD GPU にまたがってベンチマークした Qwen3.5（35B MoE、27B Dense、122B MoE）— ROCm と Vulkan の結果は意外で、コンテキスト長が重要

Reddit r/LocalLLaMA / 2026/3/27

💬 オピニオンDeveloper Stack & InfrastructureTools & Practical UsageModels & Research
原文を読む →
共有:

要点

  • 著者は、推論に残すマシンを決めるために、薬事（ファーマコビジランス）風の実運用プロンプトを用いて Qwen3.5 のバリアント（アクティブ 3B の 35B MoE、27B dense、アクティブ 10B の 122B MoE）を Apple Silicon および AMD GPU 上でベンチマークした。
  • 8K コンテキストでの結果では、35B MoE モデルにおいて ROCm が AMD 上で Vulkan に劣っている（例：R9700/W7900 で約 78.9 tok/s vs 約 133.0 tok/s）。一方で、このケースに限れば Mac の MLX 性能は AMD の Vulkan とほぼ近い。
  • 27B dense モデルでは、生成速度は全体的に大幅に低く、AMD 上では Vulkan が ROCm をわずかに上回る（例：W7900 で ROCm 約 25.2 tok/s vs Vulkan 約 31.8 tok/s）。これはバックエンド／ランタイムの影響を示唆する。
  • テストでは、4-bit 機械量子化、単一ユーザー・単一リクエスト、/no_think、temp 0.3 など一貫した設定を用い、8K を超えてコンテキストを最大 196K までスケールさせている。そのため、性能の結論はコンテキスト長に強く依存することが強調されている。
  • この記事では、エンジン／ビルド周りの実務的なつまずきと検証の詳細（mlx-lm vs llama.cpp、ROCm vs AMDVLK、過去に掲載した Fedora のバイナリに対する修正）を取り上げ、ベンチマーク手法とソフトウェアのバージョン管理が結果に実質的な差を生むことを補強している。

Apple SiliconとAMD GPUでQwen3.5をベンチマーク — ROCm vs Vulkanの結果は意外だった

自分のマシン間で推論性能を比較して、新しいMacBook ProをGPUサーバーと併せて持ち続ける価値があるかどうか判断したかった。実用的な比較――実モデル、実ワークロード、Apple Silicon vs AMD GPU、ROCm vs Vulkan――を探してみたが、合成ベンチマークか、単一マシンのレビュー以上のものはあまり見つからなかった。そこで自分でテストを行った。

セットアップ

ハードウェア: - MacBook Pro — M5 Max、48 GBユニファイド - Mac Studio — M1 Max、64 GBユニファイド - Fedora 43サーバー — Core Ultra 7 265K、192 GB DDR5、W7900（48GB、RDNA3、PCIe Gen4 x8）、R9700（32GB、RDNA4、PCIe Gen5 x8）¹

エンジン: Macではmlx-lm 0.31、Fedoraではllama.cpp — どちらもROCm 7.2ビルド（914eb5f、2026-03-25）と、AMDVLK Vulkanビルド（24d2ee0、2026-03-04）。 訂正: 元の投稿では、両方のFedoraバイナリをb5065として誤って記載していた。これは誤りだった。version: 1 の出力ではビルド番号は表示されない。実際のコミットは、上に示した通り最近の2026年ビルドである。EDIT 3でのMacBook Proのllama.cppテストは、Homebrewのb8500リリースを使用している。

モデル: Qwen3.5-35B-A3B（MoE、アクティブ3B）、Qwen3.5-27B（密）、Qwen3.5-122B-A10B（MoE、アクティブ10B）。いずれも4ビット（MLX 4bit / GGUF Q4_K_M）。

ベンチマーク: 実作業に基づくドメイン特化プロンプト（薬剤監視データ分析――コード生成、臨床推論、規制文書の作成、構造化抽出）。8Kコンテキストの7プロンプト＋196Kまでのコンテキストスケーリングテスト。単一ユーザー、単一リクエスト、/no_think、temp 0.3。

結果: 生成速度（tok/s）— 8Kコンテキスト

Qwen3.5-35B-A3B（MoE、アクティブ3B）

マシン バックエンド Gen tok/s
Fedora R9700 AMDVLK Vulkan 133.0
MacBook Pro M5 Max MLX 128.0
Fedora W7900 AMDVLK Vulkan 123.7
Fedora W7900 ROCm 78.9
Fedora R9700 ROCm 68.8
Mac Studio M1 Max MLX 57.6

Qwen3.5-27B（密）

マシン バックエンド Gen tok/s
Fedora W7900 AMDVLK Vulkan 31.8
MacBook Pro M5 Max MLX 31.3
Fedora R9700 AMDVLK Vulkan 30.6
Fedora R9700 ROCm 25.2
Fedora W7900 ROCm 24.4
Mac Studio M1 Max MLX 15.0

プロンプト処理（tok/s、約2.9K入力）

マシン バックエンド 35B-A3B PP 27B PP
MacBook Pro M5 Max MLX 3,235 779
Fedora R9700 ROCm 1,190 547
Fedora W7900 ROCm 1,001 434
Fedora R9700 AMDVLK Vulkan 1,030 244
Fedora W7900 AMDVLK Vulkan 948 177
Mac Studio M1 Max MLX 431 67

8KにおけるROCm vs Vulkan

AMDVLK Vulkanは、単一GPUワークロードの生成においてROCmを圧倒した:

GPU モデル ROCm Gen Vulkan Gen Vulkanの優位
R9700 35B-A3B 68.8 133.0 +93%
W7900 35B-A3B 78.9 123.7 +57%
W7900 27B 24.4 31.8 +30%
R9700 27B 25.2 30.6 +21%

しかしROCmは、27Bの密モデルにおいて、全てのコンテキストサイズでプロンプト処理が3.5〜4倍速い。

コンテキストスケーリング: 単一GPU（W7900、32K割り当て）

35B-A3B（MoE）

プロンプトトークン ROCm PP Vulkan PP ROCm Gen Vulkan Gen
1,137 1,537 1,534 84.2 132.0
4,415 1,524 1,435 83.3 129.3
8,824 1,452 1,332 81.6 119.2
17,635 1,297 1,121 79.2 116.6

27B（密）

プロンプトトークン ROCm PP Vulkan PP ROCm Gen Vulkan Gen
1,137 704 171 26.2 36.1
4,415 720 167 25.6 34.9
8,824 684 164 25.1 33.8
17,635 611 153 24.5 30.6

パターン: コンテキストが大きくなるほど、ROCmのPP優位は増える。Vulkanの生成優位はコンテキストとともに縮むが、単一GPUでは16Kまでプラスのままだ。

要点

  1. M5 Maxは速い。 MoEで128 tok/s、PPは3,235 tok/s。PCIeボトルネックのないユニファイドメモリは確かな利点。持つ価値がある。

  2. ROCm > Vulkanだと決めつけない。 単一GPU推論では、AMDVLK Vulkanが生成で30〜93%速かった。両方をテストすべき。

  3. しかしROCmは密モデルのPPを支配する — 3.5〜4倍速い。もしあなたのワークロードが長いコンテキスト入力（RAG、ドキュメント分析）なら、ROCmの「最初のトークンまでの時間（time-to-first-token）」の優位は非常に大きい。

  • PCIe帯域は重要です。 VRAMが少なくCU数も少ないにもかかわらず、Gen5 x8のR9700は、Gen4 x8のW7900に対してMoE生成で上回ります。

  • MoEはプロシューマ向けの最適解です。4ビットの35B-A3Bは、単一のAMD GPU上で123〜133 tok/sです。同程度のベンチマーク品質で比較すると、25〜32 tok/sの27B denseは明らかに遅くなっています。

    • 注意点

    • ドメイン固有のプロンプト — 医薬品安全性監視（ファーマコビジランス）のワークロードです。他のタスクでは結果が異なる可能性があります。
    • PCIeスロットは同等ではありません — R9700はW7900の2倍の帯域です（Gen5 x8 vs Gen4 x8）。これによりGPU同士の比較がややこしくなります。
    • RADVではなくAMDVLK — 近年のMesa 25.3+では、LLM推論向けにRADVが大幅に改善されています。結果が変わるかもしれません。
    • 量子化が異なります — MLXの4-bitとGGUFのQ4_K_Mの間で異なります。
    • シングルユーザーのみです。並行リクエストのテストは行っていません。

    ¹ 併せてW6800（32GB、RDNA2、Gen4 x4のチップセットスロット）もテストしましたが、Qwen3.5ではROCmをまったく実行できませんでした（Gated Delta Netのクラッシュ）。またVulkanの性能はx4チップセットリンクによって強くボトルネックされていました。わかりやすさのため、主要な表からは結果を省略しています：38.4 tok/s gen（35B-A3B）、18.0 tok/s gen（27B）。

    ベンチマークのスクリプト、オーケストレーション、および本稿はClaude Code（Claude Opus 4.6）の協力を得て作成されました。私はテスト戦略とハードウェアの判断を指揮しました。Claudeはベンチマークのハーネスを作成し、モデルのダウンロードを管理し、SSH経由で全マシンに対してテストを実行し、ポストの下書きを作成しました。

    編集： 122Bモデルでフルスイートを実行しました（デュアルGPU W7900+R9700、--split-mode layer）。パターンは反転します。ROCmがすべてを勝ち取ります：

    指標 ROCm Vulkan 勝者
    Gen tok/s（8K） 45.7 40.5 ROCm +13%
    PP tok/s（2.9K） 735 588 ROCm +25%

    コンテキストスケーリング（8K〜16K）では、すべてにおいてROCmが+10〜23%で勝っていました。分岐点は：

    モデル アクティブパラメータ GPU Genの勝者 PPの勝者
    35B-A3B（MoE） 3B Single Vulkan +57-93% ほぼ同率
    27B（Dense） 27B Single Vulkan +21-30% ROCm 3.5-4x
    122B-A10B（MoE） 10B Dual ROCm +13% ROCm +15-25%

    TL;DR: 単一GPU、小さなモデル → Vulkan。複数GPU、大きなモデル → ROCm。

    編集2： ご要望により、35B-A3Bで大きなコンテキストをテストしました。単一GPU（W7900、131K割り当て）とデュアルGPU（W7900+R9700、262K割り当て）です。

    単一GPU（W7900）— 最大100Kコンテキスト

    コンテキスト（トークン） ROCm PP Vulkan PP ROCm Gen Vulkan Gen
    8,824 1,525 1,422 81.7 124.5
    17,635 1,315 1,120 79.4 116.8
    35,577 1,096 846 75.3 100.0
    71,603 808 561 67.7 85.4
    109,510 602 380 61.2 72.3

    単一カードでは、すべてのコンテキストサイズ（最大100K）でVulkanが生成（generation）で勝ちますが、その差は8Kの+52%から100Kの+18%へと縮まります。ROCmのPP優位は、同範囲で+7%から+59%へと増えています。

    デュアルGPU（W7900+R9700）— 最大196Kコンテキスト

    コンテキスト（トークン） ROCm PP Vulkan PP ROCm Gen Vulkan Gen
    8,824 2,148 2,072 74.8 82.1
    35,577 1,679 1,380 69.2 70.3
    71,603 1,447 782 63.2 59.4
    109,510 854 563 58.0 48.3
    143,695 665 432 53.8 42.6
    215,917 523 301 46.7 34.3

    デュアルGPUでは、生成（generation）の分岐点がコンテキスト約65K付近にあります。それより下ではVulkanの方がわずかに速くなります。それより上ではROCmが抜き、差が広がります。196KではROCmは生成で36%高速、PPで74%高速です。

    インタラクティビティの崖

    どのバックエンドでも、非常に大きなコンテキストではROCmとVulkanの両方が、急激に性能が劣化します。そしてインタラクティビティを殺すのは、プロンプト処理の低下です。デュアルGPUのVulkanでは、PPが8Kで2,072 tok/sから196Kで301 tok/sにまで落ちます。これは85%の低下です。つまり196Kトークンのプロンプトは、Vulkanでのtime-to-first-tokenだけで約12分かかり、ROCmでは約7分です。65Kでも、最初のトークンが出るまで50〜90秒待つことになります。生成速度も低下します（Vulkanで82→34 tok/s、ROCmで75→47 tok/s）が、大きなコンテキストが実運用で遅く感じる主因はPPのウォールクロックです。長いコンテキストのRAGやドキュメント解析を対話的に行う場合は、この点を見込んでください。ネイティブな262Kコンテキストは技術的にはサポートされていますが、128K以上での体験は8Kとはかなり異なります。

    ROCm安定性に関する注記

    ROCmは、65K+コンテキストでデフォルトのマルチスロット構成を使用した際、R9700でメモリアクセス違反によりクラッシュしました（Memory access fault by GPU node-1 on address 0x7fedadca1000. Reason: Page not present or supervisor privilege.）。クラッシュは、リクエスト間でのKVキャッシュのチェックポイント再利用の最中に発生しました。-np 1（単一の並列スロット）に制限することで解決しました。Vulkanは、最大196Kまでのすべてのコンテキストサイズで安定性の問題は一切ありませんでした。

    大規模コンテキストでROCmがうまくいかないと言っていたコメントした人は正しかった——生の速度（65K未満ではVulkanが速いこと）と安定性（マルチスロットのクラッシュ）という両面で。だが、65Kより上では、安定性の問題を回避すればROCmは回復し、実際に生成で先行します。

    編集 3: 元の比較が、MacではMLX 4-bit、fedoraではGGUF Q4_K_Mだった点は、公正に見ればそのとおりです。これらは異なる量子化フォーマットで、ファイルサイズも違うため、同じ条件での比較（りんご同士）ではありません。MacBook Proにllama.cpp b8500（Metal）をインストールし、まったく同じGGUFファイル（fedoraのマシンからコピーしたもの）を実行しました。

    すべての環境で同じ llama.cpp GGUF Q4_K_M — 同一ファイル

    Qwen3.5-35B-A3B（MoE）

    マシン バックエンド Gen tok/s PP tok/s（2.9K）
    Fedora R9700 AMDVLK Vulkan 133.0 1,030
    Fedora W7900 AMDVLK Vulkan 123.7 948
    MacBook Pro M5 Max Metal（b8500） 89.4 783
    Fedora W7900 ROCm 78.9 1,001
    Fedora R9700 ROCm 68.8 1,190

    Qwen3.5-27B（Dense）

    マシン バックエンド Gen tok/s PP tok/s（2.9K）
    Fedora W7900 AMDVLK Vulkan 31.8 177
    Fedora R9700 AMDVLK Vulkan 30.6 244
    Fedora R9700 ROCm 25.2 547
    Fedora W7900 ROCm 24.4 434
    MacBook Pro M5 Max Metal（b8500） 23.7 171

    同じGGUFファイルで、生成においても両モデルとも、Vulkan上のfedora GPUがM5 Maxに勝っています。元の投稿でMacBook Proが好成績だったのは、単にハードウェアの差だけではなく、Apple Siliconにおけるllama.cppよりもMLXの最適化面での優位によるところが大きいです。

    MacBook ProでのMLX vs llama.cpp（別比較）

    これらは異なる量子化フォーマットとファイルサイズを使っているため、純粋な速度比較ではなく「エンジン比較」です：

    モデル MLX 4-bit Gen llama.cpp Q4_K_M Gen MLX Advantage
    35B-A3B 128.0 89.4 +43%
    27B 31.3 23.7 +32%

    MLXはApple Silicon上で大幅に高速ですが、MLX 4-bitモデルの方がQ4_K_MのGGUFよりも小さいため、その速度差を推論エンジンだけのせいにすることはできません。適切な比較には、同じサイズの量子化か、あるいは2つのフォーマット間のKLD driftのような品質指標が必要です。

    編集 4: コメンターが指摘したとおり、W6800のROCmクラッシュはおそらくアーキテクチャ上の制限ではなく、ビルドの問題でした——彼らはROCmで、さらに古いGPU（Radeon Pro VII、gfx906）でもQwen3.5を動かしています。ビルド設定を確認し、次のことを確認しました：ROCmバイナリは AMDGPU_TARGETS=gfx1100;gfx1201 のみでコンパイルされており、gfx1030は一度も含まれていません。 gfx1030;gfx1100;gfx1201で再ビルドしたところ、W6800は今度はROCmで問題なく動作します。

    W6800 ROCm vs Vulkan（修正版）

    Qwen3.5-35B-A3B（MoE）

    バックエンド Gen tok/s PP tok/s（2.9K）
    ROCm（gfx1030 build） 58.3 1,359
    AMDVLK Vulkan 38.4 534
    ROCm advantage +52% +155%

    Qwen3.5-27B（Dense）

    バックエンド Gen tok/s PP tok/s（2.9K）
    ROCm 19.3 316
    AMDVLK Vulkan 18.0 143
    ROCm advantage +7% +121%

    W6800では、ROCmが生成とPPの両方でVulkanより速い——W7900/R9700の結果とは逆です。これは興味深いです。RDNA 2のカードはROCmの恩恵を受け、新しめのRDNA 3/4のカードはVulkanの恩恵を受けています。W6800はPCIe Gen4 x4のスロット上にもあるため、ボトルネックは主にPPであり、生成ではありません（モデルはVRAMに完全に収まるため、生成にPCIeの帯域は必要ありません）。

    「RDNA 2はGated Delta NetモデルではROCmを動かせない」という当初の主張は誤りでした——ビルド構成のエラーだったのです。これを指摘してくれたコメンターに感謝します。

    submitted by /u/neuromacmd
    [link] [comments]

    関連おすすめサービス

    ※当サイトはアフィリエイト広告を利用しています
    🎧

    Notta搭載AI議事録イヤホン ZENCHORD1

    AI時代の仕事術。Notta搭載で会議の議事録を自動生成するスマートイヤホン。

    🎙️

    AI搭載ボイスレコーダー Plaud

    世界100万人が愛用。AIで文字起こし・要約を自動化するボイスレコーダー。

    🖼️

    画像高画質化AIツール Aiarty Image Enhancer

    AIで画像を高画質化。写真・イラストを簡単にアップスケール。