Token Factoryとは：GPU・モデル・Tokenを運用可能なAIサービスへ変える6つの要点

GPUを持っているだけでは 、AIサービス事業を持っていることにはなりません。機器を設置した後も、運営者は多くのことを決める必要があります。 顧客がどうリソースを申し込むか、モデルをどうデプロイするか、使用量をどう計測するか、テナントをどう分離するか、請求書をどう作るか、ピーク時にもサービス目標を守れるか。これらがなければ、GPUは高価な在庫にすぎません。繰り返し提供でき、計測もできる仕組みがあって初めて、計算リソースは商品になります。

これが Token Factory の考え方です。データ、モデル、計算リソースを投入し、標準化された推論、スケジューリング、ガバナンス、メータリングを通して、Tokenサービスを継続的に生み出します。このサービスはAPIで利用でき、サービスレベルで管理でき、コストと収益をどこに帰属させるかも明確にできます。ただし、Tokenそのものが常に同じ事業価値を持つわけではありません。Tokenは推論生産の共通単位であり、最終的には顧客が得るサービスの成果へ結びつける必要があります。

INFINITIXの製品ポジショニングでは、Token Factoryは ixCSP に対応します。ixCSP公式ページは、AI-Stackを基盤にした商用AIクラウドサービスプラットフォームとして、GaaS、MaaS、TaaS、従量課金、マルチテナント管理が示されています。これらが、現時点で確認できる製品の基盤です。より完全なユニットエコノミクス、サービスカタログ、モデル横断配置は、未公開機能ではなく、運用設計と今後の方向性として扱います。

リクエスト、モデル、計算リソースを計測可能なAIサービスへ変えるToken Factoryの生産ライン

図：Token Factoryはリクエスト、モデル、計算リソースを推論、スケジューリング、ガバナンス、メータリングに通し、提供可能なAIサービスへ変えます。

一、機械室ではなく「生産の仕組み」としてのToken Factory

NVIDIAはAI Factoryを、エネルギーとデータをTokenへ変える新しいインフラと位置付けています。 その経済性は、Tokenスループット、Token/ワット、Token単価、使用率などで評価するとしています （AI Factories）。推論が単発のモデルデモから、継続的な大量生産へ移っていることを理解するうえで、分かりやすい比喩です。

しかし、1秒当たりのToken数だけでは工場を説明できません。製造には、原料仕様、作業指示、品質検査、在庫、保守、出荷が必要です。Token Factoryにも、少なくとも次の6つの機能が必要です。

• サービスの定義
• テナントとID
• モデルと実行環境
• リソースのスケジューリング
• 使用量の計測
• 請求とサービス品質

つまりToken Factoryは、特定のGPUでも、１台の推論サーバーでもありません。技術リソースを、注文できるサービスへ変える仕組みです。顧客が見るべきなのはラックの数ではなく、サービスカタログ、クォータ、エンドポイント、メーター、サポートの範囲です。

二、原料から出荷まで：Tokenサービスの5つの工程

運用可能なToken Factoryは、5つの工程に整理できます。

全工程で、同じテナント、プロジェクト、サービスIDを使う必要があります。推論はエンドポイント名、請求はアカウント、監視はPod名だけを記録していると、月末に人がデータを突き合わせることになり、顧客からの 問い合わせにも答えられません。最初に標準化すべきなのは、モデルの最適化ではなく、システムを横断する識別子である場合が多いのです。

OpenTelemetryの 生成AI可観測性は、モデル名、入出力Token、ツール呼び出し、遅延をトレース、メトリクス、イベントとして記録する方法が示されています。共通の定義があれば、顧客のリクエストからモデル、ツール、インフラまでを一続きで追跡できます。

三、同じ工場の3つの製品階層としてのGaaS・MaaS・TaaS

ixCSPは、商用のサービス提供を3つのモデルに分けています。これらはどれか1つを選ぶものではなく、事業者が運用責任をどの層まで引き受けるかの違いです。

Token Factoryでは、この3つの層が基盤と運用データを共有できます。GaaSのGPUプールがMaaSのモデルエンドポイントを支え、MaaSがTaaSの推論元になります。各層は製品の境界と料金体系を保ちながら、ID、監視、請求の仕組みを毎回作り直す必要がありません。

ixCSPの公開情報には、使用量計測、従量課金、マルチテナント管理、GaaS/MaaS/TaaSが含まれています。製品メッセージは明確です。AI-Stackがリソースと制御の基盤を提供し、ixCSPがそれを販売・計測・継続運用できるサービスに変えます。

四、Token数だけでは足りないメータリング

Tokenは課金の単位としては自然ですが、サービスを評価する指標としては不十分です。NVIDIAの LLM推論指標 では、Time to First Token（TTFT）、Inter-token Latency（ITL）、End-to-end Latency、Tokens per Second（TPS）、Requests per Second（RPS）を区別しています。測定ツールによって定義が違う数値は、そのまま比べることができません。

運用可能なTaaSには、次の4種類の指標が必要です。

1. 使用量：入力Token、出力Token、リクエスト、ツール呼び出し
2. 体験：TTFT、全体の遅延、ストリーミングの安定性、エラー率
3. 容量：同時実行数、キューの待ち時間、TPS、使用率、飽和点
4. 成果：タスクの完了、再試行、人への引き継ぎ、コンテンツ/権限ポリシーの結果

「TPSは高いほど良い」にも条件があります。バッチを大きくすると全体のスループットは上がりますが、個々の利用者の待ち時間が長くなる場合があります。コンテキストが長くなると、最初のTokenが返るまでの時間とメモリーの負荷が増え、飽和点に近づくとキューが急に伸びます。サービスカタログには、モデル、ハードウェア、入出力の長さ、同時実行数、測定した範囲を明記すべきです。1つのピーク値を、全負荷での保証として扱ってはいけません。

請求データは、あとから計算し直せることも必要です。使用記録ごとに、 テナント、サービス、モデルバージョン、入出力Token、時刻、料金バージョン、割引ルールを残します。Tokenizer、料金、プランが変わっても過去の請求を説明できなければ、リアルタイム画面だけでは商用運用を支えられません。

五、ログイン画面ではなく製品の境界としてのマルチテナント

Token Factoryは、複数の社外顧客や社内部門にサービスを提供します。マルチテナントとは、アカウント分離だけではなく、データ、ネットワーク、モデル、リソース、ログ、請求の分離まで含みます。

Kubernetes公式の Multi-tenancyガイドでは、クラスターを共有するとコスト削減や管理の簡素化につながる一方で、セキュリティ、公平性、noisy neighbor（ほかの利用者の高負荷による影響）の課題があると説明しています。信頼関係、規制、性能の要件によって、namespace、仮想コントロールプレーン 、専用ノード、独立クラスターなど、必要な分離の方法は変わります。

サービス提供者は、分離を「確認できる条件」として示す必要があります。

• ID/APIキーで、自分のエンドポイントと使用量だけが見えるか
• モデル、プロンプト、ベクトルデータ、ログがテナント間で共有されていないか
• 1つのテナントの高負荷が、ほかのサービスを遅くしないか
• 管理者がコンテンツにアクセスできるか、その操作を監査できるか
• 契約終了後、モデル、データ、キャッシュ、バックアップをどう処理するか

分離の方式は、価格にも直接影響します。共有リソースは平均使用率を上げやすい一方で、精密なクォータ、優先順位、保護の仕組みが必要です。専用リソースは分離や容量を説明しやすいものの、固定費が増えます。Token Factoryでは、1つの方式をすべての顧客に当てはめず、サービスの階層ごとに技術的場境界を明示します。

六、コストセンターからサービス事業へ：ユニットエコノミクスによる検証

クラウドAPI単価とGPU購入費だけを比べるだけでは、商用化できるかどうかは判断できません。 固定費には、機器、施設、ネットワーク、ソフトウェア、運用の人件費が含まれます。変動費には、電力、モデル呼び出し、ストレージ、通信、サポート、再試行があります。GPUの減価償却をToken数で割るだけでは、提供コストの多くを見落とします。

FinOps Foundationの Cloud Unit Economics は、コストを分かりやすい業務単位に結び付ける考え方です。Token Factoryでは、2つの視点を持つことができます。技術単位は、100万Tokenあたりのコスト、1リクエストあたりのコスト、実際に使える容量です。商用単位は、テナント、サービス、完了したタスクごとのコスト、売上、粗利です。Tokenは共通の物差しですが、最終的な単位は顧客が受け取るサービスです。

90日検証は、3段階に分けられます。

1〜30日：サービスSKUを1つ定義

モデルとワークロードを1つ選び、テナント、データ範囲、入出力範囲、想定同時実行数、サポートの責任、課金単位を決めます。未検証のSLAを約束せず、コスト基準を作ります。

31〜60日：計測から請求までの一本化

申込、デプロイ、APIキー、リクエスト、使用量集計、請求書まで、同じIDを使います。通常時とピーク時の負荷で、TTFT、TPS、キュー、エラー、再試行を確認し、すべての請求を裏付けとなる記録までたどれる状態にします。

61〜90日：2番目のテナントと例外ケースの追加

クォータ枯渇、モデル障害、料金バージョンの変更、テナントの削除、noisy neighborを試します。例外が起きてもサービス、請求、ガバナンスの記録が食い違わないことを確認してから、モデルカタログと顧客数を広げます。

Token Factoryの本質は、Tokenを新しい商品として言い換えることではなく、AI推論を反復可能なサービス生産へ変えることです。ixCSPのGaaS、MaaS、TaaS、計測と課金、マルチテナントの機能が、検証可能な基盤となります。そのうえで、サービスカタログ、ユニットエコノミクス、エンドツーエンドの可観測性が、GPU資産を顧客のAIサービスへと結び付けます。