Post

Replies

Boosts

Views

Activity

On-device specialization of ahead-of-time compiled Core AI LLM bundles preallocates 35 GB and crashes the app
I am shipping Core AI language models in an App Store app and have followed the ahead-of-time compilation workflow from WWDC26 session 326 and the article "Compiling Core AI models ahead of time". The remaining on-device specialization step is unusable for LLM exports, and I would like to know whether there is a supported way around it. Setup Models are exported with the coreai-models recipes and compiled with coreai-build for the Neural Engine: uv run coreai.llm.export Qwen/Qwen3-0.6B --platform iOS --compression-config models/qwen3/qwen3_0_6b_mixed_4bit_8bit.yaml xcrun coreai-build compile <model>.aimodel --platform iOS --architecture h18pThe compiled .aimodelc bundles are hosted remotely, one per architecture, and selected at runtime with AIModel.deviceArchitectureName. Loading uses CoreAILanguageModel(resourcesAt:) and FoundationModels.LanguageModelSession. Xcode 27.1 (27A9275), coreai-build 3600.83.1, coreai-models cc3c234, iPhone 17 Pro. The published bundles are public for reproduction: https://huggingface.co/333i/qwen3-0.6b-coreai-ios https://huggingface.co/333i/smollm2-1.7b-coreai-ios What happens on device Each compiled bundle carries its 30 Neural Engine regions (extend and prompt_opt, contexts 256 to 4096, query sizes 8, 16 and 64) as .mlir.bc under main-h18p-delegates/MPSGraph. On first load, ANELargeModelCompilerService compiles all 30 on the device. Qwen3 0.6B: the first reply takes over two minutes. Later launches load from the cache in about eight seconds. SmolLM2 1.7B: the compile fails after about a minute. The device reported 56 GB free. Freeing 20 GB more moved the failure from 33.6 GB to 35.5 GB. ANELargeModelCompilerService Convert 27/30 procedures of ANEHLO task 308/7012 ANELargeModelCompilerService ANECompiler internal error: temp file: F_PREALLOCATE failure (35500589056 bytes) -> (35511074816 bytes): No space left on device ANELargeModelCompilerService Caught ZinException kernel ERROR: [ANELargeModelCompilerService:61615] FATAL exception: type=0x1 reason=0x25 code=0x106 aned Could not create connection to com.apple.ANELargeModelCompilerService MPSGraphANEUtils.mm:1033: Error = Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.ANELargeModelCompilerService" MPSGraphANEUtils.mm:1038: ANE compile failed! MPSGraphExecutable_Project.h:510: failed assertion `could not load module from MPSGraphPackage'The assertion terminates the app. No error reaches the load call, so there is no way to fall back or tell the user what happened. Compiling the same export with --preferred-compute gpu avoids the Neural Engine compiler but allocates roughly 0.5 GB of GPU memory per compiled function at load time. The 0.6B model reaches a 17 GB footprint at 4096 context on a Mac and is killed by Jetsam at about 6 GB on iPhone 17 Pro. What I have ruled out The ahead-of-time workflow is followed as documented. The article states that the compiled asset still requires some specialization on the device, and for these exports that residual step is the Neural Engine compile described above. coreai-build compile --help offers no option to generate the Neural Engine executables on the build machine. The failure reproduces on the October 18 runtime and on coreai-models cc3c234. Disk space is not the limit in practice. The compiler preallocates more than 30 GB of temporary storage for a 1.7B model, which no production device can be expected to provide. Related reports apple/coreai-models issue 387 (this failure, open since October 27 with no response): https://github.com/apple/coreai-models/issues/387 apple/coreai-models issue 406: a 0.6B export measured at roughly 600 seconds per specialization on iPhone 16 Pro Max, with Jetsam kills during specialization on a current-toolchain export. apple/coreai-models issue 205: coreai-build exits 0 and writes a GPU-only bundle when offline Neural Engine compilation fails, with an empty ErrorList. The Gemma 4 README in coreai-models states that ahead-of-time compilation is not supported for that model on the Xcode 27.2 beta toolchain and recommends on-device specialization from the raw .aimodel, which is the same path that fails here at 1.7B. Questions Is there a supported way to generate the Neural Engine executables for an LLM bundle on the build machine, so that no ANELargeModelCompilerService run happens on the user's device? If on-device specialization is the intended path, is there a bound on its temporary storage and time, and can the export emit fewer specializations or share work across them? Can a Neural Engine compile failure be surfaced as an error from the load call instead of an MPSGraph assertion that terminates the process? Is the per-function GPU memory in the --preferred-compute gpu build expected, and is there an export option that avoids it? At this point I have removed Core AI text models from the shipping app and kept Core AI for diffusion only, where ahead-of-time compilation works well. I would like to bring the text models back and am happy to test any build or export change.
1
0
53
16h
On-device specialization of ahead-of-time compiled Core AI LLM bundles preallocates 35 GB and crashes the app
I am shipping Core AI language models in an App Store app and have followed the ahead-of-time compilation workflow from WWDC26 session 326 and the article "Compiling Core AI models ahead of time". The remaining on-device specialization step is unusable for LLM exports, and I would like to know whether there is a supported way around it. Setup Models are exported with the coreai-models recipes and compiled with coreai-build for the Neural Engine: uv run coreai.llm.export Qwen/Qwen3-0.6B --platform iOS --compression-config models/qwen3/qwen3_0_6b_mixed_4bit_8bit.yaml xcrun coreai-build compile <model>.aimodel --platform iOS --architecture h18pThe compiled .aimodelc bundles are hosted remotely, one per architecture, and selected at runtime with AIModel.deviceArchitectureName. Loading uses CoreAILanguageModel(resourcesAt:) and FoundationModels.LanguageModelSession. Xcode 27.1 (27A9275), coreai-build 3600.83.1, coreai-models cc3c234, iPhone 17 Pro. The published bundles are public for reproduction: https://huggingface.co/333i/qwen3-0.6b-coreai-ios https://huggingface.co/333i/smollm2-1.7b-coreai-ios What happens on device Each compiled bundle carries its 30 Neural Engine regions (extend and prompt_opt, contexts 256 to 4096, query sizes 8, 16 and 64) as .mlir.bc under main-h18p-delegates/MPSGraph. On first load, ANELargeModelCompilerService compiles all 30 on the device. Qwen3 0.6B: the first reply takes over two minutes. Later launches load from the cache in about eight seconds. SmolLM2 1.7B: the compile fails after about a minute. The device reported 56 GB free. Freeing 20 GB more moved the failure from 33.6 GB to 35.5 GB. ANELargeModelCompilerService Convert 27/30 procedures of ANEHLO task 308/7012 ANELargeModelCompilerService ANECompiler internal error: temp file: F_PREALLOCATE failure (35500589056 bytes) -> (35511074816 bytes): No space left on device ANELargeModelCompilerService Caught ZinException kernel ERROR: [ANELargeModelCompilerService:61615] FATAL exception: type=0x1 reason=0x25 code=0x106 aned Could not create connection to com.apple.ANELargeModelCompilerService MPSGraphANEUtils.mm:1033: Error = Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.ANELargeModelCompilerService" MPSGraphANEUtils.mm:1038: ANE compile failed! MPSGraphExecutable_Project.h:510: failed assertion `could not load module from MPSGraphPackage'The assertion terminates the app. No error reaches the load call, so there is no way to fall back or tell the user what happened. Compiling the same export with --preferred-compute gpu avoids the Neural Engine compiler but allocates roughly 0.5 GB of GPU memory per compiled function at load time. The 0.6B model reaches a 17 GB footprint at 4096 context on a Mac and is killed by Jetsam at about 6 GB on iPhone 17 Pro. What I have ruled out The ahead-of-time workflow is followed as documented. The article states that the compiled asset still requires some specialization on the device, and for these exports that residual step is the Neural Engine compile described above. coreai-build compile --help offers no option to generate the Neural Engine executables on the build machine. The failure reproduces on the October 18 runtime and on coreai-models cc3c234. Disk space is not the limit in practice. The compiler preallocates more than 30 GB of temporary storage for a 1.7B model, which no production device can be expected to provide. Related reports apple/coreai-models issue 387 (this failure, open since October 27 with no response): https://github.com/apple/coreai-models/issues/387 apple/coreai-models issue 406: a 0.6B export measured at roughly 600 seconds per specialization on iPhone 16 Pro Max, with Jetsam kills during specialization on a current-toolchain export. apple/coreai-models issue 205: coreai-build exits 0 and writes a GPU-only bundle when offline Neural Engine compilation fails, with an empty ErrorList. The Gemma 4 README in coreai-models states that ahead-of-time compilation is not supported for that model on the Xcode 27.2 beta toolchain and recommends on-device specialization from the raw .aimodel, which is the same path that fails here at 1.7B. Questions Is there a supported way to generate the Neural Engine executables for an LLM bundle on the build machine, so that no ANELargeModelCompilerService run happens on the user's device? If on-device specialization is the intended path, is there a bound on its temporary storage and time, and can the export emit fewer specializations or share work across them? Can a Neural Engine compile failure be surfaced as an error from the load call instead of an MPSGraph assertion that terminates the process? Is the per-function GPU memory in the --preferred-compute gpu build expected, and is there an export option that avoids it? At this point I have removed Core AI text models from the shipping app and kept Core AI for diffusion only, where ahead-of-time compilation works well. I would like to bring the text models back and am happy to test any build or export change.
Replies
1
Boosts
0
Views
53
Activity
16h