vLLMにプラグインでTenstorrentを統合：メッシュ型アクセラレータ向けに段階別スケジューリングとデータ並列経路を構築

Tenstorrentチームは、vLLMの標準的なプラットフォーム機構と汎用プラグインエントリポイントを通じて、ハードウェア、モデルアーキテクチャ、ワーカープロセス、スケジューラを登録する`vllm-tt-plugin`を公開した。環境からTT-Metalの`ttnn`をインポートできれば、vLLMはTenstorrentプラットフォームを認識する。外部からは従来のOpenAI互換エンドポイントとリクエスト形式をそのまま利用できる。この設計の要点は、ハードウェア依存コードをApache 2.0ライセンスのプラグイン内に収め、上流への追随が遅れがちなvLLMのフォークを長期的に保守する必要をなくすことにある。

現在、このプラグインはLlama、Qwen、Mistral、Gemma、DeepSeek V3、GPT-OSS、および一部のVision-Languageアーキテクチャに対応している。モデル実装はプラグイン自体には含まれず、TT-Metalが手書きのTTNNカーネルを提供する。プラグインはcheckpointで宣言されたアーキテクチャ名に基づいて登録を行う。そのため、「モデルを認識できる」ことは、あらゆるデバイス、精度、コンテキストの組み合わせが検証済みであることを意味しない。デプロイ担当者は、引き続きTT-Metalのモデル対応表とコミットバージョン表を照合する必要がある。

本質的な違いはスケジューリングにある。上流のvLLMは、同一ステップ内でchunked prefillとcontinuous decodingを混在させられるが、現在のTenstorrent経路では各ステップをprefillまたはdecodeのいずれかに固定し、両者を切り替える。decodeが安定している間は、深さ2のキューによって、ホストが次のステップをスケジュールするのと同時に、前のステップの結果を非同期で読み戻せる。バッチ形状が変わる場合、prefillを再開する場合、structured outputを使用する場合、またはサンプリング方式が一致しない場合には、まずパイプラインを空にする必要がある。Galaxyシステムでは、ステップごとのプロセス間での分散と集約によって並列化の効果が相殺されるのを避けるため、単一プロセスによるlane data parallelismも採用している。

現在のインストーラはvLLM 0.26.0を対象にソースコードからビルドする。旧バージョン向けの互換タグは継続的にはバックポートされない。LoRA、speculative decoding、prompt logprobs、マルチホストサービスはまだサポートされておらず、prefix cacheと非同期decodeについても、モデル側が対応能力を明示的に宣言する必要がある。エンジニアリングチームが次に注目すべきなのは、prefillとdecodeの混在、ホスト間スケーリング、実環境でのスループットデータだ。今回の公式説明が示したのはアーキテクチャの実現可能性であり、GPUと同一条件で比較したコストやレイテンシのデータは提供されていない。