きっかけ

2026年7月、Moonshot AIがKimi K3(2.8兆パラメータのMoEモデル)の重みを公開した。自分がやっているteai.io(LLM APIゲートウェイ)にすぐ追加したのだけど、それだけで終わらせず「自前でホストしたら本当に安いのか」「teai.io自身の道具で、teai.io自身を直せるのか」を実際にやってみることにした。

結論から書く。8×H100を6回借りて、5回失敗した。$29を無駄にした後にようやく真因が分かり、6回目で動いた。そして最後は、teaiの公式CLIとKimi K3自身に、teaiのコードを実際に直させた。

盛らずに、失敗も含めて全部書く。

自前ホストは安いのか、まず試した

Kimi K3は2.8TB級で単体GPUには載らない。RunPodで8×H100($23.92/hr)を借りて、vLLMで配信できるか試した。

1〜5回目: 全滅。しかも原因が見えなかった

vllm/vllm-openaiイメージで235B×2・30B×1の構成を試した。全部/v1/modelsが200を返さず、起動失敗。

最初は「ダウンロードが遅いのか」「/dev/shmが足りないのか」「8並列の起動が単に遅いのか」と推測した。全部ハズレだった。

一番まずかったのは、使っていたvllm公式イメージにsshdが入っておらず、ログが1行も見えなかったことだ。コンテナが起動してるのか死んでるのかすら分からないまま、原因不明のまま約$29が消えた。

転機: ログさえ見えれば5分で分かった

sshd入りのベースイメージに変えて、初めてSSHでログを見ることができた。そこにはこう書いてあった。

ValueError: The output_size of gate's and up's weight = 96
is not divisible by weight quantization block_n = 128.

真因はインフラでも時間でも/dev/shmでもなかった。**FP8量子化されたMoEモデルは、内部の次元がFP8のブロックサイズ(128)で割り切れないと、vLLMの重み読み込みで即クラッシュする。**今回は96という次元で、96は128で割り切れない。GPUの並列数をどう変えても直らない構造的な問題だった。ちなみに/dev/shmは937GBあって、shm不足説は完全にハズレだった。

**ログさえ見えれば5分で分かることに、$29かかった。**これが自前ホストの隠れたコストだと思う。

6回目でようやく動いた

回避策は単純で、この量子化を使わないbf16版のモデルに変えるだけだった。それで一発で立ち上がり、実際にスループットも測れた。

で、自前ホストは安いのか

計算すると、K3を自前でフルにホストする場合、月間$137,779かかる。API利用と釣り合うには月9.2億トークンの出力を、24時間フル稼働で回し続ける必要がある。普通の稼働率(20〜40%程度)なら、実効コストは2〜4倍に膨らんでAPIに負ける。

自前ホストが勝つのは、桁違いに大量のトラフィックを常時さばいている場合だけ、というのが正直な結論だった。teai.ioでは当面、自前ホストはしないことにした。

teaiに、teai自身を直させてみた

ここが今回一番面白かったところ。teai.io公式のコーディングエージェントCLI「Sente」と、Kimi K3自身を使って、teai.ioのコード(Rustで2.5万行の1ファイル)を実際に直させた。

curl -fsSL https://teai.io/te | sh
te max run "OpenAI応答に system_fingerprint を追加して cargo check して"

K3は該当する6箇所すべてに正確にフィールドを追加し、cargo checkまで自分で確認して完走した。人間がやったのはレビューと、別の目での独立検証だけだ。自分のツールと自分のモデルで、自分のコードを直せたことになる。

ただし良いことばかりでもない。別の効率化タスクを渡したときは、無料枠のクレジット(1,000cr)を使い切ってしまい、最後の1行は結局自分で直した。皮肉なことに、これ自体が「AIに実作業をやらせるコスト」の生々しい実測値になった。

ついでに見つかった、いやなセキュリティの穴

独立したレビューエージェントに、teai.ioの認証・レート制限・課金まわりを実際に到達性まで確認させたところ、重大な穴が1つ見つかった。

X-Forwarded-Forというヘッダをクライアントが自由に偽装でき、コードはその偽装可能な値を「クライアントのIPアドレス」として信用していた。つまり、このヘッダを毎回変えるだけで、匿名アクセスの回数制限や不正利用対策を無限にすり抜けられる状態だった。すぐに直した。信頼できるのはインフラ(Fly.io)が付け足す末尾の値だけで、クライアントが触れる先頭値を信じてはいけない、という当たり前だけど痛い教訓だった。

かかったコストの全部

  • GPU代(8×H100を6回、うち5回失敗): 約$45
  • Kimi K3のAPI利用: 無料枠1,000クレジットを完全消費
  • 直したコード: 4件(うち重大なセキュリティ修正1件)

全部で$45と無料枠1本分。これだけで「2.8兆パラメータのモデルは自前で持つべきか」「AIに自分のコードを直させられるか」の両方に、実測込みで答えが出た。

学んだこと

  • **ログが見えない状態でGPUを触ると、金だけ溶ける。**先にログの見え方を確保してから始めるべきだった
  • 量子化されたMoEモデルの自前ホストには、今回のような「割り切れないと即死」系の罠がよくある
  • モデルの重みが公開されても、勝負は「安く持つ」ことじゃなく「どう届けるか」に移っている
  • AIに自分のコードを直させるのは、もう現実的にできる。ただし人間のレビューはまだ外せない

teai.ioでは今回の実測を元に、しばらく自前ホストはせず、API仕入れのまま提供を続ける。