OpenAI DevDayまであと72時間
OpenAIの開発者向けアカウントが、DevDay開催まで72時間と告知した。「ずっと作ってきた。成果を見せる時だ」と短く予告している。
DevDayは例年、API・モデル・開発者ツールの発表が集中する場。今週前半は新しいAPIや料金の変更に備えて、依存しているエンドポイントを棚卸ししておくとよさそう。
CONTACT →
Daily AI Briefing
毎日のようにAI関連のニュースが届きますが、その多くは一次情報ではなく、ノイズも少なくありません。研究機関・開発企業・第一線の専門家による発信の中から、本当に押さえておきたい情報だけを厳選してお届けします。
OpenAIの開発者向けアカウントが、DevDay開催まで72時間と告知した。「ずっと作ってきた。成果を見せる時だ」と短く予告している。
DevDayは例年、API・モデル・開発者ツールの発表が集中する場。今週前半は新しいAPIや料金の変更に備えて、依存しているエンドポイントを棚卸ししておくとよさそう。
PyTorch公式が、vLLMのElastic Expert Parallelismを紹介した。トラフィックを受けている最中のMixture-of-Experts配備に対して、サービスの中断とダウンタイムを最小限に抑えたままGPUを追加・削除できるという。PyTorchCon North America 2026でNVIDIAのItay Alroy氏が発表する。
MoEモデルの自前ホスティングでは、需要に合わせてGPU数を動かすたびに再起動が必要なのが痛かった。vLLMでこれが標準機能になると、オートスケールの設計がかなり楽になる。
Nathan Lambert氏は、いまは「フロンティアモデルが素の状態で従業員とどう関わるか」に適した仕事文化を持つ企業が、競合に対して大きく加速する局面だと述べた。従業員側についても、モデルをどれだけ柔軟に使えるかで同じことが言えるとしている。
モデルを組織に合わせて作り込むより、モデルの得意な進め方に組織側が寄せるほうが早い、という見方。ドキュメント文化やテキストベースの意思決定が強いチームほど恩恵が大きそう。
DeepLearning.AIが、Andrew Ng氏の考えを紹介した。初期段階のAIプロジェクトに厳格なテスト要件を課すと停滞することは知られているのに、それでも実施する企業があると指摘。AIエンジニアリングの手法は速度のためだけでなく信頼性のためにも、プロジェクトの段階に応じて適応させる必要があると説明している。
プロトタイプ段階でevalsやテストを重装備にしすぎると、そもそも何を測るべきかが決まる前に消耗する。「いつから厳格にするか」を設計に含める視点は、AI機能の開発フローを組む際の指針になる。
Hamel Husain氏がevals FAQの一項目を投稿した。「モデルのせいではない問題も記録すべきか」という問いに対し、答えは「Yes」。プロダクトの有用性を下げるものは何でも書き留め、根本原因を調べる前に、どの問題を直すかを決めるべきだとしている。
エラー分析をしていると、UIや前処理の不備をモデルの問題と分けて捨てがち。まず全部記録し、優先順位づけを先に済ませてから深掘りする、という順序は真似しやすい。
Towards Data Scienceが、RAGシステムをエージェント型ワークフローに接続する最良の方法を扱った記事を紹介した。著者のemmimalpa氏が、この目的のために構築した接続層を順に解説している。
検索をエージェントの1ツールとして呼ぶだけだと、コンテキストの受け渡しや再検索の判断が雑になりがち。RAGとエージェントの間に明示的な層を置く設計例として参考になる。
Towards Data Scienceが推論配備のサイジングに関する記事を紹介した。共有GPUプールで中規模モデルを配備した際、重みは余裕をもって載り、テストでも正常に動いたにもかかわらず、同時トラフィックがかかるとGPU演算の使用率は低いままCUDA out-of-memoryが返ってきた、という事例から始まる。
モデルの重みサイズだけ見てGPUを決めると、KVキャッシュなど同時リクエスト数に比例して膨らむメモリを見落とす。単発テストで安心せず、負荷をかけた状態でメモリを見る必要がある。
Towards Data Scienceが、Ubaldo Hervas氏の記事を紹介した。ITSA(Interrupted Time Series Analysis、中断時系列分析)の解説に加えて、それを実行するために著者が構築したマルチエージェントシステムを順に説明している。
施策前後の効果測定という定型的な分析をエージェントに分担させる例。手順が決まっている統計手法は、エージェント化の題材として現実的で、自分の業務に置き換えて考えやすい。
Towards Data Scienceが、Sam Black氏の記事を紹介した。サイレント・ブロードキャスティングとは何か、それがどのようにモデルを壊すのか、そして学習パイプラインへの侵入をどう防ぐかを扱っている。
形状の違うテンソル同士がエラーを出さずに勝手に拡張されて計算が通ってしまう問題は、lossが下がらない原因として気づきにくい。形状のアサーションを習慣にする良いきっかけになる。
こうした動きを、自社の業務にどう活かせばいいか ―
迷ったときに相談できる窓口があります。