MoE（Mixture of Experts）の話2026

昨年メモリの多いノートPCを手に入れてLLMで遊んでみた。

LLMのベンチマーク - 48's diary

　

MoE（Mixture of Experts）モデルに限りCPU推論でもメモリに乗る限りそこそこ動くという話であった。

完全に別件だがねね将棋チームが将棋界（NNUE界隈）にもMoE的手法を持ち込んでいた。

wcsc36反省会 - 48's diary

　

MoEの利点は個々のモデルが小さくても全体として精度の高いモデルになるということ、分散学習に向いているなど色々利点がある。

欠点は巨大になることと巨大な割に一枚岩のものに精度で劣るということだ。

　

LLM界隈も昨年のgpt-ossのみならず、Gemma4やQwen3.6などのMoEが目立った活躍をしている。最近のDeepSeek4 Flashなどもそうであるが、直近はQwen3.8 Flash Nextが話題だ。

　

これらをうまく動かすためにはMoEでもかなりのハードウェアが必要となるが、これらに対して工夫をしてきたのが以下のようなものだ。DS4に関してはメモリ128GBのMacで動かそうというモチベーションのようだ。

GitHub - antirez/ds4: DeepSeek 4 Flash and PRO local inference engine for Metal, CUDA and ROCm · GitHub

で、昨日からの話題がStrataである。これはQwen3.8 Flash NextをVRAM12GBのGPUとメインメモリ64GBでなんとかしようとするものである。

GitHub - Niko1221/Strata: Qwen3.8-Flash-Next (125B MoE) on a 8GB+ NVIDIA GPU: one-click install for Windows / Linux. Strata inference engine, OpenAI/Anthropic API on localhost, optional image input. · GitHub

　

今回はこちらを試してみた。

実測で80tok/s前後が出ている。4070TiS（VRAM16GB）としてはRTX5070を超えているので良いとしよう。

ちなみにRTX3090やRTX5090でも全て推奨値で試してみたが実のところあまり差異がなかった。設定変更で差異が出るのかもしれない。

うっかりHDDにモデルを置いた場合激烈に遅かった以外特別速くなるパターンはみられなかった。出力時にもアクセスがあるのでワーキングエリアになっているものと思われる。

　

つまり、RTX5090が生かせていないのでボトルネックが恐らく似たようなところにあるのではないかと推測できる。仮説としてはMoEのExpertのキャッシュヒット率が86%程度と出ているのでヒット外をCPU演算するかGPUに転送するかなどの作業がボトルネックと思われる。

PCIeの帯域かCPU演算能力である。比較できそうなマシンがないので仮説で置いておく。

旧世代でメモリ64GBのマシンがあれば是非テストして欲しい。

　

全体の雑感としては、Unslothで入れた場合よりThinkingの時間が長く応答文言も長いように思うのでこれはデフォルト設定だろうか。

とにかく、割と普通のゲーミングPC級でこの動作ができるようになるのは大きいと思われる。

特にDGX SparkやらMac Ultraやらに高額をかけた人には精神的ダメージがあるのではないかと感じた。

　

公式にはAMD: RX 9070 XT (16 GB), Ryzen 9 3900X, 47 GB RAMという例があるが、これで表記通りのパフォーマンスが出るならハードウェアに巨額を投じる意味が薄くなる。

こちら是非確かめられる人は確かめて欲しい。

 

---

こういうのは開発速度が恐ろしく速く，翌日（１０月３日）にVRAMの最低メモリ６GBから自動チューニングの対象になっている。速度的なペナルティがあるだろうが今後改善する期待もあるので動作範囲は一気に広がりそうである。

https://github.com/Niko1221/Strata/releases#release-v0.1.38

RTX Spark発売直前であるのも面白いタイミングである。

---

自宅でダウンロードするのに時間がかかったが5年前のノートPCでも動くことが確認された。放置してたマシンだが、ちょっとファン清掃しようという気になる。

 

 

 

Go言語のループ

考えてみると初期のGo言語から触ってるが残念で放置していた部分を休日を利用して整理してみた。

　

そもそもGo言語はforループが遅かった。

初期の頃は遅い理由としてループ変数のリストを先に生成しているのだと説明を聞いたことがある。つまり，０～５のループを回すときに，メモリ上にリスト{0,1,2,3,4,5}を生成していたのである。

　

その後さすがに修正されたが，面白いことに1.21から1.22でスコープの問題で再度見直されることになった。これは並行計算を実際にコーディングしている人は経験しているだろう。例を挙げよう

　

for i := range 5 {

  go func() { fmt.Println(i) }()

}

　

上記のプログラムでループ変数iをGoroutine内で参照しているが，この参照時に既にiがインクリメントされていることがある。

で，1.22以降ではこの参照されるiのアドレスをループ中で別のものになる実装となった。初期の思想に戻った感じでもある。速度面のペナルティより安全側をとったということだろう。

これはコンパイルオプションloopvarで選択できる。リストが巨大な場合など特殊なケースではパフォーマンスに大きな影響が出る。

　

次に境界チェックである。

これはループに限らないが主にループ内で多大な影響になる。

golangでBCEを意識してスライスへのアクセスを速くする #Go - Qiita

BCE を意識して Go のコードを高速化する

　

実はこれはコンパイルオプション-gcflags="-B"でチェックしないようにできる。

場合によると10%以上の高速化となる。

　

最後にループ展開である。

ループ展開 - Wikipedia

　

今のCPUはレジスタ数や演算器数が多く同時処理ができるものが多いので，コンパイラ側で自動ループ展開するのが一般的になっている。

が，何故かGo言語ではこれを未だに行わないので場合によっては手動でソースを弄りループ展開してやると高速化することがある。

これも議論には何度も上がっているので今後のバージョンで対応されるかもしれない。

手元で試したものでは4命令展開や8命令展開まで高速化したケースがあった。

実効環境毎に最適形が異なるのでソースを弄るのは美しくない。

　

低レイヤコーディングを人間が行うことは減っているらしいので，今後はどうなることやら

　

注意点ばかり挙げたので否定的な話に思えるが，実際のところはバージョンアップのたびに少しずつ性能改善があるので初期から比べるとループは随分と速くなっている。

 

AIに詳しい人

ちょっと休日の空いた時間でメモしておきます

可能ならソフトランディングの一助になればいいと思ってのことです

　

　

将棋界は結構怖いところです

ふと，「将棋界はエコーチャンバーを起こしやすいですか」とGeminiに聞いてみたところ，以下のようでした

将棋界は、その構造やファンのコミュニティの性質上、エコーチャンバー（類友の閉じた空間で特定の意見が増幅される現象）が比較的起きやすい環境にあると言えます。
主な要因は以下の通りです。
1. 狭く濃いつながりのコミュニティ
将棋ファンや棋士、関係者のコミュニティは、サッカーや野球などのメジャースポーツに比べて規模が小さく、「将棋ムラ」と表現されるほど緊密な関係性を持っています。SNS（特にX/旧Twitter）上でも、ファン同士が同じクラスタ内でフォローし合うため、特定の棋士への称賛や、特定の出来事に対する批判が一気に偏って広がりやすい性質があります。
2. 「棋力」によるヒエラルキーと権威性
将棋には明確な段位や実力の差（棋力）が存在します。そのため、プロ棋士や有力なアマチュア、あるいは声の大きい「有段者」の発言が絶対視されやすく、異論や反論が挟みにくい空気が生まれがちです。これにより、コミュニティ内での「正解」とされる意見が固定化されやすくなります。
3. 多様化する推し活と感情の先鋭化
近年の将棋ブームにより、純粋な盤上の戦いだけでなく、棋士のキャラクターや人間性を応援する「観る将（みるしょう）」と呼ばれるファンが急増しました。これは素晴らしい発展である一方、ファン同士の「推し」をめぐる対立や、特定の棋士に対する過剰な擁護・批判が、閉じたコミュニティの中でエスカレートしやすい側面も生み出しています。
4. 過去の大きな騒動（AI不正疑惑など）での前例
2016年に起きた将棋ソフト不正疑惑騒動の際には、ネット上や関係者の間で根拠の薄い噂や批判が瞬く間に増幅され、客観的な事実が見失われるという典型的なエコーチャンバー現象が発生しました。この件は、将棋界が一度特定の方向に流されるとブレーキが効きにくくなるリスクを証明した事例でもあります。
一方で、エコーチャンバーを打破する要素もあります。
それは「盤上の真理（結果）は絶対である」という点です。どれだけ周囲が特定の意見や評価をエコーチャンバーによって増幅させようとも、対局の勝敗やAIによる形勢判断という「客観的な事実」がすべてを覆します。そのため、最終的にはファンの間で歪んだ認知が修正されやすいという自浄作用も持ち合わせています。
将棋界の人間関係やファンコミュニティの動向について、特定の棋士のケースや、最近のSNSでの議論など、さらに詳しく知りたい具体的なトピックはありますか？

　

もう少しあったのですが，Geminiらしくないくらい辛口でしたので切っておきました

事前に想定した以上に的確で付け足すことがあまりないくらいです

連盟が大きな訴訟で負けてばかりなのはエコーチャンバーで勘違いしやすいのが一因だと昔誰かがコメントしていましたが，まぁそういう面は大きいと感じます

　

個人的にも思い当たるところはありますが，「権威」が怖いのでここには記載しないことにしておきます

世の中的にはAI界隈恐ろしく伸びている分野ですので，一時期の中途半端な知識で一部を全部のように語ると大恥をかきます

お気をつけください

　

---

一時期はメディアの方やプロ棋士の方などが間違っている点などやんわり指摘していた時期もあったのですが，基本的に間違っていてもその場が盛り上がる方が興行的には喜ばれるようです

 

AppleのNeural Engine

以前からNPU関連に興味を持って調べています。

多くはINT8演算ですがそうでもないものもあるようです。

40AI TOPSなどMSが定義している性能があるのですがこれはINT4のものが多いです。

まだまだ残念な位にキラーアプリがありません。

　

GPU側はFP8やFP4へ移行しつつあります。

fp4の話（4ビット浮動小数点数） - 48's diary

MXFP4やNVFP4の話（ブロック浮動小数点数） - 48's diary

こちらはLLMで既に実績というか最先端を切り開いています。

大違いですね。

　

で，割と最近知ったのですが，AppleのNeural Engineはfp16を扱うらしいです。

他者はほぼINT演算なのでどこかの段階で量子化のキャリブレーションが必須になるのですがfp16ならギリギリキャリブレーションなしで推論エンジンが動かせるので汎用的に扱える感じです。

　

で，これに関してリバースエンジニアリングしてLinuxドライバを書こうとしている人の記事で結構面白い発見がありました。

Retrospectively Reverse-Engineering Apple's Neural Engine | Eileen Yoon

fp16保持ですが，演算機はQ16.16の固定小数点演算だそうです。以前，整数演算でも同じ演算器を使うとどこかに書かれていたようですが納得の実装です。

また，32点ルックアップテーブルでの線型補完器を持っており非線形の活性化関数のアクセラレータとして働くそうです。

面白いですね。

　

他のNPUだと整数の行列演算ばかりが話題ですが，こちらはかなり実用的に実装されているようです。低レイヤまで手が入るかどうかわかりませんがもう少し調べて遊べそうなら弄ってみたいものです。

Appleはハードウェア設計からドライバ開発，最終製品まで作りますので，こういった新しいものは無駄がなく実用化するのが上手なようです。

といっても現時点でANEがあまり有効に使われていないとの批判は多いようです。今後を期待しましょう。

　

最後にですが，新しいMac miniに搭載されるM6と新しいiPhoneに搭載されるA20 ProにはANEが以前の二倍入っているそうですよ。

 

 

KataGo近況

本日第51期囲碁名人戦第3局がありました。（これ執筆中現在進行形なのですが）

www.youtube.com

　

電通大の伊藤先生がゲスト出演してコメントを述べられておりました。

ふと色々気になって調べてみたところ随分情報が遅れていることが分かって、少しアップデートしておきました。

　

KataGoが7月末にTransformer Modelに対応しました。まだ、Nested Bottleneck Modelがデフォルトです。

KataGoが8月末にTransformer Modelをデフォルトにしました。すでに分散並列学習の教師データ生成もTransformer Modelに移行しています。

強化学習のグラフを見る限りはっきりと強くなってそうです。

　

移行が速いですね。

そして、OpenCLライブラリ使用が推奨となっていたのですが、TransformerとなるとCUDAの最新がチューニングが進んでおりCUDA推奨となっています。TensorRTよりもCUDNNの方が性能が出るらしく昨今のチューニング現状は理解しづらい状況です。

https://github.com/lightvector/KataGo/releases

https://katagotraining.org/

　

CUDNNも9.8.0以降でないと性能が出ないらしいので遅れている人はライブラリもアップデートする価値がありそうです。

LLMブームもまだまだ盛り上がりそうですし、時代はTransformerでしょうか。

 

 

盆休み

今年の盆休みは例年より長かった

職場の電気工事が入ったためで，無理に出勤してもパソコン・エアコンすら動かないのでどうしようもなかった

　

若い頃ほど計画的に旅行したりすることもないので，実家の方のスケジュールを確認してみると，墓参りと引っ越しがあるようなので手伝いと称して様子見に行ってきた

　

大した戦力にはならないのだが，免許返納した親を墓参りに連れていくくらいはどうってことはない

タクシーを使うのはどうも苦手らしい

暇そうだと言うことで随分顔を見ていない親戚への挨拶もしたり古本を運んだりという話になって

結局１週間で２回フルの給油をして1000kmほどドライブすることになった

　

もちろん盆休みの渋滞に嵌っているので移動時間は随分とかかる

渋滞にはよいこともあって，電話ではわざわざしない話を聞く機会になった

帰りが遅くなったので回転寿司でいいかと適当に停めてみても大行列で諦めることになった

結果普段よりスーパーのお惣菜率の高い盆休みとなっていたが自分自身食に頓着しないのでどうということはない

　

岡山へ帰り，久しぶりに後楽園の幻想庭園と移転したばかりのビールバーに挨拶して今年のお盆は終わり

　

無計画な割に色々と行事があったもんだ

 

24点法

24点法に関しては以前からたびたび取り上げている。

将棋の駒落ち戦の宣言法について - 48's diary

連盟モバイルの勝率表示の件 - 48's diary

珍しい入玉局面の話 - 48's diary

wcsc35反省会 - 48's diary

CSAで提案したこと2025 - 48's diary

連盟モバイルでは27点法の白ビールで評価値を出している点を確認した。プロの入玉ルールと異なる点も理解されていると思っている。

　

先日7月18日のCSA例会で，第38回選手権では入玉宣言法24点法に変更と決定したそうだ。個人的に休日出勤でオープンキャンパスの役目があったので全く関与していない。

31点以上ある場合は「KACHI」宣言が可能
24点以上ある場合は「HIKIWAKE」宣言が可能

と議事にある。

　

どちらかというと電竜戦で先行実験をしてから検討に上がるつもりでいたが実験前に決定事項になってしまったようだ。選手権に関しては運営側ではないがやや心配である。

また，プロトコルに関しては2025年提案では「宣言法でプレイヤーが行うのは宣言をすると言うだけ」であることを確認していたのでプロトコルの追加は不要との認識を共有していたはずなので少し違和感がある。

事実「宣言します」以外の発言はないはずである。宣言したのち点数を数え，31点以上なら勝ち，24点から30点の間なら無勝負，宣言条件を満たしていないなら負けとなるのがルールであるとの認識だ。

　

で，指し直しは無いんだろうか？

議事に詳細が無いのでちょっとよく分からない。