2026-07-29 · teai.io team · 12 min read

Kimi K3を測り、直し、teaiに自分を直させた
2.8兆モデルと$45の全記録

2026年7月、Moonshot AIがKimi K3(2.8兆パラメータ)の重みを公開した。私たちはこれを題材に、teai.io自身の道具でteai.ioを測り、直し、最後には「teaiに自分のコードを直させる」ところまでやった。本記事は、実測ベンチ・8×H100自前ホストの6回の試行(5回全滅→6回目で成功)・そこで見つけた真因・ teaiのセルフアップデート、そしてかかったコスト($45)と作業量まで、盛らずに全部書く。

15,112

実測 8×H100 集約tok/s(30B MoE)

6回目

でvLLM配信成功(5回全滅)

4 PR

改善+Critical脆弱性1件修正

~$45

GPU実費 + 無料枠1000cr

1. 測る — teai.io経由でK3を叩く

まず同一のK3を2経路で実測した:teai.io と OpenRouter直(Moonshotルート)。結果は品質パリティ(同一モデルなので当然)、レイテンシもコストも実質互角で、teaiがラッパーとして遅延を足していないことを確認。ついでにK3は「常時思考(always-on thinking)」型で、max_tokensを20など小さくすると本文が空で返る挙動も実測した(推論トークンで枠を使い切るため)。

副産物のバグ発見: teai.ioのストリームは stream_options.include_usage を付けても usage(トークン数)を返していなかった。OpenRouterは返す。→ 後述の「直す」で根治した。

2. 自前ホストは安いのか — 8×H100の6回

K3自体は2.8TB級で単体GPUに載らない(最小64×80GB)。そこで実際にRunPodで8×H100($23.92/hr)を借り、自前ホスト可能なMoEをvLLMで立ててスループットを測ろうとした。ここからが本編だった。

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

vllm/vllm-openaiイメージ + runpodctl --args で235B×2・30B×1・SSH付き構成、いずれも /v1/models が200を返さず撤収。当初は「DL律速」「/dev/shm不足」「TP8起動が遅い」と推測したが、全部ハズレだった。致命的だったのは公式vllmイメージにsshdが無く、ログが1行も見えなかったこと。原因不明のまま約$29を溶かした。

転機: ログが見えたら、一発で真因が出た

runpod/pytorchベース(sshd内蔵)に変えてSSHでログを見たら、こう書いてあった:

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

真因はインフラでも時間でもshmでもなかった。 block量子化FP8のMoEチェックポイント(Qwen3-*-2507-FP8)は、エキスパートのgate/up次元がFP8ブロックサイズ128で割り切れず、vLLMの重み生成で即クラッシュする。しかも96<128なのでTPをどう変えても直らない(235Bも192で同じ死に方)。/dev/shmは937GBあった(shm説も棄却)。これが5回全部の敗因で、ログさえ見えれば5分で分かったことに$29かかった——まさに自前ホストの隠れた運用コストだ。

6回目: bf16版で一発で立った

回避策は「block-fp8パスを通らないbf16版を使う」。vllm serve Qwen/Qwen3-30B-A3B-Instruct-2507(positional指定・--host 0.0.0.0)で起動し、pod内localhostから実測:

同時実行	集約 tok/s	1req tok/s	p95
1	275	275	1.9s
32	5,293	167	3.1s
64	8,624	137	3.8s
128	15,112	121	4.3s

正直な注記: 30B-A3Bは active 3BでK3(~50B active)より遥かに軽く、15,112 tok/sは上限側の楽観値。K3代表値は公開のDeepSeek-V3(37B active・8×H100≈821 tok/s)が近く、K3は8GPUで~500–900 tok/s、64GPUで~4,000–6,000 tok/s程度と見るのが妥当。

結論: ほぼ全員APIが安い

K3自前ホスト(64×H100)は月$137,779。API($15/1M出力)と並ぶには集約3,540 tok/sを100%稼働で回し続ける=月9.2B出力トークンが必要。現実の稼働率(20–40%)では実効コスト2–4倍でAPI負け。自前が勝つのは超大量・高稼働のハイパースケール帯だけ。詳細はGPU-TCOレポートにまとめた。

3. 直す — teaiにteaiを直させる

ここが本記事の核心。teai.io自身の道具(公式CLI「Sente」)と、teaiが配信するモデル(Kimi K3)で、teaiのコードを直した。

① stream usageバグの根治(人間+PR #167)

「測る」で見つけたusage未返却バグを修正。stream_options.include_usage:trueのとき、[DONE]直前にOpenAI準拠のusageチャンク ({"choices":[],"usage":{...}})を出すようにした。本番デプロイ後にcurlで実測確認済み。

② teaiのセルフアップデート(Sente×K3・PR #172)

teai公式CLI「Sente」の最高性能モード te max(= Kimi K3)にタスクを渡し、K3自身に26,000行のhttp.rsを編集させた:

# 自分のCLI × 自分のモデル × 自分のコード
curl -fsSL https://teai.io/te | sh
te max run "OpenAI応答に system_fingerprint を追加して cargo check して"

K3は6箇所すべてに "system_fingerprint": "teai" を正確に追加し、cargo checkまで自走。人間はレビューと独立検証のみ。 = 自分で自分を更新できた。

③ ストリーム効率化(Sente着手→PR #173)

空のcontentチャンクを送らない効率化も Sente(K3)に着手させた。K3は該当箇所をgrepで特定するところまで自走したが、 ここで無料枠クレジット(1000cr)を使い切った。残りの1行ガードは人間が完了。 皮肉にも、これ自体が「K3で実作業を回すコスト」の実測データになった。

④ セキュリティ確認 — Critical を1件発見・即修正(PR #174)

独立したレビューエージェントに、teaiのHTTP API(認証・レート制限・課金・入力検証)を到達性まで確認させた。結果、Critical を1件発見:

🔴 X-Forwarded-For 偽装によるレート制限の全バイパス
クライアントは X-Forwarded-For ヘッダを任意に設定でき、コードはその先頭値(=申告値=偽装可)を「クライアントIP」として採用していた。 → ヘッダを毎回変えるだけで匿名 10req/min・1日50回のファーミング対策・登録IP上限を全て無限にバイパス可能だった。レート制限のロジックは直っていたのに、IPそのものが偽装できるため実質無効という、いやな穴。

即修正した: XFFは先頭でなく末尾(Flyが付加する信頼値)を採り、Fly-Client-IP(edge観測・偽装不可)を最優先に。他カテゴリ — 認証バイパス(匿名が有料/adminに到達)・クレジット残高のunderflow/レース・ストリーム切断による無料トークン刈り取り・model名注入による無償ルーティング — はいずれも到達性を追って問題なしと確認できた。

教訓: レート制限は「回数の数え方」だけでなく「誰を数えるか(=IPの信頼源)」まで正しくないと意味がない。プロキシ配下では、クライアントが触れるヘッダを信じてはいけない。

4. コストと作業量(全部書く)

項目	実費 / 量
GPU(8×H100 SXM ×6 pod)	~$45(@ $23.92/hr)
K3/API(Sente実行+APIテスト)	無料枠1000cr 完全消費
teaiへのPR	4本(#167 merged / #172 / #173 / #174)
セキュリティ発見	1件 Critical(XFF偽装・修正済 #174)
本番デプロイ	1本(#167・stream usage)
公開ブログ(K3解剖 ja/en)	2本本番LIVE
レポート(artifact)	2本(APIベンチ / GPU-TCO)
調査エージェント	2体(根本原因 / セキュリティ)
GPU起動試行	6回(5失敗→1成功)

※ GPUの$45は「動かなかった5回」込み。ログが見えるベースイメージを最初から選べば$29は不要だった=学習コスト。

5. 学び

ログが見えないデバッグは金を溶かす。8GPUを立てる前に「ログをどう見るか(SSH/コンソール)」を先に用意する。
block量子化FP8のMoEは、TP次元が128で割り切れないと即死。bf16版か、割り切れるTP/DP構成を使う。単体GPUでもない限り、これは高確率で踏む罠。
自前ホストは「速いか」でなく「安いか」で負ける。フロンティア級の重みが開いても、コスト構造で勝てるのは超大量トラフィックだけ。それ以外はAPI+ゼロ運用。
モデルはコモディティに近づき、勝負は「届け方」へ。teaiがやるべきは、Claude Code/Codex/Sente互換・国内商習慣の課金・自己改善できる開発ループ。
AIに自分のコードを直させるのは、もう現実。ただし人間のレビューと独立検証はまだ外せない。

まとめ: 2.8兆のオープンウェイトを、teai自身の道具で測り、直し、自己更新までやってみた。答えは「安く使うならAPI、勝負どころは届け方」。そしてteaiは、自分のCLIと自分のモデルで自分を直せるところまで来た。全部$45と無料枠1本で。

teaiを無料で試す → 公式CLI Senteを見る

実測: 2026-07-28〜29。GPU=RunPod 8×H100 SXM・vLLM 0.26。ベンチはpod内localhost計測。K3外挿・TCOは概算で実機K3の64GPU実測ではない。数値は参考値。

Kimi K3を測り、直し、teaiに自分を直させた2.8兆モデルと$45の全記録