Cronología de WWDC: la evolución de Core ML 2022–2025

Parte de la Base de conocimiento sobre la ANE. Fuentes: páginas de sesiones de WWDC en developer.apple.com/videos (consultadas el 2026-07-12; los detalles a continuación son resúmenes de las sesiones oficiales, con números de sesión para verificación).

Este documento sigue lo que Apple lanzó para Core ML en cada WWDC de 2022 a 2025 — el contexto de plataforma en el que vive cada técnica de esta KB. Léelo como la "cronología oficial de la API" que corre en paralelo a la historia de optimización de los docs 02–07. Para la discontinuidad de 2026 (Core AI), véase el doc 09.

De un vistazo#

Año	Sesiones clave	Funciones destacadas	coremltools
2022	10027 — Optimize your Core ML usage	Informes de rendimiento en Xcode 14, Instruments de Core ML + Neural Engine, .cpuAndNeuralEngine, E/S nativa Float16, output backings, primera compresión de pesos	ct 6
2023	10047 — Model compression, 10049 — Async prediction	ct.optimize (palettize/prune/quantize), compresión en tiempo de entrenamiento, descompresión JIT de pesos en la ANE (iOS 17), API de predicción asíncrona, API de disponibilidad de cómputo	ct 7
2024	10159 — Bring your ML & AI models to Apple silicon, 10161 — Deploy on-device with Core ML, 10223 — Explore ML on Apple platforms	Modelos con estado (MLState), modelos multifunción, MLTensor, palettization per-grouped-channel, cuantización int4 per-block, SDPA fusionado (iOS 18), compresión basada en calibración	ct 8
2025	360 — Discover ML & AI frameworks (paraguas; sin sesión dedicada a Core ML)	Framework Foundation Models, sesiones de MLX (298, 315), Core ML: visualización de la arquitectura del modelo en Xcode, mejor inspección; BNNS Graph Builder	—

WWDC22 — el año de la observabilidad#

La sesión 10027 "Optimize your Core ML usage" entregó las herramientas de las que depende el documento de flujo de trabajo de esta KB:

• Informes de rendimiento (Xcode 14 → pestaña Performance): despacho de unidad de cómputo por operación + tiempos medianos de carga/predicción, sin necesidad de código. Esta es la herramienta a la que apunta el propio README de ml-ane-transformers de Apple (doc 05).
• Instrument de Core ML + Instrument de Neural Engine: carriles de perfilado en vivo (actividad/datos/cómputo) — la primera visibilidad pública de cuándo se está ejecutando realmente la ANE.
• MLModelConfiguration.computeUnits = .cpuAndNeuralEngine: nueva opción para mantener la GPU libre (y para forzar la detección de recursos a la GPU — argmaxtools usa después CPU_AND_NE como su valor por defecto en las pruebas, doc 06 §8).
• Float16 nativo: MLMultiArrays Float16 y búferes de píxeles de un componente de 16 bits como E/S del modelo (iOS 16) — se acabó el up/down-casting del lado de la app alrededor de un motor FP16.
• Output backings + búferes respaldados por IOSurface: preasignar salidas, zero-copy entre unidades de cómputo sobre memoria unificada.
• Primera compresión de pesos: cuantización de 16/8 bits + representación sparse para ML Programs (coremltools 6) — solo tamaño en este punto.
• Inicialización de modelos en memoria (encriptación personalizada) y empaquetado de modelos con Swift Package.

WWDC23 — el año de la compresión#

La sesión 10047 introdujo la caja de herramientas ct.optimize que esta KB documenta en profundidad (doc 07):

• Tres técnicas, dos flujos de trabajo: palettization / pruning / cuantización lineal, cada una disponible post-entrenamiento (ct.optimize.coreml, rápida, sin datos) o en tiempo de entrenamiento (ct.optimize.torch, diferenciable — por ejemplo, palettization DKM) — con la regla práctica demostrada de que la palettization a 2 bits post-entrenamiento falla donde a 2 bits en tiempo de entrenamiento mantiene la precisión.
• El runtime convirtió la compresión en una característica de latencia: en iOS 17+ la ANE descomprime los pesos justo a tiempo, de modo que pesos de menos bits = menos tráfico de memoria = más rápido en regímenes limitados por el ancho de banda (medido: ~5–30 % para palettization a 4 bits, hasta 75 % para modelos sparse en iPhone 14 Pro Max). Esta es la confirmación oficial de la economía del Principio 4 (doc 02) — en iOS 16 la descompresión era anticipada (ahead-of-time) y no ganaba nada.
• Sesión 10049: predicción asíncrona (thread-safe, cancelable, ~2× de rendimiento en la demo), ciclo de vida/caché del modelo explicado ("prepare and cache" = especialización del dispositivo), MLModel.availableComputeDevices para detectar la presencia de la ANE en tiempo de ejecución.

WWDC24 — el año de la IA generativa#

El mayor lanzamiento de Core ML de este período (coremltools 8), dirigido de lleno a los transformers:

• Modelos con estado: register_buffer + ct.StateType → los KV caches viven dentro del modelo y se actualizan in-place; Swift los consume mediante MLState. Demostró una aceleración de decodificación de 1.6× en Mistral-7B (M3 Max). Este es exactamente el camino StatefulKVCachedAttention en argmaxtools (doc 06 §4).
• Modelos multifunción: varias funciones que comparten pesos deduplicados en un único .mlpackage (adaptadores, variantes multi-shape) — usados por el CoreMLMultifunctionTestsMixin de argmaxtools.
• MLTensor: operaciones tensoriales al estilo de NumPy en Swift despachadas a Apple silicon — elimina el pegamento escrito a mano (bucles de decodificación, sampling) entre modelos.
• Salto en la granularidad de compresión: palettization per_grouped_channel (Stable Diffusion 5 GB → 1.3 GB a 4 bits), cuantización int4 per-block (Mistral-7B 13 GB → <4 GB), combinaciones sparse+palettized/quantized, y un flujo de trabajo intermedio basado en calibración (~128 muestras) entre el sin datos y el fine-tuning.
• SDPA fusionado: con minimum_deployment_target=iOS18, la atención se convierte en una única operación fusionada — la primera señal de que la atención descompuesta a mano (al estilo de Apple 2022) se estaba convirtiendo en tarea del runtime en lugar del autor.
• Mejoras en los informes de rendimiento: tiempo estimado por operación, pistas de "no soportado en este dispositivo de cómputo", comparación de ejecuciones.

WWDC25 — la meseta (y el giro)#

• Sin sesión dedicada a Core ML. La sesión paraguas (360) situó a Core ML como la capa de despliegue en un stack ahora encabezado por el framework Foundation Models (LLM on-device integrado con guided generation) y MLX (investigación/fine-tuning en Apple silicon, sesiones 298/315).
• Las mejoras de Core ML fueron incrementales: visualización completa de la arquitectura del modelo en el visor de modelos de Xcode e inspección más rica de latencia/despacho.
• Visto en retrospectiva, el año tranquilo precedió al reemplazo de plataforma anunciado en WWDC26 (doc 09): Core AI.

Cómo se corresponde esta cronología con la KB#

Función de plataforma (año)	Dónde la usa la KB
Informes de rendimiento / Instruments (2022)	Flujo de trabajo de verificación del Doc 05
.cpuAndNeuralEngine (2022)	TEST_COMPUTE_UNIT de argmaxtools (doc 06)
E/S Float16 (2022)	TEST_COREML_IO_FLOAT_DTYPE = np.float16 de argmaxtools
Palettization ct.optimize (2023)	Todo el doc 07; el Palettizer de argmaxtools se construye sobre ella
Descompresión JIT de pesos en la ANE (2023)	Por qué la compresión es una victoria de latencia (P4, docs 02/07)
Modelos con estado / MLState (2024)	StatefulKVCachedAttention (doc 06 §4)
Modelos multifunción (2024)	Exportación de shape variable (doc 06 §8)
Per-grouped-channel / int4 (2024)	--palettization-group-size de whisperkittools (doc 07)
SDPA fusionado (2024)	Precursor del enfoque de operaciones compuestas de Core AI (doc 09)
MLComputePlan (coremltools 8.1, era 2024)	Verificación programática del despacho a la ANE (doc 06 §8)

El hilo conductor: de 2022 a 2024 la plataforma absorbió de forma constante lo que los usuarios expertos construían a mano — observabilidad (2022), compresión (2023), KV caches, atención fusionada y empaquetado multi-modelo (2024) — y en 2026 esa absorción se convirtió en un nuevo framework (doc 09).