西川和久の不定期コラム

Qwenが速くなる？LM StudioのMTP対応をRTX 5060 Tiで最速検証

西川和久

2026年5月26日 06:11

　「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/s	2,112	19.3
DGX Spark(GB10)	273GB/s	4,580	13.5
M4 Max 128GB	546GB/s	970	32.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(通常)
1	13.39	13.39	—	37.34s	500
2	10.71	21.4	80.0%	46.68s	1000
3	8.41	25.23	62.8%	59.46s	1500
4	6.92	27.68	51.7%	72.26s	2000
qwen3.6-27b-mtp(MTP有効)
1	18.07	18.07	—	27.67s	500
2	8.83	17.61	48.7%	56.78s	1000
3	5.99	17.83	32.9%	84.11s	1500
4	4.52	17.96	24.8%	111.36s	2000

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(通常)
1	59.05	59.04	—	8.47s	500
2	49.44	98.83	83.7%	10.12s	1000
3	34.12	102.34	57.8%	14.66s	1500
4	27.25	108.97	46.1%	18.35s	2000
qwen3.6-35b-a3b-mtp(MTP有効)
1	63.68	63.67	—	7.85s	500
2	28.51	56.44	44.3%	17.72s	1000
3	19.17	57.32	30.0%	26.17s	1500
4	14.59	57.71	22.7%	34.65s	2000

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/s	4並列実効t/s
27B dense(通常)	13.39	27.68
27B dense(MTP)	18.07	17.96
35B MoE(通常)	59.05	108.97
35B MoE(MTP)	63.68	57.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をエンジンとしたエージェントだ。機能としては、