AMDが「全部公開した」LLMモデルは自分で作れるのか〜Instella-MoEについて調べてみた

2026年8月2日

本ページは広告（アフィリエイトプログラム）を含みます。詳しくはプライバシーポリシーをご覧ください。

AMD が2026年7月に、自社として初めての完全オープンなMoEモデル「Instella-MoE」を公開しました。特徴は公開範囲の広さで、完成した重みだけでなく、学習の全工程の途中経過・学習に使ったコード・学習データそのものまで出しています。ここまで開けているのなら、手順どおりにやれば自分でもモデルを作れるのでしょうか。

本記事では、AMD が公開した設定ファイルを実際に開いて学習の規模を確かめ、そのうえで手元の AMD 製ミニPC で何ができるのかを調べました。

2026年7月時点の内容です。

1. 使用した機器の概要
- 1.1. GMKtec EVO-X2（Ryzen AI Max+ 395 / 128GB / 2TB）
2. AMD は何を公開した？「完全オープン」の中身
3. 自分で学習できる？設定ファイルを開いて規模を測る
4. では動かせる？ 128GBのミニPCなら余裕で載る
5. すぐ動かせる？用意されていない道が多かった
- 5.1. ひとつ注意しておきたい落とし穴
6. 「完全オープン」は何を指す？ライセンスを読み比べる
7. 調べて分かったこと〜自分で作れるのか
8. 実際に動かしてみた：どの精度なら、どれくらいの速さで動くのか
- 8.1. 結果
- 8.2. この測定の限界（正直な注記）
9. 予想が外れたところ
10. 「文脈の領域も軽く済みそう」は当たっていたのか
11. 動かすまでにつまずいたところ
12. 熱について
13. 手元で遅いなら、借りる手もある
14. 動かしてみて分かったこと
15. 参考にしたサイト
16. 記事で紹介した機材

使用した機器の概要

今回の主役は、AMD のチップを積んだミニPCです。

機種	GMKtec EVO-X2（以下、EVO-X2）
CPU	AMD Ryzen AI Max+ 395
GPU	Radeon 8060S（CPU内蔵）
メモリー	128GB（ユニファイドメモリ）
OS	Ubuntu

ユニファイドメモリは、CPU と GPU が1つのメモリを分け合って使う仕組みです。グラフィックボードのように容量が固定されていないため、大きいモデルを載せるうえでは有利に働きます。

GMKtec EVO-X2（Ryzen AI Max+ 395 / 128GB / 2TB）

手のひらより少し大きい程度の箱です。今回は「AMD が作ったモデルを、AMD のチップで動かせるか」という話なので、この機体が主役です。

[kimono_product id="16082″]

AMD は何を公開した？「完全オープン」の中身

まず、何が公開されたのかを整理します。モデル本体は16B（160億パラメータ）で、そのうち実際に動くのは2.8B（28億）だけという MoE（混合エキスパート）の構成です。

公開されているものは、次のとおりです。

公開されたもの	内容
学習の各段階の重み	事前学習→中間学習→長文脈対応→教師あり調整→選好学習→最終版の6段階
学習コード	MITライセンス
学習データ	実体がダウンロード可能。合計約42.5TB
設定ファイル	各段階の学習設定

途中経過の重みが6段階ぶん公開されている点が珍しいところです。完成品だけを配るのではなく、「どこからどう育てたか」が追えるようになっています。

自分で学習できる？設定ファイルを開いて規模を測る

手順が公開されているなら、同じことをやれば作れるはずです。実際にどれくらいの規模なのかを、公開されている設定ファイルから確かめました。

事前学習の設定には、次の値が書かれています。

train_iters: 443876
global_batch_size: 4096
seq_length: 4096
expert_model_parallel_size: 8

上の3つを掛け合わせると、学習に使ったトークン数が出ます。443,876 × 4,096 × 4,096 で、約7.45兆トークン。文庫本にして数千万冊ぶんの文章を読ませた計算です。

そして最後の行が、個人にとっての壁でした。expert_model_parallel_size: 8 は、8台のGPUで分担する前提という意味です。この値は事前学習だけでなく、中間学習も、教師あり調整も、選好学習も、公開されている全段階の設定に同じように入っていました。1台で動かすための設定は用意されていません。

AMD がこの学習に使ったのは、MI300X と MI325X という、データセンター向けのGPUです。手元の EVO-X2 に載っている Radeon 8060S は同じ AMD 製ですが、用途がまるで違います。ざっと見積もると、EVO-X2 の内蔵GPUで同じ学習をやろうとすれば数百年かかる計算でした。

加えて、学習データが42.5TBあります。トークン化した後のデータを置く場所も要るため、作業用のディスクだけで数十TBという規模です。回線とディスクの両方で、個人の手には余ります。

ちなみに、AMD は学習に使ったGPUの台数や時間、費用を公表していません。設定ファイルからトークン数は逆算できましたが、実際にどれだけの計算資源を注いだのかは分からないままでした。

「手順を踏めば作れるのか」への答えは、作れない、でした。ただし、AMD が何かを隠しているからではありません。規模がまるで違うためです。

では動かせる？ 128GBのミニPCなら余裕で載る

作るのが無理でも、動かすのはどうでしょうか。ここで EVO-X2 の大容量メモリが効いてきます。

形式	サイズ	EVO-X2（実用上限約90GB）
BF16（そのまま）	31.7GB	余裕で載る
8ビットに圧縮	約16GB	載る
4ビットに圧縮	約9GB	載る

圧縮せずそのままの状態でも31.7GBですから、128GBのユニファイドメモリなら余裕があります。品質を落とさずに動かせる、ということです。

文脈を保持するための領域も軽く済みそうです。このモデルは記憶領域を圧縮して持つ仕組みを採用しており、長い文脈を扱ってもメモリを食いにくい設計になっています。

すぐ動かせる？用意されていない道が多かった

容量に余裕があると分かったところで、次の壁が出てきました。動かすための道がほとんど用意されていません。

動かす手段	使えるか
Ollama	使えない
llama.cpp	使えない（変換の時点で対応外）
GGUF形式のファイル	存在しない（第三者が作ったものも含めて）
transformers（Python）	これだけ使える

ローカルでモデルを動かすとき、多くの人が使うのは Ollama です。手軽に始められますが、今回は使えません。その土台になっている llama.cpp が、このモデルの形式に対応していないためです。

自分で変換しようにも、変換ツールの対応リストにこのモデルが入っていません。「モデルが載る」ことと「使える」ことは別だという、分かりやすい例になりました。

残された道は、Python の transformers というライブラリから直接呼び出す方法だけです。手軽さでは Ollama に及びませんが、動かすこと自体はできます。

ひとつ注意しておきたい落とし穴

このモデルの設定ファイルには、内部的に別のモデル形式の名前が書かれています。そのため、設定を少し書き換えれば変換ツールを通せてしまいます。

ところが、このモデルには独自に追加された仕組みがあり、書き換えて変換するとその部分が黙って捨てられます。エラーは出ないので変換は成功したように見えますが、出来上がるのは中身の欠けたモデルです。動くけれど本来の性能が出ない、という厄介な状態でした。

「変換が通った＝正しく変換できた」ではない、という点は覚えておいて損がなさそうです。

「完全オープン」は何を指す？ライセンスを読み比べる

もうひとつ、確かめておきたい点がありました。ライセンスです。

モデル	ライセンス	商用利用
Instella-MoE	Research-only RAIL	不可（学術・研究目的に限る）
OLMo 3	Apache-2.0	可
Moonlight	MIT	可

学習コードはMITライセンスで自由に使えますが、モデルの重みは研究目的に限定されていました。仕事で使うことはできません。

同じく「完全オープン」を掲げる OLMo 3 は Apache-2.0 で、商用利用に制限がありません。「オープン」という言葉が指す範囲は配布元によって違う、という点は注意しておきたいところです。公開の広さでは Instella-MoE が上回りますが、使える範囲では OLMo 3 のほうが広い、という関係になっています。

調べて分かったこと〜自分で作れるのか

「全部公開されているなら自分でも作れるのか」という問いへの答えは、作れない、でした。学習に必要なトークンは7.45兆、設定は8台のGPUで分担する前提、データは42.5TB。規模がまるで違います。

ただし、公開された意味がないわけではありません。途中の段階の重みが6つ揃っているため、ゼロから作るのは無理でも、既にあるものに手を加える入口は開いています。そこが今回の公開の実質的な価値だと考えられます。

動かすほうは、128GBのミニPCなら容量に余裕がありました。もっとも、Ollama も llama.cpp も使えず、道は限られています。手軽さを求める段階には、まだ来ていないようです。

ここまでは公開された資料を読んで確かめた話です。ここから先は、実際に EVO-X2 で動かしてみた記録に移ります。

実際に動かしてみた：どの精度なら、どれくらいの速さで動くのか

動かす道は transformers しか残っていません。そこで Python の環境を用意し、精度を3段階（そのまま・8ビット・4ビット）に変えながら測りました。文脈の長さも2通り試しています。

測定条件	内容
測定機	GMKtec EVO-X2（Ryzen AI Max+ 395 / ユニファイドメモリ128GB）の内蔵GPU
使ったモデル	Instella-MoE-16B-A3B-Think（最終段階の重み）
測り方	各条件5回くり返し、1回目は捨てて中央値を採用（幅も併記）
生成量	1回あたり128トークン
測定日	2026年7月29日

結果

条件	使ったメモリ	読み込む速さ（tok/s）	書き出す速さ（tok/s）	消費電力平均／最大	最高温度
そのまま（BF16）／文脈4096	29.6GB	882	5.33	77W／100W	83℃
そのまま（BF16）／文脈32768	37.8GB	3,038	4.59	84W／98W	90℃
8ビットに圧縮／文脈4096	15.3GB	726	4.35	79W／109W	96℃
4ビットに圧縮／文脈4096	9.1GB	333	7.73	84W／113W	98℃

読み込みにかかった時間は、どの条件でも10.6秒前後でした。

この測定の限界（正直な注記）

今回の数字には、次の限界があります。読むときに割り引いてください。

1回あたり128トークンしか書き出していません。1回が約24秒で終わるため、長く動かし続けたときに速度が落ちるかどうかは見ていません。
条件ごとに開始時の温度が揃っていません。前の測定の熱が残ったまま次を測っており、開始温度は42℃から68℃までばらついていました。
各条件を1回ずつしか測っていません。測る順番が結果に影響していないかを確かめていません。
文脈32768で測ったのは圧縮していない状態だけです。8ビットと4ビットは文脈4096でのみ測っています。

これらを潰した測り直しを予定しています。結果が変われば、この記事に追記します。

予想が外れたところ

測る前は、圧縮したものは動かないだろうと考えていました。AMDのこのGPUでは圧縮用の部品が読み込みの時点で落ちる、という報告が出ていたためです。

ところが8ビットも4ビットも普通に動きました。報告されていた不具合は、今回の組み合わせには当てはまらなかったようです。

もうひとつ意外だったのが速さです。いちばん圧縮した4ビットが、圧縮していないものより速いという結果でした。5.33 に対して 7.73 tok/s ですから、4割ほど速くなっています。

なぜ圧縮したほうが速いのか

文章を1文字ずつ書き出すとき、GPUは毎回モデルの中身を読み直しています。このとき効いてくるのは計算の速さではなく、メモリを読み出す速さです。

そのままの状態では29.6GBを読み直し、4ビットに圧縮すると9.1GBで済みます。読む量が3分の1になれば、それだけ速く進みます。計算量が減ったのではなく、運ぶ荷物が軽くなったと考えると分かりやすいと思います。

逆に、文章を読み込む側（上の表の「読み込む速さ」）は圧縮すると遅くなりました。882 から 333 tok/s へ落ちています。こちらはまとめて計算する場面で、圧縮を解く手間が上乗せされるためと考えられます。

「文脈の領域も軽く済みそう」は当たっていたのか

この記事の前半で、このモデルは記憶領域を圧縮して持つ仕組みなので、長い文脈を扱ってもメモリを食いにくそうだ、と書きました。ここは資料を読んだだけの推測でしたので、実際に確かめています。

文脈の長さを4096から32768へ、8倍に伸ばしたときのメモリの増え方を見ました。

文脈の長さ	使ったメモリ
4096	33.0GB
32768（8倍）	37.8GB
増えたぶん：4.8GB

8倍に伸ばして4.8GBの増加でした。推測は当たっていたと言えます。128GBのユニファイドメモリなら、文脈を伸ばしても余裕があります。

書き出す速さは 5.33 から 4.59 tok/s へ落ちましたが、下がり方は1割ほどにとどまりました。

動かすまでにつまずいたところ

すんなり動いたわけではありません。最初の2回は起動すらしませんでした。

原因は、記事の前半で触れた設定ファイルの中身でした。このモデルの設定には、内部的に別のモデル形式の名前が書かれています。そのため新しい版の transformers は、モデルに同梱されている専用のプログラムではなく、自前で持っている同名の実装のほうを使おうとします。中身が違うので、当然かみ合わずに止まります。

解決は単純で、transformers を1世代前の版に下げるだけでした。古い版はその実装を持っていないため、モデル同梱のプログラムが使われます。

ここでも「通ってしまう」道があった

足りないと言われた項目を設定ファイルに書き足せば、新しい版でも起動できてしまいます。ただしそれは、記事の前半で触れた落とし穴と同じ道です。このモデル独自の仕組みが黙って捨てられた状態で動きます。エラーは出ないので、うまくいったように見えてしまいます。

今回はこの道を取らず、版を下げるほうを選びました。

熱について

圧縮した条件では96〜98℃まで上がりました。圧縮していない状態の83〜90℃より高い数字です。荷物が軽くなったぶん計算が詰まって流れるため、と考えられます。

今回は数分ずつの測定でしたので問題ありませんでしたが、長時間続けて動かす場合はこの水準を見込んでおいたほうがよさそうです。

手元で遅いなら、借りる手もある

4ビットに圧縮して7.73 tok/s でした。動くには動きますが、待ち時間は相応にあります。文章が書き出されるのを眺めながら待つ速さです。

このモデルは31.7GBと、フロンティア級のものに比べればずっと小さいので、データセンター向けのGPUを1枚借りれば快適に動きます。手元で粘るより、1時間いくらで借りて試すほうが早い場面があります。とくに「このモデルが自分の用途に合うか」を確かめたいだけなら、借りて確かめて終わりにできます。

そうしたサービスのひとつが RunPod です。

[kimono_product id="16675″]

※上記は紹介リンクです。リンク経由で登録すると、双方にクレジットが付きます。