Project MayaとStrataは何が違うのか――同じ土台から分かれたローカルLLM推論基盤を整理する
想定タグ:
ローカルLLMCUDAMoEDeepSeek生成AI
Project Mayaのソースを読んでいると、あちこちにStrataという名前が出てきます。
たとえば、Python側で推論エンジンを管理するクラスは今もStrataEngineです。CMakeのターゲットにもstrata_core、strata_kernels、strata_engineといった名前が残っています。一方、実行ファイルはmaya.exeやmaya-ds4.exeです。
ここまで名前が混在していると、次の疑問が出てきます。
Project MayaはStrataの名前を変えただけなのか。それとも、別の推論エンジンなのか。
先に結論を書くと、Project MayaはStrataを出発点にした派生プロジェクトですが、現在は対象モデルもエンジン内部もかなり違います。
外側の仕組みには共通点があります。GPU、RAM、SSDを組み合わせて巨大なMoEモデルを動かす考え方も共通しています。しかし、「何のモデルを、どの規模のPCで、どう運用するか」という部分で、両者は別の方向へ進んでいます。
この記事では、AIやGPUに詳しくない人でも追えるように、まず用語を整理してから違いを見ていきます。
確認日は2026年10月22日です。Project Mayaについては、筆者が静的解析したコミット451f9cb6a21ea65673bdde2e57b4a670ae2b8859を基準にしています。Strataは同日時点の公式READMEとv0.2.2を参照しました。
まず「モデル」と「推論エンジン」を分けて考える
この話で最初につまずきやすいのが、「モデル」と「推論エンジン」の混同です。
モデルは、学習済みの巨大な数値データです。DeepSeekやQwen、GLMといった名前は、主にモデル側の名前です。
推論エンジンは、そのモデルを読み込み、GPUやCPUを使って回答を計算するプログラムです。たとえるなら、モデルが楽譜で、推論エンジンが演奏者に近い関係です。同じように見える楽譜でも、構造が違えば演奏側にも専用の対応が必要になります。
Project MayaもStrataも、この3つをまとめて扱うローカルLLM環境です。ただし、それぞれが中心に据えているモデルは異なります。
1分で分かる違い
細部へ入る前に、現在の立ち位置を大まかに並べてみます。
| 項目 | Strata | Project Maya |
|---|---|---|
| 出発点 | 元になったプロジェクト | Strataを土台にした派生プロジェクト |
| 中心モデル | Qwen3.8-Flash-Next | GLM-5.3-Flash、DeepSeek-V4.1-Flash-1017 |
| モデル規模 | 主力は125B | 321B、748B |
| 主な狙い | 一般的なゲーミングPCで扱いやすくする | より巨大なモデルを高性能PCで動かす |
| 最低メモリの目安 | RAMとVRAMの合計32GBから選択肢あり | 一律の最低容量は示されていない。RAM不足分をSSDから読み出せる |
| モデルファイル容量 | 選択する量子化形式による | GLMは約94.7～156.3GB、DeepSeekは約340～508GB |
| 対応アクセラレータ・プラットフォーム | NVIDIA、AMD、Intel、Apple Silicon | NVIDIA中心、AMDは実験的対応 |
| OS | Windows、Linux、macOS | Windows、Linux |
| 配布形態 | アプリ、Terminal、GPU別ビルド済みエンジン | ソース取得後にPC向けエンジンをビルド |
| API | OpenAI・Anthropic互換 | OpenAI・Anthropic互換 |
| UI | デスクトップアプリとTerminalが中心 | ブラウザのダッシュボードが中心 |
この表だけを見ると完全に別物に見えますが、内部の基本思想にははっきりしたつながりがあります。
両者の関係は「親子」に近い
Project MayaのREADMEには、エンジンがStrataから始まり、GLM-5.3-Flash向けに書き換えられたこと、サーバーとダッシュボードもStrataから発展したことが記載されています。
コードにもその痕跡があります。
-
StrataEngineというクラス名が残っている -
strata_coreやstrata_kernelsというライブラリ名を使っている - 旧実行ファイル
strataをmayaへ変更する互換処理がある -
strata-ds4をmaya-ds4へ変更する処理がある
Project Mayaのv1.1.16では、以前の実行ファイルを再コンパイルせず、そのまま新しい名前へ変更するコードも入っています。少なくともこの時点では、両者のつながりは単なる参考実装というより、直接的なコード上の系譜だったことが分かります。
ただし、現在のProject Mayaを「Strataの別名」と呼ぶのは正しくありません。
土台は共通していますが、その上に載せるモデルが違うため、必要なカーネル、Attention、キャッシュ、投機的デコードなども別々に発展しています。
共通点：PC全体を使ってMoEモデルを動かす
StrataとProject Mayaに共通する一番大きな特徴は、GPUだけでモデル全体を抱え込もうとしないことです。
通常、巨大なモデルを高速に動かすには、大容量VRAMを載せたサーバーが必要です。しかし、一般的なPCのGPUは12GBから24GB程度、多くても数十GBです。そこで両者は、GPU、システムRAM、SSDを階層として使います。
ここで重要になるのがMoE、Mixture of Expertsです。
MoEモデルには、多数の小さなニューラルネットワークが入っています。これをExpertと呼びます。文章の1トークンを処理するとき、すべてのExpertを使うのではなく、Routerが必要なExpertだけを選びます。
そのため、すべてのExpertを常にGPUへ置く必要はありません。
- よく使うExpertはGPUへ置く
- GPUへ入らないExpertはRAMへ置く
- RAMにも収まらないデータはSSDから読む
この発想は両者に共通しています。
違い1：中心にしているモデルが違う
現在のStrataは、主にQwen3.8-Flash-NextをローカルPCで動かすことを中心に設計されています。公式READMEでは125Bモデルとして説明されており、量子化形式や派生モデルを選ぶことで、RAMとVRAMの合計32GB程度から使える構成が用意されています。
Project Mayaは、さらに大きなモデルを対象にしています。
- GLM-5.3-Flash：321B
- DeepSeek-V4.1-Flash-1017：748B
DeepSeek-V4.1-Flash-1017では、量子化後でも構成によって約340GBから508GBのモデルファイルを扱います。これは96GBのVRAMにも収まりません。ただし、同じ容量のシステムRAMが必須という意味ではありません。RAMに収まらないExpertはSSD上のモデルファイルから読み出せるため、十分なSSD容量が必要で、RAM容量とNVMe性能が実効速度を大きく左右します。
この差は、単に「Mayaの方が大きなモデルを読める」というだけではありません。モデルの内部構造も違うため、推論エンジンも専用化されています。
Project Mayaには少なくとも次の2種類の実行ファイルがあります。
maya.exe GLM-5.3-Flash用
maya-ds4.exe DeepSeek-V4.1-Flash-1017用
DeepSeek用にはsrc/ds4/以下に専用のモデル実装があります。Engram、DSpark、DeepSeek固有のAttention、Vision処理などもこちらに実装されています。
一方、Strataの主力モデルには別の構造があります。たとえば公式の仕組み解説では、Qwen3.8-Flash-Nextの48層を1回通してMTPの候補を検証すると説明されています。Strata: How does it work?
Project Mayaで扱うDeepSeek-V4.1-Flash-1017のテキスト部分は40層です。層数だけを比べても優劣は決まりません。1層の幅、Expert数、Attentionの方式、補助メモリなどが異なるからです。
違い2：SSDに置くものが違う
両者ともSSDを使いますが、使い方には差があります。
Strataの場合
Strataの公式解説では、Qwen3.8-Flash-NextのExpertをRAMへ置き、頻繁に使うExpertをGPUへキャッシュする構成が基本です。SSDには約28.8GBのn-gramテーブルを置き、トークンごとに必要な行だけを読みます。
GPU: Attention、共有部分、頻出Expert
RAM: 全Expertまたは必要なExpert
SSD: 主にn-gramテーブル
RAMが少ない場合はlow-RAM modeもあり、モデルによってはSSDストリーミングが発生します。ただし基本の説明は、「ExpertをRAMへ置き、SSDには検索テーブルを置く」です。
Project Mayaの場合
Project Maya、とくにDeepSeek用エンジンでは、RAMに収まらないExpertそのものもモデルファイルから読みます。
GPU: 頻出Expert、Attention、KVキャッシュ
RAM: CPUで計算するExpert、SSDのページキャッシュ
SSD: 低頻度Expert、モデル本体、Engramテーブル
必要なExpertがGPUにない場合、エンジンは次のどちらが速いかを判断します。
- RAM上のExpertをCPUで計算する
- ExpertをPCIeでGPUへ転送して計算する
RAMにもなければ、まずSSDから読みます。
つまりProject Mayaは、より大きなモデルを動かすため、ストレージ階層も積極的に使う設計です。とくにDeepSeekをRAMへ収めきれない構成では、システムRAM容量とNVMe性能が体感速度へ直結します。
違い3：Strataは製品としての間口が広い
2026年10月時点のStrataは、推論エンジンだけでなく、デスクトップアプリ、Terminal、モデル管理、更新、診断までまとめた製品に近い構成です。
Strata v0.2.2では、Windows、Linux、Apple Silicon Mac向けの配布物があります。NVIDIA、AMD、Intel向けにエンジンが分かれ、利用者のGPUに合うパッケージを選ぶ仕組みも用意されています。
主な入口は次の2つです。
- デスクトップアプリ
-
strataコマンドを使うTerminal
strata launchでモデル選択、コンテキスト、画像、接続範囲を設定し、strata doctorで環境を確認できます。エンジンはGPUやOS別のビルド済みパッケージとして提供されます。
Project MayaにもブラウザUI、モニター、OpenAI・Anthropic互換APIがあります。ただし、導入方法は開発者向けです。リポジトリを取得し、NVIDIA環境ではCUDA Toolkit、AMD環境ではROCm/HIP環境とC++コンパイラを使って、そのPC向けのmaya.exeまたはmaya-ds4.exeをビルドします。
配布形態と対応範囲から筆者が整理すると、この違いは次のように表せます。
Strata すぐ使えるローカルLLM製品を目指している
Project Maya 特定の巨大モデルへ深く最適化した開発者向け基盤
もちろん、Project Mayaにもセットアップスクリプトはあります。コマンドを手で何十個も入力する必要はありません。ただし内部では依存関係の準備とローカルビルドが行われるため、ドライバやCUDA Toolkit、ROCm/HIP環境との相性問題に遭遇しやすい構成です。
違い4：対応ハードウェアの考え方
Strataは、対応するPCの範囲を広げる方向へ進んでいます。
- NVIDIA CUDA
- AMD HIP
- Intel Arc
- Apple Silicon / Metal
- Windows、Linux、macOS
メモリが少ないPC向けには、より小さい量子化やGyroといった選択肢があります。
Project Mayaは、モデルの規模を優先しています。NVIDIA GPUが中心で、AMDとWindowsへの対応も進んでいますが、一部は実験的です。Intel ArcやApple Siliconを主対象にはしていません。
今回調べたRTX PRO 6000 Blackwell 96GBのような環境は、Project Mayaの狙いに合っています。それでもDeepSeekのモデル全体はVRAMへ入りません。モデルを保存できるSSD容量は必須で、RAMが多くNVMeが速いほど、SSDからの読み出し待ちを減らしやすくなります。
一方、同じ96GB GPUでStrataを使う場合、主力のQwenモデルではかなり多くのExpertをVRAMへ置けます。同じRAM・SSD条件で、より小さいモデル構成を選ぶなら、Project Mayaよりストレージ待ちが少ない構成を作りやすいと考えられます。
違い5：最適化の対象が違う
StrataとProject Mayaは、似た仕組みを使いながら、別のモデルに合わせて最適化されています。
Strata
- Qwen3.8-Flash-NextのExpert構造
- DeltaNetやAttention
- MTPによる投機的デコード
- RAM上のExpertをCPUとGPUで分担
- 多様なGPUとOSへの対応
Project Maya / GLM
- GLM-5.3-Flash固有のAttentionとExpert構造
- MTPまたはDFlash2
- KV streaming
- 複数GPUへのlayer split
- Maya独自量子化
Project Maya / DeepSeek
- 384個のrouted Expertから各トークン6個を選択
- 40層のテキストモデル
- Engramテーブル
- DSpark drafter
- DeepSeek固有のVision Encoder
- VRAM、RAM、SSDにまたがるExpert配置
名前の近い関数や共有ライブラリがあっても、実際のモデル計算は同じではありません。モデルごとに専用エンジンが必要になる理由がここにあります。
APIの使い方はよく似ている
利用する側から見ると、両者はかなり似ています。
どちらもローカルにHTTPサーバーを立て、OpenAI互換APIやAnthropic互換APIを提供します。対応アプリでは、クラウドAPIの代わりにローカルアドレスを指定できます。
OpenAI互換のbase URL:
http://127.0.0.1:8080/v1
Anthropic互換のエンドポイント:
http://127.0.0.1:8080/v1/messages
内部では、Pythonサーバーが会話をトークンへ変換し、常駐するC++製のネイティブ推論エンジンへ渡します。NVIDIA環境ではCUDA、AMD環境ではHIPなどのGPUバックエンドが使われます。エンジンが返したトークンIDは、Python側で文字列へ戻され、SSEで少しずつ画面へ送られます。
そのため、APIを使うだけなら、両者の違いをあまり意識しないこともあります。差が出るのは、モデルの回答傾向、必要メモリ、速度、セットアップ、対応GPUです。
更新方法にも違いがある
Strataは、プラットフォーム別のエンジンパッケージを配布しています。公式説明では、更新フィードは署名され、ファイル単位で検証し、切替前に起動テストを行い、失敗時にはロールバックする設計です。これは更新フィードとエンジンファイルについての説明で、インストーラー自体のコード署名とは別の話です。
Project Mayaは、Gitリポジトリの更新後、必要に応じてローカルのエンジンを再ビルドします。モデルファイルについては、マニフェストに記録されたサイズとSHA-256を使う構成があります。
この差は、開発方針の違いとも言えます。
- Strataは、ビルド済み製品を安全に更新する仕組みへ力を入れている
- Project Mayaは、ソースとモデル固有の最適化を素早く更新する構成になっている
Project Mayaのコードを監査した範囲では、明確なマルウェアやバックドアは確認できませんでした。一方、Python依存関係の固定不足や、Gitベースの更新に独立した署名検証がない点は、導入時に意識したい部分です。なお、この静的セキュリティ監査はProject Mayaの指定コミットを対象としたもので、Strataについては公式資料と公開実装の確認にとどまります。
どちらを選ぶか
用途で考えると分かりやすくなります。
Strataが向いている場合
- 普通のゲーミングPCでローカルLLMを始めたい
- 32GBから64GB程度のメモリ環境で使いたい
- NVIDIA以外のGPUやMacも使いたい
- ビルド作業を減らしたい
- デスクトップアプリやTerminalから管理したい
- Qwen3.8-Flash-Nextを使いたい
Project Mayaが向いている場合
- GLM-5.3-Flashを使いたい
- DeepSeek-V4.1-Flash-1017をローカルで動かしたい
- 96GB級GPU、十分なSSD容量、高速NVMeを用意できる
- より多くのExpertをキャッシュするため、大容量RAMも用意できる
- CUDA ToolkitまたはROCm/HIPとビルド環境を扱える
- モデル固有の最適化を優先したい
- 実験的な構成や新しい実装を試せる
Project Mayaを「Strataの上位版」と考えるのは少し違います。モデル規模だけならMayaの方が大きいのですが、対応環境、導入のしやすさ、運用機能ではStrataの方が広く整備されています。
反対に、Strataを「Mayaの古い版」と考えるのも違います。現在のStrataは独自に開発が続いており、別のモデルと幅広いハードウェアを対象にしています。
まとめ
Project MayaとStrataは、無関係な2つの推論エンジンではありません。Project MayaはStrataのコードと設計を出発点にしています。
共通しているのは、MoEモデルをGPUだけへ詰め込まず、VRAM、RAM、SSDへ分けて動かす考え方です。PythonのAPIサーバーとC++製のネイティブ推論エンジンを分離する構成にも共通点があります。
そこから、現在は次のように分かれました。
Strata
└─ Qwen系を中心に、幅広いPCで使いやすくする
Project Maya
├─ GLM-5.3-Flash向けの専用エンジン
└─ DeepSeek-V4.1-Flash-1017向けの専用エンジン
同じ土台を持っていますが、対象モデルが変われば、層構造もExpert数もAttentionも違います。今では「同じ構造の名前違い」ではなく、共通の祖先を持つ別プロジェクトとして見るのが自然です。