#インフラ

大規模言語モデルの性能は、モデルの中身だけでは決まらない。実際には、学習したモデルをどう動かすか、つまり推論基盤の出来が応答速度やコスト、安定性を左右する。今回の元記事は、GLMを手がけるチームが、その推論インフラを自分たちで組み上げていった経緯をたどる内容だ。単なる技術自慢ではなく、なぜ外部の完成品に乗るだけでは足りなかったのか、そして自前化がどこまで効くのかを考える材料になる。 元記事が中心に描いているのは、GLMのチームがモデル開発だけでなく、そのモデルをユーザーに返すための推論インフラまで自分たちで作った、という話だ。推論インフラとは、学習済みモデルに入力を与え、応答を生成し、同時に多数のリクエストをさばくための仕組みを指す。ここが弱いと、モデルが賢くても返答は遅くなり、コストもかさむ。 記事では、最初から万能な仕組みがあったわけではなく、まず既存のやり方で運用を始めたことが示される。ただ、モデルが大きくなり、利用が増えるにつれて、一般的な推論環境では限界が見えてきた。GPUの使い方がうまくいかない、レイテンシが読みにくい、ピーク時にスケールさせるのが難しい、といった問題が積み

PlanetScaleが、sharded Postgres をうたう「Neki」をplatform previewとして公開した。単に「Postgresをもっと速くした」と言っているのではなく、1台のマシンの限界にぶつかる前提で、最初から分散運用できる形に作り直した、という話だ。元記事はかなり技術寄りだが、要するに既存のPostgresアプリを大きく壊さずにスケールさせたい人向けの新しい選択肢を出した、というニュースである。しかもPlanetScaleは、これをMySQLで培った分散運用の知見の延長として語っている。 Nekiは、PlanetScaleが公開した sharded Postgres のプラットフォームだ。platform previewとして利用できるようになったが、記事でははっきり「この段階のNekiで本番ワークロードは走らせるべきではない」と注意している。まだ変化が大きく、壊れる変更もありうるからだという。 PlanetScaleによれば、Nekiは同社が8年間かけて運用してきた大規模な sharded MySQL クラスタの経験から生まれた。何千もの本番ワークロード

読んでまず思ったのは、Cloudflareらしいな、でも本丸はそこじゃないな、ということだった。 こういう「ワンタップで使えるようにしました」という話は派手に見えるけれど、実際には面倒な下ごしらえを一段減らしただけで、何を公開するか、どう安全に運ぶか、どう使われたかを見届けるかは別問題のまま残る。この記事はその線引きをかなりはっきり書いていて、そこが好感だった。 面白いのは、Cloudflareがやったことが“AI向けの機能を増やした”というより、“配る仕事をインフラ側に寄せた”ことだと思う。HTMLに bridge を差し込んで、browser 側で WebMCP をつなぐ。要するに、各サイト運営者が毎回同じ接着剤を貼らなくてよくなる。これは地味だけれど、レガシーなサイトが多い世界ではかなり効くはずだ。こういう「面倒だけど避けられない部分」を押し下げるのは、インフラ企業の強みがそのまま出るところだと思う。 ただ、記事がちゃんと釘を刺しているように、これでサイトが“agent-ready”になるわけではない。ここを読み飛ばすと危ない。 商品検索や予約、購入みたいな「実際に何かをする」動