[chowes]

On Apple Silicon, the server's memory grows with every request and never comes back down.

_check_memory() returns False for MPS, and both generate paths only check memory when the device is cuda, so _clear_memory() (which already calls torch.mps.empty_cache()) never runs on MPS. PyTorch's MPS allocator keeps the buffers it caches, and each new input length adds more.

This checks MPS too, against the existing memory_threshold, using torch.mps.driver_allocated_memory(), which includes the allocator's cache. The CUDA path is unchanged.

Measured

M3 Pro, start-gpu_mac.sh settings, 60 /v1/audio/speech requests of 5 to 120 words with af_heart+af_nicole(2)+af_jadzia, process footprint from footprint. Measured on v0.9.0, whose kokoro_v1.py is identical to master's:

	after startup	after 20	after 40	after 60	total time
v0.9.0	1.9 GB	5.2 GB	7.1 GB	8.9 GB	77s
v0.9.0 + this change	1.9 GB	2.0 GB	2.1 GB	2.0 GB	76s

The default memory_threshold (0.8 GB) is below the ~1.2 GB of GPU memory the process holds after loading, so the cache is likely emptied at the start of nearly every request. That made no measurable difference to speed in the run above.

Testing

• New tests for the MPS memory check and for both generate paths clearing memory over the threshold. They fail on master and pass here.
• uv run --extra test --extra cpu pytest: 568 passed, 9 skipped.
• ruff format and ruff check clean.
• Run natively with uv on Apple Silicon. Not tested in Docker, since containers on macOS can't use MPS, and not on CUDA hardware, though that path is unchanged.

🤖 Generated with Claude Code