Per-component offload: streaming text encoder while transformers stay GPU-resident (warm-serving OOM at 96 GB)

オープン
  • 何か問題がありますか？
#232 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
52/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
python, pytorch
領域
machine-learning

調査の方向性

Start with packages/ltx-pipelines/src/ltx_pipelines/utils/blocks.py, especially PromptEncoder.__call__ and _text_encoder_ctx, then trace how pipeline constructors pass offload_mode to the prompt encoder and diffusion stages. Check the related issues (#164, #143, #140, and #152) for context. Done means callers can stream the text encoder while keeping transformers GPU-resident, with the default behavior preserved.

索引モデルが issue の本文から書いたものです。

説明

Setup

Self-hosted serving of LTX-2.3 (22B) on a single RTX PRO 6000 (96 GB), bf16. To keep warm latency low we keep both stage transformers GPU-resident between requests (~70.8 GB) and cache text embeddings per prompt.

Symptom

The first request with a new prompt on a warm container OOMs:

70.8 GB resident transformers + ~23 GB Gemma full-GPU build → 93.75 GB → CUDA OOM

PromptEncoder.__call__ builds the full Gemma text encoder on GPU per call (packages/ltx-pipelines/src/ltx_pipelines/utils/blocks.py — _text_encoder_ctx returns gpu_model(self._build_text_encoder()) when offload_mode == NONE). With embedding caching, every repeated-prompt request skips this entirely, so benchmarks stay green and the OOM only appears in production on the first unseen prompt.

Why --offload cpu doesn't solve it

The streaming text-encoder builder already exists on every PromptEncoder instance and works well — but offload_mode is a single global knob: every pipeline factory passes the same value to the PromptEncoder and all DiffusionStages. Setting --offload cpu to fix the text encoder also layer-streams the 22B transformers, which defeats persistent-GPU serving (and per the README, offload disables FP8 quantization as a further coupling).

So today there is no supported way to get: streaming text encoder + GPU-resident transformers.

Request

Per-component offload granularity — for example a text_encoder_offload_mode parameter on the pipeline constructors (defaulting to the global offload_mode), or an explicit offload_mode override accepted by PromptEncoder consumers. Even exposing it only at the Python API level (not CLI) would cover the serving use case.

Workaround we run (in case it helps others)

We wrap the prompt-encode call and flip _offload_mode to OffloadMode.CPU only for cache-miss calls when free VRAM is below a threshold, restoring it after. Same weights/dtype → identical embeddings; the request that used to die completes at 78.6 GB peak (~+10 s once per prompt, then cached). Happy to share details or a patch if useful.

Related: #164 (Gemma VRAM pain, smaller-encoder angle), #143 (Gemma co-residency OOM), #140 (offload question), #152 (adjacent external-serving OOM).

主要言語
Python
スター
10k
フォーク
1.6k
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Lightricks/LTX-2 のほかの issue

Lightricks/LTX-2 の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。