どうも、マイクです。おはようございます。
九月十九日、土曜日の朝七時になりました。今週も「zenncast」スタートしていきましょう。
この時間は、Zennに上がっている最新トレンドの記事の中から、気になるものをピックアップして、ゆるっと、でも中身はしっかりめにご紹介していきます。

今日はお便りコーナーはお休みで、そのぶん記事紹介たっぷりめでいきますね。

さて、きょうご紹介する記事は、全部で五本です。
前半三本は、いま話題の推論専用モデル「Jev」まわりの話。
後半二本は、データ分析基盤の作り方と、GPUサーバで起きたちょっと怖いトラブルシュートのお話です。

それでは、一つ目からいきましょう。

まず一つ目は、「Jev（ジェブ）」という新しい推論専用モデルを紹介している記事です。
ここでのポイントは、普通の大規模言語モデル、いわゆるLLMを「文章を一個ずつ考えて返すCPU」だとすると、Jevは「構造化された選択肢に対して、高速にスコアを付けるGPU的な推論エンジン」として設計されている、という見立てなんですね。

Jevは、人間が読む自然言語をそのまま出すというより、最初からJSONみたいな構造化データを出すことを前提にしています。
その代わり一リクエストあたり、およそ五百ミリ秒で、最大二百五十六個の選択肢に同時にスコアを付けられる。
深い推論とか、長文をダラダラ生成する用途には向いていないんですけど、「危険なコマンドを実行していいか、YESかNOか」をチェックするガードレールだったり、たくさんあるツールやスキルの中から「どれを使うか」を一瞬で選ぶ、みたいな用途で、既存のLLMを安価かつ高速に補助できるのが肝だ、と記事では説明しています。

著者が強調しているのは、「五百ミリ秒で二百五十六並列」という前提が、これまでの設計発想とはだいぶ違う、という点です。
リアルタイム性が求められるエージェントとか、ゲーム操作、自動ブラウザ操作みたいな場面では、これまで「LLMだとちょっと重いよね」とされていたところに、新しい設計のチャンスが出てくるかもしれない。

そのうえで、プログラマ目線で見ると、「入力の事前条件をどう決めるか」「出力の構造をどう定義するか」「どのくらい並列させるのか」といった設計の重みが増してくる、と指摘しています。
記事の結論としては、Jevのようなモデルは、LLMを単なるチャットボットから、「リアルタイム計算機」として捉え直す転換点になり得る、と。
チャットでおしゃべりする相手、というより、システムの中で高速に判断してくれる、裏方の計算ユニット、みたいな位置づけに変わっていくかもしれない、というお話でした。

。。。。

続いて二つ目、こちらもJevの話なんですが、もうちょっとテクニカルな視点から、「それ、普通のLLMでもできるんじゃない？」と検証している記事です。

TypeSafe AIのJevは、「文章をきれいに生成する」ことよりも、ソフトウェアから直接呼び出して使える、「判断と確率」を高速に返す専用モデルとして紹介されています。
この記事の筆者は、まず「LLMでも似たことできるんじゃない？」と考えて、実験をしているんですね。

やってみたこととしては、従来よくある「LLMにJSONを出させて、その内容をパースする」というやり方をやめて、
あらかじめ選択肢を一つ一トークンに割り当てて、そのトークンごとのlogit、つまり生のスコアを直接読む、という方式をGemmaスリーで試しました。
その結果、自己回帰的にJSONを出させるやり方と比べて、最大で七十七倍速くできた、というデータが出ています。

さらにゲーム制御の話も出てきます。
JevはDOOMとかマリオみたいなゲームを、およそ百ミリ秒単位で操作できると言われているんですが、記事の推測では、画像を直接見ているのではなくて、ゲーム側から渡される構造化データの「ハーネス」を通して制御しているんじゃないか、という見立てです。
同じ環境で旧世代のLLMと比較すると、たしかにJevの方がいいスコアだったんですが、最新の高速LLMとは公平な条件で比べられていなくて、「専用モデルが決定的に優れている」とまではまだ言えない、と冷静に結論づけています。

一方で、Jevを開発している側は、「既存LLMが出す確率値にはクセが多い」という指摘もしています。
選択肢の並び順とか、トークナイザの細かい仕様、それからモデル特有の『自信過多』な性格のせいで、出てくる確率が現実の確率とはかなりズレることがある。
Jevの価値は、そこを統計的にきちんと調整して、「信頼できる確率」を返すところにあるんだ、という主張です。

筆者としては、「じゃあ、その“正しい確率”が本当に必要になる場面ってどこなのか」とか、「LLM側をちょっとキャリブレーションするだけでどこまで改善できるのか」といった点は、これからもっと検証が必要だね、というスタンス。
専用モデルの面白さも認めつつ、汎用LLMの工夫次第でどこまで追いつけるのか、これからの比較が楽しみになる内容でした。

。。。。

三つ目もJev関連ですが、今度は「ハーネスエンジニアリング」という現場寄りの話です。

LLMを現場で本気で使おうとすると、人間が細かい判断を何度も挟んであげる「ハーネス」作りがボトルネックになりがちだ、という問題提起から始まります。
ここでいうハーネスっていうのは、「このプロンプトを投げて、こういう条件ならツールを呼ぶ」「この場合は人間のレビューに回す」みたいな、周りを取り巻く制御ロジックのことですね。
さらに、確率的な最適化──たとえば「この設定だと成功率が何パーセントでした」とか──も、モデルをアップデートするたびに全部見直しになって、技術的負債になりやすい、という悩みも挙げられています。

そこで著者が目を付けているのが、「高速で激安な、型付きの判断APIとしてJevをハーネスに組み込む」というアプローチです。
Jevに、きちんと型の決まった入力と出力を与えて、「ここはYES／NOを決めてもらう」「ここはレベル分けしてもらう」といった判断部分を、ほぼ決定論に近い形で外出しする。
そうすることで、LLM側の挙動が変わっても、ハーネスの判断ロジックはあまり揺れないようにしよう、という狙いです。

具体例もいくつか紹介されています。
一つは、Claude CodeのAuto Modeのように、「コマンドを本当に実行して大丈夫か」「これは危険じゃないか」をJevに分類させて、許可・拒否を決める仕組み。
もう一つは、「スラッシュ・グリル・ミー」という仕様詰めツールで、ユーザーの要求に対してJevが一次評価を行い、その結果をもとに要件定義のADR──アーキテクチャ・ディシジョン・レコードですね──を自動生成する仕組みです。
このやり方だと、人間がチェックしなきゃいけないポイントは残しつつ、「まだ決まっていない部分」はハッキリと明示的に残せるようになる。

著者は、JevがLLMそのものを置き換えるというよりは、
ツールコールの結果をまとめて判定する、とか、コードや仕様に対してラフなLinterとして機械的にチェックを入れる、といった「周辺の判断作業」を、安価に自動化する部品として大きな可能性がある、と見ています。
まずは小さな例から組み込んでみて、ハーネス作りの負担がどれだけ減るか試してみる価値があるよ、という背中を押す締め方でした。

。。。。

四つ目は、ちょっとガラッと変わって、データ分析基盤「Laplace（ラプラス）」をどう作ったか、その経緯と設計思想をまとめた記事です。

元々の構成は、Redashで本番データベースを直接たたく、というよくあるパターンだったんですが、
これだと「重いクエリはなかなか返ってこない」「ビジネスメンバーが自分で分析しづらい」「個人情報、いわゆるPIIの扱いが怖くて、権限を極端に絞るしかない」といった限界があったそうです。

そこで新しく組んだのが、BigQueryとdbtを組み合わせた分析基盤。
データはBigQuery上で整形して、dbtの `schema.yml` を唯一の定義源にすることで、セマンティックレイヤー──「指標が何を意味するか」を定義する層ですね──をLightdashの上に構築しています。
重要なのは、「指標定義」と「権限制御」をすべて一か所、つまりdbtの定義に集約して、人間もAIも、そこを共通の参照元として使うようにしたところです。
これによって、間違った集計をしづらくなりますし、PIIが勝手に漏れてしまうリスクも抑えながら、非エンジニアでもセルフサービスで分析ができるようになった、というわけです。

さらに面白いのが、LightdashのAPIを包んだMCPサーバを自前でホストしている点です。
これを入り口にして、自然言語で問い合わせると、そのままダッシュボードまで生成してくれる、AIベースのアクセス手段を用意しています。
その際、AIがPIIを読まないようにする仕掛けや、期限付きの権限付与、監査ログとの連携といったガバナンス周りもしっかり実装している。

全体としては、およそ一人月、しかも書いたコードのほとんどはLLMに生成させたもの、という軽い工数で、複数プロダクトに対応できる安価な分析基盤を実現した、というのがこの記事のオチになっています。
少人数チームでも、設計を工夫すればここまでできる、という良い事例ですね。

。。。。

そして五つ目。
最後は、Ubuntu二十四・ゼロ四を載せたNVIDIAのDGX Sparkで、apt upgradeを実行したら大変なことになった、というトラブルシュート記事です。
GPUサーバ運用している方には、ちょっと背筋が冷たくなる内容かもしれません。

起きたことをざっくり言うと、GPUドライバとカーネル周りの依存関係がずれてしまって、「起動中のカーネルに対応するNVIDIAモジュールだけが欠けている」という不整合状態になってしまった、というものです。

apt upgradeをかけたあと、カーネルだけが「ろくてんじゅうなな・ゼロ・一ゼロ三二・エヌビディア」に上がったのに、そのバージョン用の `nvidia.ko` などのモジュールパッケージが入ってこなかった。
その結果、GUI側がGPUを使えなくなってしまって、描画その他が全部CPUで頑張ることになり、CPU負荷が一気に跳ね上がった、という状況です。

そこでapt full-upgradeをかけてみたところ、今度は「ろくてんじゅうなな・ゼロ・一ゼロ一四」向けのカーネルと、それに対応するNVIDIAドライバ一式は入ったんですが、
実際に起動しているカーネルのバージョンとは噛み合わないまま、という非常にややこしい状態に。

最終的な復旧手順としては、起動中のカーネルバージョンをきちんと確認したうえで、そのカーネルに対応する `linux-modules-nvidia-ゴーハチゼロ・オープン・ろくてんじゅうなな・ゼロ・一ゼロ三二・エヌビディア` を明示的にインストールし、
それに対応した `nvidia-driver-ゴーハチゼロ・オープン` のバージョンも合わせて入れて、NVIDIAのドライバスタック全体のバージョンをそろえることで復旧しています。

あわせて、/proc/pressure配下のファイルを使うと、CPU・メモリ・ディスクのどこが詰まっているのかを数値で把握できる、というTipsも紹介されています。
SSHがやたら遅いとか、リモートが重いと感じたときに、すぐ「ネットワークのせいだ」と決めつけずに、リソースの圧迫状況と、GPUドライバがちゃんと動いているかをまず確認したほうがいいよ、という教訓で締めくくられています。
GPUサーバを本番運用していると、「たかがapt upgrade」とはいえ、怖いですね……というリアルな実録記事でした。

。。。。

というわけで、きょうの「zenncast」では、全部で五本の記事をご紹介しました。
ざっとおさらいすると、
前半三本では、Jevという推論専用モデルが、チャットボットというより「リアルタイム計算機」としてどう位置づけられそうか、その性能をLLMとどう比べればいいのか、そしてハーネスエンジニアリングの負担をどう軽くできるのか、という話が続きました。
後半二本では、BigQueryとdbt、LightdashとMCPを組み合わせて、指標定義と権限を一元管理するデータ分析基盤「Laplace」の事例。
そして、Ubuntu二十四・ゼロ四のDGXで、カーネルとNVIDIAドライバの依存関係がずれてGPUが効かなくなったトラブルと、その復旧手順、という内容でした。

気になった記事があれば、詳しい情報や元記事へのリンクはショーノートにまとめておきますので、そちらからぜひチェックしてみてください。
この番組「zenncast」では、あなたからの感想や、取り上げてほしいテーマ、技術的なお悩み相談なんかも幅広く募集しています。
普段聞いているだけの方も、「ここが面白かった」「ここがわかりにくかった」など、一言でももらえると、とっても励みになります。

それでは、そろそろお別れの時間です。
きょうも一日、良いコードと、良い学びがありますように。お相手はマイクでした。
また次回の「zenncast」でお会いしましょう。お疲れさまでした。