「LM Studio」とllama.cppがQwen限定という暫定的ではあるもののMTP対応し、一般でも使えるようになった。そこで今回は実際どの程度速度に差が出るのか確認してみたい。
5月14日に「まだ一般向けではありません」と載せたばかりなのに……。
5月14日に以下のような記事を掲載した。内容的にはMTPという技術を使いLLMを高速化できる話だ。ただ実行する環境がvLLMなのでLinux + Dockerが必要と、ちょっと一般的ではないため、このようなタイトルになっていた。
もちろん記事を書いていた頃からllama.cppなど対応を始めていたので、近いうちには使えるようになるだろう……と思っていたが、5月20日、まさかたった1週間足らずでLM Studio = llama.cppが対応できるとは思ってもみなかった。
5月20日、LM StudioがMTP対応したことをXに載せた画面キャプチャ
さて、今回も実測してみたいが、先日の記事で紹介した筆者手持ちの環境はちょっとご家庭用とは言いがたい部分もあり、今回はGMKtecのミニPC「EVO-X1」(Ryzen AI 9 HX 370/16GB/1TB)のOCuLinkにGeForce RTX 5060 Ti(16GB)を接続、テストすることにした。
これならメインメモリは16GB、VRAM 16GB搭載のGPUは10万円未満で購入可能といったあたりで、AI PCとしては一般的といえるではないだろうか
EVO-X1にOCuLinkでGeForce RTX 5060 Ti(16GB)を接続
GeForce RTX 5060 Ti(16GB)でLLMを動かすにあたって、筆者の環境とどの程度違うのか？を調べるため、簡単なプログラムを作り、ベンチマークテストした。結果は以下の通り。なかなか興味深い内容でそれぞれの個性が見て取れる。
Prefill / Decode 測定。Qwen2.5-7B-Instructを使いTransformersで計測モデル帯域幅Prefill (tok/s)Decode (tok/s)GeForce RTX 5060 Ti(16GB)448GB/s2,11219.3DGX Spark(GB10)273GB/s4,58013.5M4 Max 128GB546GB/s97032.6
LLMにおいて、PrefillはGPUのAI演算性能、Decodeはメモリ帯域……がそのまま出ているのだ。つまりPrefillはBlackwell搭載のDGX Spark互換機、Decodeはメモリ帯域の広いM4 Max 128GB。GeForce RTX 5060 Ti(16GB)はちょうどその間、ということになる。
以前から筆者が書いている、M4 Maxはちょっとしたチャットなら速いが、バイブコーディングになると遅い。DGX Spark互換機は、ちょっとしたチャットは遅いが、バイブコーディングだとM4 Maxより速くなるが証明された格好にもなっている。
これでおおよそGeForce RTX 5060 Ti(16GB)の性能が分かったのでテストを始めたい。
LM Studioでチェック
さて、LM StudioをMTP対応の0.4.14(Build 4)アップデートして、MTPをキーワードにモデルを探してみると、引っかかるのはほぼQwenだけだ。Gemma 4などほかが見当たらない。
この原因を調べてみると、Gemma 4のMTPドラフターは、Gemma4AssistantForCausalLMという独自アーキテクチャ(外部ファイル)で、llama.cppの変換スクリプトがこのアーキテクチャに未対応のためGGUFにできないということらしい。一方、Qwen 3.6はMTPヘッドがモデル本体に内蔵してる関係で素直にGGUF化できるようだ。
ただし、Gemma 4のフォーク版ではMTPヘッドの埋め込みに対応し、動作確認済み。これを本家に取り込む作業も進んでいる。つまり近い将来Gemma 4対応の可能性が高いということだ。
この辺りの事情もあり、今回のテストはQwen 3.6だけに絞った。VRAMが16GBなので頑張れば動きそうなのはqwen3.6-27bとqwen3.6-35b-a3bだろうか。前者はDenseモデル、後者はMoEモデル。
そう言えば、最近Denseというキーワードを頻繁に見かけるようになった。なぜかについて理由を調べると、MoEが流行ったために、対比するキーワードが必要になったのでは？という感じだ。元々は全部Denseだったのでわざわざ書く必要がなかったのだ。
qwen3.6-27b vs qwen3.6-27b-mtp
今回のテストはUnslothの「qwen3.6-27b」とqwen3.6-27b-mtp」で行なった。ただし、VRAMが16GBということもあり、量子化モデルの「Q3_K_S」を使用、コンテキスト長はほかのアプリとのバランスも考え50,000とした。Thinkingは、
models→interface→プロンプトテンプレートで
{%- set enable_thinking = false %}
としオフ。動作状況は以下の画面キャプチャの通り。
qwen3.6-27b、コンテキスト長50,000で動作中
qwen3.6-27b-mtp、コンテキスト長50,000で動作中
ただ、タスク マネージャーを見ると分かるように、モデルが共有メモリに溢れてしまっている。NVIDIA Control PanelでLM Studioを「システム メモリ フォールバックなしを優先」にしても状況変わらず。コンテキスト長4,096にしても、IQ2_MにしてもKVキャッシュを量子化しても同じ。これが完全にVRAMに収まるようになればもっと速くなるのだが……。
qwen3.6-27bとqwen3.6-27b-mtp、1～4並列の結果並列数平均t/s実効t/s並列効率総実行時間生成トークンqwen3.6-27b(通常)113.3913.39—37.34s500210.7121.480.0%46.68s100038.4125.2362.8%59.46s150046.9227.6851.7%72.26s2000qwen3.6-27b-mtp(MTP有効)118.0718.07—27.67s50028.8317.6148.7%56.78s100035.9917.8332.9%84.11s150044.5217.9624.8%111.36s2000
qwen3.6-27bとqwen3.6-27b-mtp、1～4並列の結果をグラフ化したもの1並列: 13.39 → 18.07 tok/s +35.0%2並列以降: MTPが通常版を下回る
これを見ると、単独だと13.39 vs 18.07 tok/sと若干速くなっているが、2並列以降は逆転し、遅くなっている。普通にチャットする場合は並列がないので、これはこれでありだろう。2並列以降はやはりvLLMに軍配があがる。
qwen3.6-35b-a3b vs qwen3.6-35b-a3b-mtp
次はqwen3.6-35b-a3bとqwen3.6-35b-a3b-mtp。どちらもIQ2_M。コンテキスト長50,000、Thinkingオフ。
qwen3.6-35b-a3b、コンテキスト長50,000で動作中
qwen3.6-35b-a3b-mtp、コンテキスト長50,000で動作中並列数平均t/s実効t/s並列効率総実行時間生成トークンqwen3.6-35b-a3b(通常)159.0559.04—8.47s500249.4498.8383.7%10.12s1000334.12102.3457.8%14.66s1500427.25108.9746.1%18.35s2000qwen3.6-35b-a3b-mtp(MTP有効)163.6863.67—7.85s500228.5156.4444.3%17.72s1000319.1757.3230.0%26.17s1500414.5957.7122.7%34.65s2000
qwen3.6-35b-a3bとqwen3.6-35b-a3b-mtp、1～4並列の結果をグラフ化したもの1並列: 59.05 → 63.68 tok/s +7.8%2並列以降: MTPが通常版を大きく下回るLM Studio(llama.cpp)でMTPの効果は？
上記のテストをまとめると以下のようになる。
1並列t/s4並列実効t/s27B dense(通常)13.3927.6827B dense(MTP)18.0717.9635B MoE(通常)59.05108.9735B MoE(MTP)63.6857.71
確かにMTPの効果はあり、1並列だと少し速くなる。
27B dense：+35.0%35B MoE：+7.8%
ただし、MoEに関しては、各トークン生成時に全パラメータではなく一部のExpertだけ使うため、そもそも1トークンあたりの計算コストが低い。よってMTPのドラフト検証オーバーヘッドが相対的に重くなり効果が出にくい構造。これが確認できた結果にもなった。
また、どちらも2並列以降はMTPなし通常版と逆転。vLLMでは2並列以降も効果があったので、これはllama.cpp構造上の問題だろう。
つまりLM Studio(llama.cpp)では、
Qwen 27bを使うならMTP(ただし1並列=通常のチャットに限る)Qwen 35b a3bを使うなら通常版
と、こうなるだろうか。単純に速度を取るならQwen 35b a3b。もちろんQ3_K_SとIQ2_Mで精度が異なるため、ある意味何とも……なのだが、この点は何に使うか？にもよるだろう。
結果はあくまでも執筆の5月24日時点の結果であり、今後の改良によって大きく変わることも十分考えられる。あらかじめご了承いただきたい。
いずれにしてもVRAM 16GBだともっとBの小さいモデルも考えられるが、賢いという意味では(加えてVision対応)今のところQwen 3.6 27bもしくは35b a3bには敵わないと思う。
VRAM 24GBや32GBがあればもっとほかの選択肢もあるだろうが、そうするとご家庭用AI PCと呼ぶには価格的に難しくなる。今年(2026年)の傾向としては小型モデルがどんどん賢くなっているのでそれに期待したい。
DwarfStar 4(ds4)その後
+αの話題として、前回触れた「ds4」のその後について書いてみたい。
ds4は「Redis」の作者antirez氏が、DeepSeek V4 Flash専用のMetal推論エンジンを作り、96GB以上搭載のAppleシリコンであればq2-imatrixに量子化されたDeepSeek V4 Flashが実用レベルで動くというものだ。加えてKVキャッシュをSSDに持つという特殊な構造にもなっている。
氏はDGX Sparkも所有していたらしく、早いタイミングでDGX Sparkにも対応。手元にないものは確認できず、対応できないとXに投稿したところ、有志からM5 Max 128GB搭載のMacBook Pro、メーカーからROCm用にAMD Ryzen AI Max+ 395 128GB搭載PCが送られるという、何とも羨ましい(笑)状況になっている。
そして目玉であるds4-agentをリリース！これは名前の通り、DeepSeek V4 Flashをエンジンとしたエージェントだ。機能としては、
bashシェル コマンドの実行read ファイルの読み込み(行範囲指定可)write ファイルの作成・上書きedit 行レベルのファイル編集(CRC32チェック付き)search 正規表現によるファイル検索list ディレクトリ一覧more 前回の続きからファイルを読む
このようなものを持つ。面白いのはeditのCRC32チェック。書き換えようとする行のCRC32チェックサムを提出する必要があり、ファイルが変更されていたり記憶が不正確だと編集を拒否。コード破損防止の安全機構が入っている。
さらに、
・コンテキスト自動圧縮: 使用率が85%を超えると自動的に会話を要約してコンテキストを再構築
・セッション永続化: /save、/switch、/history、/newでセッションを保存・復元(KVキャッシュごと)
・マルチスレッドUI: 推論中も入力を受け付けるターミナルUI
なども搭載。汎用エージェントと言うより、開発に特化している感じで、氏もds4-coder的なと言っている。q2-imatrixに量子化されたDeepSeek V4 Flashとは言え、Vibeコーディングに使えばかなりいけるのではないだろうか？
DGX Spark互換機で動作中のds4-agent。お題は”今日の東京の天気”
M4 Max 128GB搭載MacBook Proで動作中のds4-agent。お題は”Prefill / Decode 測定プログラムの検証”
Prefillの状態が分かるのは面白い(下ピンクのバー)。これを見てるといかにPrefillの速度が重要かが分かる
ちょうどこの画像キャプチャを撮るためgit pullし、最新版で試したところ、DGX Spark版がかなり速くなっていて、もうM4 Maxで動かさなくていいかも？的になっているので流石だ。今後の展開が非常に楽しみなプロジェクトといえよう。
以上のように、LM Studio(llama.cpp)でQwen 3.6によるMTPの効果はある程度は確認できた。ただしその効果はvLLMほどではなかったのが残念なところ。
おそらくこの記事掲載後、少しすればGemma 4のMTPにも対応すると思うので、興味のある人はぜひ試してほしい。