CLAP model crash after several inference iterations

A CLAP model that fails after roughly 150–300 inference slices and stays dead until a full PC restart is likely suffering from per-iteration memory growth rather than a model defect, since re-creating the model every 50 slices does not help. The proposed diagnostic runs three configurations — the original code, inference under torch.inference_mode() storing only plain floats, and that plus a forced allocator release every 50 slices via garbage collection and malloc_trim through ctypes or a worker process per batch — while logging resident memory every 10 slices. A flat memory slope in the second run indicates tensor retention, a flat slope only in the third indicates allocator growth, and identical climbing slopes in all three point to a bug inside the processor worth reporting upstream.

This one never got an answer, and the shape of it — fine for roughly 150–300 slices, dead until a full PC restart, and re-creating the model every 50 slices does not help — points away from the model and toward things that grow per iteration. Three suspects, all visible from here: Re-initializing the model cannot fix any of the three, which fits what you saw. The check that separates them: log resident memory every 10 slices across three runs. Run A, your code as-is. Run B, inference under torch.inference mode storing only plain floats. Run C, B plus a forced allocator release every 50 slices on CPU, garbage collection plus malloc trim through ctypes, or simply a worker process per batch . If B runs flat, it was retention. If B climbs but C is flat, it was the allocator. If all three climb at the same slope, the growth is inside the processor and you have a much rarer bug worth reporting upstream. Once the slope is flat, batching becomes safe: fixed-size batches with a memory ceiling set from the measured slope, and this class of crash is simply gone.