Llama Stack en un Teléfono: Agentes Llama Autoalojados con un Modelo Llama 4 Ajustado

Llama Stack es la arquitectura de referencia oficial de Meta para construir agentes sobre modelos Llama. Agentes, herramientas, filtros de seguridad, evaluaciones y telemetría se sitúan detrás de una superficie API unificada única. Es lo más cercano que el mundo open-weight tiene a un stack de agentes canónico, y su intención de diseño es clara: dejar de reinventar el bucle de agente, la capa de seguridad y el harness de evaluación en cada proyecto.

La mayoría de la cobertura de Llama Stack asume un despliegue en servidor — un cluster de Kubernetes, un pool de GPUs, un endpoint de API que tu aplicación llama por la red. Esa es la ruta obvia, y también es la ruta que recrea cada problema económico y de privacidad que el ecosistema open-weight se suponía que debía resolver. El coste por token se mantiene positivo. Los viajes de ida y vuelta de red se mantienen lentos. Los datos del usuario aún salen del dispositivo.

Lo menos apreciado es que Llama Stack envía SDKs cliente Swift y Kotlin de primera clase. La misma abstracción de agente puede ejecutarse con el modelo embebido en una aplicación iOS o Android, hablando con un servidor de inferencia local empaquetado en el binario. El bucle de agente, el dispatcher de herramientas, el filtro de seguridad, el pipeline de telemetría — todo puede ejecutarse en el teléfono del usuario, contra un derivado Llama 4 ajustado con el que la aplicación se envía.

Esta guía recorre esa arquitectura: un agente Llama Stack completo ejecutándose en dispositivo, impulsado por un modelo Llama 4 ajustado en Ertas Studio y enviado a la aplicación móvil vía Ertas Deployment CLI.

La arquitectura

Hay tres componentes y encajan limpiamente.

El primero es la inferencia en dispositivo. El SDK cliente Swift de Llama Stack envía una clase LocalInference respaldada por ExecuTorch que ejecuta el modelo directamente dentro de la aplicación iOS host — no se requiere un proceso de servidor Llama Stack separado para inferencia. El cliente Kotlin proporciona un adaptador en dispositivo equivalente para Android. El modelo se ejecuta en el espacio de direcciones de la aplicación y el SDK traduce las llamadas a la API de Llama Stack en llamadas de inferencia locales.

El segundo es el modelo en sí. El adaptador de inferencia en dispositivo carga un binario GGUF (o de formato ExecuTorch) con el que la aplicación se envía — típicamente un derivado Llama 4 ajustado en tus datos de dominio y cuantizado para móvil. El Ertas Deployment CLI maneja la conversión de formato y el registro de assets.

El tercero es la plataforma de agentes. Los clientes Swift y Kotlin implementan el bucle de agente de Llama Stack, el despacho de herramientas, el filtrado de seguridad y la telemetría localmente — las mismas primitivas que un despliegue Llama Stack del lado del servidor expondría, solo impulsadas por inferencia en dispositivo en lugar de un endpoint de red. Desde la perspectiva de la aplicación, la superficie de API es idéntica a un despliegue remoto de Llama Stack.

El resultado es una separación limpia. El código de la aplicación habla Llama Stack. El cliente Llama Stack impulsa el adaptador de inferencia en dispositivo. El adaptador de inferencia habla con el modelo GGUF a través de llama.cpp o ExecuTorch. Nada de esto requiere un viaje de ida y vuelta de red.

Por qué Llama Stack específicamente

Hay una pregunta perfectamente válida acechando aquí: si vas a ejecutar llama.cpp en dispositivo de todos modos, ¿por qué involucrar Llama Stack en absoluto? ¿Por qué no simplemente llamar a llama.cpp directamente a través de sus enlaces Swift o Kotlin y saltarse la capa de abstracción?

La respuesta honesta es que las configuraciones de inferencia móvil hechas en casa se saltan las partes de un agente que son fáciles de saltar y difíciles de añadir de vuelta. La llamada de herramientas se convierte en un parser hecho a medida. El filtrado de seguridad se convierte en o nada o un regex escrito a mano. La evaluación se convierte en unos pocos scripts puntuales. La telemetría se convierte en cualquier llamada a Logfire o OpenTelemetry que recordaste añadir. Cada brecha es resoluble en aislamiento; juntas, producen los agentes frágiles que hacen que la IA en dispositivo se sienta como una degradación frente a los agentes respaldados por API.

Llama Stack cierra esas brechas como parte de la arquitectura estándar:

• Agents API te da un bucle de agente estructurado con memoria multi-turno y despacho de herramientas — sin parser que escribir.
• Tools API registra tus funciones con esquemas tipados y maneja el enrutamiento automáticamente.
• Safety API ejecuta Llama Guard (o tu modelo de seguridad elegido) sobre entradas y salidas antes de que lleguen al usuario.
• Eval API ejecuta benchmarks contra conjuntos de prueba reservados para que puedas detectar regresiones cuando envías una nueva versión del modelo.
• Telemetry API captura trazas estructuradas de cada ejecución de agente para depuración y entrenamiento continuado.

Obtienes todo esto contra un modelo local, en un teléfono, sin escribir nada de ello tú mismo. Esa es la propuesta de valor real de Llama Stack en dispositivo — no "un envoltorio de inferencia" sino una plataforma de agentes completa que resulta soportar ejecución embebida.

La capa de fine-tuning

Un modelo Llama 4 estándar es un generalista. Para la mayoría de los casos de uso móviles agénticos — coaching de fitness, asistencia financiera, programación, soporte al cliente, cualquier cosa específica de dominio — un derivado ajustado es drásticamente más fiable. Tasa de alucinación menor en tus herramientas, menos violaciones de esquema, estilo más consistente, mejores rechazos en solicitudes fuera de alcance.

El pipeline se ve así:

1. Cura el dataset en Ertas Studio. El módulo Data Craft de Studio toma tus esquemas de herramientas como entrada y produce conversaciones de entrenamiento estructuradas que cubren llamadas de herramientas, flujos multi-paso y rechazos. Para un agente especializado en dominio típicamente quieres 400 a 800 ejemplos — suficientes para enseñar los esquemas, no tantos como para empezar a ajustar ruido.
2. Ajusta Llama 4 en Studio. Llama Stack se envió originalmente junto con Llama 3.2 en septiembre de 2024 y ha rastreado la familia Llama a través de Llama 3.3 y Llama 4 — los derivados Llama 4 son la base canónica actual para nuevos despliegues en dispositivo y se integran con la Safety API y la Eval API sin traducción. La configuración predeterminada de Studio es QLoRA en rango 32 sobre 3 épocas. Entrenar un dataset de 500 ejemplos en una base Llama 4 8B típicamente se completa dentro de una hora.
3. Exporta a GGUF. El flujo de exportación de Studio produce un binario GGUF cuantizado en el nivel que especifiques. Para Llama 4 8B en teléfonos, Q4_K_M aterriza alrededor de 5 GB en disco y se ejecuta limpiamente en cualquier flagship moderno. Para huellas más agresivas, Q3_K_M lo baja más a un pequeño coste de calidad.
4. Envía a móvil vía Ertas Deployment CLI. El CLI instala llama.cpp en el proyecto iOS o Android, deja caer el GGUF en el directorio de assets correcto, configura el servidor local de Llama Stack para servir el modelo y conecta el cliente Swift o Kotlin. Desde ejecutar el CLI hasta hacer la primera llamada al agente típicamente toma menos de quince minutos.

ertas deploy mobile \
  --project ./fitness-app \
  --model ertas-fitness-coach-llama4-8b.gguf \
  --framework ios \
  --runtime llama-stack

El flag --runtime llama-stack le dice al CLI que conecte el adaptador en dispositivo de Llama Stack (LocalInference en iOS, el equivalente Kotlin en Android) en lugar de una llamada llama.cpp pelada. El CLI genera el código de registro del adaptador de inferencia, configura el asset del modelo y engancha el cliente Swift o Kotlin en el ciclo de vida de la aplicación host para que la plataforma de agentes esté lista cuando la aplicación se lance.

Un ejemplo trabajado: un agente de coaching de fitness

Aquí está el agente que construiremos. Un usuario abre una aplicación de fitness y escribe algo como "Hice 3x10 sentadillas a 135, regístralo y dime qué hacer a continuación". El agente tiene tres herramientas:

• log_workout(exercise: String, sets: Int, reps: Int, weight: Double) registra el entrenamiento
• fetch_progress(exercise: String, weeks: Int) devuelve el historial reciente
• suggest_routine(goal: String, equipment: [String]) propone la siguiente sesión

En Studio, curamos un dataset de alrededor de 600 conversaciones cubriendo llamadas de una sola herramienta, flujos multi-paso (registrar luego sugerir), rechazos (los consejos médicos quedan fuera de alcance) y casos límite de validación (el peso faltante por defecto es peso corporal). Ajusta Llama 4 8B sobre 3 épocas. La suite de evaluación pasa con 96% de precisión de nombre de herramienta, 95% de precisión de nombre de parámetro, 94% de precisión de valor de parámetro. Listo para producción.

Ejecuta el Deployment CLI, apúntalo al proyecto iOS, elige --runtime llama-stack. Dos minutos después el proyecto se construye, el adaptador de inferencia en dispositivo se registra con el modelo y el cliente Swift se conecta.

Aquí está la integración completa del agente del lado del cliente:

import LlamaStack

let client = LlamaStackClient(transport: .embedded)

let agent = try await client.agents.create(
    model: "ertas-fitness-coach-llama4-8b",
    instructions: "You are a fitness coach. Use the tools to log workouts and suggest routines. Refuse medical questions.",
    tools: [
        Tool(name: "log_workout", description: "Log a completed workout"),
        Tool(name: "fetch_progress", description: "Fetch recent workout history"),
        Tool(name: "suggest_routine", description: "Suggest the next routine"),
    ],
    safety: .llamaGuard
)

let session = try await agent.createSession()

let response = try await session.turn(
    messages: [.user("I did 3x10 squats at 135, log it and tell me what to do next.")],
    toolHandlers: [
        "log_workout": logWorkoutHandler,
        "fetch_progress": fetchProgressHandler,
        "suggest_routine": suggestRoutineHandler,
    ]
)

print(response.finalMessage.content)

Aproximadamente treinta líneas de Swift. El bucle de agente, el despacho de herramientas, el filtrado de seguridad a través de Llama Guard, la memoria de sesión multi-turno — Llama Stack maneja todo. La aplicación host proporciona tres manejadores de herramientas (las funciones Swift que realmente registran en Core Data, consultan el historial y producen rutinas) y Llama Stack hace el resto.

El mismo patrón en Kotlin es esencialmente idéntico:

val client = LlamaStackClient(transport = Transport.Embedded)

val agent = client.agents.create(
    model = "ertas-fitness-coach-llama4-8b",
    instructions = "You are a fitness coach. Use the tools to log workouts and suggest routines.",
    tools = listOf(
        Tool("log_workout", "Log a completed workout"),
        Tool("fetch_progress", "Fetch recent workout history"),
        Tool("suggest_routine", "Suggest the next routine"),
    ),
    safety = Safety.LlamaGuard,
)

Todo lo que sucede después de eso — la inferencia, las llamadas de herramientas, las verificaciones de seguridad — es idéntico entre iOS y Android. El Stack abstrae el runtime limpiamente.

La economía

El caso de costes es el mismo que se aplica a toda arquitectura de agente en dispositivo. Un flujo de coaching de fitness multi-turno contra una API frontier corre aproximadamente tres a ocho centavos por sesión dependiendo de la longitud del contexto. Con mil usuarios activos diarios promediando cuatro sesiones al día, eso son ciento veinte a trescientos veinte dólares al día, o tres mil seiscientos a nueve mil seiscientos dólares al mes. La factura escala linealmente con los usuarios.

En dispositivo, el coste marginal por inferencia es el tiempo de GPU/CPU en el teléfono del usuario — típicamente unos pocos cientos de milisegundos y una fracción de centavo de la batería del usuario. El coste fijo es la huella del modelo en disco. Ningún término crece con tu recuento de usuarios.

Para constructores de aplicaciones móviles, el precipicio de costes agéntico muerde en algún lugar entre quinientos y cinco mil usuarios, dependiendo de la intensidad de la sesión. Ese es el rango donde los costes de API empiezan a consumir los ingresos de suscripción más rápido de lo que el crecimiento de uso puede superar. La inferencia en dispositivo elimina ese precipicio por completo, y Llama Stack en dispositivo lo elimina sin forzar al equipo a reconstruir el bucle de agente, el filtro de seguridad o el pipeline de telemetría desde cero.

Para casos de uso sensibles a la privacidad el cálculo es aún más agudo. Los dominios de salud, finanzas y legal tienen requisitos estrictos sobre dónde viven los datos del usuario. Un agente en dispositivo nunca hace verdadera la oración "mensaje de usuario enviado a Meta" o "mensaje de usuario enviado a OpenAI". Ese es un argumento de cumplimiento tanto como un argumento de costes, y para algunas categorías de aplicación es el único argumento que importa.

Diferenciación frente a otros enfoques en dispositivo

Hay otras formas de enviar un modelo en un teléfono. Puedes llamar a llama.cpp directamente a través de sus enlaces Swift. Puedes usar Apple Foundation Models en iOS 26+. Puedes usar AICore de Google en Android. Puedes hacer rodar tu propio bucle de agente sobre cualquiera de estos.

Lo que Llama Stack en dispositivo ofrece que las alternativas no, es el resto de la plataforma de agentes. Llama Guard para filtrado de seguridad, integrado y configurado. La Eval API para detectar regresiones cuando envías un nuevo fine-tune. La Telemetry API para trazas estructuradas que puedes retroalimentar en la siguiente ronda de entrenamiento. La Tools API para esquemas tipados y auto-despacho. Memoria de sesión multi-turno manejada por la Agents API.

No estás construyendo esas capas desde cero y no estás cosiendo media docena de bibliotecas open source para aproximarlas. Estás usando la arquitectura de referencia que Meta diseñó para exactamente este propósito, con el modelo embebido en la aplicación en lugar de detrás de un endpoint de red.

Cierre

Los constructores móviles que envían funciones de IA pueden enviar un stack de agentes completo — no solo inferencia — enteramente en el dispositivo del usuario. La arquitectura de referencia de Meta, un derivado Llama 4 ajustado y una pequeña cantidad de pegamento. La combinación de Llama Stack, Ertas Studio y el Ertas Deployment CLI colapsa lo que solía ser un trimestre de ingeniería de plataforma en una tarde de trabajo de integración.

La pieza de fine-tuning es donde Studio se gana su puesto — un modelo Llama 4 estándar es un generalista, y la fiabilidad del agente que necesitas para enviar viene de un modelo que conoce tus herramientas a fondo. La pieza de despliegue es donde el CLI se gana su puesto — conectar llama.cpp (o ExecuTorch), el adaptador de inferencia en dispositivo de Llama Stack, el cliente Swift o Kotlin y un archivo de modelo de 5 GB en un proyecto iOS o Android son veinte a cuarenta horas de configuración de build que la mayoría de los constructores de aplicaciones nunca terminan. Apila las tres piezas juntas y el camino desde "queremos un agente en dispositivo" hasta "tenemos un agente en dispositivo" se convierte en una sola tarde.

Para constructores de aplicaciones que miran el precipicio de costes agéntico, ese es el camino. Llama Stack te da la arquitectura. Llama 4 te da el modelo base. Studio te da la especialización. El Deployment CLI te da el pipeline de envío móvil. El agente se ejecuta en el teléfono del usuario, la factura deja de escalar con el uso y los datos del usuario nunca salen del dispositivo.