最近アルゴリズムサービスを書いていて、twap や vwap のようなモジュールをいくつか展開したところ、またこの古い問題に直面しました。
C++ でクラス名に頼ってセマンティクスを無理やり押し付けると、名前はすぐに制御不能になります。TwapOrderManager、VwapOrderManager、AlgoOrderManager のようなものは、書き進めているうちに「自分の構造が手に負えないことはわかっているけど、とりあえずプレフィックスを付け足しておこう」という感じになってしまいます。端的に言えば、フォルダで階層分けをして、さらに namespace を一つ追加するのは、コードの潔癖症なのではなく、C++ に Java のようなネイティブな package システムがないことによる空隙を埋めているのです。
今回フォーラムを巡回していて、一番印象に残ったのは、「またランキングを出した」というところではなく、「VRAMが足りないから、パラメータがどれだけ大きくても無駄だ」という、かなり生易しい（陳腐な）一言でした。
以前は「モデルが遅い」ことを計算能力の問題だと捉えがちでした。しかし、後になってよく気づいたのは、多くのケースでGPUの計算能力が足りないのではなく、データが適切な場所に留まらないことが原因だということです。メモリのパスが少し変わるだけで、トークン速度は少し落ちるというレベルではなく、直接落ちてしまいます。
ランキングだけを見ると、一番心が動くのは間違いなく 31B です。
しかし、実際にマシンを前にすると、やはりアップグレードされていない RTX 3060 12GB の方が、判断はすぐに変わります。どう言えばいいか、ローカルにデプロイするということは、最後に一番派手なものが勝つのではなく、長く一緒にいられそうなものを選ぶことなんです。私にとっては、今回まず試す価値があるのは 31B ではなく、26B A4B です。
初日に私がやりたかったことはとてもシンプルでした。Gemma 3 に対応するアップグレード版を見つけて、まずダウンロードして動かしてみることです。
しかし、全体をざっと見ていくと、少し戸惑いを覚えました。以前慣れていた 4B / 12B / 27B という命名規則がなくなり、代わりに E4B、26B A4B、31B といったものが現れたのです。どう言えばいいか、今回Googleが真に変わったのは、単にモデルのサイズだけではなく、「この一連のモデルをどう理解すべきか」という部分まで変わってしまったからです。
普段は家に引きこもりがちなので、2026年の清明連休に久しぶりに出かける機会があり、偶然松江大学城の文匯路をぶらついていました。最初に思ったのは景色ではなく、お店のことでした。
「好特卖不稀奇」なんてものは、上海ではもうどこにでもあるので驚きませんでした。私を立ち止まらせたのは、「零食很忙（おやつが忙しい）」という店を見つけたことです。このブランドは以前、実家の方でよく見かけるもので、私はずっとここから上海までは少し距離があると思っていたんです。ところが、文匯路を歩いているうちに、私の固定観念はあっけなく崩れ去りました。
今の私の判断はかなり明確です。「零食很忙」のような店が松江にオープンできたのは、上海が急に「下層化」したからではありません。むしろ、松江自体が、多くの人が想像するような上海の片隅の場所ではないからです。ここを郊外だと見なしても、十分な人流があり、十分に若い客層がいて、滞在時間も長い。これを単なるベッドタウンだと見なしても、その背後には松江という地域の歴史的な基盤や、大学城の科学技術リソース、さらには上海南西の玄関口としての新しいポジショニングがあるのです。
Codex を使っている期間、ずっと気になっている問題があります。デフォルトの思考レベルが medium なのですが、ネットで話題になっている GPT-5.4 のような話を聞くと、皆とてもすごい口ぶりをします。実際に自分で試してみると、medium、high、xhigh は一体どれくらい違うのか、公式からも特に分かりやすい表が出ていません。
私なりの結論はかなり明確になりました。普段のコーディングでは、私は迷わず high を使う方がいいと思っています。medium が使えないわけではありません。ちょっとした作業や、細かい修正、方向性を試す程度なら問題ありませんが、複数のファイルを変更したり、要求に曖昧さがあったりして、コードを見ながら判断を求められるような状況だと、medium では計算能力の配分を間違えやすい気がします。逆に xhigh はあまり頻繁には使いません。行き詰まった大きなタスクのために取っておくのが良いと思います。
倉庫の構成を一周確認した結果、逆に確信したことがあります。このシステムは、単体のモデルがどれだけ強力かではなく、どのレイヤーにコストを負わせるべきか、という点にかかっているということです。
最も明白なシグナルは、現在有効な published.runtime.json が依然として 2026年4月2日に生成された minimax-m2 であることです。しかし、2026年4月3日16:38の 5f17088 は、blog-style-suite のデフォルトプロバイダーをローカルの LM Studio 内の gemma-4-26b-a4b に切り替えています。これは一見すると前後で矛盾しているように見えますが、実はそうではありません。むしろ、このパイプラインに分業が始まったことを示しています。
トークンが十分にある場合、最も手っ取り早い方法は非常に粗暴ですが、過去の記事をそのままモデルに投入し、自分で学ばせることです。
問題は、この方法はたまに1記事書くのには適していますが、繰り返し書くのには適さないということです。もしブログ執筆を長期的なワークフローとして真剣に取り組むのであれば、「生データ（歴史的な文章）」というアプローチは、すぐに「高コストで散漫」になってしまいます。