SystemLanguageModel.Adapter leaks ~100MB of irrecoverable APFS disk space per call

Question

Created 22h

Replies 3

Boosts 1

Participants 3

FoundationModels framework, macOS Tahoe 26.4.1, MacBook Air M4.

Loading a LoRA adapter via SystemLanguageModel.Adapter(fileURL:) leaks ~100MB of APFS disk space per invocation. The space is permanently consumed at the APFS block level with no corresponding file. Calls without an adapter show zero space loss.

Running ~300 adapter calls in a benchmark loop leaked ~30GB and nearly filled a 500GB drive. The total unrecoverable phantom space is now ~239GB (461GB allocated on Data volume, 222GB visible to du).

Reproduction:

Build a CLI tool that loads a .fmadapter and runs one generation
Measure before/after with df and du:

Before: df free = 9.1 GB, du -smx /System/Volumes/Data = 227,519 MB After: df free = 9.0 GB, du -smx /System/Volumes/Data = 227,529 MB

df delta: ~100 MB consumed du delta: +10 MB (background system activity) Phantom: ~90 MB -- no corresponding file anywhere on disk
Without --adapter (same code, same model): zero space change

du was run with sudo -x. Files modified during the call were checked with sudo find -mmin -10 -- only Spotlight DBs, diagnostics logs, and a 7MB InferenceProviderService vocab cache. Nothing accounts for the ~90MB loss.

fs_usage shows TGOnDeviceInferenceProviderService writing hundreds of APFS metadata blocks (RdMeta on /dev/disk3) per adapter call.

Recovery Mode diagnostics:

fsck_apfs -o -y -s: no overallocations, bitmap consistent (118.6M blocks counted = spaceman allocated)
fsck_apfs -o -y -T -s: B-tree repair found nothing
fsck_apfs -o -y -T -F -s: "error: container keybag (39003576+1): failed to get keybag data: Inappropriate file type or format. Encryption key structures are invalid."

No fsck_apfs flag combination reclaims the space. The leaked blocks are validly allocated in the APFS bitmap and referenced in the extent tree, but not associated with any file visible to du, find, stat, or lsof.

Has anyone else observed space loss when using SystemLanguageModel.Adapter? If I am missing something obvious, I would love to know.

Boost

Answer 1

DTS Engineer OP

Apple

20h

Do you have a feedback report yet? If not, would you mind to file one with the information you described above and a macOS sysdiagnose, and then share your report ID here? Thanks.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

0

Answer 2

tbrrss OP

3h

I set up a probe for my project using an AFM LoRA, here's a summary:

New files are written to /private/var/db/AppleIntelligencePlatform/AppModelAssets/ with a unique hash (not a content-based hash), copying lora.part.bin and metadata.json attributable to TGOnDeviceInferenceProviderService. These materialize per process invocation, and don't appear to be cleaned up.

See FB22523518 from macOS 26.3.1 (a) (build 25D771280a) M4 Air (A3241)

1

Answer 3

es617 OP

1h

Great analysis tbrrss! That pointed me in the right direction.

I ran fs_usage -f diskio -w | grep AppModelAssets while triggering two adapter calls and confirmed the behavior: each invocation writes lora.part.bin + metadata.json to a new subdirectory with a unique hash. Two consecutive calls, same adapter, same machine — two different hashes (3a0bede9... and d42d8d5a...). So it's not content-addressed, it's generating a new UUID every time.

From booted macOS, sudo ls and sudo find on /private/var/db/AppleIntelligencePlatform/AppModelAssets/ both return "Operation not permitted" — SIP blocks access entirely. That's why du couldn't account for the space and why it looked like a filesystem-level issue.

Booted into Recovery Mode (which bypasses SIP), and there they were: 1,684 hash directories, each containing a full copy of the adapter (~160MB). That's ~269GB, matching the "missing" space almost exactly.

Deleted them all with rm -rf from Recovery and the space came back immediately.

So this is a caching bug in TGOnDeviceInferenceProviderService, not data loss or APFS corruption. The files are real and legitimately allocated, they're just completely invisible from userspace because SIP protects that path. No amount of fsck, purge, or Safe Mode will help because there's nothing wrong with the filesystem.

The real fix from Apple would be some form of cache management, content-based hashing to deduplicate identical adapters, an LRU/TTL eviction policy, or cleanup on process exit. Right now there's zero garbage collection.

For anyone hitting this, here's the workaround from Recovery Mode:

Reboot into Recovery Mode (hold Power button on Apple Silicon)
Open Terminal from Utilities menu
diskutil apfs list — find your Data volume (e.g. disk3s5)
diskutil mount disk3s5
diskutil apfs unlockVolume disk3s5 (enter your password if FileVault is enabled)
ls /Volumes/Data/private/var/db/AppleIntelligencePlatform/AppModelAssets/ | wc -l — confirm the cached copies
rm -rf /Volumes/Data/private/var/db/AppleIntelligencePlatform/AppModelAssets/*
Reboot

Updating my Feedback Assistant report with these findings.

0