AI の高額化に経営陣が衝撃、戦略の見直し迫られる
エンタープライズ企業の経営層が、AI モデルの運用コストの急増と収益性の欠如に直面し、導入戦略の見直しやコスト削減への転換を迫られている。
キーポイント
コスト管理の困難さ
KPMG の調査によると、エンタープライズ AI 展開がスケールする際、経営層の約 3 割が運用コストを理解できておらず、コスト対効果が期待値を下回る場合、導入計画の見直し(re-phase)を検討している。
使用量ベース課金の衝撃
AI モデルへの依存度が高まる中で、突発的な請求額の高騰(sticker shock)が経営層を驚かせており、従来型の予算管理モデルとの乖離が課題となっている。
コスト削減とモデル選定
高コストな大規模モデルへの依存を見直し、低コストモデルと高精度モデルを使い分ける戦略や、トークン消費を最小化する「tokenminning」の手法が模索されている。
業界の収益性への疑問
AI 業界全体が依然として不採算であり、人間開発者よりも AI モデルに支払うコストを抑えようとする動きや、使用量ベース課金に対する反発が業界の将来を左右する要因となっている。
重要な引用
business leaders are simply shocked to learn the AI their organizations are becoming dependent on is suddenly a lot more expensive
29 percent of them struggled to understand the operating costs as they scale with enterprise AI deployments
Nearly half of them were also looking to re-phase their AI deployments when the costs outweigh the expected value
影響分析・編集コメントを表示
影響分析
この記事は、AI 技術の実装フェーズから成熟・定着フェーズへ移行する過程で顕在化する「コストの壁」を浮き彫りにしており、企業の AI 戦略が単なる導入競争から、ROI(投資対効果)と持続可能性を重視した現実的な段階へとシフトしていることを示唆しています。今後は、大規模モデルへの依存度を下げ、より効率的なアーキテクチャやコスト最適化技術の採用が企業競争力の鍵となるでしょう。
編集コメント
AI の可能性が語られる一方で、その実装コストという冷徹な現実が経営層を揺さぶっている状況は、業界全体が「夢から現実に」移行する過渡期であることを如実に示しています。今後は技術の性能だけでなく、いかにコスト効率よく運用できるかが企業の存続条件となるでしょう。
「ケトル」:ドラッグディーラーのように、一度依存させたら料金を値上げするビジネスリーダーたち。組織が依存し始めた AI が突然高騰していることに、経営陣は驚愕しています。
このページの最新エピソードを聴くほか、Spotify、Apple Music、YouTube でも購読して新着通知を受け取ることができます。今週の「ケトル」では、ホストのブランドン・ヴィギリオロが、レガースターのリンジー・クラークと寄稿者のジョーブ・ジャクソンを迎え、エンタープライズ AI のコスト上昇に関する最近の記事や、人気のあるオープンソースプロジェクトが「トークンマキシング(トークンの無駄遣い)」に対抗するために「トークンミニミング(最小化)」を試みている件について議論します。しかし、こうした対策がバブルを吹き飛ばすコスト対効果分析を防ぐのに十分かどうかは依然として疑問です。
AI 業界は、まだ黒字化していない事実や、従量課金への反発、そして AI モデルに人間の開発者と同じかそれ以上の報酬を支払いたくないという欲求に適応できるのでしょうか。それが今週の議題です。以下は、軽微な編集を加えた transcript です。
ブランドン:『ザ・レジスター』ケトルポッドキャストへようこそ。私はレガースターのブランドン・ヴィギリオロです。今週何について話すか知ったら、皆さん驚くでしょう。もちろん冗談です。AI についてです。具体的には、企業や従業員の生活を楽にするはずの巨大モデルを実際に動かすのにどれほどコストがかかるかを、世界がようやく気づき始めているという事実です。しかし、その結果として請求書の衝撃(インボイス・ショック)を招いているようです。
最新の AI コストに関するパニックについて語るため、レガースターのリンジー・クラークと寄稿者のジョーブ・ジャクソンをお迎えしました。お二人ともありがとうございます。
リンジー:こちらこそ、ありがとう。
ジョーブ:ありがとうございます。
ブランドン:ではリンジーから始めましょう。最近の C suite(経営陣)が、新しい従量課金型の AI コストを把握できていないという記事を書かれましたね。いったい何が彼らを混乱させているのでしょうか?
リンジー:大企業は AI に両足を踏み入れて突っ走っている印象です。最新トレンドとして、コーディングやビジネスアプリに活用し、業務で何かをやろうとしています。KPMG(カーン・マリー・ゲルマン)のような巨大なグローバルコンサルティングファームも例外ではありません。彼らは IT サービスやアウトソーシングサービスを提供しています。
ブランドン:そしてそのレポートを書いたのが KPMG ですね?
リンジー:はい、そうです。彼ら自身もこの問題に利害関係があります。20 カ国以上の 2,000 人以上のシニア経営者を対象にした調査で、企業 AI の導入規模拡大に伴う運用コストを理解できないと答えた人が 29% に上ることが分かりました。また、ほぼ半数が、コストが見込み価値を上回った場合に AI 導入を見直す意向を示しています。
ブランドン:「見直す(re-phase)」とは具体的に何を意味するのでしょうか?導入自体を再考しているのか、それとも範囲を変更するのか?
リンジー:要はペースを落とし、現在何をしているかを検討し直しているということです。高コストなモデルだけでなく、低コストモデルや高精度モデルも組み合わせ、最も高価なものに頼り切るのではなく、最適なモデルのミックスを探っているのです。
ブランドン:従量課金という仕組みはこの分野では比較的最近の動きですね。最初は無料サンプルでユーザーを囲い込み、依存状態になってから「実はこれでお金を稼がなきゃいけない」と気づかせるパターンです。「AI フロンティア・ラボ」としては、利益を出せない以上、トークン単位で請求せざるを得ないのです。
リンジー:Anthropic、OpenAI、GitHub はいずれも、サブスクリプションや定額制の「食べ放題」モデルから、トークンベースの従量課金へ移行しました。ベンダー側は、モデルプロバイダーだけでなく、自社アプリで AI エージェントを使いたいアプリケーションベンダーも同様です。彼らはユーザーに両足を踏み入れて、できるだけ多く使ってほしいと考えています。そして IT 業界ではよくあることですが、利用が進むにつれて料金体系を変更しようとするのです。
ブランドン:これは大きな問題で、C 級経営者の 4 人に 1 人以上が請求書の衝撃を受け、「このコストを払えるか」と realizing しています。しかし、エンジニアたちが長く使い続けているため、ある程度依存してしまっているのも事実です。私は最近、オープンソースツールについての記事を書きました。これはエンジニアのスキル低下を防ぐためのテストツールで、多くの開発者が AI に依存しすぎて、以前はできていた基本的な作業を忘れてしまっている現状を反映しています。
この状況は、AI 企業にとって「さて、本格的にお金を稼ごう」という大きな入り口となりますが、同時に彼らを危険な立場に追い込みます。料金を高くしすぎれば、エンタープライズ顧客は回避策を探します。中国のオープンソースモデルや他のソリューションに切り替えたり、導入を見直したり、大規模モデルではなく小規模モデルを使ったりするでしょう。逆に料金が安すぎれば、十分な収益を上げられません。
AI ラボはこの針金を渡せるのでしょうか?それともバブルを突き破る鋭い針なのですか?
リンジー:数週間前に Gartner から興味深いレポートが出ていました。AI 支援コーディングのコストに関する調査です。
ブランドン:6 月末にあなたが取り上げたあの研究ですね?
リンジー:はい、その通りです。研究者の Nitish Tyagi は、コーディングエージェントのコストについてベンダー側が透明性を欠いており、クラウドで期待されるようなコスト最適化ツールも不足していると指摘しました。
このため、2028 年には開発者 1 人あたりの AI エージェントのコストが、グローバルな平均給与を超える可能性があると予測されています。すでに給与水準が低いインドなどの地域では、エージェントのコストはすでに開発者の給与を超えています。これは、エージェントのコストが世界中で一定であるのに対し、開発者の給与は地域によって異なるためです。
ブランドン:シリコンバレーの開発者なら、コストが給与を超えることはまずないでしょうね。あの人たちは高給取りですから。
リンジー:その通りです。
ブランドン:数百ドルではなく、数十万ドル規模のトークンコストになる可能性は低いですが、それでもグローバル平均では依然として大きな金額です。そのため、多くの企業が AI 導入の持続可能性に懸念を抱き、レイオフした人材を再雇用しているのも頷けます。「このビジネスモデルは本当に持続可能なのか?」という問いが突きつけられています。
リンジー:バブルの話に戻りますが、これらのコストをどこかで回収する必要があります。マクロな視点では、ある大手投資会社が 2030 年までの 5 年間で AI データセンターに投入される CAPEX(資本支出)を調査しました。その額は 1.5 兆ドルです。これは莫大な金額で、どこからか捻出しなければなりません。
Gartner の研究では、モデルプロバイダーごとに課金方法がバラバラで標準化されていないことも指摘されています。そのため、ベンダーのやり方に任せていると非常に困難です。Gartner は企業側が自ら対策を講じ、利用を最適化し、最小化するよう促しました。
その議論から浮かび上がった重要な点は、トークン消費量の増加と生産性やコーディング効率の向上に直接的な相関関係がないということです。「使えば使うほど成果が出る」とは限りません。むしろ、注意深く制御して使用すれば、消費量は減るだけでなく、生成されるコードの品質も高まることが示されました。
これは数週間前に Cockroach Labs の CEO、スペンサー・キムボール氏との会話でも確認できました。コーディング界では有名な方で、Google で長く働いた後、GIMP(オープンソース画像処理ツール)の開発にも関わりました。彼は「Cockroach ではトークンマキシングは行いません」と言います。多くのモデル、特にオープンソースや安価なモデルを活用しています。
適切なコンテキストを提供せずにモデルを最大限に使う意味はないと彼は指摘します。そうすれば返ってくるのはゴミばかりです。Gartner の見解とも一致しており、商業レベルでの導入には慎重な姿勢を示しています。
ブランドン:「トークンマキシング」の話から、次の記事へ移りましょう。ジョーブさん、Netflix のエンジニアが作ったオープンソースツールについての記事を書かれましたね。このツールは瞬く間に人気を集め、入力データを LLM に最適化することでトークンコストを削減し、多くのユーザーに数十万ドルの節約をもたらしました。
これは「トークンマキシング」の対極にある、「トークンミニミング(最小化)」です。いったいどのような仕組みなのでしょうか?
ジョーブ:これも他の優れたオープンソースプロジェクト同様、個人の趣味から始まったものです。彼は Claude Sonnet からのデバッグや MCP 関連作業で 287 ドルの請求書を受け取りました。「この程度の作業でどうやって高額な請求が来るのか?」と疑問に思ったのです。
彼は Claude に送信したデータを確認しました。トークン消費の大部分は入力側にあることは知られています。入力と出力の両方に課金されますが、請求書の大半を占めるのはシステムに入力する情報です。
彼のエージェントが提出していたデータの多くが完全に冗長であることを発見しました。有用な指示ではなく、データベーススキーマや JSON テンプレート、あるいは大量のログデータでした。
「冗長部分を切り取り、必要な情報のみを送信すればコストを節約できる」と考えたのです。Claude にはいくつかの設定がありますが、それらをいじると AWS の請求書管理の地獄に陥ります。キャッシュ設定などがあり、LLM にクエリを送るたびに履歴全体が添付されるため、同じ情報が繰り返し送られます。
この履歴を保持する時間を 5 分や 1 時間に設定できます。しかし、1 時間設定するとコストは倍になりますが、読み込みコストは 90% 削減されます。ここで複雑な計算が必要になります。送信するデータと作業負荷のバランスをどう取るかです。
ブランドン:つまり、余計な部分を切り落とす「脂肪落とし」ですね。すべてのデータをトークン入力として再送するのではなく、「これは既に持っているからこれを使え」とモデルに指示しているのです。
ジョーブ:単に会話が多いという問題ではありません。必要以上に冗長なスキーマが問題なのです。例えば、Rust コマンドを詳細モードで実行すると、LLM が必要としないような詳細情報がすべて出力されます。
彼はデータベース圧縮や JSON のトリミングなどを行う「スクワッシャー(squashers)」と呼ばれるいくつかのモジュールを開発しました。現在 VC 資金によるトークン削減ツールは多数ありますが、彼はコマンドラインから直接動作するインライン型のツールを欲していました。
念のため補足しますが、これは Netflix での業務ではありません。彼は別の職で働いており、このプログラムは私的に開発したものです。数人の同僚エンジニアに試してもらい好評でしたが、いつの間にか勝手に爆発的な人気になりました。
ブランドン:社内製品ではなく、個人のプロジェクトですね。仕組みが気になります。これは完全にコンテキストウィンドウ(文脈の記憶領域)に依存しているのでしょうか?
ジョーブ:コンテキストウィンドウを整形する、というのが正確です。
ブランドン:一定の点を超えると、コンテキストウィンドウには限界がありますね。その時点で同じ会話を続けるためには、再びデータを再送する必要が出てくるはずです。つまり、この手法が有効なのは会話内容がコンテキスト内に留まっている間だけということですね?
ジョーブ:私は Gemini をよく使いますが、確かにキャッシュ機能があり、会話としてシームレスに感じられます。しかし一定の点を超えると、会話自体は途切れないものの、すべてのデータが LLM によって再度読み込まれて解析されることになります。
ブランドン:なるほど。「Project Headroom」ですね?この「頭上のスペース(余白)」をクリアしているのは何でしょうか?別の LLM なのか、彼自身が書いたローカルアルゴリズムなのか。どこで圧縮やトリミングが行われているのですか?
ジョーブ:すべてクライアント側で行われています。LLM を一切使用していません。統計分析を利用しています。
例えば、データベーステーブルを送信した場合、LLM はその全表を必要としません。理解するために必要なのは最初の数行、スキーマ、そして外れ値だけです。10 万行すべてを必要とするわけではありません。彼と他の貢献者が考え出した一連のトリックでデータを整理しているのです。
ブランドン:記事によると、このツールを使っている人々の節約額は 70 万ドルに上ると話されていました。5 月末に記事を書かれたようですが、現在の節約額や利用者数について何か更新はありますか?
ジョーブ:最近確認していませんが、当初の推計では、テレメトリ(利用状況データ)への参加者から約 2,000 億トークンの削減、換算で 70 万ドルの節約が見込まれていました。ただし、この情報を送信していないユーザーもいるため、正確な数は把握できません。オープンソースなので追跡が難しいのです。
最近彼と話しましたが、プロジェクトは順調に成長しており、引き続き注目を集めているとのことでした。
ブランドン:記事では、トークン予算や平均クエリに対してどれほどの割合を削減できるかの推計は見当たりませんでしたか?それとも用途によって異なるのでしょうか?
ジョーブ:サーバーログの 90% は不要です。JSON の 70% もカットできます。多くの部分はフォーマットに過ぎないからです。定型フォーマットのデータは本当に必要ありません。
また、テキスト圧縮を行う便利な機能もあります。すべて可逆的なので、LLM がさらに情報が必要になった場合でも、元に戻して取得できます。
ブランドン:つまり、これは恒久的な削除ではなく一時的な圧縮ですね。AI コストの急騰や巨額の請求書という恐怖物語がある一方で、逆に利用制限に達して業務が途中で止まってしまうケースも日常茶飯事です。企業がトークンを確保し AI 経費を削減するために必要な手段かもしれません。
お二人はどう思われますか?これで十分なのでしょうか?それとも他に何かを変える必要があるのでしょうか?
ジョーブ:生成 AI の進化についてよく語られますが、ダーウィンの進化論に戻って考えれば、資源の制約こそが核心的な要素です。制限なく無限に成長できるものはありません。ある時点で、真のイノベーションが始まります。資源が限られているからこそです。
データセンターの電力消費過多を訴える声もありますが、LLM もその限界点に達しつつあります。限られた資源でどうやって成り立たせるかを考えなければなりません。
私は多くの AI 研究を読んでいますが、AI の効率化に関する研究がラボから出てくるのをあまり見ていません。もしかすると、これが次の必然的なステップなのかもしれません。私たちはまだ完全に理解していない技術を持っていますが、私たちにも限界があります。その限界を考慮に入れる必要があります。
リンジー:オープンソースツールの検討に加え、ベンダー側も大きな機会を見出しています。特にデータベース市場ではです。私はいくつかのデータベースベンダーに話を聞き、彼らが効率化と LLM への呼び出し回数の削減に取り組んでいることを知っています。
例えば、ベクターデータベースで先行した Pinecone は、エージェントとビジネスデータ・技術環境の間にセマンティックレイヤー(意味層)を構築しようとしています。データベーススキーマや財務プロセスなどの基本情報を保存しておくことで、毎回 LLM に問い合わせる必要がなくなります。
つまり、オープンソースまたはプロプライエタリなベンダー双方から、企業が AI エージェントのコスト削減を実現できるという訴求で市場に参入する動きが増えるでしょう。
ブランドン:Oracle がそれに取り組んでいればいいのですが。先週議論した通り、彼らはこのバブルの影響を最も受けやすい立場にあります。Microsoft、Amazon、Google などの大手データセンタープレイヤーは、もしバブルが弾けても fallback(後退先)となる大きな事業を持っていますが、Oracle は他で十分な収益が見込めない中で巨額の負債を抱えています。
しかし、データベースをセマンティックレイヤーとして機能させ、呼び出し回数を削減できれば、それは非常に価値あることになるでしょう。
リンジー:Oracle も OpenAI に依存しているため、一概には言えません。昨年 9 月、4,500 億ドル規模のデータセンター投資パイプラインを発表し、市場は好意的に反応しました。しかし数週間後、そのうち 3,000 億ドルが OpenAI の負担になることが判明したのです。
Oracle もこれらのデータセンターを建設するために借金をしています。
ジョーブ:Microsoft は最近の Build コンファレンスで、こうした中間製品は結局必要になると指摘しました。エンタープライズ業務は特殊なタスクであり、ドメイン知識を LLM プロバイダーに委ねたくないからです。分析のためのデータ近傍ミドルウェアが必要となり、それは業界全体から提供されることになります。
リンジー:モデルビルダーの収益予測が、今後数年で見られるような最適化トレンドに基づいているのか、それともトークンマキシングに基づくものなのかで大きく異なります。そこが大きな分かれ目です。
ブランドン:ジョーブさんの発言を踏まえると、ラボからは効率化の研究が出てこないようです。後者(トークンマキシズム依存)の可能性が高く、業界の未来にはあまり良い兆候ではありませんね。
これはバブルの一部として警戒すべきことでしょうか?問題を悪化させるのか、それとも克服して業界の不安定化を招かずに乗り越えられるのでしょうか?
リンジー:バブルについてはよく議論されますが、市場は依然として順調です。私よりも賢い人々が巨額の資金を投じています。しかし、ビジネスモデルがどうなるかが明確でない点には懸念があります。
ブランドン:投資に対するリターンはまだほとんど見えていませんね。
リンジー:その通りです。負債に関する疑問もあります。AI エージェントによるコーディングの話だけでなく、大手アプリケーションベンダーは財務や HR などの業務を代行する AI エージェントの構築にも注力しています。責任の問題について話しましたが、彼らが決定に対して責任を負うことはありません。そこにも疑問符がつきます。
過去にバブルが弾けた事例はいくつもあります。私の感覚では、将来的には需要に応じた容量が使われることになるでしょうが、その過程でいくつかの障害があるかもしれません。
ブランドン:ドットコムバブルが弾けてもウェブサイトが消えたわけではありません。AI も消えることはありません。ただ、その範囲や形状、利用方法は制限されたり変化したりするでしょう。
ジョーブさん、どう思われますか?
ジョーブ:不思議なことに、ドットコムバブルを思い起こさせると同時に、タブレットブームにも似ています。Microsoft はユーザーの 90% がタッチスクリーンを持っていないにもかかわらず、Windows をタブレット形式にリファクタリングしました。
18 ヶ月間、ソフトウェアベンダーはタッチ対応版を開発し、ラップトップメーカーもタッチスクリーンを搭載する必要がありました。やがて iPad や Surface が登場しました。
テクノロジー業界は往々にして一方に傾きすぎますが、最終的には顧客の需要を測るために後退し、より小さくても有用な産業が残ります。
ブランドン:大きな疑問は、AI 業界がこの制約によるダーウィニズム的進化のフェーズに入り、それが業界を救うことになるかどうかです。
原文を表示
KETTLE Like a drug dealer who's hooked you and raised their prices, business leaders are simply shocked to learn the AI their organizations are becoming dependent on is suddenly a lot more expensive. You can listen to the latest episode of The Kettle right here on this page, as well as on Spotify, Apple Music, or YouTube where you can subscribe to get notified of the latest episode. Kettle host Brandon Vigliarolo is joined by Reg reporter Lindsay Clark and contributor Joab Jackson this week to discuss their recent stories about the rising cost of enterprise AI - and one way a popular open source project is trying to fight tokenmaxxing with tokenminning - but the question remains whether such measure will be enough to prevent cost-benefit analyses from popping that bubble. Will the AI industry adapt to the fact it's still unprofitable, blowback from usage-based billing, and a desire to not pay AI models as much as the human devs they're supplementing or replacing? That's what's on the hob for this week's episode. A lightly edited transcript is below: Brandon: Welcome back to The Register Kettle podcast. I'm Reg Reporter Brandon Vigliarolo, and you're going to be absolutely shocked to discover what we're talking about this week. I'm kidding, of course, it's AI. Specifically the fact that it seems the world is starting to wake up to how much it costs to actually run these giant models that are supposed to make life easier for enterprises and their employees, but it seems like they're leading to some invoice shocks. With me to talk about the latest panic over AI costs are Reg reporter Lindsay Clark and our contributor Joab Jackson. Thanks to both of you for coming on. Lindsay Clark: No problem, thank you. Joab Jackson: Thank you. Brandon: So Lindsay, let's start with a story you wrote recently about the fact that C-suite occupants are apparently having trouble getting a handle on new usage-based AI costs. What exactly has them so confused? Lindsay Clark: I get the impression that big companies are diving in with both feet with AI. It's the latest trend. They're using it for a lot of coding and business apps, trying to do stuff in the business with it. KPMG is a massive global consultancy. They provide IT services and outsourcing services. Brandon: And they're the ones who wrote the report, correct? Lindsay Clark: That's right; they wrote the report and they have some skin in the game. They did a survey of more than 2,000 senior execs over 20 countries and found that 29 percent of them struggled to understand the operating costs as they scale with enterprise AI deployments. Nearly half of them were also looking to re-phase their AI deployments when the costs outweigh the expected value. Brandon: Explain re-phase. Are they rethinking the deployment itself or are they changing the scope? What's that mean exactly? Lindsay Clark: It's just slowing down and looking at what they're doing. They're looking at lower-cost models and high-fidelity models. It's looking for a mix of models to deploy rather than just maxing out on the most expensive ones. Brandon: Usage-based billing seems to be a relatively recent development in this space. It was all free samples until we get you in the door to the point where you're dependent on this, and then we realize we actually have to make money off this. Speaking as an AI frontier lab, we're going to have to charge you per token because we're just not able to turn a profit. Lindsay Clark: Anthropic, OpenAI, and GitHub have all moved from a subscription, flat-fee, all-you-can-eat model to usage-based billing based on tokens. The vendors, both the model providers and the application vendors that want you to use AI agents in their applications, want people to jump in with both feet and use this stuff as much as possible. Then, as is typical for the IT sector, they try to change the commercials as we go. Brandon: It's a big enough issue that more than a quarter of C-suite people are getting bill shock and realizing that they might not be able to afford this. But they're maybe a little bit hooked in because their engineers have been using this long enough. I wrote a story recently about an open source tool that someone wrote to test engineers to make sure they're not losing their edge in this environment, because a lot of them are. We've written plenty of stories about developers becoming dependent on this, forgetting how to do some of the basic things they used to be able to do. It gives these AI companies a big inroad to basically say, "Well, now we're going to actually try to make money." But it does put them in a precarious position. If you charge too much, these enterprise customers are going to try to find a way around it, whether it's an open source Chinese model or some other solution, rethinking their deployments and trying to go with smaller, large-scale models. But if you charge too little, you're never going to make enough money. Is this a needle that these AI labs can thread, or is it one that's pointed straight at the bubble? Lindsay Clark: There's a report from Gartner from a few weeks ago that was quite interesting. They had done some research about the cost on this topic for AI-assisted coding. Brandon: Right, this is one you covered back at the end of June, right? Lindsay Clark: That's right. A researcher called Nitish Tyagi was saying that there's a real lack of transparency from the vendors over the costs of their coding agents and they don't have cost optimization tools that you would expect in the cloud, for example. Because of this, the costs of the coding agent per developer was going to exceed the actual salary of the developer in 2028. That is the average salary globally. He was already finding that in areas of the world where salaries are a lot lower, like India, the cost of agents is actually exceeding the salary of the developer. This is because the cost of agents is the same throughout the world, whereas developers get paid differently according to where they're located. Brandon: I imagine the cost of these are maybe never going to exceed the salary of a developer in Silicon Valley; those guys are making a lot of money. Lindsay Clark: Exactly. Yes. Brandon: When I think about that, there's no way that you could have token costs being in the hundreds of thousands of dollars. But the overall global average is still a lot. I can understand that it's probably why you see a lot of companies concerned about the viability of AI deployments, causing companies to rehire the people they're laying off. It's another thing that screams, "How sustainable is this?" Lindsay Clark: That research, to your point about the bubble, means they have to recoup these costs somewhere. On the macro picture, a big investment house was looking at the capex across the industry for AI datacenters, and it was $1.5 trillion over five years until 2030. That's a lot of money, and it has to come from somewhere. Again, on the Gartner research, they were saying that all the model providers all have kind of different ways of doing the billing as well. There's no standard. So if you're looking at a way to approach this the model providers are likely to, then it's very hard. Gartner were encouraging people to take matters into their own hands, to look at optimizing their own usage, minimizing their own usage. And one of the things that came out of that call was that there was no direct relationship between any increase in token consumption and an increase in productivity and coding in this case. And that was very telling. It's not the case that the more that you use, the more that you get out of it. Actually, they were arguing that if you are careful with how you do this and controlled, then not only do you end up consuming less, but the quality of the code you produce is also higher. That was reflected in a conversation I had a few weeks ago with Spencer Kimball, who's CEO of Cockroach Labs. Spencer Kimball is well known in the coding world, spent a long time at Google, and he wrote the GIMP open source image processing tool. He said at Cockroach they don't do tokenmaxxing; they just use a whole bunch of models, including a lot of open source models and the cheapest models. He said there's no point in maxing out a model when you haven't provided the right context because you'll just get more rubbish back. He was in line with what Gartner had said; he's quite circumspect about how you deploy it on the commercial level. Brandon: Speaking of tokenmaxxing, that brings me to the next story. Joab Jackson, you wrote this a little while ago about a Netflix engineer who wrote an open source tool that has become popular very fast. It's apparently saved many users who have adopted it hundreds of thousands of dollars by trimming input to LLMs in order to save token cost. It's the opposite of tokenmaxxing; this is like tokenminning. What exactly did he come up with? Joab Jackson: This was a home project, as all good open source projects started out as. He had gotten a $287 bill from Claude Sonnet for some debugging and MCP type work he was doing. He was curious how you generate that large of a bill from that modest of a workload. He took a look at what he was sending over to Claude, and it's known that most token consumption is from input. You get charged for both token input and output, but most of the bills come from what you're putting into the system. He was inspecting the stuff that his agent was submitting, and the vast majority of it was completely redundant. It wasn't useful instructions; it was database schemas, JSON templates, or a lot of log work. He figured that if he could create a program that would tear out the redundant parts and then submit the useful information, he could save money. Claude does have a number of settings, but you quickly descend into AWS billing hell. There's a cache setting. Every time you give a query to an LLM, you're tagging on your complete history up until that point, so a lot of the same information gets passed up. You can set that history to stay for five minutes or an hour. This is how things get tricky real quick. You can set it for an hour, but it costs twice as much, though you get ninety percent savings in reads. Now you have to do the math of the stuff you're submitting versus your workload. Brandon: So this is basically trimming the fat, where instead of resending all that stuff as token input, it's basically telling the model, "You've already got this, use what you have." Joab Jackson: It's not even that you're being chatty. It's all these needlessly verbose schemas. If you have it execute a Rust command in verbose mode, you're going to get all that verbose stuff, even though the LLM doesn't need it. So he came up with a bunch of little modules that he calls squashers that look at these areas: database compression, JSON trimming, and so on. There are a lot of VC-backed token trimming tools now, but he wanted something inline that worked directly from the command line. Now, just a clarification, this wasn't work he was doing [for Netflix]; he has another job entirely at Netflix, but he built this program on his own. He let a few Netflix engineers try it and they liked it, but it just took off all of a sudden on its own anyway. Brandon: It's not an internal Netflix product; it's his own project. I'm curious how this would work. I'm assuming that this is entirely dependent on a context window? Joab Jackson: This is shaping the context window, basically. Brandon: If we go back beyond a certain point, because context windows have a termination, I'm assuming that at that point you're going to have to start resending stuff if you're still undertaking the same conversation. This is only effective as long as it remains in context. Joab Jackson: I use Gemini quite a bit, and they do keep a cache of the stuff so it does seem like a conversation. But after a certain point, although the conversation is seamless to you, all that data is being loaded back for the LLM to parse once again. Brandon: Gotcha. It's Project Headroom, right? So what's doing the work of clearing that headroom out? Is this another LLM or local algorithms that he's written to do this work? Where is that compression and trimming being performed? Joab Jackson: That's all being done on the client. He isn't using the LLM at all. He used some statistical analysis; say you send over a database table, the LLM probably doesn't need that entire table. It needs the first few entries, the schema, and any outliers to get an understanding, but it doesn't need all 100,000 rows. It's basically a series of tricks that he and other contributors have come up with to tidy it up. Brandon: I think you wrote in the story that his talk mentioned $700,000 in savings for the people who've been using it. You wrote the story at the end of May; do you have any update on how much money this thing has saved and how many people are using it? Joab Jackson: I haven't checked in lately, but originally he had estimated, just from the users who opted into telemetry, that they saved about two hundred billion tokens, which accounts for about $700,000. But there are other users who aren't submitting this information. It's open source, so you can't really track it. I did speak with him fairly recently and he said the project is taking off; it continues to attract attention. Brandon: I didn't see in your story whether there was an estimate of the percentage of a token budget or average query that this was trimming off, or is that going to vary by use case? Joab Jackson: Like sNinety percent of server logs aren't necessary. Seventy percent of JSON can also be cut because a lot of it is formatting. Anything that's routine formatting data you don't really need. He also had a nifty feature where he does some text compression. Everything is reversible, so if the LLM needs to go back and get more information, it can do that. Brandon: So this isn't a permanent thing. It's interesting; we're seeing horror stories about AI costs skyrocketing and huge bills. On the flip side, we see daily limits getting eaten up, leaving users with workflows and projects that are freezing in the middle of a workday. This might be what businesses need to free up tokens and trim AI expenses. What do you guys think? Is this going to be enough, or does something else have to give? Joab Jackson: We talk a lot about how generative AI is evolving, but if you really want to go back to evolution and you want to discuss Darwin, one of the core components was limitation of resources. Everything can grow indefinitely without limitations, but at some point, and that's when the real innovation kicks in, you only have limited resources. We have people complaining about data centers using too much electricity; I think the LLMs now are hitting that point. They're going to have to figure out how to make this work strictly with limited resources. I read a lot of AI research and I'm not seeing a lot of AI efficiency research coming out of the labs. Maybe it's just a necessary next part: we have this technology that we don't fully understand, but we have limits too. We have to start to factor in those limits. Lindsay Clark: I was going to add that as well as people looking at open source tools, the vendors, at least within the database market, see a big opportunity here. I've spoken to and read about a number of database vendors who are trying to improve the efficiency and reduce calls to LLMs. For example, a company called Pinecone which did vector databases a while back before everybody else did, is now looking to create a semantic layer between the agent and the business data and tech environment. You store the basics of the landscape in terms of database schema or how the company does financial processes, so you don't have to make calls to the LLM and create queries to find that out every time afresh. The point is, I think we're going to see a lot of people, perhaps from open source or proprietary vendors, see an opportunity here in selling to companies on the basis that they can reduce the costs of AI agents in their business. Brandon: I would hope that Oracle's working on that because, as we discussed last week, they're one of the most exposed to this bubble. Other big data center players that are courting the AI market, it's Microsoft, it's Amazon, it's Google, they all have big things to fall back on if the bubble ends up popping, whereas Oracle is on the hook for a lot of money without as much going on elsewhere. But if they can turn that database into a semantic layer that sits between and reduces calls, that might be pretty valuable. Lindsay Clark: I don't know, because they're also reliant on OpenAI. Last September, they announced a $450 billion pipeline of committed datacenter spending and the market reacted positively. Then a few weeks later, it turned out OpenAI were on the hook for $300 billion of that. Oracle is borrowing money to build these data centers as well. Joab Jackson: As Microsoft pointed out at the recent Build conference, you're going to need these in-between products anyway because the enterprise is a specialized task. There's domain knowledge you don't want to hand over to the LLM providers. There's going to be a whole set of middleware near the data, for analysis, and that will have to come from the channel. Lindsay Clark: It all depends whether the model builders' revenue forecasts are based on this trend for optimization that we're going to see in the next few years, or are the forecasts based on tokenmaxxing? That could be a big difference. Brandon: Based on what Joab just said, you don't see a lot of efficiency work coming out of these labs. My thought would be it's probably the latter, which probably doesn't bode well for the future of this industry. What do you guys think? Is this another thing that we have to watch out for as a potential part of the bubble? Is this going to exacerbate problems, or is this something that can be conquered and moved beyond without causing industry destabilization? Lindsay Clark: I don't know. We keep thinking about a bubble, there's been lots written about a bubble, but the markets seem fine. There are a lot smarter people than me investing a lot of money in this. But there is also cause for concern in terms of we don't really see exactly what the business model is going to be. Brandon: There aren't a lot of returns yet on investments. Lindsay Clark: Exactly. There are question marks over liabilities. There's a whole other side to this, there's AI agents doing coding, but all the big application vendors are looking to build AI agents that do business work for you in finance and HR, you talk about liability but they're not going to be liable for any of the decisions they make. So there's a question mark over that as well. We've seen bubbles burst in the past. My feeling is the capacity will be used at some point in the future, but there might be a few bumps in the road along the way. Brandon: We still have websites; the dot-com bubble burst but websites didn't go away. AI is not going to go away. It's just its scope and shape and use is probably going to be curtailed or changed. Joab, what are your thoughts? Joab Jackson: Weirdly enough, it reminds me of the dot-com bubble, but also reminds me the tablet craze. Microsoft refactored Windows for the tablet format even though 90% of their users didn't have any sort of touch screen capability. For 18 months, software vendors had to come up with touch-enabled versions and laptop manufacturers had to do touch screens. Eventually we got the iPad and the Surface. The tech industry does tend to go too far in one direction, but eventually it pulls back to gauge customer demand, and a much smaller but more useful industry is there somewhere. Brandon: The big question is whether or not we're entering this phase of constraint-driven Darwinian evolution in the AI industry that will save it
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み