XNNPACK packs a reused weight once per use, so memory grows with every reuse
Mantenedores costumam responder em até 1 dia
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 45/100
- Tipo de issue
- Bug
- Clareza
- Razoavelmente clara
- Status de atividade
- Ativa
- Domínio
- machine-learning, performance
Direção de pesquisa
Start by tracing how XNNPACK's weight cache is configured in the partitioner and runtime backend options; the issue names no source files or tests. Check how cache settings reach program loading and how reused weights are keyed. Done means repeated uses share a packed weight and the repro shows memory growth near one weight copy, with the existing runtime option still understood.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
What happens
When one layer runs several times in a program, XNNPACK keeps a separate packed copy of its weights for each use. This is common in robot policies: torch.export unrolls a denoising loop, so one Linear becomes N delegate calls that share one weight. Each call packs that weight again, because the XNNPACK weight cache is off by default.
Repro
import os, sys, tempfile, torch
from executorch.exir import to_edge_transform_and_lower
from executorch.backends.xnnpack.partition.xnnpack_partitioner import XnnpackPartitioner
from executorch.runtime import Runtime
n, cache = 10, len(sys.argv) > 1
class Loop(torch.nn.Module):
def __init__(self):
super().__init__()
self.lin = torch.nn.Linear(4096, 4096) # 64 MiB of float32 weights
def forward(self, x):
for _ in range(n):
x = torch.tanh(self.lin(x))
return x
ep = torch.export.export(Loop().eval(), (torch.randn(1, 4096),))
prog = to_edge_transform_and_lower(ep, partitioner=[XnnpackPartitioner()]).to_executorch()
path = os.path.join(tempfile.mkdtemp(), "loop.pte")
with open(path, "wb") as f:
prog.write_to_file(f)
def rss_mib():
return int([l for l in open("/proc/self/status") if l.startswith("VmRSS")][0].split()[1]) // 1024
if cache:
Runtime.get().backend_registry.set_option("XnnpackBackend", {"weight_cache_enabled": True})
before = rss_mib()
Runtime.get().load_program(path).load_method("forward").execute([torch.randn(1, 4096)])
print(f"cache={cache} file_mib={os.path.getsize(path) // 2**20} rss_growth_mib={rss_mib() - before}")
Output (executorch 1.6.0, torch 2.15.0, Linux x86_64):
cache=False file_mib=64 rss_growth_mib=642
cache=True file_mib=64 rss_growth_mib=65
On a real policy (LeRobot Diffusion Policy, 10 DDIM steps, 1.05 GB of weights, 16 threads), host memory is 10.4 GB without the cache and 1.9 GB with it, and latency goes from 358 ms to 239 ms.
Ask
Turn the weight cache on by default, or let the partitioner record in the program that the cache is needed, so a reused weight is packed once. Today the workaround is to set weight_cache_enabled through the runtime backend options before loading.
Related: #24667.
- Linguagem predominante
- Python
- Estrelas
- 5.2k
- Forks
- 1.2k
- Merge médio
- 1d 23h
- PRs com merge (30d)
- 700
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Tem um modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de pytorch/executorch
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 64/100
pytorch/executorch#24767 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
pytorch/executorch#24434 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100
pytorch/executorch#24410 ·
Mantenedores costumam responder em até 1 dia
-
enhancement triaged
Dificuldade 2/5 Meio dia Facilidade para iniciantes 68/100
pytorch/executorch#21640 ·
Mantenedores costumam responder em até 1 dia
-
No safe way to set the CPU thread count from Python: _unsafe_reset_threadpool after load_method crashes or hangs XNNPACKTalvez já em andamento @shoumikhin assumiu hoje. Abertabug
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 25/100
pytorch/executorch#24765 ·
Mantenedores costumam responder em até 1 dia
Todas as issues de pytorch/executorch
Issues semelhantes
-
ChatBedrockConverse changes the keys of JSON tool results to camelCase (`order_id` becomes `orderId`)Talvez já em andamento @geyazheng assumiu hoje. Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
langchain-ai/langchain-aws#1469 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 88/100
EESSI/docs#949 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
b4b usability
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
Mantenedores costumam responder em até 1 dia
-
fix(schedule): align list_tasks since cursor filter boundary from strict > to >=Talvez já em andamento @bfs2021 assumiu hoje. Abertaagent-ready bug p2 schedule
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 83/100
allenporter/supernote#540 ·
Mantenedores costumam responder em até 1 dia
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100
frazane/scoringrules#164 ·
Mantenedores costumam responder em até 1 dia