$1.5B Series FのBaseten、AI推論を「速さ・control・運用」に分解する基盤

2019年、AIの実用化を待つのではなく準備する

Basetenは2019年に、Tuhin Srivastava、Amir Haghighat、Phil Howes、Pankaj Guptaらが機械学習の影響を加速するために始めた。

まだlarge-scale model servingを必要とするteamが多くなかった時期に、創業者たちは後のproduction AIに必要な基盤へ賭けた。出典

2022年、市場が推論を必要とし始めた

Tuhin SrivastavaはSeries D発表で、2019年から2022年にはlarge-scale model servingをするteamが少なかった一方、ChatGPT、Stable Diffusion、Whisperによって状況が変わったと振り返る。

「Seemingly overnight, inference went from niche to mainstream」と記した。出典

OSSのTrussから本番運用へ

2024年のSeries Bでは、BasetenはTrussをproduction model servingのopen-source standardとして位置付け、開発から本番までをまたぐworkflowを打ち出した。

同年の$40M Series Bは、IVPとSparkが主導した。出典

資金と需要が同時に加速した2025年から2026年

2025年9月に$150M Series D、2026年1月に$300M Series E、6月に$1.5B Series Fを発表した。

Series Eでは前年のinference volume 100倍、Series Fでは過去1年のrevenue 20倍とinference volume 40倍を公表している。出典 出典

結び

Basetenの道のりは、AI modelが賢くなることを待つのではなく、速さ、信頼性、cost、deploymentの問題を先に解こうとした時間だった。

今後の焦点は、急増する推論需要を性能だけでなく顧客のcontrolと運用速度に変え続けられるかにある。

Basetenが解くのは、AI product teamがモデル選定・fine-tuning・GPU確保・runtime最適化・autoscaling・観測を別々に組み合わせず、独自モデルを本番APIとして運用したい痛みだ。

公式docsはTrussでmodelをcontainer化し、architecture別engineがquantization、tensor parallelism、KV cache、batchingを担うと説明する。出典

shared APIの手軽さを越えて、低遅延、data residency、独自modelのcontrolを求める段階で適合する。

Model APIsで試せる入口と、self-hosted・hybridまで同じstackで伸ばせることがPMFを支える。出典

moatはGPUそのものではなく、model architecture別のengine、Truss/Chainsの開発workflow、multi-cloud capacity management、運用実績を一つのcontrol planeに重ねることにある。

customerがfine-tuned model、autoscaling設定、observability、regional deploymentを運用へ埋め込むほど移行コストは上がると考えられる。出典

直接的な二面市場network effectは強くない。

ただしTrussのOSS adoption、model examples、engine対応、customer事例が開発者の選択コストを下げ、より多いworkloadから得る性能最適化の知見がproductを強くする学習効果はある。

これは市場規模よりtechnical feedback loopに近い。出典

対象は、shared model APIの手軽さでは不足し、独自・fine-tuned・open-weight modelを自社productの核として本番運用するAI companyとenterprise AI teamだ。

特に低latency、predictable cost、regional deployment、private VPC、complianceを同時に求めるvoice、healthcare、agent、searchのworkloadに適合する。出典

第一にTrussをOSSにし、Pythonのconfigとcustom codeからdeploymentへ進める開発者導線を持つ。

Trussはcontainerization、dependency、GPU configurationを扱い、Basetenまたは自前infrastructureでproduction-ready servingを目指す。出典

第二に、runtime最適化とmulti-cloud capacityを商品中核に置く。

Series Fではrevenue 20倍、inference volume 40倍を公表し、customerのpost-trainingからservingまで伴走する方針を示した。出典

GPU供給、cloud pricing、open-weight modelの更新速度に事業原価とperformance約束が左右される。

Basetenは複数cloud・regionでcapacityを配分するが、model loadingとcold startには時間と従量課金が発生する。出典

また、専用inference platformはhyperscaler、model provider、vLLM/SGLangを自前運用する顧客と比較される。

forward-deployed支援が価値になる一方、導入時にはworkload計測とコスト設計が必要である。

成長の入口はModel APIsとTrussによるdeveloper self-serveで、open-weight modelをすぐ試せることにある。

productionでlatency、uptime、data residency、private deploymentが問題になるほど、dedicated deployment、self-hosted、hybrid、forward-deployed engineeringへ拡張できる。出典

Wispr Flowのようなcase studyでp99 latencyやautoscalingを具体化し、AI applicationの成功がBasetenの利用量へ連動する構図を作る。出典

主要チャネル: productLedGrowth, developerDocumentation, openSource, contentMarketing, caseStudies, enterpriseSales, partnerEcosystem

AI infrastructureの価値はGPUを貸すことだけではない。

顧客が欲しいのは、modelを替え、fine-tuneし、trafficが急増してもproduct experienceを壊さず運用できる反復速度である。

OSS CLIを入口にしつつ、productionではruntime・capacity・supportを束ねる設計は、PLGとenterpriseの接続例になる。出典

日本で同型の事業を作るなら、GPU調達だけを主戦場にせず、国内data residency、医療・金融の監査、Japanese speech/voice、社内RAGやagentのevaluationを含む導入支援まで商品化するべきだと考える。

shared APIからprivate VPCへ移る判断を、latency・cost・complianceの実測templateで支援する余地がある。出典