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

Abierto
  • ¿Algo no está bien?
#232 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
python, pytorch
Área
machine-learning

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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).

Lenguaje dominante
Python
Estrellas
10k
Forks
1.6k
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Lightricks/LTX-2

Todos los issues de Lightricks/LTX-2

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.