カスタムWebGPUカーネルでのポーカーソルバーの実現

2026-07-30T14:16:04.000Z カスタムWebGPUカーネルによるポーカーソルバー コーディングエージェントは、ライブラリが不要になるほど十分に賢くなったのでしょうか？ この記事は、その答えが「そうではない」というケースを recounted しています。私はポーカーモデルをWebGPUで実行するためにテンソルライブラリを必要としました。私が欲しかったライブラリは存在しませんでした。結局、それは必要ありませんでした。 背景 過去1年間、私はポーカーソルバーの現状に興味を持っていました。知らない方のために説明すると、ソルバーはポーカーのあらゆるゲーム状況に対して近似的なナッシュ均衡戦略を見つけます。実際には、それらは「スポット」（公開カードとベット履歴のセット）を取り、出力戦略を生成します。戦略は均衡を近似しているため、ε（イプシロン）まで証明可能な非搾取性（non-exploitable）です。つまり、プレイヤーがあなたの均衡とは異なる戦略をプレイした場合、期待値であなたに勝つことはできません。商用ソルバーは長年存在していますが、非常に高価な傾向があります。私はオープンソースで、ブラウザ内で動作し、無料で提供できるソルバーを作成したかったのです。計算要件を考えると、ニューラルネットワークとアルゴリズムをブラウザで実行する方法を見つける必要がありました。WebGLまたはWebGPUを使用してモデルを評価する良い方法はありますが、PyTorch1のような汎用テンソルライブラリは存在しません。私は数ヶ月かけてPyTorchでさまざまなモデルを構築し、テストしました。最終的な出力が自分のコンピュータで動作することに満足しても、ブラウザで提供するという私の目標を達成する方法はありませんでした。 参照実装 しかし、今は2026年です。私が求めていたのは、WebGPUで（同じ関数、異なるプラットフォームで）迅速に同じ出力を生成するコードだけでした。私は、参照実装パターンをどこでも見分けることを学びました。PyTorchは正しさのオラクルです。そこで、私はCodexに、モデルとコアアルゴリズムの評価を可能にするWebGPUカーネルのセットを構築し、PyTorch参照とのパリティを確認するように指示しました。それは単一のプロンプトの後、パリティテストに合格したので、カーネルを最適化するために一晩中ループで実行させました。この単純なアプローチにより、Codexは最初の試行で、独自のナイーブ実装と比較して10倍以上の速度向上を達成しました。また、パフォーマンスのためにモデルのアクティベーション関数を切り替える必要があることも指摘しました。 一次近似として、ライブラリは、正確で、高速で、よく設計されたコードを書くことが高価であるために存在します。そのため、私たちはそのコストを数千人のユーザーに償却し、汎用性に伴う抽象化のペナルティを受け入れます。生成が安価で検証可能であれば、そのトレードオフは反転する可能性があります。この場合、私の計算を正確に行うカスタムカーネルは、汎用ライブラリよりも優れている可能性があります。他の人が指摘しているように、関連するすべての動作を実行すると信頼できるテストスイートは、LLM時代においては仕様よりも優れている場合があります。これはどこでも機能するわけではありません。計算は明確に定義されている必要があり、参照実装は信頼できる必要があり、テストは重要な動作を捉える必要があります。 実際には 均衡ソルバーは、カウンターファクチュアル後悔最小化（CFR）と呼ばれる探索スタイルのアルゴリズムに依存しています。従来のソルバーには、さまざまなスポットにおける戦略と期待値の巨大なテーブルが付属しており、抽象化という技術を使用して類似のスポットを1つのバケットにまとめます。より現代的なアプローチは、代わりに各スポットを限定的な探索深度まで「再ソルブ」し、深度カットオフでの近似関数としてニューラルネットワークを使用します。表形式（例: Piosolver）およびニューラル（例: GTOWizard）の商用ソルバーが利用可能です。 私は昨秋、主に手動でCFRアルゴリズムの最初の実装を書きました。その時点では、LLMはバグ検索とGoogleの強化にしか役立っていませんでした。それらは、私が実際にコミットしたいコードはもちろんのこと、動作するコードを生成するのに苦労していました。たとえEager PyTorchコードであっても、テンソルを反復するためにループを導入することがよくありました（これは絶対に避けるべきことです）。そして、カスタムカーネルを作成しようとしたとき、それらは非標準的で複雑な操作には対応できませんでした。 数ヶ月後、状況は大きく変わりました。モデルは常に最初の試行で完璧なコードを書くわけではありませんが、今では通常、論文全体をゼロから正しく実装できます。エージェントにCFRのバリアントについて文献を調査させ、それらを実装させ、パフォーマンスを比較させることができます。ハイパーパラメータを最適化し、基本的なスケーリング法則を導き出すために、短いランニングトライアルを自律的に実行できます。昨秋、動作するモデルへのクリティカルパス上にないという理由で延期したすべての作業が、今では完了できます。 特にWebGPUタスクでは、検証可能な報酬のおかげで、LLMを数時間（数日）実行して目的の出力を得ることができました。エージェントが実質的に私のコードのすべてを書いているとしても、私は依然としてその上層の計画と判断レイヤーです。私の実験では、モデルにはまだその能力がありません。このプロジェクトには、LLMコーディングと実験を監督するのに数ヶ月の作業が必要でした。別の言い方をすれば、私はエージェントにますます多くのタスクを委任していますが、彼らはまだ何を構築すべきかを決定するのに苦労しています。 結論 ライブラリとプログラミング言語の選択は、かつてないほど拘束力がなくなっています。この原則の拡張：リライトはもはや禁断の果実ではありません。ソルバーは holdem.computer で利用可能であり、コードはすべて https://github.com/phulin/poker2 で入手可能です。 追伸 私はこの作業のほとんどを、ニューヨーク市のプログラマーのためのリトリートであり、私が世界で最も好きな場所の一つであるRecurse Centerの参加者として行いました。応募を検討しているなら、ぜひ応募してください！ このプロジェクトは、学術文献のさまざまな論文の方法論を組み合わせました。特に、DeepStackとReBeLが非常に役立ちましたが、依存した論文が多すぎてすべてをリストアップすることはできません。ライブモデルは、現時点で最も強力なポーカーソルバーではなく、2人用（「ヘッドアップ」）プレイのみをサポートしています。また、「ノードロッキング」（相手の非均衡戦略を悪用する方法を教える）のような商用ソルバーの機能も欠けています。学術文献のモデルよりも100倍少ないコンピューティングリソースでトレーニングされている可能性が高いため、強力なプレイヤーになるには、基盤となるモデルにもっとGPU時間が必要になります。 脚注 TensorFlowプロジェクトにTFJSがありますが、それは大部分が放棄されているようで、私が求めたいくつかのプリミティブ操作をサポートしておらず、テストでは非常に遅かったです。↩