中国CXMT、メモリチップの新プラットフォームが量産開始

ロイターが9月20日、中国のメモリチップメーカーCXMTが新しいメモリチッププラットフォームを量産段階に移行したと報じた。報道本体の詳細は現時点で収集できておらず、仕様や生産規模の内訳は記事で確認する必要があるが、中国勢のメモリ量産能力がさらに一段拡大する方向性を示す出来事といえる。

供給側のこの動きは、LLMと無関係ではない。LLMの推論、特にトークン生成はメモリ帯域に律速されやすく、メモリはAIインフラの供給制約そのものだからだ。実際、同日のLocalLLaMAコミュニティでは、後述するようにメモリ帯域をオーバークロックで引き上げて生成速度をほぼ倍増させた実験報告が話題になっている。ロイターの報道も同じコミュニティですぐに共有され注目を集めており、メモリがLLM実運用の関心事であることを裏付ける光景といえる。

英語の関数仕様を小さなモデルの「重み」にコンパイルするProgramAsWeights

ワーテルールー大学の研究者が、英語の関数記述をコンパイルしてローカル実行できる「ニューラルプログラム」に変えるオープンソースプロジェクト「ProgramAsWeights（PAW）」を共有した。発想は「コンパイルと推論の分離」だ。やりたい処理を英語で記述するとコンパイラがタスク特化のLoRAアダプタを生成し、それを小さな「インタプリタ」モデルにロードしてCPUでもローカル実行できる。paw.compile_and_load("Classify urgent emails") のような1行で関数が得られ、コンパイル後の呼び出しに外部APIは不要になる。

構成は明快だ。標準コンパイラはファインチューニング済みのQwen3-4Bで、タスク記述から疑似プログラム（整えたタスク説明と少数の入出力例）とともにLoRAアダプタを生成し、凍結されたQwen3-0.6Bのインタプリタに適用する。訓練は（タスク記述、入力、出力）のトリプルで行い、凍結インタプリタを通った勾配がコンパイラ側へ流れる。アダプタ生成の仕組みはtext-to-LoRA（Charakorn et al., 2025）に近いという。コンパイルは数秒で完了し、以降の推論に大きなモデルは不要になる。GPUがあればコンパイラを自前ホストすることも可能で、重みは公開済みだ。

結果も示唆的だ。仕様ベースでtrain/testを分割した自作ベンチマークFuzzyBenchで、0.6Bのインタプリタは73.4%の完全一致精度を達成し、Qwen3-32Bへの直接プロンプト（68.7%）を上回った。さらに追報「Compile by Training」では、生成されたアダプタを教師モデルが合成した例で100ステップ追加訓練（デプロイ環境で約1分）することで、元の評価で完全一致が取れなかった仕様だけを集めたFuzzyBench-Hardで83.6%の意味的精度に達するという。コンパイル時間と精度のトレードオフが異なる2つのコンパイラを、同じローカル実行形式で提供している。

投稿者はJevへの注目が高まる中でこれを共有したと明かしている。「大きなモデルが道具（小さなプログラム）を作り、現場では小さなモデルで繰り返し実行する」という方向性は、LLMの周辺で同じ流れとして読める。

CMP 170HXのオーバークロックで1.89TB/s──Qwen 3.8 27Bが110→202 T/S

LocalLLaMAでは、マイニング向けの中古カードCMP 170HX 40GBのメモリをオーバークロックし、帯域を1,386.2GB/sから1,890.1GB/s（+36.4%）まで引き上げた実験報告が注目を集めている。設定は他に何も変えていないにもかかわらず、Qwen 3.8 27Bのトークン生成速度が110 T/Sから202 T/Sへとほぼ倍増したという。このときのGPU消費電力は300ワットで、温度はむしろわずかに下がったとされる。

昨日このブログでも「250ドルのマイニングカード2枚でQwen 3.8 27Bを30 tok/s」という報告を紹介したが、同カードの潜在能力を引き出す試みはその後も続いている。投稿者は、出荷時の設定でカードのポテンシャルが大幅に制限されていると指摘しており、安価な大容量カードがローカルLLMの入口になりつつある現状を映す報告といえる。

何も変えずにメモリ帯域を36%上げるだけで生成速度が84%伸びたという結果は、トークン生成がメモリ帯域律速であることの分かりやすい実例だ。冒頭のCXMTの量産報道と合わせ、「メモリこそAIのボトルネック」というテーマが供給側と消費側の両端で同時に動いている日だった。

重みを超曲面から動的生成──パラメータ16%でどこまで迫れるか

研究寄りの個人実験では、デコーダ1層をループで再利用しつつ、反復のたびに重みそのものを更新するアーキテクチャ実験「LoopSLM」が共有された。Universal Transformerに近い発想だが、ループの深さを入力に反映する代わりに、側の重みを動的に更新する点が異なる。学習した「超曲面」の断面から重みデルタΔWlを生成し、Wl = W0 + ΔWlとして各反復の重みを構成する。周期関数には三角波が最も良い結果を出し、その振幅・周波数・位相を学習する。さらにGated Linear Attentionで入力から状態ベクトルを計算し、超曲面の形状を変調することで、重みデルタを系列の内容に応じたものにしているという。

FineWeb-Eduの10Bトークン標本を使った事前学習（GPT-2の凍結埋め込み、位置符号を使わないNoPE、系列長1024、1万ステップ）では、標準的な24層デコーダ（約1.7億パラメータ）に対し、三角波＋文脈変調のループブロック3つの構成は約2,700万パラメータ（約16%）で、単にループを展開しただけのベースラインを明確に上回る損失に達した。絶対的な損失では依然としてフルパラメータの通常構成が最良だが、訓練のボトルネックがVRAMである現状で「大幅に軽い構成でどこまで迫れるか」という問いに1つのデータポイントを与える実験といえる。投稿者は次のステップとして、より大きな文脈ベクトルと拡張した関数基底で再挑戦する予定を明かしている。

Jev、国内テックメディアでも解説記事──メモリ検索の活用報告も

先週から海外コミュニティで注目が続く「Jev」（米TypeSafe AIが9月15日発表、元OpenAI研究者が開発）について、国内ではITmedia AI+が解説記事を公開した。「文章を書かないAI」としてJevがなぜ話題なのか、LLMとどう違うのかを整理したもので、「“スマートなif文”と考えてみて」という捉え方を紹介している。海外だけでなく日本のAIコミュニティでも関心が広がっていることの裏付けといえる。

実践側の動きも続く。MachineLearningコミュニティでは、Jevを記憶の検索に使う「jev-recall」という試みが「ゲームチェンジャー」として共有された。現時点ではGitHubリポジトリの共有のみで詳細はこれからだが、Jevの応用先が分類や抽出のような処理から個人のメモリ検索にまで広がりつつあることがうかがえる。

Claude Codeのセッション開始時入力、なぜ9万トークンになるのか

Qiitaでは、Claude Codeのセッション開始時に入力されるトークン数を分解した検証記事が注目を集めた。著者によれば、セッションは最初の応答の時点でもう7〜9万トークンを入力している。自身の書いた文書（CLAUDE.md・auto memory）を削って79Kまで下げた翌日、同じ依頼文で始めたら86K、その翌日には88Kに戻っていたという。何がトークンを戻したのかを、要素の除去と復元を繰り返しながら「毎回入るもの」として分解していく内容だ。

セッション開始直後から数万トークンが使われる構造は、エージェント開発におけるコンテキスト設計の重要さを示す。何が毎回入り、何が削除でき、何が復元されるのか。自動で注入される要素を把握することは、限られたコンテキストを有効に使うための前提条件といえる。