巨大なAIモデルをローカル環境で実行する推論ソフトウェア「Project Maya」の新版「v1.1.28」が、2026年10月26日（日本時間）に公開された。今回の更新では、LinuxでNVIDIA GPUを1枚使用する環境向けに、RAMからGPUへのデータ供給方法を改善。開発者がRTX 3090を搭載した同一PCで比較したところ、DeepSeekのテキスト生成速度が12.9から27.8トークン／秒へと約2.2倍に向上した。また、512Kと1Mのコンテキスト長も新たに選択できるようになった。ただし、生成速度の向上と1Mコンテキストへの対応は異なる環境で検証されたものであり、両方の恩恵を同時に得られるとは限らない。
Project Mayaは、Mixture of Experts（MoE）アーキテクチャを採用した巨大言語モデルを、限られたGPUメモリでも動作させるためのソフトウェアだ。MoEモデルでは、入力に応じて必要な計算部分（エキスパート）を選択する仕組みを利用し、エキスパートを使用頻度に応じてGPUのVRAM、システムRAM、NVMe SSDに分散して保持する。対応モデルには、3,210億パラメータのGLM-5.3-Flashと、7,480億パラメータのDeepSeek-V4.1-Flash-1017が含まれる。GPU 1枚で動作するといっても、モデル全体がVRAMに収まるわけではない。例えば、DeepSeek向けのMaya-SはEngramを含めて約340GBのメモリを必要とし、実際の容量は量子化方式や構成によって異なる。
RAMからGPUへのデータ供給を改善、生成速度が約2.2倍に
今回の高速化の中心となるのは、RAMに保持したエキスパートをGPUへ供給する経路の見直しだ。新方式では、RAM上のデータをGPUから直接参照できるようにし、従来必要だった中間バッファへのコピーを省略した。さらに、DSparkによる推測的デコードで複数トークンを検証する際にも新しい転送経路を利用し、読み込んだエキスパートをVRAM内のキャッシュに保持する仕組みを導入している。従来は、DSparkの検証処理でVRAMにないエキスパートをCPUが計算している間、GPUが待機する場面があった。今回の変更は、こうした待ち時間を減らし、GPUの稼働効率を高めることを狙ったものだ。
この変更を実装したプルリクエスト（PR）#476には、RTX 3090（24GB）、Ryzen 5 5600X、125GBのDDR4メモリを搭載したPCでの測定結果が掲載されている。Maya-XSとDSparkを使用し、エキスパートの利用プロファイルを固定してv1.1.27と比較したところ、64Kコンテキスト設定での生成速度は12.9から27.8トークン／秒へ向上した。128Kトークンの入力後は14.0から23.2トークン／秒、256Kトークンの入力後は15.9から26.1トークン／秒となっており、いずれも明確な改善が確認されている。ただし、入力の長さや処理状況によって高速化の割合は異なる。
一方、入力された文章をモデルが読み込む「プリフィル（Prefill）」の速度は、ほとんど変化していない。8K、128K、256Kトークンの入力に対し、従来版の処理速度はそれぞれ563、1,158、1,417トークン／秒だったのに対し、新方式では560、1,148、1,407トークン／秒だった。つまり、今回の改善は主に回答を生成する段階に効果があり、長い文書を読み込む時間まで同じ割合で短縮されるわけではない。
Project Mayaの管理者であるmw00氏も、NVIDIA V100とMaya-XSを組み合わせた環境で約14%の生成速度向上を報告している。また、VRAMの空き容量が少ない条件では約35%の改善が見られたという。ただし、こうした結果をすべてのGPUに当てはめることはできない。CPUとGPUの計算分担や演算順序が変わることで、出力結果の最下位ビットに違いが生じる可能性もある。開発側の検証ではパープレキシティーに実質的な変化は確認されていないものの、生成結果が完全に一致するとは限らない。
1Mコンテキストに対応、長文処理には時間とVRAMが必要
v1.1.28では、DeepSeekのコンテキスト長として512Kと1Mを新たに選択できるようになった。従来は設定画面やセットアップで256Kまでしか選べなかったが、今回の変更によってモデルが本来対応する最大1,048,576トークンのコンテキストを利用できる。これは入力と出力を合わせたコンテキスト全体の上限であり、回答を生成する場合はそのための領域も確保しなければならない。なお、今回の対応は推論エンジンそのものの変更や、位置情報の扱いを拡張するRoPEスケーリングによるものではない。モデルが元から備えていた対応範囲を、設定から選択できるようにしたものだ。
実装を担当した開発者は、PR #442で長文処理の検証結果を公開している。試験には、テンソル並列度を8に設定した合計9基のGPUと、LibertAIDAIによる3.5bit量子化モデルを使用した。リポジトリ内のファイルを入力文書として使い、全体の10%、50%、90%の位置に3つのコードを埋め込み、それらを正しく取り出せるかを調べた。その結果、118,084、497,760、1,028,310トークンのいずれの入力でも、3つすべてのコードを回収できたという。
ただし、入力が長くなるほど処理時間は増加する。118,084トークンの読み込みには2.3分、497,760トークンでは10.4分かかり、最大の1,028,310トークンでは23.8分を要した。最大入力時の処理速度は720トークン／秒だった。また、この最大入力の試験ではv1.1.26の推論エンジンを使用し、--prefill-chunk 2048によって入力を分割処理していた。したがって、今回の更新によってGPU 1枚で100万トークンを快適に処理できるようになったことを意味するものではない。特定位置に埋め込んだ情報を検索できたという結果も、長文全般に対する理解力を保証するものではない。
コンテキスト長の拡大は、VRAMの消費量にも直接影響する。開発者によると、コンテキストの保持には、テンソル並列グループ内の各GPUで1トークン位置あたり約1.1KBのVRAMが必要になる。この領域はエキスパートのキャッシュと競合するため、コンテキストを長くするほどVRAMに保持できるエキスパートが減り、RAMからの読み込みやCPUによる計算が増える可能性がある。さらに、入力処理に使われるインデクサーの計算量は入力長の二乗に応じて増えるという。1Mコンテキストを活用するには、最大入力長だけでなく、読み込み時間とVRAM使用量のバランスを考慮する必要がある。
高速化は環境次第、約19%遅くなったとの報告も
今回の高速化は、すべての環境で同じ効果が得られるわけではない。GitHubのIssue #496では、利用者のtalisp氏が、Linux上のNVIDIA L40S-48Q vGPU（48GB）で生成速度が低下したと報告している。測定環境はXeon Platinum 8580を使用した仮想マシンで、32基の仮想CPU（vCPU）と約504GBのRAMを備え、推論処理には28スレッドを割り当てている。UD-Q8_K_XL量子化モデルとDSparkを使用した比較では、v1.1.26の平均42.4トークン／秒に対し、v1.1.28の既定設定では34.4トークン／秒となり、約19%の性能低下が確認されたという。
追加分析では、CPUが処理するエキスパートの割合をそろえて比較しても、約17%の性能低下が見られたと報告されている。一方、新しいデータ供給経路を無効にした場合に旧版との間で生じていた平均速度の差については、生成テキストによってCPUが担当するエキスパートの割合が異なったためだと、報告者自身が訂正している。ログの分析によると、この環境ではRAMからGPUへの転送よりCPUで直接計算する方が速く、新しい経路を通じた転送は実際には行われていなかった。それにもかかわらず性能が低下していることから、追加のキャッシュ管理や同期処理が影響している可能性が考えられるが、原因はまだ特定されていない。
今回の新しいデータ供給経路は、LinuxでNVIDIA GPUを1枚使用し、補助GPUを持たない構成では既定で有効になる。一方、WindowsやAMD GPU、複数GPU構成では従来の経路が維持される。主な変更と検証結果を整理すると、次のようになる。
| 対象環境・変更 | 適用状況 | 測定結果・主な変更 | 注意点 |
|---|---|---|---|
| Linux、単一NVIDIA GPUの新しいデータ供給経路 | 既定で有効 | RTX 3090で12.9→27.8トークン／秒 | v1.1.27との比較。プリフィル速度はほぼ不変 |
| DeepSeekの512K・1Mコンテキスト | 設定から選択 | 最大1,028,310トークンの入力を処理。所要時間23.8分 | 合計9GPUでの試験。最大入力の検証にはv1.1.26を使用 |
| Linux、L40S-48Q vGPU | 新経路が既定で有効 | 平均42.4→34.4トークン／秒、約19%低下 | v1.1.26との比較。利用者による個別報告 |
| GLM・AMD向け追加機能 | 任意で有効化 | レイヤー分割との併用、RDNA向けエキスパート計算など | 既定では無効 |
| DeepSeekの複数GPU向け追加機能 | 任意で有効化 | DSparkの分散処理、補助GPUへのエキスパート配置 | 補助GPU機能はLinux向け。既定では無効 |
RTX 3090とL40Sでは、比較対象となる旧版やモデル構成、CPU性能などが異なるため、測定された絶対速度だけでGPUの優劣を判断することはできない。重要なのは、RAMからGPUへデータを転送する方が効率的なのか、それともCPUで直接計算する方が速いのかが、ハードウェア構成によって変わるという点だ。特に、CPUの演算性能が高い環境では、GPUへの転送を増やすことが必ずしも高速化につながらない。現時点の測定結果はいずれも開発者や利用者による報告であり、独立した第三者による追試が完了したものではない。
Windows・AMD向けの追加機能と更新方法
今回のリリースでは、WindowsやAMD GPU、複数GPUを使用する環境にも機能が追加されている。GLMをAMD GPUで実行する場合には、モデルのレイヤー分割とエキスパートの補助処理を組み合わせる機能や、RDNA向けに最適化したエキスパート計算カーネルなどが利用可能になった。また、DeepSeekの複数GPU構成では、DSparkによる推測的デコードをテンソル並列グループ内で分散させ、最初のGPUのメモリ使用量を減らす仕組みが追加された。VRAMに収まりきらないエキスパートを補助GPUへ割り当てる機能も用意されているが、こちらはLinux向けとなる。いずれも既定では無効であり、利用するには個別の設定が必要だ。
ユーザーインターフェースにも改善が加えられた。長いコードを生成する際に表示がちらついたり、画面が不自然にスクロールしたりする問題を修正したほか、利用者が上方向へスクロールすると、新しい出力への自動追従が停止するようになった。サイドバーにはモデル名とロゴも表示される。更新はダッシュボードの「About > Update」から実行でき、手動で更新する場合はgit pullの後に./setup.shを実行する。WindowsではSTART-MAYA.batを使用する。変更された部分の再コンパイルは必要だが、モデルを再ダウンロードする必要はない。
今回の更新を適用する際は、まず起動ログで新しいデータ供給経路が有効になっているか確認するとよい。そのうえで、同じモデル、量子化方式、入力データ、設定を使用し、プリフィル速度と生成速度を分けて比較することが重要だ。1Mコンテキストへの対応によって扱える入力の規模は広がったが、長文処理によるVRAM消費と読み込み時間の増加には注意が必要となる。Project Maya v1.1.28の恩恵を最大限に受けられるのは、RAMからGPUへのデータ転送によってCPU側の処理待ちを減らせる環境であり、実際の効果は個々のPC構成とワークロードによって左右される。
