正しさの限界費用

「正しさ」にかかる限界費用はゼロに近づいています。これがソフトウェアエンジニアリングの実践においてどのような意味を持つのか、しっかりと理解しておく必要があります。物事を正しく行うことに徹底的にこだわる必要があります。

変化する状況

かつては、エンジニアは純粋な技術力――効率的なアルゴリズム的思考、スケーラブルな分散システム、デバッガーのブレークポイントを手作業で丹念に追うことなど――によって、他者と差別化を図ることができました。しかし、この傾向は加速する勢いで薄れつつあります。エージェントの登場により、誰でも正しいコードを書けるようになっているのです。

今、他者と差別化を図るために身につけるべき最も重要なスキルは、「嗅覚」だ。つまり、何かがおかしいと察知する能力と、それを正しい方向へと導く意志力である。

動作の遅いAPIを見抜く

Pangramでは現在、新しいモデルのトレーニングを行っています（これを明かしても、あまり多くの情報を漏らしているとは思わないでください）。このモデルは、これまでのモデルよりも規模が大きく、賢く、そして*高速*になる予定です。 この「高速」という最上級の評価は、単に「正しくやる」ことへのこだわりなしには実現できなかったでしょう。なぜなら、私たちにはそれができるからです。私たちの技術に誇りを持っているからです。そして、ある日私がAPIをテストしていた際、「これより絶対に速くあるべきだ」と感じたからです。

当時、その「ウサギの穴」に飛び込むことが、具体的にどのような成果をもたらすのか、私には知る由もなかった。ただ、「物事はきちんとやるべきだ」という確信と、「Fableが味方なら何でも可能だ」という信念だけを胸に抱いていた。

それからわずか数日後、私たちは困難を乗り越え、ドッグフーディングを悩ませてきたレイテンシーに打ち勝つことができました。Fableを活用することで、複雑な分散型APIオーケストレーター向けの、完全にローカル環境で動作するテスト環境を構築することができました。コード内のすべてのホットスポットに対して仮説を立て、それぞれの修正をテストしました。複雑なRedis操作をパイプライン化し、動作が維持されていることを検証しました。また、本番環境のトラフィックに基づいてさまざまな負荷パターンのシミュレーションを実行し、必要なインフラを推定しました。

エージェントがなければ、これは実現不可能な、提案すらできないプロジェクトだったでしょう。エンジニアリング作業に数週間から数ヶ月を要したはずです。しかし実際には、バックグラウンドでトレーニング実行が完了する間、これはサイドプロジェクトとして進めることができました。

こうした取り組みの結果、GPU使用率は約5倍に上昇し（20％から98％へと、これは痛かった）、スループットもベアメタルノードと同等レベルに達しました。これにかかるコストはごくわずかでした。そのおかげで、すべてを手に入れることができました。これにより、新しいモデルのホスティングは、コスト的に手が出ない状態から、まさに破格の安さへと一変したのです。

嗅覚を鍛える

残念ながら、鼻の感覚を磨くための「たった1つの簡単なコツ」というものはありませんが、これは鍛えることができるスキルです。私にとって効果があった（と思う）方法は以下の通りです：

痛みに弱い

自分がイライラすることなら、おそらくユーザーもイライラしているはずです。ただ我慢してやり過ごすのではなく、自分自身と向き合う必要があります。日中に何に微かな苛立ちを感じるか、無意識のうちに避けてしまいがちなコードベースの部分、あるいは作業中に少し落ち着きがなくなるタスクなど、注意を払ってみてください。こここそが改善の余地がある場所です。これが、私がAPIの最適化に本格的に取り組むきっかけとなったのです。

私は「簡単なことは簡単であるべきだ」とよく言っています。これはコードベースにも（例えば、単純なトレーニングのアブレーションを実行するのに頭を使う必要はないはず）、製品にも（例えば、1回のAPI呼び出しはフォワードパス自体とほとんど変わらない程度の速度であるべき）当てはまります。「こんなに難しいはずがない」と思ったときは、すぐに修正しましょう！ もうエージェントがあります！ ワークツリーを立ち上げて、Codexを実行しましょう /目標 さあ、やってみよう――失うものなんてある？

あらゆることを第一原理から問い直す

エージェントのおかげで、こうした作業がとても簡単になります。「バッチサイズ、GPUのスペック、パラメータ数を考慮すると、このタスクにはどれくらいの時間がかかるべきか」。「データ量とクエリ数を踏まえると、このプロバイダーにはどれくらいの費用をかけるべきか」。何が「正しい」状態なのかが分かっていれば、何が「正しくない」かを特定するのもずっと簡単になります。

私は、当社がサポートするすべてのモデル／ノード／リクエスト形状のトポロジーについて、この作業を行っています。これは、vLLMの設定を微調整し、理論上の限界値に近づけるための方法です。この作業を通じて、当社のAPIスループットとベアメタルノードで得られる結果との間にギャップがあることを把握できたのです。

この原則は、あなたのコードベースにも当てはまります。もしある抽象化が奇妙に思えるなら、「昔からそうだったから」という答えを鵜呑みにしてはいけません。第一原理から契約を見直してください――現在の知識を踏まえて、それはどのような形であるべきでしょうか？ あなたの仕事は、エージェントをどこに向けるべきかを考え出すことです。エージェントなら、一晩でリファクタリングを行い、正しさを検証することができます。

好奇心を持って、たくさん本を読みましょう

パングラム入社初週に実装した最適化のうち、私が特に気に入っているものの1つは、DeepSeek V4のハイブリッドスパースアテンションメカニズムに着想を得たものです。

私の最適化は、ニューラルアーキテクチャとは全く関係がなく、ましてやアテンション機能とは特に無関係でした。これは、人間が書いたテキストとAIが生成したテキストの境界を検出するために使用しているアルゴリズムの改善であり、以前は制限のない2回目の推論処理が必要でした。

できるだけ多くの賢い人々から、できるだけ多くの興味深いアイデアを吸収しましょう。今のあなたの仕事は、限りない好奇心を持ち、物事のつながりを発見し、「もし～だったら？」と問い続けることです。覚えておいてください。物事を調べるための限界費用はゼロに近づいているのです。

トークンを使ってください

毎週日曜日、私は「コーデックス」をランダムな場所に置くという習慣があります /目標 リセット前に毎週のトークンを使い切ろうとして。たいていはコードを捨ててしまったり、忘れ去られたPRの下書きの中に放置されたりしてしまう。でも、時にはそれが報われることもある。この作業から、ほぼ毎回何かを学べる。いずれにせよ、私にとっては何のコストもかからない。これをスロットマシンを回すようなものだと呼ぶ人もいるが、私は「やらないと勝てない」と思う。