Tensorfuse

Tensorfuse

Tensorfuse (Y Combinator W24, San Francisco) · コーディング · その他

Tensorfuseは自社のAWS・Azure・GCPアカウント内でAIモデルの配備、ファインチューニング、自動スケーリングを回すサーバーレスGPU基盤だ。モデルの重みもデータもVPCの外に出ない。

Tensorfuse の画面プレビュー

Tensorfuse について

What Is Tensorfuse

Tensorfuseは、モデルはすでにあり、その提供のためにKubernetesを自分で面倒みたくないチーム向けの基盤だ。自社のクラウドアカウントを指定すると、EC2インスタンス上にKubernetesクラスタ、ロードバランサー、オートスケーラーを組み上げ、最後にデプロイ用のコマンドを渡してくる。

売り物は運用の手間を減らすことで、GPUそのものを安く売ることではない。GPU時間はこれまでどおりクラウド事業者に支払い、Tensorfuseはその管理料を取る。計算資源、モデルの重み、データセットはVPC内に残るので、プロンプトもチェックポイントも第三者のアカウントを通らない。企業のセキュリティ審査では、この一点が評価を分ける。

弱点は、ホスティング済みのエンドポイントではないことだ。GPUクォータのあるクラウドアカウント、リソース作成の権限、アプリかモデルを入れたDockerfileが要る。クラウドアカウントを持たず5分で動くエンドポイントが欲しいなら、ホスティング型のサービスのほうが速い。料金表も公開していないので、比較の前に営業との打ち合わせが入る。

Getting Started

  1. クラスタを作る。ログインしてクラウド事業者を選び、指定されたIAM権限を与えて待つ。この工程に25〜30分かかる。
  2. Tensorkube CLIを導入し、さらに5〜10分。ローカル環境をクラスタに同期する。
  3. 動かすものをまとめる。FastAPIアプリでも推論サーバーでもDockerfileに入れ、秘密情報とモデル設定はenvファイルに書く。
  4. CLIでデプロイし、最小・最大レプリカ数を決めて、エンドポイントが正常になるまで状態を見る。

AIツール情報

Tensorfuseの料金、対応プラットフォーム、性能を簡単に確認できます。

無料プランはい
有料プランCustom quote, billed per managed GPU hour plus your cloud GPU bill
プラットフォームWeb dashboard, Tensorkube CLI, AWS (Azure and GCP supported)
開発元Tensorfuse (Y Combinator W24, San Francisco)
カテゴリコーディング · その他
リリース日Jun 2024
最終更新Oct 2026
サイト訪問数4.5K
サイト世界ランキング4M
API提供状況はい

こんな人におすすめ

このツールが最も力を発揮するユーザー、タスク、シーン。

ユーザー

  • シードからシリーズAのMLエンジニア:プラットフォーム担当を雇わずにオートスケール付きの推論を手に入れられる。調達額50万ドル未満なら管理料が6か月無料になるプログラムもある。
  • 規制産業のプラットフォームチーム:重み、プロンプト、データセットがVPC内に残るため、セキュリティ審査が短く済み、顧客データも既存のコンプライアンス境界から出ない。
  • すでにAWSを払っている個人開発者:GPUクォータとDockerfileがあれば、コマンド1つでモデルを公開でき、コストは既存のクラウドコミットに乗る。

タスク

  • オープンウェイトのLLMを提供する:vLLM、SGLang、TensorRT-LLM、Dynamoがコンテナとして動くので、アプリが呼んでいるOpenAI互換APIをそのまま使える。
  • 自社データでファインチューニングする:Axolotl、Unsloth、自作の学習ループでLoRAやQLoRAを回し、データセットは私有S3バケットから読む。
  • 埋め込み、評価、ラベリングなどのバッチ処理:ジョブキューが実行時だけGPUを起動し、終われば解放する。一晩中インスタンスを遊ばせずに済む。
  • 顧客別アダプターを大量に配る:マルチLoRAで数千個のアダプターを1枚のGPUに載せ、リクエストごとに差し替える。

シーン

  • トラフィックが増えると遅くなるSageMakerエンドポイントの置き換え:オートスケーラーは固定のインスタンス数ではなく実際のリクエスト負荷を見る。
  • 契約済みのAWS利用額を消化する:GPU時間が既存のクラウド請求に乗るため、クレジットや企業割引が効く。
  • 企業のセキュリティ質問票を通す:自前で基盤を組まなくても、データは自社アカウントから出ないと答えられる。

主な機能

自社VPC内でのサーバーレス推論

デプロイは流入するトラフィックに合わせて増え、リクエストが止まれば縮む。コンテナは自前で用意する。vLLM、SGLang、TensorRT-LLM、NVIDIA Dynamoのどれでもよく、クラスタ、ロードバランサー、スケーリング規則はTensorfuse側が持つ。エンドポイントの振る舞いは既存のホスティングAPIと同じなので、移行でコードを書き直す必要はない。

大きなコンテナの高速コールドスタート

サーバーレスGPUの弱点はコールドスタートに出る。Tensorfuseは数GBのGPUイメージを想定したコンテナランタイムを積んでおり、起動は秒単位だと会社は説明する。利用者にとっては、アイドル時にゼロへ落としても最初のリクエストがタイムアウトにならないかどうかの差になる。

1枚のGPUで複数LoRAを動かす

数千個のLoRAアダプターを1枚のGPUで学習し、入れ替えながら提供できる。顧客ごと、用途ごとにエンドポイントを分けず、ベースモデルを1つ立ててリクエストに応じてアダプターを載せる。顧客別のカスタマイズが多いチームほど効く。アダプター数がGPU数に直結しなくなるからだ。

使い慣れたフレームワークでのファインチューニング

学習は自社クラウドのGPU上で、Axolotl、Unsloth、Hugging Faceのライブラリ、自作ループのいずれでも回せる。データセットと出力した重みは私有S3バケットに残る。独自形式を強制されないので、ノートPCで試した実験を同じスクリプトのまま移せる。

バッチ処理向けのジョブキュー

評価、データの再生成、ラベリングのような長い処理に常時稼働のエンドポイントは要らない。コードからキューに積み、コスト制御のために最小・最大スケールを決め、状態はコマンド1つで確認する。GPUは実行時だけ現れて消える。時間課金の意味はそこにある。

IDEと同期する開発コンテナ

SSHなしでローカルのコードをクラウドGPUにつなぐ。エディタで書き続ければ、変更は実行中のコンテナへ即座に反映される。本番デプロイの前に、モデルの変更を実機で確かめる最短の道だ。

メリットとデメリット

メリット

  • モデルの重み、データセット、プロンプトが自社クラウドアカウント内に残る。セキュリティ審査で最も通りやすい構成だ。
  • GPU時間が既存のAWS請求に乗るため、コミット済み利用額、クレジット、企業割引がそのまま効く。
  • コンテナなら何でも動く。vLLM、SGLang、TensorRT-LLM、自作FastAPIサービスが同じデプロイ手順に乗る。
  • クラスタ構築は1時間かからず、スケーリング規則も設定済みで自前実装が要らない。
  • マルチLoRAにより顧客別アダプターのコストが下がる。数千個が1枚のGPUを共有する。

デメリット

  • 最初のデプロイ前にクラウドの管理者権限とGPUクォータが要る。インフラ経験のないチームはここで止まる。
  • GPUの請求はクラウド事業者から出るので、最小レプリカを遊ばせていると静かに費用が積み上がる。自分で調整する必要がある。
  • 公開の料金表がない。ホスティング型GPU事業者と比べるには、まず営業との会話が前提になる。
  • AzureとGCPのドキュメントはAWSよりかなり薄い。マルチクラウドのチームは初回デプロイで試行錯誤が増える。

よくある質問

自社のクラウドアカウント内にサーバーレスGPUの一式を導入して運用する。コンテナを渡せば、クラスタ、ロードバランサー、オートスケーラーを用意し、モデルはトラフィックに追従するHTTPエンドポイントの背後で動く。