Modelos de Razonamiento·9 min de lectura

Router semántico para LLMs locales: herramientas en Apple Silicon

Crea agentes de IA locales con enrutado semántico. Separa la selección de herramientas para reducir la latencia a 40 ms en Apple Silicon.

Primer plano macro de una placa de circuito integrado con pistas de procesamiento y rutas electrónicas
Foto: Vishnu Mohanan · Unsplash
Resumen técnico
  • Sobrecarga de herramientas autorregresivas en silicio móvil: Incluir diez definiciones de funciones en el prompt de un LLM inyecta entre 1.500 y 3.000 tokens de esquema JSON en el contexto, disparando el tiempo hasta el primer token (TTFT) de 90 ms a más de 950 ms en procesadores móviles y consumiendo ancho de banda innecesario.
  • El enrutado semántico desacopla la decisión de la generación: En lugar de forzar a un modelo de miles de millones de parámetros a determinar si necesita herramientas, elegir la adecuada y formatear argumentos a la vez, un router semántico evalúa la intención en una sola pasada hacia adelante en menos de 45 ms.
  • Capas de acción destiladas frente a vectores estáticos de enunciados: Mientras la similitud coseno por bi-encoders compara incrustaciones estáticas, las capas de acción destiladas (como el modelo Lapis-SAL de 150M) cruzan herramientas registradas dinámicamente y generan respuestas NONE calibradas con un 95,1 % de precisión en pruebas sintéticas, evitando falsos positivos en peticiones conversacionales.
  • Canalización en dos fases que protege la memoria y evita alucinaciones: Filtrar las consultas a través de una capa de enrutado MLX de 150M antes de la generación mantiene limpio el contexto del modelo principal. Las peticiones generales responden al instante sin esquemas, y las acciones reales inyectan únicamente el esquema requerido para una decodificación gramatical exacta.

Los agentes de inteligencia artificial autónomos capaces de invocar herramientas locales y ejecutar razonamientos en varios pasos representan la frontera del aprendizaje automático en el dispositivo. Sin embargo, ejecutar agentes interactivos en procesadores Apple Silicon se enfrenta a una barrera computacional directa: inyectar múltiples esquemas JSON de herramientas en un modelo autorregresivo satura la ventana de contexto, multiplica el tiempo hasta el primer token y genera alucinaciones en preguntas conversacionales simples. Desacoplar la selección de herramientas de la generación de argumentos mediante un router semántico o capa de acción reduce la latencia de decisión a menos de 45 milisegundos en Apple Silicon, eliminando la sobrecarga de contexto y transformando agentes móviles lentos en software personal instantáneo.

El cuello de botella computacional de la selección autorregresiva de herramientas

Analizar los límites mecánicos de la IA local exige comprender cómo procesan los modelos de lenguaje autorregresivos las peticiones con herramientas. La pasada hacia adelante de un modelo opera en dos fases diferenciadas según el modelo Roofline: una fase inicial de prellenado (prefill) limitada por cómputo, seguida de una decodificación autorregresiva secuencial estrictamente limitada por el ancho de banda de la memoria.

En las arquitecturas de agentes convencionales—como los bucles ReAct, los esquemas de function calling tipo OpenAI o las instrucciones de sistema directas—, cada herramienta disponible debe serializarse como un esquema JSON e inyectarse en la ventana de contexto. Declarar un conjunto habitual de ocho a quince herramientas (agenda de calendario, búsqueda en documentos locales, recordatorios, calculadora, contactos y ejecución en terminal local) introduce entre 1.500 y 3.500 tokens de esquemas estáticos en cada interacción.

Este patrón arquitectónico impone penalizaciones severas en hardware móvil como el iPhone 16 Pro (A18 Pro) y ordenadores Mac:

  • Disparo de la latencia de prellenado (TTFT): Evaluar un prefill de 2.500 tokens en silicio móvil consume entre 600 ms y 1.200 ms de cómputo continuado en la GPU antes de emitir el primer token. En un asistente interactivo, este retraso introduce una pausa molesta antes de cada respuesta.
  • Saturación de memoria por la caché KV: Los estados de Claves y Valores asociados a esos esquemas estáticos deben permanecer retenidos en la DRAM unificada durante toda la sesión. En conversaciones extensas, esquemas que el usuario no utiliza consumen cientos de megabytes de memoria residente, aproximando el proceso a los límites de expulsión de Jetsam en iOS.
  • Elevada tasa de falsos positivos en modelos pequeños: Mientras los modelos en la nube de 70.000 millones de parámetros distinguen con fiabilidad cuándo usar una herramienta y cuándo responder con texto directo, los modelos optimizados para dispositivos (entre 1,5B y 8B de parámetros) sufren ante instrucciones complejas. Enfrentados a esquemas densos en JSON, los modelos compactos alucinan argumentos, generan sintaxis JSON defectuosa o ejecutan herramientas innecesarias ante un simple saludo.

Forzar a un modelo generativo a interpretar la intención, seleccionar la función adecuada y estructurar los argumentos en JSON de manera simultánea amplía los puntos de fallo. Resolver esta fricción requiere separar la decisión de qué ejecutar del formateo generativo de los parámetros.

Para analizar cómo se ejecutan los bucles de razonamiento y acción en el dispositivo, revisa la guía sobre agentes de IA locales en iPhone con Apple MLX.

Arquitectura del enrutado semántico: proximidad vectorial frente a clasificadores destilados

El enrutado semántico intercepta las entradas del usuario en el perímetro del sistema, clasificando la intención y enviando el mensaje al destino adecuado antes de invocar un modelo generativo pesado. En entornos locales se diferencian dos enfoques principales:

  1. Enrutado por proximidad coseno mediante bi-encoders: Popularizado por bibliotecas como semantic-router, este enfoque procesa la consulta con un modelo compacto de incrustaciones vectoriales (como MiniLM o BGE, habitualmente entre 20M y 100M de parámetros) para obtener un vector denso. El sistema calcula la distancia coseno frente a vectores precalculados que representan frases de ejemplo para cada herramienta. Si la similitud supera un umbral calibrado, la consulta se envía a esa herramienta. Aunque la ejecución es rápida (10–25 ms en Metal), comparar vectores estáticos presenta dificultades con herramientas registradas dinámicamente en tiempo de ejecución y resulta muy sensible cuando la redacción del usuario se aparta de los ejemplos de referencia.
  2. Capas de acción semántica destiladas: En lugar de basarse en distancias vectoriales entre frases aisladas, un modelo de clasificación especializado cruza directamente la consulta del usuario con las definiciones de las herramientas activas en una sola pasada. La red calcula probabilidades softmax sobre las herramientas registradas e incorpora una clase explícita y calibrada NONE para peticiones conversacionales. Esto permite registrar herramientas dinámicamente y gestionar caídas a conversación sin reindexar vectores.

La comparativa técnica entre estas arquitecturas evidencia las ventajas de desacoplar el enrutado en Apple Silicon:

Arquitectura de enrutado Latencia de decisión (A18 Pro / M4) Huella en DRAM unificada Registro dinámico de herramientas Sobrecarga de tokens de contexto Alucinación de herramientas (Falsos positivos)
Esquema autorregresivo completo (8B Q4) 850–1.400 ms (Prefill) 4,65 GB + Caché KV Alto (Reconstruye el prompt) 1.800–3.500 tokens Moderado a alto (12–18 %)
Proximidad coseno bi-encoder (384d) 12–25 ms (Metal / CPU) ~120 MB Bajo (Exige reindexar vectores) 0 tokens (Filtrado) Moderado (Depende del umbral)
Capa de acción destilada (Lapis-SAL 150M MLX) ~40 ms (Núcleos Metal fusionados) ~185 MB Nativo (Evalúa listas dinámicas) 0 tokens (Filtrado) Mínimo (Caída calibrada a NONE)

Al delegar la selección de herramientas en un modelo especializado de menos de 200 MB, el LLM generativo principal queda libre de procesar esquemas monolíticos en su contexto, reduciendo la latencia de respuesta y preservando ancho de banda de memoria.

Para profundizar en la definición de esquemas y llamadas a funciones estructuradas con gramáticas Metal, consulta la guía de function calling con LLMs locales en Apple Silicon.

Lapis-SAL: destilación y capas de decisión en 40 ms

Para investigar la viabilidad del enrutado semántico directamente en dispositivos Apple, Lapis Labs desarrolló Lapis-SAL (Semantic Action Layer), un proyecto de investigación abierto enfocado en la selección dinámica de herramientas en silicio Apple. El trabajo busca resolver el conflicto entre la flexibilidad de herramientas dinámicas y los límites estrictos de memoria en dispositivos móviles.

La arquitectura del proyecto se fundamenta en la destilación de conocimiento desde un modelo profesor:

  • Modelo Teacher (421M parámetros): Entrenado sobre conjuntos de datos bilingües (inglés y español) que abarcan definiciones de herramientas en múltiples dominios, requisitos de parámetros y casos conversacionales fuera de alcance. El profesor aprende representaciones semánticas generalizadas sobre intenciones y patrones conversacionales cotidianos.
  • Modelo Student destilado (150M parámetros): La destilación transfiere la capacidad de clasificación del profesor a un modelo estudiante de 150M parámetros. Los pesos se cuantizan y adaptan al formato nativo Apple MLX (lapislabsai/lapis-sal-150M-MLX), compilando directamente contra Metal Performance Shaders para ejecución con copia cero en memoria unificada.
  • Publicación en código abierto: Publicada bajo licencia Apache 2.0, la familia de modelos ofrece pesos abiertos para las comunidades de MLX, PyTorch y Hugging Face.

En un conjunto de prueba sintético privado de 1.000 ejemplos de evaluación, el estudiante MLX de 150M registró una precisión del 95,1 %, resolviendo la selección entre herramientas dinámicas o la respuesta NONE en aproximadamente 40 milisegundos en hardware Apple Silicon.

Es indispensable distinguir con claridad los límites de esta investigación: Lapis-SAL es un modelo de clasificación y enrutado de intenciones, no un LLM conversacional generativo. No genera texto libre ni redacta respuestas. Su función es actuar como un filtro determinista y ligero previo a los modelos generativos, garantizando que el cómputo pesado se active únicamente cuando sea necesario.

Para comprender cómo la sobrecarga de tokens y el crecimiento del contexto degradan la memoria unificada, revisa límites de la ventana de contexto en LLMs locales.

Canalización en dos fases: generación guiada sin saturar el contexto

Incorporar un router semántico transforma la arquitectura del agente local en un flujo en dos fases claramente diferenciadas. En lugar de procesar todas las entradas mediante un prompt monolítico, el sistema bifurca la ejecución de forma condicional tras una clasificación de alta velocidad:

  1. Fase 1: Percepción y enrutado de intención (0–45 ms): La consulta del usuario entra junto al registro de herramientas activas en la capa de acción de 150M. En unos 40 milisegundos, el router devuelve un identificador de herramienta (por ejemplo, CALENDAR_CREATE_EVENT) o el estado NONE.
  2. Fase 2A: Respuesta conversacional directa (Cuando Router = NONE): Si el usuario realizó una pregunta general, solicitó una explicación o envió un saludo, la petición no activa herramientas. El texto se envía al LLM generativo sin ningún esquema JSON. El modelo comienza a emitir tokens en 80–110 ms, eliminando la latencia de prellenado y anulando el riesgo de alucinación sintáctica.
  3. Fase 2B: Extracción guiada por gramática (Cuando Router = ID de herramienta): Si se selecciona una herramienta concreta, el entorno recupera únicamente el esquema de esa función específica y lo proporciona al modelo. Además, la generación se vincula a un autómata finito (FSM) en Apple MLX, asegurando una extracción de argumentos JSON con validez sintáctica del 100 % mediante enmascaramiento de logits.

Esta división en dos fases aporta ventajas directas en iOS y macOS:

  • Compresión de contexto: Al cargar únicamente el esquema pertinente en lugar de quince definiciones no utilizadas, los tokens del prompt se reducen hasta en un 90 %, bajando la latencia de prefill de más de 900 ms a menos de 120 ms.
  • Ahorro térmico y de batería: El procesador móvil reduce notablemente su permanencia en estados de máxima frecuencia gráfica. En sesiones multiturno habituales donde solo entre el 10 % y el 20 % de los mensajes requieren herramientas, el dispositivo evita cálculos intensivos de prefill en el 80 % de las interacciones.
  • Margen de memoria operativo: El presupuesto de DRAM unificada se mantiene bajo control. El clasificador de 150M consume unos 185 MB de memoria cableada, mientras que el LLM generativo trabaja con una caché KV reducida que opera holgadamente por debajo del límite de expulsión de 5,0 GB del demonio Jetsam en iOS.

Para evaluar por qué la decodificación secuencial token a token depende del ancho de banda del bus de DRAM, consulta ancho de banda en Apple Silicon para LLMs.

Seguridad sin emisiones y control de memoria en Apple Silicon

Más allá de la velocidad y la eficiencia de memoria, el enrutado semántico en Apple Silicon fija una garantía estricta de privacidad. Los sistemas de agentes en la nube canalizan las consultas a través de servidores externos, exponiendo preguntas personales, eventos de calendario, nombres de contactos y documentos confidenciales a centros de datos remotos antes de ejecutar cualquier acción local.

La computación local soberana exige procesamiento sin emisiones de red. En aplicaciones nativas desarrolladas con Swift y Metal, tanto la capa de acción semántica como los modelos generativos operan íntegramente en la memoria DRAM del equipo sin abrir sockets de red. Desactivar el entitlement com.apple.security.network.client en el sandbox del kernel Darwin asegura que ni el clasificador de intenciones ni el agente generativo puedan enviar telemetría ni fragmentos de conversación fuera del dispositivo físico.

Para usuarios y organizaciones que buscan una alternativa privada, sin cuotas mensuales y con control total sobre sus datos, la ejecución local en Apple Silicon define el estándar de la informática personal moderna. Lapis integra modelos locales de lenguaje, análisis privado de documentos y ejecución inteligente de herramientas en una aplicación nativa diseñada para iPhone, iPad y Mac disponible en la App Store.

Si quieres trabajar con modelos que requieren más memoria, conoce Lapis para Mac y sus opciones de inferencia local.

Cómo se elaboró este artículo

La metodología evalúa la latencia de clasificación, el consumo de memoria unificada y la precisión sintáctica en la selección dinámica de herramientas en Apple Silicon (procesadores A18 Pro y M4), comparando la inferencia autorregresiva tradicional con esquemas JSON completos frente a capas de acción semántica destiladas (Lapis-SAL 150M en Apple MLX) y routers basados en similitud coseno de incrustaciones vectoriales.

Las referencias enlazadas al final permiten consultar los fundamentos del artículo. Para reproducir cifras de rendimiento se necesitan la configuración completa y los datos de cada prueba.

Las tablas de este artículo no incluyen datos brutos ni un protocolo completo de medición. Sus cifras están pendientes de validación reproducible y deben leerse con esa limitación.

Fuentes y referencias

Ejecución en local con Lapis

Con Lapis puedes conversar con modelos compatibles en iPhone, iPad y Mac. Descárgalos una vez y utiliza la inferencia local sin conexión; el tamaño del modelo depende de los recursos de tu equipo.

App Store