Arquitectura de LLM: Diseño de sistemas para IA en producción
Ejecutar un modelo es un problema de infraestructura. Obtener valor de un modelo es un problema de arquitectura.
La capa de infraestructura —entornos de ejecución, hardware, puntos finales de API— determina lo que es posible. La capa de arquitectura determina lo que realmente ocurre con una solicitud: qué modelo la maneja, cuánto cuesta, qué la valida y cómo se detectan los errores.
La mayoría de los sistemas comienzan con un solo modelo y sin arquitectura alguna. Esto es correcto para la prototipación. Se convierte en una desventaja en producción.
La arquitectura de LLM abarca las decisiones de diseño que transforman “un modelo que puedo llamar” en “un sistema en el que puedo confiar”.
Dónde se sitúa la arquitectura de LLM en el stack
La arquitectura de LLM se sitúa en el medio de un modelo de tres capas:
| Capa | Qué abarca | Área relacionada |
|---|---|---|
| Modelos | Entornos de ejecución, servicio, configuración de GPU | Alojamiento de LLM · Rendimiento de LLM |
| Arquitectura | Enrutamiento, costos, guardarrails, orquestación | Estás aquí |
| Aplicaciones | Asistentes de IA, pipelines RAG, agentes | Sistemas de IA · RAG |
La capa de arquitectura a menudo se omite al principio. Se vuelve esencial cuando tienes más de un modelo, más de un tipo de tarea o más de un usuario. Cada patrón de arquitectura en este clúster existe porque “un modelo para todo” dejó de funcionar.
Mapa del clúster
Los cinco temas de este clúster se construyen mutuamente. Léelos en este orden para obtener el camino más lógico:
- Estás aquí — este pilar: qué es la arquitectura de LLM, cómo encajan las piezas
- Prompts — Escritura de prompts efectivos para LLMs — la base: dar forma a lo que recibe el modelo
- Enrutamiento — Estrategias de enrutamiento de modelos — el despachador: qué modelo maneja qué
- Costos — Optimización de costos para sistemas LLM — presupuesto de tokens, caché, economía local vs API
- Seguridad — Guardarrails de LLM en la práctica — validación de entrada, filtrado de salida, cumplimiento
- Orquestación — Diseño de sistemas multimodelo — patrones secuenciales, paralelos, jerárquicos y de conjunto
Si solo tienes tiempo para uno, comienza con el enrutamiento. Es el punto de decisión donde comienza la arquitectura.
Ingeniería de prompts
La ingeniería de prompts es la capa más cercana al modelo. Antes del enrutamiento, antes del caché, antes de los guardarrails, está el prompt. Lo que envías al modelo determina lo que obtienes a cambio.
Las técnicas prácticas que importan:
- Claridad y estructura — las instrucciones claras superan a los marcos ingeniosos
- Ejemplos específicos — los ejemplos few-shot anclan el comportamiento del modelo
- Asignación de roles — los prompts basados en roles afinan el tono y las restricciones
- Enfoques variados — diferentes formatos revelan a lo que responde el modelo
- Gestión del contexto — lo que incluyes moldea lo que el modelo pondera
La ingeniería de prompts no es una tarea de una sola vez. Es una calibración continua entre los requisitos de tu tarea y el comportamiento del modelo.
Análisis profundo:
- Escritura de prompts efectivos para LLMs — técnicas prácticas para el rendimiento de modelos de lenguaje
Enrutamiento de modelos
Una capa de enrutamiento decide qué modelo maneja qué solicitud. Sin ella, cada solicitud va al mismo modelo —a menudo demasiado grande para tareas simples, demasiado pequeño para tareas complejas.
Cuatro estrategias de enrutamiento cubren la mayoría de los casos de producción:
| Estrategia | Optimizar para | Mejor cuando |
|---|---|---|
| Basada en capacidad | Calidad de la tarea | Cargas de trabajo de complejidad mixta |
| Consciente del costo | Gasto de tokens | Sistemas con presupuesto limitado |
| Consciente de la latencia | Tiempo de respuesta | Herramientas interactivas y chat en tiempo real |
| Híbrida | Los tres anteriores | Sistemas de producción con restricciones reales |
Una cadena de respaldo maneja los errores: ordena los modelos de mejor a más confiable, terminando con un modelo local que no pueda ser limitado por tasa o apagado por una interrupción de la API.
Análisis profundo:
- Estrategias de enrutamiento de modelos: Local vs API, Consciente del costo, Consciente de la latencia — enrutamiento basado en capacidad, consciente del costo y consciente de la latencia con código Python
Optimización de costos
Los costos de los LLM escalan linealmente con el uso. Las estrategias que realmente reducen la factura:
El presupuesto de tokens establece límites por sesión, por tarea o adaptativos. Los presupuestos adaptativos rastrean el uso real y ajustan las asignaciones con el tiempo.
La inferencia local cambia por completo la estructura de costos. Después de la amortización del hardware, los modelos locales se ejecutan al costo de la electricidad. Una GPU con un uso moderado se paga a sí misma en meses.
El caché es la optimización más infravalorada. El caché de coincidencia exacta captura prompts repetidos. El caché semántico captura prompts que significan lo mismo. Para sistemas de alto tráfico, el caché semántico elimina una gran parte de las llamadas a la API antes de que ocurran.
Las cadenas de respaldo reducen el costo promedio por solicitud: prefiere modelos costosos cuando el presupuesto lo permite, recurre a modelos más baratos o locales a medida que avanza la sesión.
Análisis profundo:
- Optimización de costos para sistemas LLM: Presupuesto de tokens, Modelos de respaldo, Caché — cifras reales de hardware, tablas de punto de equilibrio y patrones Python funcionales
Guardarrails
Los LLM son impredecibles por defecto. Los guardarrails limitan lo que entra y lo que sale, sin eliminar la capacidad del modelo.
Tres capas de guardarrails importan en la práctica:
La validación de entrada detiene los problemas antes de que lleguen al modelo. La sanitización de prompts captura intentos de inyección. Los límites de longitud evitan el desperdicio de tokens. Los filtros de contenido bloquean violaciones de políticas antes de que la inferencia cueste nada.
El filtrado de salida captura los problemas después de la generación. La validación estructural asegura formas de respuesta esperadas. Las verificaciones de contenido bloquean salidas dañinas. La verificación de hechos (para dominios críticos) valida afirmaciones contra una base de conocimientos.
Los mecanismos de seguridad protegen el sistema con el tiempo: la limitación de tasa previene el abuso, los presupuestos de tokens limitan los costos por solicitud, la gestión de la ventana de contexto previene desbordamientos y fugas de datos entre turnos.
Para sistemas con altos requisitos de cumplimiento (GDPR, HIPAA, SOC 2), añade registros de auditoría con entradas estructuradas y solo de adición, y controles de residencia de datos.
Análisis profundo:
- Guardarrails de LLM en la práctica: Validación de entrada, Filtrado de salida, Seguridad — patrones prácticos de guardarrails y notas de cumplimiento
Diseño de sistemas multimodelo
Cuando un solo modelo no es suficiente, la pregunta de arquitectura es: ¿cómo orquestas múltiples modelos sin crear una complejidad que cueste más de lo que ahorra?
Cinco patrones cubren el espectro:
| Patrón | Latencia | Costo | Calidad | Usar cuando |
|---|---|---|---|---|
| Modelo único | Más baja | Más bajo | Variable | Prototipación, cargas de trabajo uniformes |
| Secuencial (Pipeline) | Alta | Media | Alta | Flujos de trabajo multinivel con especialización |
| Paralelo (Fan-Out) | Baja | Alta | Alta | Tareas independientes, pruebas A/B |
| Jerárquico (Planificador-Ejecutor) | Alta | Alta | Más alta | Razonamiento complejo con ejecución especializada |
| Conjunto (Ensemble) | Media | Más alto | Más alta | Decisiones críticas que requieren consenso |
La regla general: comienza con el patrón más simple que maneje tus restricciones reales. La mayoría de los sistemas de producción alcanzan el nivel paralelo o jerárquico solo después de que el enrutamiento basado en capacidad por sí solo deja de ser suficiente.
Análisis profundo:
- Diseño de sistemas multimodelo: Cuándo usar qué modelo y por qué — los cinco patrones con código Python funcional y tablas de compensaciones
Marco de decisión de arquitectura
Usa esto como un triaje rápido para qué agregar y cuándo:
| Problema | Solución | Cuándo agregarlo |
|---|---|---|
| La factura es demasiado alta | Enrutamiento consciente del costo, caché, inferencia local | Cuando los costos de API se convierten en una línea presupuestaria real |
| La latencia es demasiado alta | Enrutamiento consciente de la latencia, modelos más pequeños | Cuando los usuarios notan lentitud |
| La calidad es inconsistente | Enrutamiento basado en capacidad, cadena de respaldo | Cuando las tareas simples obtienen modelos costosos o las complejas obtienen modelos baratos |
| Los usuarios están abusando del sistema | Validación de entrada, limitación de tasa | Cuando abres el acceso más allá de un equipo de confianza |
| Las respuestas son inseguras o fuera de política | Filtrado de salida, guardarrails de contenido | Cuando sirves a usuarios generales |
| Un solo modelo maneja todo | Diseño multimodelo | Cuando las cargas de trabajo divergen lo suficiente como para justificar la complejidad |
| Los prompts no están funcionando | Iteración de ingeniería de prompts | Siempre — los prompts necesitan ajuste a medida que las tareas evolucionan |
Construye la arquitectura desde abajo hacia arriba. La ingeniería de prompts siempre está en el ámbito. Agrega enrutamiento cuando las compensaciones de costo/calidad se vuelvan reales. Agrega guardarrails cuando sirvas a usuarios externos. Agrega orquestación multimodelo al final.
Cómo se relaciona la arquitectura de LLM con otros temas
La arquitectura de LLM se sitúa en la intersección de varios clústeres relacionados:
Infraestructura (por debajo de esta capa):
- Alojamiento de LLM en 2026: Comparación de infraestructura local, autoalojada y en la nube — entornos de ejecución (Ollama, llama.cpp, vLLM), hardware y decisiones de servicio. Los patrones de arquitectura dependen de la infraestructura disponible. El enrutamiento consciente del costo solo tiene sentido si tienes modelos locales y de API ejecutándose.
- Rendimiento de LLM en 2026: Benchmarks, cuellos de botella y optimización — cifras de latencia, límites de VRAM, mediciones de rendimiento. Estos son los insumos empíricos para las decisiones de enrutamiento y selección de modelos.
Capas de aplicación (por encima de esta capa):
- Sistemas de IA: Asistentes autoalojados, RAG e infraestructura local — los sistemas que consumen decisiones de enrutamiento, guardarrails y orquestación. La arquitectura multimodelo es un prerrequisito para asistentes de IA en producción.
- Tutorial de Generación Aumentada con Recuperación (RAG) — el RAG es en sí mismo un patrón arquitectónico: un pipeline de recuperación que alimenta contexto a un LLM. Los patrones de enrutamiento, costo y guardarrails de este clúster también se aplican dentro de los pipelines RAG.
Capa operativa:
- Observabilidad: Guía de monitoreo, métricas, Prometheus y Grafana — la arquitectura de LLM en producción necesita observabilidad. El seguimiento de costos, el monitoreo de latencia y las métricas de violación de guardarrails requieren instrumentación en la capa de arquitectura, no solo en la capa de infraestructura.
