Core ML vs Core AI: una comparación lado a lado

Parte de la Base de Conocimiento de ANE. Elaborado a partir de la investigación de WWDC en doc 08 (Core ML 2022–2025) y doc 09 (Core AI, WWDC26), los repositorios fijados en references/, y de informes de terceros donde se indica (consultado el 2026-07-12). La postura oficial de Apple a fecha de WWDC26: ambos frameworks coexisten en iOS/macOS 27; no se ha anunciado ninguna fecha de obsolescencia para Core ML.

1. TL;DR#

	Core ML (2017 → )	Core AI (WWDC26 → )
En una frase	Framework general de despliegue de ML; el SO decide cómo ejecutar tu modelo convertido	Stack de inferencia diseñado específicamente para cargas de trabajo modernas (transformer/generativas) con control explícito del desarrollador
Punto óptimo	ML clásico y redes neuronales de tamaño medio: clasificadores, modelos de visión/audio, pipelines ya construidos sobre coremltools	LLMs, VLMs, difusión, funcionalidades agénticas; cualquier cosa autorregresiva o con KV cache; modelos que necesitan ajuste por hardware
SO mínimo	Muy amplio (iOS 11+; funcionalidades limitadas por año — véase doc 08)	iOS/macOS 27+, Xcode 27
Estado	Mantenido; cero sesiones en WWDC26; sigue siendo la única opción para objetivos de despliegue anteriores a 27	La dirección estratégica; impulsa Apple Intelligence en el dispositivo

2. Comparación completa#

Dimensión	Core ML	Core AI
Activo del modelo	.mlmodel / .mlpackage (ML Program, ops MIL), compilado en el dispositivo a .mlmodelc	.aimodel (activo fuente independiente del dispositivo)
Punto de entrada de conversión	coremltools.convert() sobre la salida de torch.jit.trace (ct 8 añadió soporte temprano de torch.export)	coreai_torch.TorchConverter sobre programas de torch.export de forma nativa
Formas dinámicas	Añadido a posteriori: formas enumeradas/por rango, o un trace por forma + fusión multifunction (doc 06 §8)	Nativo: torch.export.Dim(min=, max=) fluye hacia el .aimodel (las dims se muestran como ? en Xcode)
Ops de alto nivel	El autor descompone a mano (la era 2022–2024 de esta KB); el SDPA fusionado llegó solo con objetivos de iOS 18	Composite ops (SDPA, RMSNorm, RoPE, sliding-window attention, gather_mm…) preservadas mediante tablas de descomposición; el compilador elige el lowering por hardware (coreai-torch/coreai_torch/composite_ops/)
Optimización por plataforma	Un solo grafo; Core ML lo segmenta entre CPU/GPU/ANE en la carga	Primitivas ios/ vs macos/ explícitas y flag de exportación --platform; las clases de iOS se moldean a mano para la ANE, macOS usa ops de GPU fusionadas (coreai-models/.../primitives/)
Compilación	"Especialización" en el dispositivo solo en la primera carga; opaca; mitigaciones = carga asíncrona + folclore de caché (doc 05)	La misma especialización más AOT: xcrun coreai-build compile --platform iOS en la máquina de desarrollo; APIs explícitas AIModel.specialize/AIModelCache
Estado / KV cache	Sin estado por diseño; los estados se incorporaron a posteriori como MLState (iOS 18, doc 08)	Con estado desde el primer día: búferes NDArray pasados como MutableViews non-escapable, actualizados in situ; primitiva mutable_slice_update para las escrituras en la caché
API de Swift	MLModel + feature providers / MLMultiArray; MLTensor (2024) para operaciones de enlace	AIModel → InferenceFunction.run(inputs:states:) con NDArray; vistas de copia cero, preasignación, pipelining asíncrono; seguridad de memoria mediante tipos non-escapable
Ergonomía para LLM	Bucle de decodificación hecho a mano (muestreo con MLTensor, fontanería manual de la KV — la era de WhisperKit, doc 06)	CoreAILanguageModel se conecta a la LanguageModelSession de Foundation Models: streaming, salida estructurada @Generable, llamada a herramientas — con tus pesos personalizados
Compresión	ct.optimize.coreml / ct.optimize.torch (doc 07): palettization, poda, INT4/8, por canal agrupado (limitaciones de iOS 18)	coreai-opt: las mismas familias más FP4/FP8 y QAT, guiado por presets (presets.w4().without("lm_head")), recetas YAML declarativas en el model zoo
Ops personalizadas	Composite ops MIL personalizadas / capas personalizadas (código CPU/GPU en la app)	DSL TorchMetalKernel: MSL escrito en Python, verificado contra una referencia de PyTorch, embebido dentro del .aimodel
Empaquetado multi-modelo	Modelos multifunction (iOS 18); un .mlmodelc separado por componente (patrón de WhisperKit)	Conversión multi-entrypoint: varias funciones exportadas → un .aimodel (SAM3 image_encode/text_encode/detect)
Observabilidad	Informes de rendimiento de Xcode, Instruments de Core ML + ANE, MLComputePlan (despacho programático, doc 06 §8)	Plantilla de Instruments de Core AI (eventos de carga/especialización/inferencia), Core AI Debugger (grafo ↔ código fuente Python original, inspección de tensores en el dispositivo, modo de comparación PSNR), medidor de depuración de Xcode
Verificación numérica	Hazlo tú mismo: bancos de PSNR como el de argmaxtools (umbral de 35 dB)	Integrada: comprobaciones de paridad en Python coreai.runtime + modo de comparación del Debugger (PSNR/MSE/MAE por capa)
Distribución	Bundle o recursos bajo demanda	Recomendación: mantén los modelos fuera del bundle, entrégalos mediante Background Assets con aceptación explícita (sesión 326)
Model zoo	Ninguno oficial (comunidad: Hugging Face, WhisperKit)	coreai-models: whisper, qwen3, gemma3, mistral/mixtral, gpt_oss, sam3, stable-diffusion, flux2… + paquetes de runtime de Swift + agent skills

3. Las cuatro diferencias profundas#

3.1 Quién es dueño de la optimización#

La diferencia definitoria para esta KB. En la era de Core ML, el autor del modelo era dueño de la optimización para la ANE: Apple publicó principios (2022), y equipos como Argmax construyeron a mano la atención BC1S, el softmax dividido, el enmascaramiento de caché (docs 02–06). En Core AI, la toolchain y las primitivas de la plataforma son dueñas de ella: tú escribes composite_ops.SDPA, y el compilador realiza el lowering por hardware — recurriendo a las propias primitivas ios/ moldeadas a mano por Apple (que son los principios de 2022, literalmente — doc 09 §3) para los componentes ligados a la ANE. Las vías de escape (kernels Metal personalizados, reautoría) siguen disponibles para la frontera.

Medida del cambio: Whisper necesitó una reimplementación desde cero + una biblioteca en PyPI en la era de Core ML (whisperkittools, ~5k líneas estudiadas en doc 06); la receta de Core AI exporta el whisper-large-v3-turbo estándar de HF en un único script de ~200 líneas (references/coreai-models/models/whisper/export.py).

3.2 Linaje de la KV cache#

La evolución completa, en una línea cada una:

1. 2022–23 (Core ML, sin estado): la caché como E/S del modelo + mezcla con máscara one-hot cache*(1−m)+current*m — WhisperKit (doc 06 §4).
2. 2024 (Core ML + MLState): la caché como búfer registrado, actualización in situ, aceleración de decodificación de 1.6× en Mistral-7B (doc 08).
3. 2026 (Core AI): los estados como MutableViews de primera clase en la llamada de ejecución; la escritura a nivel de grafo mutable_slice_update escribe directamente el slice del nuevo token; iOS todavía actualiza en la última dim (dim 4) frente a la dim 3 de macOS — la restricción de alineación de 64 bytes en el último eje (doc 01 §2.2) sigue dictando el layout.

3.3 La compilación se mueve hacia la izquierda#

Core ML compilaba enteramente en el dispositivo en la primera carga — un peligro de UX gestionado con folclore (cargas asíncronas, pantallas de aviso). Core AI divide la compilación: el costoso trabajo de grafo ocurre en tiempo de build (coreai-build, artefactos por plataforma en el bundle), dejando solo el acabado específico del dispositivo en la primera ejecución, con APIs de caché explícitas para el resto. La latencia de la primera ejecución pasó de "ocúltala" a "diséñala".

3.4 La verificación se convierte en un producto#

El stack de pruebas de argmaxtools (doc 06 §8) — umbrales de PSNR, volcados de despacho por op, perfilado de sensibilidad por capa — fue un tercero llenando un vacío de herramientas. Core AI incluye todo ello: comprobaciones de paridad en Python, un Debugger que rastrea cualquier tensor hasta la línea de Python que lo produjo, comparación de PSNR/MSE/MAE por capa para las decisiones de compresión, y eventos de Instruments para la especialización. La lección de la KB de "verifica en CI, no a ojo" es ahora el flujo de trabajo oficial.

4. Guía de decisión (mediados de 2026)#

Las únicas señales oficiales de Apple: Core AI acaparó todo el protagonismo de WWDC26; Core ML no tuvo ninguno, pero no fue declarado obsoleto. Los informes de terceros (9to5Mac, InfoQ, byteiota) convergen en la misma lectura. Guía práctica:

Situación	Recomendación
Debes dar soporte a dispositivos por debajo de iOS/macOS 27	Core ML — sin alternativa; Core AI es solo para 27+
Pipeline de Core ML existente y funcionando	Quédate donde estás — no se ha anunciado obsolescencia; migra de forma oportunista
ML clásico (clasificadores, regresores, visión/audio pequeños)	Core ML — maduro, de amplio alcance, nada que ganar migrando
Nueva funcionalidad transformer/generativa, objetivo 27+	Core AI — composite ops, estados, AOT, model zoo, puente con Foundation Models
LLM personalizado tras una UX de chat/salida estructurada	Core AI (CoreAILanguageModel + LanguageModelSession) — o el modelo integrado de Foundation Models si es suficiente
Investigación / fine-tuning / bucles de entrenamiento personalizados en Mac	MLX (entrena) → exporta vía coreai-torch (despliega)
Exprimir un modelo que el compilador de Apple no maneja bien	Cualquiera de los dos — los principios de esta KB (docs 01–07) son el conjunto de herramientas manual; en Core AI, exprésalos como primitivas/kernels personalizados

5. Mapeo de migración (Core ML → Core AI)#

Concepto de Core ML	Equivalente en Core AI
torch.jit.trace + ct.convert	torch.export.export (+ dynamic_shapes) + TorchConverter().to_coreai()
.mlpackage / .mlmodelc	.aimodel (+ variantes compiladas en AOT vía coreai-build)
MLModel / feature providers / MLMultiArray	AIModel / InferenceFunction / NDArray
MLState	MutableViews de estado pasadas a run(inputs:states:)
Código de enlace MLTensor	absorbido en gran medida por los paquetes de Swift de coreai-models / la API de sesión de Foundation Models
.mlpackage multifunction	.aimodel multi-entrypoint
Formas enumeradas/flexibles	dims dinámicas torch.export.Dim
ct.optimize.coreml / ct.optimize.torch	coreai-opt (Quantizer, KMeansPalettizer, presets, recetas YAML, QAT)
compute_units=CPU_AND_NE + MLComputePlan	exportación --platform iOS + primitivas por plataforma; Instruments de Core AI (informe de despacho a la ANE a nivel de op: aún una cuestión abierta, doc 09 §5.4)
Pestaña de rendimiento de Xcode	Visor de modelos de Xcode (.aimodel) + Instruments de Core AI + Debugger
Composite ops MIL personalizadas	DSL TorchMetalKernel (MSL embebido en el activo)
Carga asíncrona + esperanza (primera ejecución)	Compilación AOT + AIModel.specialize + AIModelCache + Background Assets

6. Lo que no cambia#

Toda verdad de hardware en doc 01 es independiente del framework, y las propias primitivas de iOS de Core AI de Apple lo demuestran (doc 09 §3): layouts 4D con canales primero, la restricción de alineación del último eje, cómputo de atención por cabeza, formas estáticas para la ANE, numéricos FP16, y palettization como el remedio limitado por ancho de banda. Los frameworks son cómo expresas el trabajo; la ANE es por qué el trabajo tiene el aspecto que tiene. Esa es la razón por la que los docs 01–07 siguen siendo relevantes independientemente de qué runtime gane.