Litellm on lo0 — Blog Técnico

El router de inferencia LLM: la centralita L7 que en el post de canary llamábamos LoadBalancer

Tue, 02 Jun 2026 03:00:00 +0200

Este post es la continuación natural de Canary, blue-green y shadow para modelos LLM. Allí la mecánica de promoción depositó toda la complejidad de reparto de tráfico en una caja a la que llamamos “LoadBalancer”. La descripción era operacional —servía para entender la coreografía— pero estructuralmente vaga: lo que de verdad hace ese reparto es un router de inferencia L7 con awareness LLM, una pieza de pleno derecho del stack (capa 1 de las siete capas) que merece su propio post.

TL;DR

En el post anterior sobre canary llamamos LoadBalancer a la pieza que reparte tráfico entre los pools v1 estable y v2 candidato. La descripción servía para entender el flujo, pero técnicamente era borrosa: ni un LoadBalancer L4 (kube-proxy, MetalLB, IPVS) ni un LoadBalancer L7 HTTP genérico (NGINX o HAProxy sin extensión) saben qué es un modelo, qué es una versión, cuántos tokens cuesta una request, qué prefijo tiene el prompt o qué KV cache tiene caliente cada réplica. La pieza correcta es un router de inferencia LLM: un proxy L7 con conocimiento explícito del dominio. Combina cuatro funciones: catálogo de modelos (resolver model=llama-70b@v2 → service.namespace:port), traffic splitting (aplicar el weight de canary con hash determinista o sticky deliberado para A/B), política transversal (auth OIDC, rate limit y quota por tenant, redact PII pre-prompt, guardrails ligeros inline, propagación de tracing gen_ai.*) y failover/degradación (si v2 cae, redirigir a v1; si todo el cluster está saturado, devolver 503 con Retry-After en vez de encolar para siempre). La pieza no obvia que justifica su existencia técnica más allá de la operacional es el prefix-aware routing: el router decide a qué réplica de la flota va cada request en función del prefijo del prompt, para que un sistema RAG con el mismo system prompt + el mismo bloque de documentos recuperados acierte sistemáticamente en el prefix cache (RadixAttention en SGLang, PrefixCaching en vLLM, KV reuse en TensorRT-LLM) de la misma réplica, multiplicando el hit rate del 5–15 % (round-robin ciego) al 60–85 % (afinidad por prefix). Las piezas concretas en mayo 2026 son LiteLLM Proxy (la opción más simple, OpenAI-compatible, catálogo declarativo YAML), vLLM Production Stack router (específico para flotas vLLM, aware del KV cache y del prefix), Envoy AI Gateway (filtros Envoy LLM-aware, integrable con Istio), Kong AI Gateway (alternativa empresarial con plugin ecosystem), KGateway (CNCF en gestación) y NVIDIA Dynamo router (production-grade, aware de disaggregated serving prefill/decode). En el stack de siete capas vive en la capa 1 (gateway); en el de cinco niveles de madurez aparece a partir del nivel 3; en el ciclo de siete fases de despliegue es la última pieza que F6 cierra. Este post incluye un manifest mínimo aplicable a un cluster genérico de 4×H100 SXM.

Estás aquí: DEPLOY (capa 1 del stack)

El antecedente: lo que el post de canary llamaba “LoadBalancer”

En Canary, blue-green y shadow para modelos LLM describimos el flujo así: “el LoadBalancer reparte progresivamente el tráfico siguiendo un cronograma: 1 % → 5 % → 25 % → 100 %”. Era una descripción operacional correcta — el lector entendía la coreografía sin necesitar más. Pero técnicamente dejaba sin nombre a una pieza que merece tratamiento explícito, porque ninguno de los dos sentidos habituales de “LoadBalancer” hace lo que ese párrafo asumía:

Un LoadBalancer L4 —kube-proxy con iptables/IPVS, MetalLB, F5 BIG-IP en modo TCP— reparte paquetes IP sin mirar dentro del payload. No sabe qué modelo se pide, ni qué versión, ni cuántos tokens lleva, ni si el cliente tiene quota. No puede aplicar el weight del canary “para el modelo X versión 2”: para él todos los paquetes hacia el VIP vllm-llama70b son indistinguibles.
Un LoadBalancer L7 HTTP genérico —NGINX o HAProxy en modo HTTP sin extensión, una Service de tipo ClusterIP con backend múltiple— sí reparte por URL y puede hacer routing por header, pero no entiende el cuerpo OpenAI-compatible de la request. No sabe que {"model": "llama-70b", "messages": [...]} lleva en el campo model la clave de routing; no cuenta tokens; no aplica políticas sobre estructuras LLM; no hace prefix-aware routing porque eso exige parsear el messages y hashear el prefijo común.

La pieza que el post de canary asumía haciendo este trabajo es un router de inferencia L7 con awareness LLM. Una capa de pleno derecho, con su propia configuración, su propio CI/CD, sus propias métricas y sus propios pitfalls. Este post la nombra y la desmonta.

La analogía: la centralita y triage de un hospital con múltiples especialidades

Un hospital grande recibe pacientes que llegan a urgencias por puertas distintas y que necesitan especialidades distintas: traumatología, cardiología, pediatría, oncología. Hay tres modelos posibles de “puerta de entrada”.

Puerta única sin triage. Todos los pacientes esperan en la misma sala y los van pasando por orden de llegada al primer médico libre, sea su especialidad la que sea. Funciona en un consultorio de aldea con un único médico generalista. Cuando hay 200 pacientes al día y 12 especialidades, cae rápido en disfunción: el cardiólogo atiende esguinces, el pediatra atiende infartos, los recursos especializados se desperdician. Es el equivalente del LoadBalancer L4 — reparte cuerpos sin entender qué traen.

Puerta con receptionist que pregunta el síntoma. Una persona en mesa de entrada pregunta “¿qué le pasa?” y dirige al paciente al pasillo correcto. El cardiólogo ve solo cardiología, el pediatra solo niños. Mejor, pero el receptionist es lento, no calibra urgencias y no conoce el estado de las salas: puede mandar al cardiólogo del pasillo A cuando el del B está libre. Es el equivalente de un L7 HTTP genérico con path-based routing — reparte por categoría pero sin información del estado interno.

Triage profesional con awareness completo. Una enfermera de triage formada que conoce el catálogo de especialidades, sabe qué box está ocupado y cuál libre, recuerda al paciente recurrente cuyo expediente ya está abierto en el sistema (manda al mismo médico para continuidad), aplica política transversal (verifica cobertura del seguro, registra alérgenos, redirige a urgencias pediátricas si el paciente es menor) y, si la sala de cardiología cae por una avería del electrocardiograma, redirige al hospital del otro lado de la ciudad. Esta es la pieza que un hospital grande necesita. En LLM se llama router de inferencia.

La analogía sostiene hasta el último detalle, incluido el del “expediente ya abierto”: el paciente que vuelve al mismo médico es exactamente el cliente cuyo prompt comparte prefijo con el de hace 5 minutos. Si el router lo manda a la misma réplica, esa réplica todavía tiene el KV cache caliente y la request acierta el prefix cache. Si lo manda a una réplica distinta porque iba “la siguiente en round-robin”, el KV cache hay que reconstruirlo desde cero y la TTFT se va al doble. La enfermera de triage sabe esto. El LoadBalancer ciego no.

Las cuatro funciones del router de inferencia

Función 1 — Catálogo de modelos

El router mantiene un catálogo declarativo que mapea identidad de modelo a deployment concreto:

models:
 - name: "llama-70b" # alias estable
 version: "v2" # versión canary
 weight: 5 # 5% del tráfico
 endpoint: "vllm-llama70b-v2.inference.svc.cluster.local:8000"
 capabilities: [chat, tool_use]
 lifecycle: canary
 - name: "llama-70b"
 version: "v1"
 weight: 95
 endpoint: "vllm-llama70b-v1.inference.svc.cluster.local:8000"
 capabilities: [chat, tool_use]
 lifecycle: stable
 - name: "embedding-multilingual"
 version: "v1"
 weight: 100
 endpoint: "tei-bge-m3.inference.svc.cluster.local:8080"
 capabilities: [embeddings]
 lifecycle: stable

El cliente envía {"model": "llama-70b", "messages": [...]} sin saber que detrás hay dos pools de réplicas. El router resuelve. Si mañana migras de vLLM a SGLang para una versión concreta, el cliente no se entera; cambias el endpoint en el catálogo y listo.

Lo que se gana con este desacoplamiento es la libertad de mover topología sin romper clientes. Lo que cuesta es mantener disciplinada la convención de nombres (llama-70b siempre es el alias estable; llama-70b@v2 es la versión específica para canary). Sin esa disciplina, los aliases se ensucian con llama-70b-prod-fixed-real-final-v3 y el catálogo deja de ser navegable a las pocas semanas.

Función 2 — Traffic splitting

Las particiones del post de canary (1 % → 5 % → 25 % → 100 %) se materializan aquí, no en el motor de inferencia. El router calcula un hash determinista del request_id (o del user_id, si se quiere sticky) y lo mapea al rango de weights del catálogo. Para un weight [v1: 95, v2: 5], el 5 % del espacio hash cae en v2 y el 95 % en v1.

Tres decisiones de diseño que importan:

Hash por request_id aleatorio = muestreo independiente. Cada request es una observación independiente de la distribución v1 vs v2. Es el setting correcto para canary estadísticamente comparables.
Hash por user_id = sticky por usuario. El mismo cliente ve siempre el mismo pool. Útil para A/B testing con memoria conversacional persistida, pero rompe la comparabilidad estadística del canary porque las poblaciones de usuarios no son simétricas — pitfall explicado en el post anterior.
Hash por tenant_id = particionado fuerte. Tenant A va a v1, tenant B a v2. Es el patrón para clientes con SLA distintos o para validar v2 en un tenant interno antes de exponerlo a clientes externos.

Función 3 — Política transversal

Una vez por encima de todos los modelos, el router aplica:

Auth: OIDC con tokens JWT validados contra Keycloak / Authentik. Headers Authorization: Bearer ... traducidos a tenant_id y roles.
Rate limit: token bucket por tenant (X req/min) o por modelo (Y req/min para llama-70b porque es caro).
Quota: cuota mensual de tokens consumidos por tenant. El router cuenta gen_ai.usage.input_tokens + gen_ai.usage.output_tokens y rechaza con 429 Quota exceeded cuando se agota.
Redact PII pre-prompt: Presidio o Llama Guard en línea antes de que el prompt toque el modelo. Lo que el modelo no ve, no se entrena con ello, no se loguea, no se filtra.
Guardrails ligeros inline: PromptGuard 2, Llama Guard 4, Granite Guardian — los que aparecen en Guardrails y safety en LLMs— se ejecutan en el router porque su latencia (30–150 ms) cabe en el presupuesto de TTFT.
Propagación de tracing gen_ai.*: el router inicia el span padre, propaga traceparent al motor y emite los atributos gen_ai.system, gen_ai.request.model, gen_ai.request.version que el tracing OTel GenAI consume.
Semantic cache: para prompts repetidos exactos o con similitud semántica alta (embedding cosine > 0.97 contra cache previa), devuelve la respuesta cacheada sin tocar el motor. Ahorro típico en RAG con preguntas frecuentes: 20–40 % de las requests.

Función 4 — Failover y degradación

El router conoce el estado de salud de cada endpoint (health probes activos cada 5–15 s, latencia de TTFT recientes) y decide:

Si v2 devuelve 5xx persistente o no responde, circuit breaker abierto: el router redirige el tráfico que iba a v2 hacia v1 hasta que las probes vuelvan a verde. Esto es el rollback automático del canary en su forma más simple.
Si todo el cluster está saturado (todas las réplicas reportan num_requests_waiting > N durante T segundos), el router devuelve 503 Service Unavailable con Retry-After: 30 en vez de encolar para siempre. Mejor decirle al cliente “vuelve en 30 segundos” que tenerlo esperando 4 minutos y luego dar timeout.
Si hay multi-region o multi-cluster, failover cross-cluster vía DNS o L7: la región primaria cae, el router de la secundaria asume.

La pieza no obvia: prefix-aware routing

Esta es la función que un LoadBalancer convencional no puede hacer y que justifica un router específico de LLM más allá de las cuatro genéricas.

El KV cache de vLLM, SGLang y TensorRT-LLM puede reusar prefijos comunes entre requests —ver KV cache—. Concretamente:

vLLM con --enable-prefix-caching: detecta que la request actual comparte un prefijo (longitud múltiplo del block size, default 16 tokens) con una request anterior cuyas páginas todavía están en HBM, y reutiliza esas páginas en vez de reprocesarlas.
SGLang con RadixAttention: estructura el cache como un árbol radix indexado por tokens; cada request acierta el camino común del árbol y solo computa la cola.
TensorRT-LLM: feature similar, llamado KV cache reuse.

El hit rate del prefix cache es la métrica clave: cada token acertado es un token que no se procesa en prefill, reduciendo TTFT en proporción directa. Para un sistema RAG típico —system prompt de 400 tokens + documentos retrieved de 2 000 tokens + pregunta del usuario de 50 tokens— el prefijo común (system_prompt + docs) son 2 400 de los 2 450 tokens totales. Si el cache acierta, el prefill solo procesa 50 tokens en vez de 2 450: TTFT cae aproximadamente a la vigésima parte.

Pero el cache vive por réplica, no globalmente. Si dos requests con el mismo prefix de 2 400 tokens caen en réplicas distintas, ambas hacen el prefill completo: el cache de la primera no sirve a la segunda. La segunda paga el coste íntegro.

Con round-robin ciego (cualquier LB convencional), las requests se reparten uniformemente entre N réplicas. Para un cluster de 4 réplicas y 1 000 requests con el mismo system_prompt + docs, cada réplica recibe ~250 requests, pero las 4 hacen su propio “primer prefill” y los siguientes 249 se benefician dentro de su réplica. El hit rate global es decente pero no óptimo. Para tráfico con muchos sistemas prompts distintos y poca repetición intra-prefix, el hit rate ronda el 5–15 %.

Con prefix-aware routing, el router calcula un hash del prefijo del prompt (los primeros N tokens, o el system_prompt declarado en messages[0]) y mantiene una tabla de afinidad hash → réplica. Todas las requests con el mismo prefijo caen en la misma réplica. La primera paga el prefill completo; las 999 siguientes aciertan el cache. Hit rate global: 60–85 %.

El coste de implementarlo: el router debe parsear el body de la request (no solo el header HTTP), aplicar un tokenizer ligero o un hash basado en bytes, y mantener una tabla LRU/consistent-hash de afinidad que se rebalancea cuando una réplica entra o sale. Es trabajo de servidor, no de proxy genérico. vLLM Production Stack router lo implementa nativamente. NVIDIA Dynamo también. LiteLLM en su versión enterprise tiene un beta. Envoy AI Gateway lo está incorporando como filtro experimental.

La diferencia operativa para un RAG productivo: con prefix-aware routing, el mismo cluster sirve 2–4× más requests sin añadir GPUs, simplemente porque el prefill desaparece en la mayoría de los casos.

Token-aware load balancing

La segunda pieza no obvia. El round-robin clásico reparte por número de requests; pero un prompt de 50 tokens y otro de 8 000 tokens cuestan radicalmente distinto (factor ~160× en prefill). Repartir igualmente por count desequilibra severamente la carga real.

Token-aware load balancing suma tokens de prefill esperados (longitud del prompt) y decode esperados (max_tokens del cliente) por réplica activa, y manda la nueva request a la réplica con menor carga acumulada. Es lo que tanto vLLM Production Stack como NVIDIA Dynamo implementan como estrategia por defecto cuando se activa.

La métrica que alimenta el cálculo es —otra vez— vllm:num_requests_running y vllm:gpu_cache_usage_perc —ver Observabilidad GPU para inferencia LLM—, idealmente complementadas con un estimador de tokens del prompt entrante. Los routers maduros usan tiktoken o el tokenizer real del modelo para contar tokens del prompt antes de elegir réplica.

Comparativa de piezas concretas (mayo 2026)

Pieza	Awareness LLM	Prefix-aware	Token-aware LB	Multi-modelo	Semantic cache	Plug & play
LiteLLM Proxy	Alta	Beta (enterprise)	Sí	Excelente	Sí (Redis)	Muy alto
vLLM Production Stack router	Específico vLLM	Sí, nativo	Sí	Solo vLLM	No (externa)	Medio
NVIDIA Dynamo router	Alta + disagg-aware	Sí	Sí	vLLM/SGLang/TRT-LLM	No (externa)	Bajo
Envoy AI Gateway	Media (filtros)	Experimental	Sí	Sí	Vía filtro	Medio
Kong AI Gateway	Media (plugins)	No	Sí	Sí	Sí (plugin)	Medio
KGateway	Media	Roadmap	Sí	Sí	Roadmap	Bajo (CNCF gestación)
NGINX + custom Lua	Manual	No	Manual	Manual	No	Bajo (build it yourself)

LiteLLM Proxy es la opción por defecto para empezar. OpenAI-compatible, YAML simple, soporta los providers comerciales + cualquier OpenAI-compatible self-hosted. La versión OSS cubre las cuatro funciones básicas y semantic cache; el prefix-aware y la versión enterprise añaden multi-tenancy avanzado.

vLLM Production Stack router es la opción correcta si la flota es 100 % vLLM. Aware del KV cache, del prefix, del LoRA loaded por réplica. Integra mejor con métricas vLLM nativas.

NVIDIA Dynamo router es la opción production-grade más completa, especialmente si se opera disaggregated serving (prefill workers vs decode workers separados). Requiere stack NVIDIA-aligned.

Envoy AI Gateway y Kong AI Gateway son las opciones si la organización ya tiene Envoy/Kong como gateway corporativo y quiere extenderlo con LLM-awareness sin introducir otra pieza nueva.

Manifest mínimo: LiteLLM Proxy sobre cluster genérico

apiVersion: v1
kind: ConfigMap
metadata: { name: litellm-config, namespace: inference }
data:
 config.yaml: |
 model_list:
 - model_name: llama-70b
 litellm_params:
 model: openai/llama-70b
 api_base: http://vllm-llama70b-v1.inference.svc:8000/v1
 weight: 95
 model_info:
 version: v1
 lifecycle: stable
 - model_name: llama-70b
 litellm_params:
 model: openai/llama-70b
 api_base: http://vllm-llama70b-v2.inference.svc:8000/v1
 weight: 5
 model_info:
 version: v2
 lifecycle: canary
 - model_name: embedding-multilingual
 litellm_params:
 model: openai/bge-m3
 api_base: http://tei-bge-m3.inference.svc:8080
 router_settings:
 routing_strategy: least-busy # token-aware basic
 num_retries: 1
 timeout: 60
 general_settings:
 master_key: "os.environ/LITELLM_MASTER_KEY"
 database_url: "os.environ/DATABASE_URL"
 litellm_settings:
 cache: true
 cache_params:
 type: redis
 host: redis.inference.svc
 port: 6379
 similarity_threshold: 0.97
 success_callback: ["langfuse"]
 failure_callback: ["langfuse"]
---
apiVersion: apps/v1
kind: Deployment
metadata: { name: litellm-router, namespace: inference }
spec:
 replicas: 3
 selector: { matchLabels: { app: litellm } }
 template:
 metadata: { labels: { app: litellm } }
 spec:
 containers:
 - name: litellm
 image: ghcr.io/berriai/litellm:v1.55.0
 args: ["--config=/config/config.yaml", "--port=4000", "--num_workers=4"]
 ports: [{ containerPort: 4000, name: http }, { containerPort: 4000, name: metrics }]
 env:
 - { name: LITELLM_MASTER_KEY, valueFrom: { secretKeyRef: { name: litellm-secret, key: master_key } } }
 - { name: DATABASE_URL, valueFrom: { secretKeyRef: { name: litellm-secret, key: db_url } } }
 - { name: LANGFUSE_PUBLIC_KEY, valueFrom: { secretKeyRef: { name: langfuse-keys, key: public } } }
 - { name: LANGFUSE_SECRET_KEY, valueFrom: { secretKeyRef: { name: langfuse-keys, key: secret } } }
 volumeMounts: [{ name: config, mountPath: /config }]
 readinessProbe: { httpGet: { path: /health, port: 4000 } }
 volumes: [{ name: config, configMap: { name: litellm-config } }]
---
apiVersion: v1
kind: Service
metadata: { name: litellm-router, namespace: inference }
spec:
 selector: { app: litellm }
 ports: [{ name: http, port: 80, targetPort: 4000 }]
---
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata: { name: litellm-metrics, namespace: inference }
spec:
 selector: { matchLabels: { app: litellm } }
 podMetricsEndpoints:
 - port: metrics
 path: /metrics
 interval: 15s

El cliente final apunta a litellm-router.inference.svc:80/v1/chat/completions, pone model=llama-70b, y el router decide en cada request si va a v1 (95 %) o v2 (5 %), aplica el rate limit, busca en semantic cache, propaga tracing a Langfuse, y traduce de OpenAI-compatible a OpenAI-compatible del vLLM de destino. Tres réplicas del router para HA y para que el propio gateway escale horizontalmente con KEDA si hace falta —ver Autoscaling LLM en Kubernetes—.

Cuatro pitfalls operacionales

Pitfall 1 — el router se convierte en SPoF si no se replica. Tres o más réplicas del propio router, detrás de un Service LoadBalancer (este sí, L4) con healthchecks. Una sola réplica del router significa que cada deploy de la configuración cierra el servicio entero unos segundos.

Pitfall 2 — la latencia del router se suma a la del modelo. Cada función añade milisegundos: parsing del body (5–10 ms), auth JWT (2–5 ms), rate limit (1–2 ms), redact PII con Presidio (20–80 ms), guardrails con Llama Guard inline (50–150 ms), prefix hash (5–10 ms), token counting con tokenizer (10–30 ms). En total 100–300 ms de overhead antes de tocar el motor. Si el TTFT del modelo es 400 ms y el del router 200 ms, el cliente ve 600 ms — vale la pena medir cuánto cuesta cada función y desactivar las no críticas en el path de baja latencia.

Pitfall 3 — el catálogo deriva del estado real del cluster. El router cree que vllm-llama70b-v2 existe porque está en su YAML, pero el deployment fue retirado hace tres días y nadie actualizó el config. El router devuelve 502 en el 5 % del tráfico. Solución: validar el catálogo contra kubectl get svc en CI; ningún endpoint del catálogo puede apuntar a un Service inexistente. O mejor: el router descubre dinámicamente los endpoints disponibles vía label selector (app=vllm,model=llama-70b) y aplica weights del catálogo sobre los que están vivos.

Pitfall 4 — semantic cache con embedding outdated. El semantic cache compara embedding del prompt nuevo contra embeddings de prompts cacheados. Si actualizas el modelo de embeddings (ver RAG corpus curation), las distancias se calculan en un espacio distinto y el cache deja de funcionar correctamente (falsos hits o falsos misses). Política: el cache se invalida al cambiar el modelo de embeddings; nunca se mezclan generaciones.

Encaje en el stack y la madurez

En el stack de siete capas, el router es la capa 1: la puerta de entrada que precede al motor de inferencia (capa 2), al KV cache + PagedAttention (capa 3) y al resto. Es la única pieza que ve todo el tráfico desde fuera; cualquier política que no se aplique aquí, se duplica N veces en los motores.

En los cinco niveles de madurez, el router aparece a partir del nivel 3 (GESTIONADO): sin OIDC + RBAC + cert-manager + NetworkPolicy default deny, el router no tiene a quien autenticar ni a quien aplicar quotas; antes del nivel 3 lo que toca es montar un proxy mínimo sin pretensión de catálogo. Plataformas que intentan tener router pulido en nivel 1 acaban con un yaml grande que nadie mantiene.

En las siete fases de despliegue, el router es lo que cierra F6: el último paso atómico que pone al cluster en producción. Sin router, F6 no termina — el catálogo, las quotas, los canaries y los failovers son condición necesaria para abrir tráfico productivo.

Aplicado a hardware on-premise típico

Para un cluster genérico de 4 nodos × 4×H100 SXM 80 GB, el router de inferencia consume recursos modestos: 3 réplicas del router-pod (CPU 2 cores, memoria 4 GiB cada una) bastan para soportar miles de RPS porque su trabajo es ligero (parsing, hashing, routing, no inferencia). El router vive en nodos no-GPU del cluster (nodos de control plane o de workload general), nunca consume nvidia.com/gpu.

Volumen de tráfico que un LiteLLM con 3 réplicas y 4 workers cada una sostiene: 2 000–5 000 RPS routing a backend vLLM, con overhead de 80–150 ms en path completo (auth + rate limit + cache check + propagación). Si se necesita más, escalar el router con KEDA sobre litellm:requests_per_second es trivial.

Para clusters más grandes (16+ nodos GPU), considerar vLLM Production Stack router o NVIDIA Dynamo router que son más complejos pero exprimen el prefix-aware routing y el token-aware LB que LiteLLM OSS no cubre. Para clusters multi-region, Envoy AI Gateway con Istio Service Mesh es la elección estándar.

Lo que no hemos cubierto (próximos artículos)

Comparativa profunda LiteLLM vs vLLM PStack vs Dynamo con benchmarks de prefix-aware sobre cluster on-premise real.
Semantic cache con Redis Stack + RedisVL: hit rate, falsos positivos, política de TTL.
Multi-region routing: cómo el router decide entre clúster DC1 y DC2 según latencia, salud y carga.
AI Gateway specific features: token-bucket cost-based rate limiting (penaliza prompts largos), guardrails policy engine en el router.
Migration path: cómo introducir un router en un cluster que ya tiene clientes apuntando directo al servicio vLLM, sin downtime.

Ver también

Canary, blue-green y shadow para modelos LLM — el post anterior donde llamamos “LoadBalancer” a esta pieza; este post la nombra y la desmonta.
Siete capas del stack de inferencia LLM on-premise — el router es la capa 1 del stack.
Cinco niveles de madurez — el router aparece a partir del nivel 3.
Siete fases de despliegue — el router es lo que cierra F6.
Autoscaling LLM en Kubernetes — el router puede escalar con KEDA sobre sus propias métricas; convive con el autoscaling de los motores.
Observabilidad GPU para inferencia LLM — el token-aware LB consume vllm:num_requests_running y vllm:gpu_cache_usage_perc para decidir réplica.
KV cache — qué cachea el prefix-aware routing y por qué multiplica el hit rate.
Disaggregated serving prefill/decode — los routers production-grade (Dynamo) son aware de la disaggregation y rutean prefill y decode a pools distintos.
Tracing LLM con OpenTelemetry GenAI — el router emite los spans padre gen_ai.* y propaga traceparent a los motores.
Guardrails y safety en LLMs — los guardrails ligeros inline se ejecutan típicamente en el router.
Entornos mixtos NVIDIA + Intel para inferencia LLM — el router por capability cobra todo su sentido cuando hay backends heterogéneos (NVIDIA para LLM grande, Intel para embeddings/reranker, NUC para edge); el catálogo se extiende con backend y region.

Referencias

LiteLLM project — litellm.ai (documentación de Proxy, routing strategies, semantic cache).
vLLM Production Stack — github.com/vllm-project/production-stack (router con prefix-aware nativo).
NVIDIA Dynamo — developer.nvidia.com/blog/nvidia-dynamo-1-production-ready/ (router production-grade con disaggregated-aware).
Envoy AI Gateway — gateway.envoyproxy.io/docs/tasks/ai-gateway/ (proyecto en gestación dentro de Envoy).
Kong AI Gateway — konghq.com/products/kong-ai-gateway (proxy enterprise con plugin LLM).
KGateway — kgateway.dev (alternativa CNCF en gestación).
Zheng et al. — SGLang: Efficient Execution of Structured Language Model Programs (NeurIPS 2024) — RadixAttention y prefix caching.
vLLM project — Automatic Prefix Caching (docs.vllm.ai/en/latest/features/automatic_prefix_caching.html).
Patel et al. — SplitWise: Efficient Generative LLM Inference Using Phase Splitting (ISCA 2024) — base teórica del routing prefill/decode aware.

LLM Guard: el traductor jurado con cuaderno de equivalencias — anatomía, scanners y su integración con Langfuse, vLLM y LiteLLM

Mon, 01 Jun 2026 05:00:00 +0200

Este post es deep-dive de una sola pieza dentro de la capa cubierta en el post sobre guardrails y safety LLM. Aquel mapea las cuatro líneas de defensa (input, retrieval, tool, output) y el catálogo OSS 2026 a vista de pájaro; éste baja al ras de LLM Guard porque su patrón Anonymize/Deanonymize, su modelo de scanners composables y sus cuatro modos de despliegue merecen tratamiento propio. Las analogías que se construyeron arriba (cocina HACCP, cuatro CCP) siguen valiendo: este post amplía el zoom sobre la herramienta que ocupa el cinturón de PII y de scanners individuales dentro de esa arquitectura.

TL;DR

LLM Guard es la herramienta OSS (MIT, Protect AI) que materializa la capa de guardrails LLM con un modelo radicalmente distinto al de NeMo Guardrails y al de Guardrails AI: en lugar de un DSL declarativo (Colang) o de un framework de validators con LLM-as-judge externos, ofrece un catálogo de detectores compactos especializados —15 input scanners, 21 output scanners— componibles como pipeline Python, con un mecanismo único distintivo: el patrón Anonymize → LLM → Deanonymize con Vault. El Vault es un almacén centralizado del mapping entre entidades reales (John Doe, 12345678X) y placeholders ([REDACTED_PERSON_1], [REDACTED_DNI_1]); en input, las entidades se redactan y el mapping se guarda; el LLM nunca ve datos personales reales; en output, el Deanonymize scanner restituye los originales antes de devolver la respuesta al usuario. Este post desmonta: la anatomía interna (Vault + scanners + orquestador con fail_fast y caché TTL), los cuatro patrones de despliegue con sus matemáticas (librería in-process, API FastAPI, sidecar OTel sobre vLLM, plugin de AI Gateway — LiteLLM, Envoy AI Gateway, Kong AI Gateway), los diagramas de integración con Langfuse (vía OTel HTTP exporter de LLM Guard + langfuse.score() desde el AI Gateway), las matemáticas con benchmarks del proyecto (Anonymize en 177 ms CPU → 128 ms ONNX-CPU → 125 ms GPU FP16 → 38 ms GPU+ONNX, escalado x4.6 cuando combinas ONNX + GPU), el patrón ONNX como aceleración por defecto sin GPU dedicada, la comparativa con NeMo Guardrails (DSL Colang declarativo orientado a flujo conversacional) y Guardrails AI (validators tipo contrato JSON con judges externos), la aplicación a hardware on-premise (qué scanners aguantan CPU, cuáles necesitan GPU compartida) y las siete trampas operativas específicas de la herramienta.

La analogía: el traductor jurado con cuaderno de equivalencias

Un traductor jurado serio que trabaja con documentos sensibles —un contrato laboral, una historia clínica, una declaración fiscal— no envía el texto crudo al traductor automático que tiene en la nube. Lleva un cuaderno de equivalencias abierto sobre la mesa. Cuando recibe el documento original, abre el cuaderno y va apuntando: “Marta García” → [PERSONA-1], “12345678X” → [DNI-1], “ES91 2100 0418…” → [IBAN-1]. Sustituye cada aparición en el texto por su etiqueta y pasa el texto anonimizado al servicio de traducción. El servicio devuelve una traducción que sigue conteniendo las etiquetas. El traductor abre de nuevo el cuaderno, restituye cada etiqueta por su valor original, y entrega al cliente la traducción final con la PII intacta. Para el servicio de traducción, esos datos personales nunca existieron: sólo vio placeholders.

Esta es la operación exacta que define el carácter de LLM Guard frente al resto del ecosistema. NeMo Guardrails resuelve safety con un grafo declarativo de reglas en Colang; Guardrails AI con validators que invocan a un LLM-as-judge para verificar contratos; LLM Guard con un catálogo de detectores compactos especializados + el patrón Vault. Los tres son válidos en distintos escenarios. La elección no es de gusto: es estructural según cómo se construye el sistema y dónde está el cuello.

El traductor también revisa, claro, que el texto no contenga otros problemas además de la PII: insultos, instrucciones para reprogramarse, links a páginas hostiles, código que no debería estar ahí. Para eso tiene el resto del catálogo de scanners. Pero la firma de la casa, lo que la distingue, es ese cuaderno.

Anatomía interna de LLM Guard

Las tres piezas estructurales son:

1. El orquestador (scan_prompt, scan_output). Recibe una lista de scanners en orden y los ejecuta secuencialmente sobre el texto. Devuelve la terna (sanitized_text, results_valid, results_score) donde:

sanitized_text es el texto transformado por los scanners que mutan (Anonymize, BanSubstrings con redaction).
results_valid es un dict {scanner_name: bool} indicando qué scanners pasaron.
results_score es un dict {scanner_name: float} con el risk score reportado (0 limpio, 1 violación máxima).

Soporta fail_fast=True para cortar tras el primer fail. Soporta timeout por scanner para no bloquearse en un detector lento. Cuando se expone como API FastAPI, soporta caché TTL para evitar reescanear prompts repetidos (caso de bots con preguntas idénticas).

2. El catálogo de scanners. Quince input scanners y veintiún output scanners, cada uno con su propio modelo backend y su umbral configurable:

Familia	Input	Output	Backend dominante
PII	Anonymize	Deanonymize, Sensitive	Presidio + BERT-NER
Inyección y jailbreak	PromptInjection	—	DeBERTa fine-tuned (Protect AI propio)
Toxicidad y bias	Toxicity, Sentiment	Toxicity, Bias, Sentiment	RoBERTa / BERT fine-tuned
Tópicos prohibidos	BanTopics, BanCompetitors	BanTopics, BanCompetitors	Zero-shot classifier BART-MNLI
Substrings y regex	BanSubstrings, Regex	BanSubstrings, Regex	string matching + regex
Secrets	Secrets	—	detect-secrets (Yelp) + regex
Estructura	TokenLimit, Language, InvisibleText, Gibberish	JSON, Language, LanguageSame, Gibberish, ReadingTime	tokenizer, lang-detect, JSON schema
Código	BanCode, Code	BanCode, Code	classifier de lenguaje + regex
URLs	—	MaliciousURLs, URLReachability	block-list + DNS lookup
Calidad de respuesta	—	NoRefusal, Relevance, FactualConsistency	NLI-cross-encoder + cosine similarity

Cada scanner se importa y se instancia individualmente, con su umbral propio:

from llm_guard.input_scanners import Anonymize, PromptInjection, Toxicity, Secrets
from llm_guard.vault import Vault

vault = Vault()
scanners = [
 Anonymize(vault, threshold=0.5),
 PromptInjection(threshold=0.85),
 Toxicity(threshold=0.7),
 Secrets(),
]

3. El Vault. Pieza única no encontrada en NeMo Guardrails ni en Guardrails AI con el mismo modelo. Es un diccionario in-memory por sesión o request que guarda el mapping placeholder → valor_original. Lo escribe el scanner Anonymize en input y lo lee el scanner Deanonymize en output. Si el Vault es compartido entre múltiples requests del mismo usuario, el mapping persiste (útil para conversaciones multi-turno). Si es por request, se descarta tras la respuesta.

El Vault básico es dict Python; para entornos distribuidos con múltiples pods, se sustituye por un Redis sticky (mismo usuario → mismo pod) o por un Vault custom que lea/escriba a un Redis externo, descartado tras un TTL. Esto es operacional, no de la librería core.

El flujo Anonymize → LLM → Deanonymize en detalle

El patrón canónico de uso de LLM Guard se descompone en seis pasos exactos:

1. Recibir prompt del usuario:
"Mi nombre es Marta García y mi IBAN es ES9121000418450200051332,
¿podéis revisar el cargo del 14 de marzo?"
2. scan_prompt() con [Anonymize(vault), PromptInjection(), Toxicity()]
→ Anonymize redacta entidades y las guarda en vault:
vault["[REDACTED_PERSON_1]"] = "Marta García"
vault["[REDACTED_IBAN_1]"] = "ES9121000418450200051332"
→ PromptInjection comprueba que no haya jailbreak (no lo hay)
→ Toxicity comprueba que no haya insultos (no los hay)
→ results_valid = {Anonymize: True, PromptInjection: True, Toxicity: True}
→ sanitized_prompt:
"Mi nombre es [REDACTED_PERSON_1] y mi IBAN es [REDACTED_IBAN_1],
¿podéis revisar el cargo del 14 de marzo?"
3. Llamar al LLM con sanitized_prompt:
→ vLLM recibe el prompt sin PII real
→ genera respuesta:
"Sí, [REDACTED_PERSON_1], voy a revisar el cargo en la cuenta
[REDACTED_IBAN_1]. ¿Puedes confirmar el importe?"
4. scan_output() con [Deanonymize(vault), Toxicity(), Relevance(), Sensitive()]
→ Deanonymize sustituye placeholders por valores del vault:
[REDACTED_PERSON_1] → "Marta García"
[REDACTED_IBAN_1] → "ES9121000418450200051332"
→ Toxicity comprueba que la respuesta no sea ofensiva
→ Relevance comprueba que responde al prompt
→ Sensitive comprueba que no aparezca PII no autorizada
(en este caso, la PII restituida está autorizada porque la trajo
el propio usuario y la firma el Vault → la regla aplica solo a
PII nueva inventada por el LLM)
→ sanitized_response:
"Sí, Marta García, voy a revisar el cargo en la cuenta
ES9121000418450200051332. ¿Puedes confirmar el importe?"
5. Devolver al usuario sanitized_response.
6. Si la sesión sigue, el vault persiste y los próximos turnos reutilizan
los mismos placeholders. Cuando termina la sesión, el vault se descarta.

Tres detalles que importan operativamente:

Las entidades persistentes ([REDACTED_PERSON_1] para “Marta García”) se mantienen constantes durante la sesión. Si el usuario menciona otra persona (“hablé con Juan Pérez”), Anonymize asignará [REDACTED_PERSON_2]. La coherencia inter-turno la asegura el Vault.
El LLM nunca ve los datos originales durante la sesión. Esto es la propiedad clave para casos donde el LLM se sirve desde un modelo en cloud o cuando se loguea el prompt (Langfuse, OTel) sin acceso confidencial.
El logging de LLM Guard registra los placeholders, no los valores originales. Para auditoría con valores originales hace falta una capa adicional (acceso al Vault con permisos privilegiados) — esto es por diseño, no por defecto.

Cuatro modos de despliegue

Modo 1 — Librería Python in-process

El más simple: pip install llm-guard, importar los scanners en el código de la aplicación, llamar a scan_prompt/scan_output directamente. Los modelos se cargan en el proceso. La ventaja es latencia mínima; la desventaja es que cada réplica de la aplicación carga sus propios modelos en memoria.

# en el servidor de la app
from llm_guard import scan_prompt, scan_output
from llm_guard.input_scanners import Anonymize, PromptInjection, Toxicity
from llm_guard.output_scanners import Deanonymize, Toxicity as OutToxicity, Relevance
from llm_guard.vault import Vault

vault = Vault()
input_scanners = [Anonymize(vault), PromptInjection(), Toxicity()]
output_scanners = [Deanonymize(vault), OutToxicity(), Relevance()]

# en el handler de la request
sanitized_prompt, valid_in, score_in = scan_prompt(input_scanners, user_prompt)
if not all(valid_in.values()):
 return error_response(score_in)

response = vllm_client.complete(sanitized_prompt)

sanitized_resp, valid_out, score_out = scan_output(output_scanners, sanitized_prompt, response)
if not all(valid_out.values()):
 return error_response(score_out)

return sanitized_resp

Encaja con el patrón A (sidecar) del post de guardrails cuando la app y el sidecar comparten proceso. Y con el patrón C (in-process) si la app es directamente la capa de inferencia.

Modo 2 — API FastAPI propia

El proyecto incluye un servidor FastAPI listo (llm-guard-api) que expone los scanners detrás de dos endpoints REST:

POST /analyze/prompt
body: {"prompt": "...", "scanners": [...] (opcional)}
response: {"sanitized_prompt": "...", "is_valid": bool, "scanners": {scanner: {is_valid, risk_score}}}
POST /analyze/output
body: {"prompt": "...", "output": "...", "scanners": [...]}
response: análoga

Configuración por config/scanners.yml con variables de entorno (SCAN_FAIL_FAST, CACHE_MAX_SIZE, CACHE_TTL, SCAN_PROMPT_TIMEOUT…). Lleva métricas Prometheus en /metrics y traces OTel HTTP exporter por defecto.

Encaja con el patrón B (servicio centralizado tras AI Gateway) del post de guardrails.

Modo 3 — Sidecar OTel sobre el pod del motor de inferencia

Para deployments de vLLM en Kubernetes, una variante del modo 2 es desplegar la API de LLM Guard como sidecar container en el mismo pod del vLLM, hablando por localhost. El AI Gateway delante invoca al sidecar antes y después de la inferencia. El OTel collector del nodo agrega los spans de vLLM con los spans gen_ai.guardrail.* de LLM Guard automáticamente porque comparten trace_id propagado por baggage HTTP.

Esto encaja con el patrón A (sidecar) del post de guardrails, pero con la disciplina de la API REST para no acoplar lenguaje (el AI Gateway puede ser Envoy en C++, LLM Guard en Python).

Modo 4 — Plugin dentro de un AI Gateway

Tres AI Gateways soportan LLM Guard como plugin nativo en 2026:

LiteLLM Proxy (MIT, BerriAI) — plugin llm_guard activable en config con guardrails: ["llm_guard"]. Llama internamente a la API.
Envoy AI Gateway (CNCF, Apache 2.0) — filtro ai-guardrails con backend pluggable apuntando al servicio LLM Guard.
Kong AI Gateway (Apache 2.0) — plugin ai-proxy con post-procesador que invoca LLM Guard.

En los tres casos, el AI Gateway es el punto único de entrada de la app cliente al LLM; el gateway llama a LLM Guard antes/después de pasar al motor de inferencia. Ventaja: lock-in cero en el código de la aplicación; cambiar de LLM Guard a NeMo Guardrails es cambiar el plugin del gateway, no reescribir la app. Desventaja: el hop adicional añade latencia (típicamente 5-15 ms intra-cluster).

Integración gráfica con Langfuse, vLLM y el stack OTel

Las tres rutas de integración con Langfuse que importan operativamente:

Ruta A — OTel HTTP exporter de LLM Guard. LLM Guard tiene exporter OTel HTTP nativo. Configurando OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=https://langfuse.cluster/api/public/otel, los spans gen_ai.guardrail.* que emite cada scanner llegan directamente a Langfuse y aparecen como spans hijos del span LLM principal (siempre que el trace_id se propague vía baggage HTTP desde el AI Gateway). Esta es la ruta canónica en 2026.

Ruta B — Langfuse scoring API desde el AI Gateway. El AI Gateway (LiteLLM, Envoy AI, Kong AI), al recibir la respuesta de LLM Guard con los risk_score por scanner, emite una llamada langfuse.score(trace_id, name="guardrail.PromptInjection", value=0.87, comment="blocked") por cada scanner. En Langfuse aparece como scores enganchados al mismo trace que la inferencia. Permite dashboards “bloqueos por categoría” y series temporales por scanner. Es complementaria a la ruta A: la A trae los spans, la B trae el score numérico fácil de agregar en SQL.

Ruta C — Sessions de Langfuse + Vault metadata. En modo conversacional, el AI Gateway propaga langfuse_session_id al Vault como su clave. Cuando un usuario tiene una sesión multi-turno, Langfuse muestra la traza completa de la sesión, con los placeholders que se reutilizan turno a turno. La PII original sigue sin viajar a Langfuse — sólo los placeholders y sus categorías.

El OTel Collector del nodo es el pegamento: recibe spans de vLLM (por OpenLLMetry o instrumentación nativa), de LLM Guard (por su exporter OTel) y del AI Gateway (instrumentación HTTP estándar), los une por trace_id, y los envía paralelamente a Langfuse (vía OTLP HTTP) y a Tempo/Jaeger. Las métricas Prometheus de LLM Guard van a VictoriaMetrics por scraping normal. Grafana ofrece la vista unificada para investigación cross-trace; Langfuse ofrece la vista LLM-céntrica con sessions y scores. El post sobre tracing OTel GenAI detalla la mecánica completa del Collector.

Las matemáticas que importan

Latencia por scanner — los números reales

El proyecto publica benchmarks reproducibles. Para el scanner Anonymize (input length 317 chars, batch 5), los datos de referencia son:

Plataforma	Backend	Latencia avg	p99	QPS
AWS m5.xlarge (CPU)	Transformers	177 ms	326 ms	1.789
AWS m5.xlarge (CPU)	ONNX runtime	128 ms	180 ms	2.464
AWS r6a.xlarge (AMD CPU)	Transformers	244 ms	284 ms	1.298
AWS g5.xlarge (NVIDIA A10G)	Transformers FP16	125 ms	498 ms	2.532
AWS g5.xlarge (A10G)	ONNX + GPU	38 ms	99 ms	8.317

Tres observaciones operativas:

ONNX siempre gana. Incluso en CPU, ONNX baja el avg de 177 a 128 ms (factor 1,4×). En GPU con ONNX, baja de 177 a 38 ms (factor 4,6×). La regla práctica: siempre exportar el modelo del scanner a ONNX antes de producción. La preview del SaaS oficial lo usa por defecto.
GPU sin ONNX no rinde tanto como uno espera. Una A10G sin ONNX (125 ms) es comparable a m5.xlarge con ONNX (128 ms). La GPU sola no compensa si el grafo de inferencia no está optimizado. El binomio relevante es ONNX + GPU.
La latencia p99 sin ONNX explota. En GPU sin ONNX, el p99 de 498 ms triplica el avg de 125 ms — colas y batching producen tail latencies altas. Con ONNX, el ratio p99/avg cae a 2,6× (99/38), mucho más predecible.

Para una capa de guardrails con cinco scanners ejecutados secuencialmente (Anonymize, PromptInjection, Toxicity, Secrets, BanTopics), la suma del p99 es lo que determina el budget de la línea 1 (input). Cinco scanners a ~100 ms p99 cada uno = 500 ms p99 acumulado — fuera de presupuesto para chat interactivo. Con ONNX bajamos a ~50 ms cada uno = 250 ms p99 — manejable. Con fail_fast=True, el tiempo esperado es menor (el más probable es que pasen los más baratos y fallen los caros sólo si se ejecutan).

Para un cálculo más fino, la latencia esperada del pipeline con fail_fast es:

[ \mathbb{E}[L] = \sum_{i=1}^{N} L_i \cdot \prod_{j=1}^{i-1} p_j ]

donde (L_i) es la latencia del scanner (i) y (p_j) la probabilidad de que el scanner (j) devuelva válido. En tráfico bien comportado (la mayoría de prompts pasan todos los scanners), (\prod p_j \approx 1) y la fórmula colapsa a la suma directa. En tráfico adversarial, los scanners más rápidos al principio del pipeline cortan antes y la latencia esperada baja drásticamente.

Coste computacional por scanner

El tamaño del modelo backend determina el coste y la posibilidad de correr en CPU vs requerir GPU:

Scanner	Modelo backend típico	Parámetros	VRAM FP16 / ONNX-INT8	CPU viable
Anonymize (BERT-NER)	dslim/bert-base-NER	110 M	220 MB / 55 MB	Sí (con ONNX)
Anonymize (BERT-large)	dslim/bert-large-NER	335 M	670 MB / 170 MB	Sí pero lento (~500 ms CPU)
PromptInjection	DeBERTa-v3-base fine-tuned	184 M	370 MB / 90 MB	Sí (con ONNX)
Toxicity	unitary/toxic-bert	110 M	220 MB / 55 MB	Sí
Sentiment	distilbert-sst2	67 M	130 MB / 35 MB	Sí
Gibberish	small distilbert	67 M	130 MB / 35 MB	Sí
BanTopics	BART-MNLI zero-shot	407 M	815 MB / 200 MB	Lento en CPU (~400 ms)
Bias (output)	RoBERTa-bias	125 M	250 MB / 65 MB	Sí
FactualConsistency	cross-encoder/nli-deberta	184 M	370 MB / 90 MB	Sí
Relevance	sentence-transformers	110 M	220 MB / 55 MB	Sí
TokenLimit, Regex, JSON, BanSubstrings, Secrets	(sin modelo)	—	0	Trivial

Patrón razonable on-premise: scanners sin modelo (TokenLimit, Regex, BanSubstrings, Secrets) corren en CPU sin pestañear. Anonymize, PromptInjection, Toxicity, Sentiment, Relevance corren cómodamente en CPU con ONNX-INT8 con ~50-150 ms p99. BanTopics y los basados en cross-encoder grandes (FactualConsistency) son los candidatos a vivir en una GPU compartida si quieres p99 < 100 ms.

Throughput de la API en cluster

Una instancia de la API FastAPI con 4 workers Uvicorn sobre un nodo con 8 vCPUs alcanza ~600-1.200 RPS sobre un pipeline típico de 5 scanners en CPU + ONNX. Para escalar:

Horizontal: replicar pods detrás de un Service ClusterIP — escalado lineal porque los scanners son stateless (excepto el Vault, que es por sesión y se externaliza a Redis si se quiere sticky o compartido).
Vertical con GPU: 1 H100 sirve ~5.000-10.000 RPS con todos los scanners en ONNX-GPU. Es overkill para la mayoría de deployments excepto en multi-tenant con miles de QPS sostenidos.

La regla práctica del post sobre guardrails (1 GPU guardrails por 4-8 GPUs LLM) se mantiene aquí: con cluster 4×H100 SXM sirviendo Llama 70B en TP=4, una L4 o RTX 4090 dedicada al servicio LLM Guard cubre la carga.

Comparativa con NeMo Guardrails y Guardrails AI

Las tres herramientas resuelven el mismo problema desde tres modelos arquitectónicos distintos. La elección entre ellas no es de calidad —las tres están maduras—, es de encaje con el resto del stack:

Dimensión	LLM Guard	NeMo Guardrails	Guardrails AI
Modelo conceptual	Pipeline de scanners compactos	Grafo declarativo Colang (flujo conversacional)	Validators tipo contrato JSON
Detección dominante	Modelos ML especializados (BERT, DeBERTa) por categoría	Reglas + LLM-as-judge	Validators heurísticos + LLM-as-judge externo
PII workflow	Anonymize + Vault + Deanonymize	Vía Presidio integrado, sin Vault built-in	Validators de PII, sin restitución automática
Licencia	MIT	Apache 2.0	Apache 2.0 (+ Hub paid)
Lenguaje	Python	Python + Colang DSL	Python
Madurez API	API FastAPI built-in, OTel built-in	Server FastAPI built-in, OTel parcial	API server externo
Despliegue cluster	Lib + API + sidecar + plugin gateways	Lib + server	Lib + server + Hub SaaS
Latencia típica (5 scanners ONNX-GPU)	50-200 ms	100-500 ms (más si hay LLM judge)	100-300 ms (depende del validator)
Cuándo brilla	Apps con PII fuerte, multi-tenant con sesiones, requisitos GDPR/HIPAA	Sistemas conversacionales con flujos definidos, agentes con dialog policy	Apps con contratos JSON estrictos, structured output con validación adicional
Cuándo no encaja	Si necesitas dialog policy declarativa	Si quieres detectores compactos sin LLM judge	Si quieres Vault y Deanonymize automático

Los tres son complementarios en deployments grandes. Un patrón maduro en 2026 es:

NeMo Guardrails orquesta el flujo de diálogo (qué tools puede invocar el agente, en qué orden, con qué cooldowns).
LLM Guard ocupa la línea de PII + scanners compactos en input y output, con su Vault haciendo el trabajo sucio de anonimización.
Guardrails AI valida outputs estructurados (JSON Schema, function calling) con sus validators.

La separación de responsabilidades evita el solapamiento y permite cambiar piezas sin reescribir todo. Las tres exponen API FastAPI y emiten spans OTel; el AI Gateway las orquesta secuencialmente.

Aplicado a hardware on-premise

En la RTX 4090 (24 GB)

Una 4090 dedicada al pod del servicio LLM Guard sirve cómodamente el pipeline completo en producción media:

Anonymize (BERT-NER ONNX-INT8): ~50 MB VRAM.
PromptInjection (DeBERTa ONNX-INT8): ~90 MB.
Toxicity, Sentiment, Gibberish: ~150 MB total.
BanTopics (BART-MNLI ONNX-INT8): ~200 MB.
Bias, Relevance, FactualConsistency (output): ~250 MB total.

Total ~750 MB. Resto de la VRAM ociosa o aprovechable para batching agresivo. Throughput sostenido a 3.000-6.000 RPS sobre el pipeline completo. Para deployments con < 500 RPS sostenidos, la 4090 está sub-utilizada y se puede compartir con otra carga (embeddings de RAG, reranker BGE).

En el cluster 4×H100 SXM (320 GB total, NVLink)

Sobra capacidad por orden de magnitud. Patrón razonable:

3 H100 sirviendo el LLM principal en TP=3 (Llama 70B FP8).
1 H100 dividida en MIG instances (1g.10gb o similar) — una porción para LLM Guard (~10 GB MIG es más que suficiente), otra para el reranker, otra para embeddings.

Throughput agregado para LLM Guard a esa escala: 15.000-30.000 RPS. Sobra para multi-tenant grande con sesiones largas.

Las trampas operativas específicas

Trampa 1 — Vault sin TTL. El Vault crece sin freno si no se limpia. En modo lib in-process por request, no hay problema (el objeto se destruye). En modo servicio centralizado con Redis, falta poner TTL y el Redis se llena. Trampa silenciosa que se descubre cuando el pod de Redis OOM-killea en producción a las 6 semanas.

Trampa 2 — Vault no compartido entre pods + AI Gateway sin sticky session. Si el AI Gateway distribuye round-robin entre múltiples pods de LLM Guard, el Vault local de un pod no sabe del mapping creado por otro. Resultado: en el turno 2 de una sesión, el Deanonymize no encuentra los placeholders del turno 1 y deja [REDACTED_PERSON_1] literal en la respuesta. Solución: Vault Redis compartido o sticky session por user_id.

Trampa 3 — Modelos no exportados a ONNX en producción. Se despliega con la config por defecto (Transformers) y la latencia es 3-5× peor que la que reportan los benchmarks. Equipo asume que LLM Guard “es lento”. La solución es exportar a ONNX (built-in en el proyecto) y configurar recognizer_conf con la ruta al .onnx del modelo.

Trampa 4 — fail_fast=False con muchos scanners. Sin fail_fast, todos los scanners corren siempre, incluso si el primero ya bloqueó. Latencia 3-5× peor en tráfico adversarial. Para producción, salvo razón explícita (querer métricas completas por scanner aun bloqueando), fail_fast=True es el default razonable.

Trampa 5 — cache_ttl infinito + prompts con PII variable. Si la caché de la API guarda el sanitized_prompt indefinidamente, dos sesiones distintas con misma estructura de prompt pero diferentes PII pueden colidir si la clave de caché no incluye el Vault hash. Hay que verificar que la clave de caché incluya o bien el contenido completo (sin PII) o un hash del prompt original.

Trampa 6 — Logs estructurados con PII original. Los logs stdout JSON de LLM Guard registran por defecto sólo placeholders. Pero si se añaden hooks custom para debug, es fácil filtrar la PII original al log. Auditoría regulatoria (RGPD, ENS) detecta esto y es incumplimiento. Disciplina: nunca añadir hooks que lean del Vault sin permiso explícito.

Trampa 7 — scan_output sin prompt original. El método scan_output espera (prompt, output) para validadores que comparan ambos (Relevance, LanguageSame, FactualConsistency). Si se le pasa sólo el output, esos scanners fallan silenciosamente o devuelven is_valid=True por defecto. Hay que conservar el sanitized_prompt en el AI Gateway y pasarlo al scan_output.

Cuándo elegir LLM Guard (y cuándo no)

Elegir LLM Guard cuando:

El requisito de anonimización PII con restitución automática está en la lista. Es la razón #1 para usarlo. Banca, salud, asesoría legal, RRHH — cualquier caso con PII fuerte que no debe llegar al LLM aunque éste sea local.
Quieres un pipeline pythonic sin DSL nuevo. Si el equipo es Python-puro y prefiere componer scanners como objetos antes que aprender Colang.
El stack ya tiene un AI Gateway (LiteLLM, Envoy AI, Kong AI) y se integra como plugin sin tocar la app.
Necesitas OTel y Prometheus built-in sin instrumentación adicional.

No elegir LLM Guard cuando:

El sistema es un agente conversacional con flujos de diálogo complejos (políticas, fallbacks, escalado a humano). Ahí NeMo Guardrails con Colang es estructuralmente mejor.
La capa de safety se reduce a validar outputs estructurados (JSON, function calling). Guardrails AI con sus validators es más natural.
Tu latencia budget es ultra-agresivo (< 30 ms para toda la capa). Habrá que reducir scanners y aceptar cobertura menor; quizás un único PromptGuard 2 + Presidio en sidecar (patrón del post de guardrails) sea más simple.
No quieres cargar con el peso operativo del Vault distribuido (Redis, TTL, sticky session). Para sistemas pequeños sin requerimiento fuerte de PII, sobra-dimensiona.

Lo que no hemos cubierto (próximos posts)

Custom scanners: cómo escribir tu propio scanner cuando ninguno del catálogo encaja (regex compleja de dominio, classifier fine-tuned propio). El proyecto admite scanners custom heredando de InputScanner / OutputScanner con tres métodos.
Integración con SLSA / supply chain: cómo firmar el contenedor de LLM Guard con cosign, attestations SLSA, y verificación en cluster antes de admitirlo. Tema operativo de seguridad de supply chain (OWASP LLM03).
Red teaming contra LLM Guard: técnicas conocidas que evaden detectores (homoglyphs, Unicode confusables, encoding base64 dentro del prompt). El proyecto publica un suite de tests adversariales para hacer benchmarking propio. Cómo se monta como gate continuo en CI.
Benchmark comparativo con Bedrock Guardrails y Azure AI Content Safety: F1 por categoría sobre tráfico real cruzando tres deployments distintos. El post de OSS vs hyperscalers tiene la comparativa estratégica; falta el comparativo técnico de detección.

Referencias

LLM Guard (Protect AI): https://llm-guard.com — documentación oficial, lista de scanners, benchmarks.
Repositorio: https://github.com/protectai/llm-guard.
LLM Guard API: https://github.com/protectai/llm-guard/tree/main/llm_guard_api.
Presidio (Microsoft): https://microsoft.github.io/presidio/ — base del scanner Anonymize.
detect-secrets (Yelp): https://github.com/Yelp/detect-secrets — base del scanner Secrets.
Langfuse OTel ingestion: https://langfuse.com/docs/opentelemetry/get-started.
LiteLLM guardrails: https://docs.litellm.ai/docs/proxy/guardrails.
Envoy AI Gateway: https://aigateway.envoyproxy.io.
Kong AI Gateway: https://docs.konghq.com/hub/kong-inc/ai-prompt-guard/.
OWASP Top 10 for LLM Applications 2025: https://owasp.org/www-project-top-10-for-large-language-model-applications/.
ONNX Runtime: https://onnxruntime.ai — exportación de modelos HF a ONNX para acelerar.

Ver también

Guardrails y safety en LLMs: las cuatro líneas de defensa — el marco que ubica LLM Guard como una de las herramientas dentro de la capa. Aquel post explica las cuatro líneas (input, retrieval, tool, output), OWASP LLM Top 10 y compara a vista de pájaro NeMo Guardrails, Llama Guard 4, ShieldGemma, Granite Guardian, PromptGuard 2 y LLM Guard.
El catálogo OSS para LLMOps en seis etapas — ficha extendida de LLM Guard entre el resto de herramientas OSS por etapa del pipeline.
RAG corpus curation: el bibliotecario activo — la prevención en ingest comparte el detector PII de Presidio con LLM Guard; el patrón Vault es la pieza nueva que se añade en runtime.
Tracing LLM con OpenTelemetry GenAI — el plano OTel sobre el que LLM Guard emite spans gen_ai.guardrail.* que Langfuse y Tempo consumen.
Prompt versioning con Langfuse y MLflow — el prompt_id+version viaja como atributo de span aunque el contenido del prompt esté anonimizado; complementa el blindaje PII de este post.
Evals para LLMs: la capa después del tracing — la pareja offline de LLM Guard. Cuando un scanner reporta tasa alta de FP sobre tráfico real, el ejercicio offline contra golden anotado identifica si afinar threshold o cambiar modelo backend.
Retrain: cerrar el bucle feedback → dataset → adapter — los incidentes severity HIGH que LLM Guard emite con risk_score > umbral alimentan el bucle de incident-driven retrain.
OSS vs hyperscalers en LLMOps — la columna OSS de la fila “Guardrails” (NeMo + Presidio + Llama Guard 4 + LLM Guard) frente a Bedrock Guardrails, Azure AI Content Safety, Vertex Model Armor.
Structured output: function calling y constrained decoding — el scanner JSON de LLM Guard valida estructura del output como red de seguridad cuando el motor de inferencia ya hizo constrained decoding.
El pipeline LLMOps de seis etapas — el mapa maestro donde Guardrails (este post incluido) es la pareja online de la etapa Eval.