DeepSeek蒸留でLightGBMが1000倍高速化！LLM脱却のマリオ攻略法

• 事実と背景：Jev等のLLMを用いたリアルタイムゲーム制御においてAPI遅延（約260ms）による失敗が相次ぐ課題が発生。
• 技術的変革：最強LLM「DeepSeek-V4.1-Flash」のプレイログ4,911件を教師データにLightGBMへ知識蒸留を実施。
• 現場への影響：推論速度が0.249msと1,000倍以上高速化し、未知の開始条件でクリア率100%の超高精度・超低コスト制御を実現。

深夜の障害対応でAPIのタイムアウトに悩まされた経験を持つエンジニアなら、リアルタイム制御における100msの重みが身に染みて理解できるはずだ。近年、LLM（大規模言語モデル）の高速応答性をアピールするデモとして、LLMに『DOOM』や『スーパーマリオブラザーズ』といったアクションゲームをプレイさせる試みが技術コミュニティを賑わせている。特にJevが提示した約100msでのレスポンス性能は、一見するとゲームなどのリアルタイムアクチュエーションに適用可能であるかのような錯覚を我々に抱かせる。しかし、我々現役のシニアエンジニアが現場で直面する現実は、それほど甘くはない。

実際にオープンソースのハーネス（ゲーム状態とモデルの接続基盤）である`typesafe-mario`を用い、Jevにマリオの1-1ステージをプレイさせる実験を行ったところ、衝撃的な結果となった。リアルタイム方式において、Jevのクリア率はまさかの0%（0/20試行）に終わったのだ。マリオの位置や敵までの距離などをJSON形式で入力し、7種類の操作選択肢からアクションを選ばせる構成において、モデルが思考している数百ミリ秒の間にゲーム内の状態は刻一刻と変化する。観測時点で最適だった「ジャンプ」の判断が到着する頃には、マリオは既にクリボーに接触しているか、底なしの穴へと落下しているのだ。日本のインフラから海外プロバイダのAPIを叩く際の物理的なネットワークレイテンシは、どれほどモデル側の推論が速かろうとも決して無視できない壁となって立ちはだかる。

ゲームを一時停止してAPIの応答を待つ非リアルタイム方式に切り替えることで、Jevのクリア率は55%（11/20試行）まで向上した。さらに、プロバイダをDeepInfraに固定し、より推論精度の高い`DeepSeek-V4.1-Flash`（temperature=0.25）をゲーム停止方式で投入したところ、クリア率は90%（18/20試行）へと飛躍的に向上した。以下の検証データ比較表を見てほしい。APIの通信遅延が排除された環境であれば、最新の思考型LLMは極めて高度なゲームプレイ判断を下せることが立証されたのだ。

しかし、ここで我々は大きな疑問に直面する。ゲームの一時停止を前提とした制御など、もはや「リアルタイム制御」とは呼べないのではないか？そして、API呼び出し毎にコストが発生するLLMを、わざわざ自然言語を入力としない数値データ制御に使い続けることが、エンジニアリングとして本当に正解なのだろうか？私はそうは思わない。

「自然言語を介さない制御タスクに、巨大なLLMのパラメータは本当に必要なのか？」——この確信に基づき、私はDeepSeekが弾き出した高品質な意思決定ログを教師データとし、勾配ブースティング決定木（GBDT）の代表格である『LightGBM』へと知識蒸留（Distillation）を試みた。DeepSeekがクリアした18試行から得られた教師データはわずか4,911件。API費用にしてわずか$0.5以下という、驚くほど低予算な実験環境である。

具体的に、我々エンジニアが日常的に扱うJSONデータの構造化プロセスを解説しよう。ハーネスから出力されるゲーム状態のJSONデータを数値ベクトルへ変換するにあたり、位置や速度といった連続値はそのまま利用し、接地フラグなどの真偽値は0/1のバイナリに変換。敵の種類などのカテゴリカル変数はone-hotエンコーディングを施した。入れ子構造となっている`player.x`などのオブジェクト属性はフラットに展開し、敵の配列情報は先頭3件までを取得、欠損値（null）は-1に置換した上で欠損フラグ列を明示的に付与した。正解ラベルはDeepSeekが選択した「右へ走る（right_run）」と「右へ走りながらジャンプ（right_run_jump）」の2択である。

過学習とデータの偏りを防ぐため、特徴量が完全に一致する重複データを排除し、開始フレーム条件に基づくグループ単位でのデータ分割を実施。学習データ2,145件、検証データ9件、テストデータ267件を抽出した。さらに、ステージの位置区間（500px単位）と操作の出現頻度に基づく重み付けを施し、不均衡データへの対策を万全にした。ハイパーパラメータ調整では`num_leaves`（15, 31, 63）と`min_child_samples`（5, 20）の組み合わせを探索し、最も安定したパフォーマンスを示した以下の設定を採用している。

完成したLightGBMモデルを、学習には一切使用していない未知の開始タイミングにおいてリアルタイム方式で100回プレイさせた結果、クリア率はなんと「100%（100/100試行）」という完璧な数値を叩き出した。そして何より圧巻なのはそのレイテンシである。JevのAPI応答速度の中央値が約260ms（ネットワーク遅延含む）であったのに対し、ローカル環境で動作するLightGBMの推論時間中央値はわずか「0.249ms」であった。実に1,000倍以上の超高速化である。スパゲッティコード化した大規模モデルのパイプラインを削ぎ落とし、超軽量な決定木に置き換えることで、真のリアルタイム制御がここに完成したのだ。

今回の実験結果は、我々ソフトウェアエンジニアに対して強烈なアンチテーゼを突きつけている。猫も杓子も「とりあえずLLM」とAPIを叩き、無駄な推論コストとネットワーク遅延に頭を悩ませる現在のトレンドは、本当に技術的妥当性に基づいているだろうか？自然言語の文脈理解やCalibrated Probability（確率キャリブレーション）を必要としない構造化データの制御において、数千億パラメータのLLMを使うのは、ハエを叩くために最新鋭のミサイルを撃ち込むような暴挙と言わざるを得ない。Jevのようなモデルの登場は、皮肉にも「古典的な機械学習手法（LightGBMやXGBoost）の圧倒的優秀さ」を再発見させる強力なきっかけとなった。

ただし、この「LLMから知識を吸い上げて小型モデルを作る」蒸留というアプローチを実践する上で、エンジニアが絶対に回避できない法的・倫理的リスクが存在する。それはモデル提供元の『利用規約（Terms of Service）』である。例えば、本検証の比較対象となったJevでは、規約上で出力を用いたモデルの蒸留や競合サービスの開発が明示的に禁止されている。以下はJevの規約抜粋だ。

• 「Customer will not… use the Services or any Output to perform model distillation, train a model to imitate the output of the Services, or develop… a similar or competing product or service;」

一方で、OpenAIやDeepSeekなど多くのモデルプロバイダにおいては、「自社と直接競合するLLMの開発・学習目的」でない限り、特定のドメインタスクへの知識蒸留や古典モデルへの落とし込みは広く認められている傾向にある。開発現場で蒸留パイプラインを構築する際は、利用するモデルの規約条項をリーガルチェックすることが商用化に向けた絶対の絶対条件となる。

我々エンジニアが明日からの実務で取るべき処方箋は明快だ。まず第一に、自社システムが解くべき課題の入出力構造を冷徹に見極めること。入力が構造化数値データであり、出力が確定的なアクション選択であるならば、LLMは教師データの生成器（データアノテーター）としてのみ使い、本番環境には蒸留した軽量な機械学習モデル（LightGBMなど）をデプロイすべきだ。これにより、インフラコストは数十分の一に削減され、ミリ秒未満のハイレスポンスと高い安定性が手に入る。

最後に、すべての開発者に問いたい。「あなたが今、高価なクラウドLLM APIに頼って構築しているそのシステムは、本当にLLMでなければ解けない課題なのだろうか？自らの手でデータを整形し、ローカルで動く小さな決定木を動かす勇気を忘れてはいないだろうか？」