`compile_and_save` needs twice the engine size on disk while it saves to ExecuTorch
Los mantenedores suelen responder en 3 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 18/100
Línea de trabajo
The save path is in compile_and_save in the Torch-TensorRT Python package, which writes each built engine to a temporary file before the ExecuTorch copy; the repro script in the issue measures peak disk use and is the check for done. The fix spans two projects: the ExecuTorch file-writing code that would need to punch holes in owned file-backed data after each chunk is copied, and the Torch-TensorRT hand-off of offloaded engine files. Start by reading how engine files are written and passed to ExecuTorch, then confirm the disk peak drops to about one copy.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What is wrong
compile_and_save writes each engine to a temporary file as soon as it is built. With output_format="executorch", the save then copies each file into the .pte (or .ptd). The temporary files are deleted only when the call returns. So at the end of the save, every engine is on disk twice.
For a large single-engine program this decides whether the export fits. #5026 lets the caller move the files to another disk, which helps, but the space is still needed.
What this blocks
No policy in pytorch/executorch#24353 is listed as failing because of this. It costs disk.
Any export with output_format="executorch" needs free space for twice its engines, so a large single-engine program needs twice its size free. That can decide whether it fits on a Jetson or a DGX Spark.
A fix lets an export fit when the free disk is only a little larger than the program.
Repro
import os, shutil, tempfile, threading, time
import torch, torch_tensorrt
work = tempfile.mkdtemp()
os.environ["TMPDIR"] = tempfile.tempdir = os.path.join(work, "tmp")
os.makedirs(tempfile.tempdir)
out = os.path.join(work, "model.pte")
def used(path):
return sum(os.stat(os.path.join(r, f)).st_blocks * 512 for r, _, fs in os.walk(path) for f in fs)
peak, stop = [0], threading.Event()
def watch():
while not stop.is_set():
peak[0] = max(peak[0], used(work))
time.sleep(0.2)
model = torch.nn.Sequential(*[torch.nn.Linear(8192, 8192, bias=False) for _ in range(32)]).cuda().bfloat16().eval()
x = torch.randn(4, 8192, device="cuda", dtype=torch.bfloat16)
ep = torch.export.export(model, (x,))
threading.Thread(target=watch, daemon=True).start()
torch_tensorrt.compile_and_save(ep, out, output_format="executorch", arg_inputs=[x], min_block_size=1)
stop.set()
print(f"program {os.path.getsize(out) / 2**30:.2f} GiB, disk peak {peak[0] / 2**30:.2f} GiB")
shutil.rmtree(work)
Actual
program 4.00 GiB, disk peak 8.00 GiB
Expected
The peak is about one copy. A proposal in 2 small parts:
- ExecuTorch: file-backed data that the caller marks as owned is consumed by the write. After each chunk is copied, that range of the source is released (
fallocatewithFALLOC_FL_PUNCH_HOLE, supported on ext4, XFS and btrfs), and the file is removed at the end. Elsewhere it copies as today. - Torch-TensorRT: hand each offloaded engine file to ExecuTorch as owned data, since nothing reads it after the save.
Versions
torch 2.15.0 (CUDA 13.2), torch_tensorrt 2.15.0, executorch 1.6.0, TensorRT 11.4.0.106. Script run on H100, driver 580.126.09 (btrfs).
Related: #4863 (keeping built engines on disk until the save, which is where the temporary files come from), #5026.
- Lenguaje dominante
- Python
- Estrellas
- 3k
- Forks
- 421
- Merge medio
- 4 d 7 h
- PR fusionados (30 d)
- 62
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de pytorch/TensorRT
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Los mantenedores suelen responder en 3 días
-
🐛 [Bug] torch.fmod returns a tiny value with the wrong sign when the float quotient rounds upPosiblemente ocupada @micwill755 la tomó hace 4 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
pytorch/TensorRT#4860 · 1 asignado ·
Los mantenedores suelen responder en 3 días
-
Removing ptq.hAbiertoStory: Build & Install & Packaging
Dificultad 1/5 Menos de una hora Aptitud para principiantes 65/100
Los mantenedores suelen responder en 3 días
-
Dificultad 4/5 3-5 días Aptitud para principiantes 22/100
Los mantenedores suelen responder en 3 días
-
Dificultad 3/5 Medio día Aptitud para principiantes 65/100
Los mantenedores suelen responder en 3 días
Todos los issues de pytorch/TensorRT
Issues similares
-
add entry to blockAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 65/100
StevenBlack/hosts#3299 ·
-
`garak --report` overwrites the input report when its name has no ".report"Posiblemente ocupada @0z5a la tomó hoy. Abiertoneeds-triage
Dificultad 2/5 Medio día Aptitud para principiantes 72/100
Los mantenedores suelen responder en 2 días
-
plot_graph crashes when a mesh node has no m2m edgePosiblemente ocupada @tygvi la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
mllam/neural-lam#883 · 1 comentario ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
future-agi/future-agi#4092 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
transcript analytics: a text whose only protected spans the prose pass redacts is withheld wholeAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 82/100
WingedGuardian/GENesis-AGI#4641 ·
Los mantenedores suelen responder en 1 día