Metal 4 Esencial: Lo Que Realmente Cambia La Nueva API Principal

Metal 4 no es una reescritura. Apple lo lanzó como una superficie API paralela junto con los tipos originales de Metal, con un prefijo MTL4 en los nuevos, de modo que una aplicación puede adoptar la nueva API principal de manera incremental sin reescribir el código de renderizado existente.¹ El encuadre importa: el framework Metal en sí lleva mucho tiempo en circulación; lo que cambió en la WWDC25 es la API principal de Metal 4.

Tres cosas que la nueva API principal realmente cambia para los desarrolladores de aplicaciones:

1. La codificación multihilo de búferes de comandos se convierte en un patrón de primera clase.
2. El codificador de cómputo absorbe los codificadores de blit y de estructura de aceleración en una superficie unificada.
3. El aprendizaje automático se ejecuta como un tipo de pase de primera clase junto con los pases de renderizado y cómputo, ejecutando modelos de Core ML en la línea de tiempo de la GPU sin tener que ir y volver a la CPU.

Las secciones a continuación recorren cómo se ven en la práctica cada uno de esos tres cambios, los nuevos tipos a los que recurren los desarrolladores y las razones que la documentación de Apple ofrece sobre la forma que tomaron.

TL;DR

• MTL4CommandQueue, MTL4CommandBuffer, MTL4RenderCommandEncoder, MTL4ComputeCommandEncoder, MTL4MachineLearningCommandEncoder son los nuevos tipos.¹ Los tipos originales con prefijo MTL permanecen. Adoptas de forma incremental mezclando ambos.
• Los búferes de comandos obtienen su memoria de trabajo de un MTL4CommandAllocator separado, lo que permite que múltiples hilos codifiquen a múltiples búferes en paralelo. Una sola llamada a commit:count: envía el lote a la cola.¹
• MTL4ComputeCommandEncoder reemplaza tres codificadores anteriores: MTLBlitCommandEncoder, MTLComputeCommandEncoder y MTLAccelerationStructureCommandEncoder.¹ Un codificador, tres trabajos.
• MTL4MachineLearningCommandEncoder ejecuta modelos de Core ML dentro de un búfer de comandos de Metal.² El sistema elige la GPU o el Apple Neural Engine para cada modelo. Los tensores transportan entradas y salidas; el mismo búfer de comandos mezcla inferencia de ML con trabajo de renderizado y cómputo.
• El binding de recursos se traslada a tablas de argumentos (MTL4ArgumentTable) en lugar de métodos de bind por codificador. Todos los recursos no tienen seguimiento; tú sincronizas con barreras explícitas.¹

Por Qué Una Superficie API Paralela

El encuadre de Apple para la elección de tipos paralelos, textualmente de los documentos: “Metal 4 introduce varios tipos con el prefijo MTL4 que son completamente independientes de los tipos MTL originales que reemplazan, como MTL4CommandQueue frente a MTLCommandQueue. Otros tipos son comunes a todas las versiones de Metal.”¹

La verificación en tiempo de ejecución es simple: la aplicación detecta si el sistema soporta Metal 4, crea un MTL4CommandQueue si lo hace, o recurre a MTLCommandQueue en caso contrario. El tipo de cola que crea la aplicación determina qué familia de tipos usa el resto del código de renderizado.¹

La otra mitad del diseño permite que las dos familias interoperen. MTLEvent y MTLSharedEvent sincronizan a través de instancias tanto de MTLCommandQueue como de MTL4CommandQueue.¹ Una aplicación con una base de código sustancial en Metal 1 puede cambiar un solo subsistema a Metal 4 sin romper los patrones de sincronización de los que depende el resto de la aplicación.

Eso responde a una pregunta que los desarrolladores de aplicaciones se han estado haciendo desde la WWDC25: ¿necesito reescribir mi código de Metal? No. La forma de la API fomenta la adopción incremental por subsistema.

Codificación Multihilo De Búferes De Comandos

La mejora destacada en tiempo de ejecución: la memoria de los búferes de comandos proviene de un tipo complementario, MTL4CommandAllocator, en lugar de provenir de la cola. Cada hilo puede codificar trabajo en su propio búfer de comandos usando su propio asignador, y la cola envía los búferes como un lote.

La forma de la API de Apple:¹

let device: MTLDevice = ...
let commandQueue: MTL4CommandQueue = device.makeMTL4CommandQueue()
var commandAllocators: [MTL4CommandAllocator] = ...
let commandBuffer: MTL4CommandBuffer = device.makeCommandBuffer()

// Per frame:
let frameAllocator = commandAllocators[frameNumber % kMaxFramesInFlight]
frameAllocator.reset()
commandBuffer.beginCommandBuffer(allocator: frameAllocator)
// ...encode commands to commandBuffer...
commandBuffer.endCommandBuffer()
commandQueue.commit(commandBuffer, count: 1)

Dos cambios operativos respecto a la API original:

Los búferes de comandos son reutilizables. Los documentos de Apple: “Puedes reutilizar y reasignar cada búfer de comandos indefinidamente comenzando de nuevo, codificando nuevos comandos y enviándolo otra vez, en lugar de asignar un nuevo búfer.”¹ El Metal anterior requería un nuevo búfer transitorio para cada commit.

Sin retención automática de recursos. “Cada instancia de MTL4CommandBuffer no crea referencias fuertes a los recursos.”¹ El comportamiento es similar a makeCommandBufferWithUnretainedReferences() de la API anterior. Las aplicaciones deben gestionar los tiempos de vida de los recursos explícitamente para que estos permanezcan vivos hasta que la GPU termine el trabajo.

El patrón de asignador-por-frame que Apple incluye en su código de muestra usa un asignador por cada frame en vuelo (la muestra usa tres) y los rota a medida que los frames avanzan por el ciclo de vida codificar → renderizar → mostrar.¹ Llamar a reset() en el asignador al inicio de cada frame devuelve su memoria al pool para reutilización.

El Codificador De Cómputo Unificado

MTL4ComputeCommandEncoder es “un nuevo tipo que combina la funcionalidad de sus tres predecesores: MTLBlitCommandEncoder, MTLComputeCommandEncoder, MTLAccelerationStructureCommandEncoder.”¹

La API anterior requería que las aplicaciones cambiaran de tipo de codificador según la forma del trabajo: blit para copias de recursos y transferencias de texturas, cómputo para despachos de kernels, estructura de aceleración para la gestión de escenas con ray tracing. Metal 4 colapsa esos tres en una sola superficie. Una aplicación que codifica un frame que construye una estructura de aceleración, despacha un kernel de eliminación de ruido y copia una textura a un búfer de presentación ahora puede hacer las tres cosas a través de un solo tipo de codificador.

El codificador de renderizado también incorporó un cambio de comportamiento. MTL4RenderCommandEncoder admite codificar un pase de renderizado a través de búferes de comandos suspendiendo el trabajo al final de un codificador de renderizado y reanudándolo después del inicio del siguiente en la secuencia.¹ El encuadre de Apple: “Esta técnica reemplaza conceptualmente el protocolo MTLParallelRenderCommandEncoder y simplifica la codificación de un pase de renderizado en paralelo con múltiples hilos porque cada hilo puede tener su propio codificador de renderizado en lugar de atarlos todos a un solo codificador de renderizado.”¹

El patrón se mantiene: la codificación paralela se convierte en la forma natural, y la API deja de exigir un único tipo coordinador.

Las Tablas De Argumentos Reemplazan Los Bindings De Recursos Por Codificador

La API original de codificadores de Metal exponía métodos como setVertexBuffer(_:offset:index:) y setFragmentTexture(_:index:) en cada codificador, con tablas de binding por etapa internas al codificador.¹ Metal 4 reemplaza ese patrón con una instancia explícita de MTL4ArgumentTable.

El encuadre de Apple sobre el beneficio del diseño: “Los codificadores de Metal 4 no requieren memoria para almacenar las tablas de binding para cada tipo de recurso, en cada etapa. Cada tabla consume solo la memoria que necesita para almacenar sus bindings de recursos.”¹

El flujo:¹

let descriptor = MTL4ArgumentTableDescriptor()
descriptor.maxBufferBindCount = ...
descriptor.maxTextureBindCount = ...
let argumentTable = device.makeArgumentTable(descriptor: descriptor)

argumentTable.setResource(buffer, bufferIndex: 0)
argumentTable.setSamplerState(sampler, index: 0)

renderEncoder.setArgumentTable(argumentTable, stages: [.vertex, .fragment])

Una sola tabla de argumentos puede servir a múltiples codificadores, incluidos codificadores en diferentes búferes de comandos, siempre que los recursos que vincula sean apropiados para todos ellos. Los documentos de Apple señalan: “Los ahorros de memoria y de tiempo de ejecución se acumulan con cada recurso común que comparten tus codificadores, y cada vez que asignas la tabla de argumentos a un nuevo codificador.”¹

Hay una compensación. Las versiones anteriores de Metal admitían el seguimiento de hazards para texturas y heaps que se inscribían vía MTLTextureDescriptor.hazardTrackingMode o MTLHeapDescriptor.hazardTrackingMode.¹ En Metal 4, “el framework considera que todos los recursos no tienen seguimiento. Necesitas sincronizar las etapas del pipeline que pueden acceder concurrentemente a un recurso si alguno de los shaders en estos pipelines lo modifica.”¹ Las aplicaciones añaden barreras explícitas para retrasar una etapa hasta que termine una etapa anterior. Es más código que el seguimiento opcional anterior, a cambio de un rendimiento predecible y menor sobrecarga en tiempo de ejecución.

Aprendizaje Automático Como Pase De Primera Clase

MTL4MachineLearningCommandEncoder es la adición más significativa desde el punto de vista arquitectónico. El encuadre de Apple:²

“Metal 4 introduce la capacidad de ejecutar modelos de CoreML eficientemente desde dentro del flujo de trabajo de Metal. Esto es útil para aplicaciones que necesitan aplicar la salida de un modelo en un contexto de Metal, como renderizar una escena o ejecutar un dispatch de cómputo.”

Dos cosas suceden a la vez. Primero, la inferencia de ML se ejecuta en la línea de tiempo de la GPU, en el mismo búfer de comandos que el trabajo de renderizado y cómputo. La aplicación no hace ida y vuelta a través de la CPU entre la inferencia del modelo y el pase de renderizado que consume la salida. Segundo, el sistema elige el motor de inferencia: “El sistema elige automáticamente un motor de inferencia, como la GPU del dispositivo o el Apple Neural Engine (ANE) para cada modelo de aprendizaje automático. La GPU puede ejecutar trabajo adicional e independiente de renderizado o cómputo con la GPU cuando el sistema decide ejecutar un modelo en el ANE.”²

El flujo de desarrollo:²

1. Convierte un modelo de Core ML en un paquete Metal ML usando metal-package-builder, incluido en las herramientas integradas de Xcode 26.
2. Añade el paquete Metal ML al proyecto de Xcode. Xcode lo compila a una biblioteca de Metal en tiempo de compilación.
3. En tiempo de ejecución, la aplicación crea un MTL4MachineLearningPipelineState a partir de esa biblioteca.
4. El codificador toma el estado del pipeline, un MTLHeap para memoria de scratch e instancias de MTLTensor para entradas y salidas.

MTLTensor es un nuevo tipo de recurso para arrays de datos multidimensionales.² Los documentos de Apple señalan que el tipo funciona con tipos comunes de pesos de ML como int8 y fp16. Los tensores transportan entradas hacia el modelo y salidas desde él; para datos transitorios entre invocaciones de inferencia, Metal Shading Language añade tipos de tensor que viven directamente en la GPU:²

• tensor_handle: un handle a un MTLTensor creado en la CPU
• tensor_inline: un tensor definido en la GPU como una vista a un tensor o búfer
• cooperative_tensor: un tensor que distribuye sus elementos entre los hilos que trabajan con él

El tipo cooperative_tensor es el caso sensible a la latencia: “Los tensores cooperativos proporcionan memoria temporal para tensores transitorios distribuyendo equitativamente sus datos entre los hilos que trabajan con ese tensor. Esta distribución de memoria reduce el ancho de banda de memoria al asignar la memoria desde espacios de direcciones privados de hilo o privados de threadgroup, lo cual es importante para algoritmos de aprendizaje automático críticos en latencia.”²

MSL también incorporó operadores de tensores que funcionan directamente en código de shader: convolución, multiplicación de matrices, reducción.² Las aplicaciones que necesitan manipular pesos entre pases de inferencia pueden hacerlo sin copiar tensores de vuelta a la memoria de la CPU ni ejecutar un pase de cómputo separado; los operadores encajan en kernels normales de MSL.

Hay un límite que vale la pena citar: “Los codificadores de aprendizaje automático ejecutan modelos de Core ML pero no pueden construir nuevas redes ni modificar capas y entradas de las existentes; para esas tareas, consulta Core ML y Metal Performance Shaders Graph.”² El codificador de ML de Metal 4 es para enviar inferencia, no para entrenamiento ni construcción de modelos.

Lo Que Significa Metal 4 Para El Stack De Apple

Tres puntos clave para los desarrolladores de aplicaciones que planean adoptar Metal 4:

1. Adopta de forma incremental, por subsistema. Los tipos paralelos con prefijo MTL4 y la interoperabilidad basada en eventos con la API original están diseñados para una migración parcial. Elige un subsistema con presión clara de rendimiento (una ruta de renderizado, un pipeline de cómputo, un bucle de inferencia de modelo) y migra ese primero.¹
2. La codificación multihilo es la nueva normalidad. El patrón de asignador-por-hilo, el envío en lote commit:count: y el mecanismo de suspender/reanudar pase de renderizado asumen la codificación paralela como la forma que usarán las aplicaciones de alto rendimiento. La codificación de un solo hilo aún funciona, pero las ganancias de tiempo de ejecución del framework se acumulan con la adopción multihilo.¹
3. El ML se ejecuta en el mismo búfer de comandos que todo lo demás. Para aplicaciones que combinan inferencia de modelos en el dispositivo con renderizado o cómputo (pipelines de procesamiento de imágenes que filtran a través de un modelo de Core ML, efectos en tiempo real que dependen de la salida de un clasificador, experiencias de AR cuyo renderizado depende de un resultado de inferencia por frame), la capacidad de codificar inferencia de ML en el mismo búfer de comandos que el pase de renderizado que la consume es el cambio cualitativo.²

Las adiciones de Metal Shading Language merecen su propio tratamiento. Los tipos y operadores de tensores en código de shader, además de descriptores de operación para operaciones personalizadas, cambian lo que un kernel de Metal puede expresar. Eso es un post separado.

El cluster completo del Ecosistema de Apple: el LLM en el dispositivo de Foundation Models para el framework que se ejecuta sobre este stack; el ciclo de vida de adaptadores personalizados para especialización gestionada por el desarrollador; inferencia en el dispositivo de Core ML para el framework de ML cuyos modelos Metal 4 ahora ejecuta en línea. El hub está en la Serie del Ecosistema de Apple.

Preguntas frecuentes

¿Es Metal 4 un framework separado de Metal?

No. El framework sigue siendo Metal. Los documentos de Apple describen Metal 4 como “la API principal de Metal 4”: un conjunto de nuevos tipos con el prefijo MTL4 que se incluyen junto con los tipos MTL originales en el mismo framework.¹ Las aplicaciones adoptan los nuevos tipos de forma incremental detectando el soporte de Metal 4 en tiempo de ejecución y creando el tipo de cola apropiado.

¿Necesito iOS 26 para usar Metal 4?

El framework Metal soporta iOS 8+, pero la API principal de Metal 4 es la versión que Apple introdujo en la WWDC25. Ejecuta una detección en tiempo de ejecución y crea un MTL4CommandQueue o un MTLCommandQueue según lo que el dispositivo soporte.¹

¿Cuál es la relación entre los pases de ML de Metal 4 y Foundation Models?

Se ejecutan sobre stacks diferentes. MTL4MachineLearningCommandEncoder ejecuta modelos de Core ML convertidos a paquetes Metal ML, en el mismo búfer de comandos que el trabajo de renderizado y cómputo.² Foundation Models es un framework separado que ejecuta el modelo de lenguaje del sistema en el dispositivo de Apple con su propia API de sesión, cubierto en el post sobre LLM en el dispositivo de Foundation Models. Los dos son complementarios: una aplicación puede usar Foundation Models para la generación de texto y los pases de ML de Metal 4 para inferencia de modelos de visión o audio dentro de su bucle de renderizado.

¿Por qué se unifica ahora el codificador de cómputo?

Los documentos de Apple combinan MTLBlitCommandEncoder, MTLComputeCommandEncoder y MTLAccelerationStructureCommandEncoder en MTL4ComputeCommandEncoder.¹ La justificación es operativa más que solo de rendimiento: un solo tipo de codificador para cómputo, blit y trabajo de estructura de aceleración simplifica la gestión del pipeline y reduce la rotación de codificadores en aplicaciones que entrelazan los tres.

¿Siguen disponibles las opciones de store-action en Metal 4?

No para MTL4RenderCommandEncoder. Los documentos de Apple señalan: “Las opciones de store-action (consulta MTLStoreActionOptions) no están disponibles porque no aplican a las GPUs de Apple silicon.”¹ La decisión arquitectónica refleja el objetivo exclusivo de GPU de Apple para la API principal de Metal 4.

¿Tengo que usar tablas de argumentos?

En Metal 4, sí. Los protocolos de codificadores no exponen métodos de bind por recurso. Configuras los bindings de recursos en una MTL4ArgumentTable y asignas esa tabla a una o más etapas del codificador.¹ El beneficio en tiempo de ejecución es que la tabla solo asigna memoria para los bindings que realmente usa, en lugar de tablas de tamaño fijo por etapa en cada codificador.

Referencias