On-Premise on lo0 — Blog Técnico

Siete fases de despliegue greenfield de una plataforma LLM on-premise: del hardware en la sala al primer token productivo

Sun, 31 May 2026 08:00:00 +0200

TL;DR

Los dos posts anteriores de esta trilogía arquitectónica fijaron las piezas: las siete capas del stack de inferencia LLM describen los componentes encima del cluster, y los cinco niveles de madurez de la plataforma describen los estratos por debajo. Este post fija el cuándo: en qué orden se despliega cada cosa cuando se parte de cero —hardware comprado, racks instalados, cableado físico hecho— y se quiere llegar a un cluster sirviendo el primer token productivo a un cliente. Siete fases nominales F0 a F6 sin compromisos de calendario, organizadas por dependencias técnicas (no se entra en F3 sin gate de F2) y con un camino crítico identificable. F0 inventario hardware y conectividad eléctrica/red. F1 OS bare metal + drivers + container runtime. F2 cluster Kubernetes con CNI y storage Ceph operativos. F3 GitOps y observabilidad de infraestructura. F4 identidad, TLS, secretos y políticas. F5 plataforma GPU con observabilidad LLM-aware. F6 stack LLM operativo y abierto a tráfico productivo. Para cada fase: qué se monta, qué tiene que estar listo antes (dependencias entre fases), gate que valida el cierre, y la trampa típica que retrasa el camino crítico. La tesis: una plataforma LLM on-premise se hunde mucho más a menudo por secuenciar mal que por elegir mal. Las herramientas están todas inventadas; el orden es lo único que cada equipo redescubre.

Estás aquí: las siete fases y sus dependencias

Las fases no se ejecutan en serie pura. F2 y F3 pueden empezarse a la vez para acelerar (instalar Kubernetes y preparar el repo GitOps en paralelo). F4 puede solaparse con la parte final de F3. F5 espera a que F4 cierre porque los pods GPU exigen NetworkPolicy y RBAC desde el primer día. F6 es un único paso atómico: el cluster entra en producción o no.

Las flechas rojas son el camino crítico: el cuello de botella secuencial que ningún paralelismo puede acortar. Las flechas grises son dependencias que admiten solape parcial. Reconocer dónde solapar y dónde no es la diferencia entre un despliegue de tres meses y uno de seis para el mismo perímetro.

La analogía: la expedición a una cumbre de ocho mil

Una expedición a una cumbre alpina alta no es un trekking largo. Es una serie de campamentos que se montan en orden, cada uno con su altura, su función y su gate de validación: si no se aclimata bien en el campo base, no se puede subir al C1 sin riesgo; si el C2 no tiene su cocina y su radio en marcha, no se puede mandar gente arriba; si el ataque a cumbre se intenta sin los porteadores en los campamentos altos, no hay descenso seguro.

El despliegue greenfield de una plataforma LLM funciona idéntico. F0 es la llegada del material al campamento base — cajas, sponsors, permisos, primera revisión. F1 es montar el campo base operativo: cocina, tiendas, generador. F2 es la subida al C1: ya hay altitud real (cluster k8s en marcha) y se respira distinto. F3 es C2: añade comunicaciones, planificación y aclimatación operativa. F4 es C3, la última noche antes del ataque: equipo cordado, oxígeno listo, todos los protocolos verificados. F5 es el día del ataque a cumbre — esfuerzo intenso, márgenes finos. F6 es la cumbre y el inicio del descenso seguro: a partir de aquí la expedición está en operación día a día, ya no en construcción.

La analogía aguanta dos lecciones útiles: no se salta un campo (subir directo del campo base a la cumbre mata al equipo), y los gates son técnicos, no anímicos (si el barómetro pone tormenta, no se sale, aunque haya entusiasmo). El equipo de plataforma que sigue esas dos reglas llega a la cumbre. El que las negocia, no.

F0 — Hardware en la sala: el campamento base

Lo que se monta en esta fase. Inventario del hardware recibido (servidores, switches, PDUs, BMC), racks montados, cableado eléctrico y de datos terminado, etiquetado físico de cada equipo (rack/U/función), conectividad a la red corporativa, IPs de gestión asignadas, BMC accesible vía VPN con MFA, primer ping de cada nodo desde el bastion.

Dependencias. Cero técnicas — esta es la fase previa al software. Sí dependencias de procurement (servidores comprados, switches comprados), de obra civil (sala con climatización suficiente, suelo técnico) y administrativas (acceso al CPD para los técnicos).

Gate de validación que cierra F0.

Cada nodo aparece en el inventario con (hostname, MAC, IP gestión, IP datos, rack, U, función, owner).
BMC de cada nodo responde a ipmitool power status y a la UI HTTPS desde la VPN de gestión.
El switch de top-of-rack tiene su configuración versionada en git (incluso si todavía no hay GitOps de cluster, los configs de switch sí).
Un comando for h in $(cat hosts); do ping -c1 -W1 $h.mgmt; done devuelve 100% de éxito.

Trampa típica. Cablear “como salga” sin etiquetado físico ni esquema. Cuando llega F4 y hay que troubleshootear una NetworkPolicy, no saber qué interfaz física lleva qué VLAN duplica el tiempo de diagnóstico de cada incidente para siempre.

Por qué F0 no se solapa con F1. Hasta que cada servidor tiene IP de gestión y BMC vivo, no se puede automatizar el bootstrap del OS. Toda hora invertida en F0 ahorra horas en cada fase posterior — es la fase con mejor ROI del proyecto y la única que no admite atajos.

F1 — Bare metal: el campamento base operativo

Lo que se monta. Imagen del sistema operativo (Debian estable o Ubuntu LTS) provisionada vía PXE o cloud-init con el cloud-config versionado en git. Cada nodo tiene: hostname coherente, particiones LVM, kernel ≥ 6.6, container runtime containerd, drivers NVIDIA para los nodos GPU, chrony sincronizando contra servidores propios, SSH key del operador como única vía de acceso, nvidia-smi pasando smoke test en los nodos GPU.

Dependencias. F0 cerrada. Necesita la red de gestión funcionando para que el PXE responda y para que el bastion alcance cada nodo.

Gate de validación que cierra F1.

ansible -i inventory all -m ping devuelve 100% de éxito (o equivalente con Salt / Pulumi / etc).
Cada nodo GPU pasa nvidia-smi mostrando las GPUs esperadas con driver consistente entre nodos.
Reloj de cada nodo desviado < 50 ms del NTP de referencia.
Reinicio físico de un nodo lo deja exactamente en el mismo estado tras boot (idempotencia).

Trampa típica. Drivers NVIDIA instalados manualmente con apt install o con el script .run de NVIDIA. Funciona el día uno y se rompe el día de la primera actualización de kernel. La regla operativa que ya quedó establecida en el post de los cinco niveles: los drivers acaban siendo gestionados por el GPU Operator en F5; lo que se haga ahora es solo para que nvidia-smi pase el smoke test, no para producción.

Solape posible. F1 puede empezar para algunos nodos mientras todavía se finaliza F0 en otros (greenfield real raramente entrega todos los servidores el mismo día). El gate de F1 es por cluster, no por nodo individual.

F2 — Cluster Kubernetes operativo

Lo que se monta. RKE2 instalado con tres nodos de control plane HA, joining de todos los workers (CPU y GPU), Cilium como CNI con kubeProxyReplacement habilitado y BGP control plane apuntando a los switches ToR del F0, Rook-Ceph desplegado en los nodos de storage para cubrir block (RBD), filesystem (CephFS) y object (RGW S3-compatible), kubectl get nodes devolviendo todos los nodos Ready, primer pod de prueba con PVC montando y datos persistiendo tras restart del pod.

Dependencias. F1 cerrada (drivers + container runtime). Switches con BGP configurado (lo cerrado en F0). Discos NVMe particionados o disponibles raw para Ceph OSDs.

Gate de validación que cierra F2.

kubectl get nodes -o wide muestra todos los nodos Ready con la versión esperada de Kubernetes.
Un Deployment con replicas=3 y antiAffinity por nodo arranca y los pods caen en nodos distintos.
Una PVC RWO (RBD) crea un volumen, el pod escribe datos, el pod se borra, otro pod la monta y lee los datos.
Una PVC RWX (CephFS) hace lo mismo con dos pods escribiendo simultáneamente.
Un bucket RGW vía s3cmd o mc acepta put y get con TLS.
Hubble (lado lectura del CNI) muestra flow logs entre dos pods de namespaces distintos.
Test de chaos: drain de un nodo worker no GPU; las cargas se reschedulean automáticamente.

Trampa típica. Empezar a kubectl apply cargas reales en F2 sin GitOps. El backlog de cosas-aplicadas-a-mano crece más rápido que la capacidad de migrarlo a git después. La regla: en F2 sólo se aplican los prerrequisitos del cluster (CNI, CSI, storage class por defecto). Cualquier carga de aplicación espera a F3.

Solape posible. F2 ↔ F3. Mientras se monta el cluster, se prepara en paralelo el repo GitOps (estructura de directorios, primeras Helm releases). Cuando F2 cierra, Flux se enchufa al repo y todo lo que iba a ser kubectl apply ya está como manifest reconciliado.

F3 — GitOps y observabilidad de infraestructura

Lo que se monta. Forgejo desplegado primero (es prerrequisito de todo lo que viene). Repo gitops-infra con la estructura inicial (apps/, infrastructure/, tenants/, clusters/). Flux instalado y reconciliando ese repo. Las cargas de prerequisito que se aplicaron a mano en F2 se mueven al repo y se reconcilian (deja de haber kubectl apply operativo). VictoriaMetrics + vmagent scrapeando métricas. Grafana con dashboards iniciales (USE/RED + cluster + Ceph + Cilium). Loki recibiendo logs vía vector/fluent-bit. Alertmanager + Keep enrutando alertas a un canal de chat. Backups Barman Cloud para Postgres (futuro CNPG) y snapshots Ceph programados.

Dependencias. F2 cerrada. Bucket RGW para almacenar backups (lo cubre Ceph del F2).

Gate de validación que cierra F3.

Cambio aplicado al repo se refleja en el cluster en < 5 minutos sin intervención manual.
Un cambio aplicado con kubectl edit directamente al cluster es detectado por Flux y revertido (drift detection vinculante, no sólo observacional).
Grafana muestra dashboards de cluster, Ceph, Cilium y nodos GPU (DCGM no llega hasta F5, pero las métricas básicas del nodo sí).
Un alert de prueba enviado a Alertmanager llega al canal de chat en < 1 minuto.
Restore de un backup Postgres en un cluster temporal devuelve datos coherentes (la prueba define el RPO real).

Trampa típica. Tener Helm charts en git pero seguir aplicando con helm install desde la terminal. Eso es nivel 1 con disfraz de nivel 2. F3 sólo se cierra cuando Flux es la única autoridad que aplica cambios y los humanos editan repo, no cluster.

Solape posible. F3 ↔ F4. Mientras se cierra F3, se puede preparar el manifest de Defguard y cert-manager en el repo. Cuando se reconcilien tienen donde aterrizar.

F4 — Identidad, certificados, secretos, políticas

Lo que se monta. Defguard desplegado con su Postgres dedicado (CNPG). Realm inicial con los operadores de plataforma enrolados con MFA y WireGuard. OIDC integrado en kube-apiserver (--oidc-issuer-url, --oidc-client-id, --oidc-username-claim), en Forgejo, en Grafana, en Alertmanager — un solo SSO. cert-manager instalado con CA interna emitiendo certs internos para mTLS y con Let’s Encrypt ACME para certs de borde. SOPS configurado con KMS (puede ser un HSM físico, una clave age en un cofre, o un Vault externo) y External Secrets Operator sincronizando secretos al cluster. Kyverno desplegado con políticas iniciales en modo audit durante una semana, después promovidas a enforce. NetworkPolicy default-deny aplicada a cada namespace existente. Tetragon habilitado para runtime security. Audit log de kube-apiserver enviado a Loki con retención larga.

Dependencias. F3 cerrada (Flux aplica los manifests, VM/Loki ingieren métricas y logs).

Gate de validación que cierra F4.

kubectl con kubeconfig admin compartido deja de funcionar; cada operador usa su propio token OIDC con MFA.
Un secret en data: plano en un commit es rechazado por el pre-commit hook (o por Kyverno admission).
Un pod sin securityContext.runAsNonRoot=true es rechazado por Kyverno en admission.
Una NetworkPolicy intencionalmente errónea (allow-all) en un namespace de tenant es rechazada.
Un audit del último día devuelve la lista completa de actores y cambios (huella regulatoria mínima).
Pen-test interno básico: un atacante con kubeconfig falsificado falla en MFA y queda registrado.

Trampa típica. Kyverno en modo audit permanente porque “no queremos romper cargas en producción”. F4 se cierra cuando las políticas están en enforce. Hasta entonces, sigues en F3 con cara de F4.

Por qué F4 no se solapa con F5. F5 introduce pods GPU que mueven mucha VRAM y mucho cómputo. Sin NetworkPolicy default-deny, sin RBAC OIDC, sin Kyverno bloqueando configuraciones inseguras, los pods GPU son la superficie de ataque más jugosa del cluster. Cualquier compromiso en F5 sin F4 cerrada es un acceso casi-total al hardware caro.

F5 — Plataforma GPU con observabilidad LLM-aware

Lo que se monta. NVIDIA GPU Operator vía Flux con la versión de driver decidida en F1 (ahora ya no se manipula a mano). DCGM Exporter expone métricas GPU a VictoriaMetrics. MIG manager configurado para los nodos donde tenga sentido (por ejemplo, en un cluster 4×H100 SXM: dos GPUs con passthrough completo para el LLM general TP=4, dos GPUs particionadas en 2×3g.40gb cada una para LLMs pequeños y embeddings). Topology Manager con política single-numa-node. KEDA con Prometheus scaler instalado y un ScaledObject de ejemplo apuntando a una métrica vLLM (vllm:num_requests_running). OpenTelemetry Collector con receivers OTLP, processors attributes (enriquecen spans con tenant_id, priority_tier), exporters a Langfuse y a Tempo. LeaderWorkerSet API habilitada para topologías tensor parallel. OME (Operator Model Engine) o vLLM Production Stack desplegado como controller — todavía sin modelos cargados.

Dependencias. F4 cerrada (los pods GPU heredan NetworkPolicy default-deny, RBAC OIDC y políticas Kyverno).

Gate de validación que cierra F5.

Un pod de prueba pidiendo nvidia.com/gpu: 1 se programa en el nodo correcto y nvidia-smi desde dentro del contenedor ve la GPU correcta (entera o un slice MIG).
DCGM Exporter expone métricas en Grafana (utilization, VRAM, temperatura, NVLink bandwidth) para cada GPU.
Un Deployment de vLLM de prueba arranca con un modelo pequeño (por ejemplo, un 7B FP16) cargado desde Ceph RGW.
Un span OpenTelemetry generado por ese vLLM llega a Langfuse con atributos gen_ai.* correctos.
KEDA escala el Deployment de prueba de 1 a N réplicas bajo carga sintética y vuelve a 1 cuando cesa.
Un upgrade del GPU Operator a una nueva versión drena y reprograma los pods GPU sin pérdida de servicio.

Trampa típica. Cargar el modelo grande “para probar” antes de que DCGM y OTel estén verdes. Cuando algo falle, no habrá métricas que distingan entre OOM, throttling térmico, mismatch de driver o problema de red — se diagnostica a ciegas. La regla: modelo pequeño primero, golden path verde, después modelo grande.

Solape posible. Ninguno con F6. F6 es atómico.

F6 — Stack LLM en producción

Lo que se monta. Las siete capas del stack de inferencia descritas en el post correspondiente, desplegadas en este orden:

Vector store + datos relacionales (Qdrant, PostgreSQL CNPG, Ceph RGW para pesos y adapters, CephFS para datasets). Algunos componentes ya existían de F3 como datos; aquí se especializan para RAG con sus colecciones y schemas iniciales.
Embeddings + reranker (Infinity con multilingual-e5-large, TEI con bge-reranker-v2-m3). Es la capa que debe estar verde antes de cualquier modelo grande, porque el RAG depende de ella.
Inferencia LLM (vLLM Production Stack con el LLM general y el LLM código). Carga modelos desde Ceph RGW. Multi-LoRA pool inicial vacío.
Gateway (Envoy AI Gateway) con OAuth Defguard, routing por body.model, rate-limit por tenant. Este es el punto que abre tráfico al exterior.
Observabilidad LLM-aware (Langfuse enchufado al OTel del F5).
Control plane GitOps y dependency tracking ya estaban activos desde F3 y F4 respectivamente; aquí simplemente se les añade el catálogo de los nuevos servicios LLM.

Dependencias. Todas las anteriores cerradas.

Gate de validación que cierra F6.

Curl al endpoint público con bearer token Defguard recibe respuesta de chat completion en castellano técnico correcta, con trace_id propagado.
La traza aparece en Langfuse con atributos gen_ai.* completos, latencia desglosada y tenant_id propio.
Un canary 5% de tráfico al nuevo modelo durante 24 h no degrada métricas de calidad ni de latencia.
Un golpe de tráfico controlado dispara KEDA, las réplicas escalan, la latencia P95 se mantiene dentro de presupuesto.
Un fallo intencional de un pod vLLM no afecta a la disponibilidad del endpoint (réplicas + reschedule).
El operador interno demuestra el camino completo de revocación de acceso a un tenant en < 5 minutos (Defguard → Kyverno → cierre de NetworkPolicy).

Trampa típica. Abrir tráfico de cliente real antes de tener el runbook de incidentes firmado, el SLO negociado y el plan de continuidad probado. F6 técnicamente está cerrada; operativamente, la plataforma sigue siendo experimento hasta que el primer postmortem real demuestre que el equipo sabe responder.

Las matemáticas que importan: peso relativo del esfuerzo por fase

Sin comprometernos con semanas calendario, sí podemos cuantificar el peso relativo del esfuerzo de ingeniería por fase en un greenfield típico. La curva no es uniforme:

$$ \text{esfuerzo}_{F_i} \approx \text{base}_i \cdot (1 + \epsilon_i) $$

donde $\text{base}_i$ es el esfuerzo nominal y $\epsilon_i$ es el factor de sorpresas (cabling errado, drivers incompatibles, certificados mal emitidos, conflictos de versiones). La tabla siguiente da el peso relativo nominal y el factor típico de sorpresa observado:

Fase	Peso nominal	Factor sorpresa típico ε	Peso efectivo medio
F0 — Hardware	8 %	0.5 (1× a 2×)	12 %
F1 — Bare metal	6 %	0.3	8 %
F2 — Cluster k8s	12 %	0.4	17 %
F3 — GitOps + obs	14 %	0.5	21 %
F4 — Identidad + políticas	18 %	0.7	31 %
F5 — GPU plane	10 %	0.4	14 %
F6 — Stack LLM live	8 %	0.3	10 %
Buffer / integración	24 %	—	—

Dos observaciones operativas. F4 concentra más sorpresas que ninguna otra (federación OIDC entre cuatro o cinco apps con configuraciones distintas, políticas Kyverno que tumban cargas legítimas, secretos rotos por encriptación mal probada). F0 tiene un coeficiente de sorpresa alto en relación a su tamaño porque cualquier error de cableado o etiquetado se descubre tarde y se paga caro. Las dos consecuencias prácticas: planificar F4 con margen generoso y no escatimar tiempo en F0 porque cada hora ahorrada ahí cuesta cinco después.

Camino crítico y holguras. El camino crítico es lineal F0 → F1 → F2 → F3 → F4 → F5 → F6. Las únicas holguras reales son los solapes ya identificados:

F2 ↔ F3 (holgura ~30 %): preparar repo y dashboards iniciales mientras se monta cluster.
F3 ↔ F4 (holgura ~20 %): manifests de identidad listos al cerrar F3, aplicación inmediata.
Dentro de F4: políticas en modo audit corriendo en paralelo con setup de Defguard.

Nada acorta el camino crítico más de un ~15 % del total. Quien promete un greenfield productivo en la mitad del tiempo razonable está vendiendo otra cosa: probablemente saltarse F4 o cargar F6 con F5 verde-pero-no-validado.

Diagrama final: el cronograma de despliegue completo

El cronograma no es decorativo: cada fila define lo que se monta en su fase y el gate que la cierra. Una fase no se da por terminada hasta que su gate está verde. Una fase con gate amarillo arrastra todas las posteriores; intentar saltar a la siguiente con un gate parcialmente cumplido es lo que produce, varias semanas después, el incidente que obliga a “volver a F4 con producción rodando” — la situación más cara de toda la matriz de costes del post de los cinco niveles.

Errores típicos de planificación

Patrones que retrasan o hunden el despliegue greenfield, independientemente de las herramientas elegidas:

1. Comprar el LLM antes que el cluster. Empezar el proyecto por “qué modelo vamos a servir” en vez de por “qué plataforma puede sostener cualquier modelo razonable”. El modelo es un parámetro intercambiable; la plataforma no.

2. Subestimar F0. “Eso lo hace el equipo de redes”. Sí, pero el resultado de F0 lo consumen todas las fases posteriores. Si el equipo de redes entrega tarde, el proyecto entero llega tarde — y nadie lo había marcado como camino crítico.

3. Solapar F4 con F5 “para ganar tiempo”. Es la única dependencia donde no hay holgura. Si se intenta solapar, F5 acaba operando con políticas en audit permanente (no estás en F4) o sin OIDC integrado (operadores con kubeconfig compartido tocando GPU). Ambos antipatrones se quedan en producción.

4. Saltar el smoke test del modelo pequeño en F5. “Vamos a por el 70B directamente”. Cuando algo falle (y algo fallará), no habrá baseline contra el que diagnosticar.

5. Tratar F6 como “encender vLLM”. F6 incluye gateway, observabilidad LLM-aware, runbook, SLO, plan de continuidad. Encender vLLM es cinco minutos; cerrar F6 es semanas de validación y firma.

6. No definir gates por escrito. Si los gates no están escritos, son negociables a posteriori. “Esto ya cuenta como F4” es la frase que precede a los seis meses siguientes de retrofit.

7. Asignar la fase a un único responsable. Cada fase necesita al menos dos personas que la entiendan. La rotación de personal en proyectos largos destruye el conocimiento; los gates por escrito + revisión cruzada lo preservan.

8. Olvidar el camino de descenso. El post se centra en subir. La operación día a día (descenso, en la analogía) es otra historia que también merece planificación — runbooks, on-call, capacidad de upgrade, plan de fin de vida. Los equipos que sólo planifican la subida llegan a la cumbre y se quedan ahí sin oxígeno.

Aplicado a hardware on-premise típico: 4×H100 SXM

Sobre el cluster genérico de referencia (4×H100 SXM 80 GB, NVLink, 640 GB RAM por nodo GPU, 3 nodos control plane, 3-5 nodos worker CPU, 2 nodos worker GPU), el reparto temporal del trabajo se distribuye así:

F0 (hardware)
└─ 8 servidores físicos racks + switches + BMC + IPs gestión
 ├─ 3 nodos cp-01..03 — control plane (sin GPU)
 ├─ 3 nodos worker-cpu-01..03 — CPU plane (Forgejo, Ceph, observabilidad)
 └─ 2 nodos worker-gpu-01..02 — GPU plane (4×H100 SXM cada uno)

F1 (bare metal)
└─ OS + drivers + containerd en los 8 nodos por igual
 (los drivers NVIDIA solo en los 2 nodos GPU, smoke `nvidia-smi`)

F2 (cluster k8s)
└─ RKE2 control plane en cp-01..03 (HA con etcd embebido)
 workers joining: 3 CPU + 2 GPU
 Ceph OSDs en los 3 nodos worker CPU
 pools por defecto: RBD-replicated-3, CephFS-replicated-3, RGW

F3 (GitOps + obs)
└─ Forgejo + Flux + VM/Grafana/Loki + Keep en CPU plane
 primer repo `gitops-infra` reconcilia lo de F2

F4 (identidad)
└─ Defguard en CPU plane (StatefulSet con Postgres CNPG)
 OIDC en kube-apiserver, Forgejo, Grafana, Alertmanager
 Kyverno como Deployment en control plane

F5 (GPU plane)
└─ NVIDIA GPU Operator targetea workers GPU
 MIG manager: 1ª GPU MIG 7g.80gb (= passthrough), 2ª 2×3g.40gb
 OTel Collector como DaemonSet en GPU plane + CPU plane
 primer vLLM con modelo 7B FP16 verde

F6 (stack LLM)
└─ Las 7 capas se reconcilian vía Flux desde un segundo repo `gitops-llm`
 primer endpoint público con OAuth Defguard
 primer cliente productivo enrolado bajo SLA

La distribución física del cluster aprovecha el aislamiento entre planos definido en F0: el plano de control no toca GPU, el plano CPU concentra estado relevante (Forgejo, Ceph, Postgres CNPG, Langfuse, Defguard) y el plano GPU se especializa al máximo. Esa separación, decidida en F0 antes de instalar el primer servidor, condiciona el éxito del resto de fases — es otro recordatorio de por qué F0 importa más de lo que parece.

Lo que no hemos cubierto (próximos posts)

Este post recorre el camino de subida a la cumbre. Quedan piezas que merecen su propio artículo:

El descenso seguro: operación día a día, runbooks por componente, on-call, capacity planning continuo, ciclo de upgrades del cluster sin downtime.
Multi-site (segunda cumbre): cómo se federan dos clusters con Cilium Cluster Mesh y qué fases extra introduce. F3.5 (Cluster Mesh) y F4.5 (replicación cross-site) son las fases que faltan.
El camino brownfield: lo que cambia cuando ya hay un cluster con cargas. Las fases siguen siendo las mismas, pero los gates se aplican retroactivamente y cada paso requiere planning de migración.
El coste calendario real: rangos típicos en semanas para un equipo de plataforma de 2-3 personas, separado por fase, con bandas de incertidumbre.
El handoff a operación: cómo se entrega la plataforma del equipo de despliegue al equipo de operación, qué documentos firman, qué se hereda y qué se renegocia.

Ver también

Anatomía de un stack de inferencia LLM on-premise — las siete capas que se montan en F6. Los componentes, no el cronograma.
Cinco niveles de madurez de la plataforma debajo del LLM — los niveles correspondientes a las fases F1→F5. Los estratos, no la secuencia.
El catálogo OSS para LLMOps en seis etapas — fichas individuales de las piezas citadas aquí.
Tracing LLM con OpenTelemetry GenAI — el OTel del F5 con detalle de las semantic conventions gen_ai.*.

Referencias

RKE2 Documentation — docs.rke2.io
Cilium documentation — docs.cilium.io
Rook documentation — rook.io/docs
Flux GitOps toolkit — fluxcd.io
Forgejo — forgejo.org
cert-manager — cert-manager.io
External Secrets Operator — external-secrets.io
Kyverno — kyverno.io
NVIDIA GPU Operator — docs.nvidia.com/datacenter/cloud-native/gpu-operator
DCGM Exporter — github.com/NVIDIA/dcgm-exporter
KEDA — keda.sh
LeaderWorkerSet API — github.com/kubernetes-sigs/lws
OpenTelemetry Semantic Conventions for GenAI — opentelemetry.io/docs/specs/semconv/gen-ai

Cinco niveles de madurez de la plataforma debajo del LLM: del servidor con Linux al cluster listo para vLLM

Sun, 31 May 2026 07:00:00 +0200

TL;DR

El post de las siete capas del stack de inferencia LLM daba por supuestas muchas piezas: un cluster Kubernetes operativo, GitOps reconciliando, identidades resueltas, GPUs visibles para el scheduler, observabilidad capaz de transportar gen_ai.*. Antes de que vLLM tenga sentido, hay que llegar a ese punto de partida, y se llega por niveles. Este post define cinco niveles de madurez de la plataforma que vive debajo del LLM, desde un servidor bare metal con Linux instalado (nivel 0) hasta un cluster listo para correr la capa de inferencia (nivel 4) y el handoff al post anterior (nivel 5). Cada nivel desbloquea una capacidad concreta —ejecutar contenedores con reproducibilidad, reconstruir el cluster desde git, autenticar humanos vía OIDC, programar GPUs con MIG y métricas DCGM, demostrar compliance sin intervención manual— y cada uno tiene un test de validación que decide si estás de verdad ahí o solo te lo cuentas. Para cada nivel: qué piezas OSS lo cubren en 2026 (Cilium, RKE2, Flux, cert-manager, Defguard, NVIDIA GPU Operator, KEDA, Trivy, Kyverno…), el orden de despliegue dentro del nivel, las decisiones que cuesta caro saltarse, y los antipatrones que te bajan de nivel cuando creías estar arriba. La tesis: subir de nivel cuesta poco esfuerzo si lo haces a tiempo, y mucho refactor si pretendes saltártelo. La inferencia LLM exige al menos nivel 4; quien intenta servir LLMs desde un nivel 1 o 2 acaba pagando con incidentes nocturnos lo que se ahorró en plataforma.

Estás aquí: los cinco niveles de un vistazo

Antes del detalle, la escalera. Cada peldaño añade una capacidad ausente en el anterior. El test del nivel es la pregunta cuya respuesta honesta dice si ya estás en él.

Los niveles no son intercambiables. Un cluster en nivel 2 no puede correr LLMs en producción con garantías: técnicamente carga el pod de vLLM, pero al primer incidente nocturno se descubre que no hay TLS, ni identidades, ni alerting, ni métricas GPU, ni forma de saber quién cambió qué. Subir un nivel después de tener LLMs ya en producción cuesta órdenes de magnitud más que subirlo cuando el cluster aún está vacío.

La analogía: del puesto callejero al restaurante con estrella

Imagina la escala de un negocio de hostelería. Nivel 0 es el puesto callejero: una plancha, una bombona, un cocinero que improvisa. Puede vender comida — funciona — pero cualquier cosa que se desvíe del día normal (una inspección sanitaria, un cliente alérgico, un pedido de 200 raciones) le tira el negocio. Nivel 1 es el bar de tapas: cocina dimensionada, carta corta repetible, varios turnos. El cocinero ya no improvisa cada día; trabaja sobre un menú escrito, aunque las recetas viven en la cabeza del jefe. Nivel 2 es el restaurante con menú del día: hay procedimientos escritos, proveedores fijos, control de stock, libro de incidencias. Si el cocinero principal se cae enfermo, el segundo puede sacar el servicio sin estragos. Nivel 3 es el restaurante con carta y servicio formal: trazabilidad de cada ingrediente, alérgenos en la carta, certificación sanitaria, contrato con los proveedores, formación obligatoria del personal. Nivel 4 es la cocina especializada en un producto complejo (sushi, alta cocina, panadería artesanal): herramientas específicas que el restaurante normal no necesita (horno de leña, cuchillos especiales, cámara de fermentación), procesos calibrados, métricas de calidad. Nivel 5 es el restaurante con estrella Michelin: el sistema entero funciona, el plato es el resultado de la organización, no del talento de una persona.

La analogía aguanta hasta el final, incluido el detalle más interesante: se puede operar a cualquier nivel, pero las promesas que se pueden cumplir son distintas. El puesto callejero no puede prometer una experiencia consistente a 80 comensales con reserva. El cluster en nivel 1 no puede prometer servicio LLM productivo multi-tenant con SLA. En ambos casos el problema no es de capacidad técnica del último componente (la plancha cocina; el pod arranca); es de capacidad organizativa del sistema entero.

Vamos nivel por nivel.

Nivel 0 — Caótico: el servidor con Linux y nada más

La capacidad que da. Ejecutar contenedores con docker/podman, ejecutar binarios, conectar el servidor a la red. El operador puede entrar por SSH, hacer cosas, y ver resultados.

El test del nivel. “Si reinstalo el servidor desde cero, ¿puedo dejarlo idéntico a como estaba en una tarde, usando sólo notas guardadas?”. Si la respuesta es no (porque los pasos están en la cabeza del que lo montó, en .bash_history, en un wiki desactualizado), estás en nivel 0.

Piezas mínimas que dejar resueltas antes de subir a nivel 1.

Pieza	Decisión sugerida en 2026	Por qué importa al subir
Distribución Linux	Debian estable u Ubuntu LTS	Soporte largo, predecible, kernel reciente disponible
Kernel	LTS reciente (≥ 6.6) con BPF y schedulers modernos	Cilium/eBPF, drivers NVIDIA recientes lo exigen
Drivers NVIDIA	Versión que casa con la CUDA del motor LLM que vas a servir	Mismatch driver/CUDA bloquea vLLM antes de empezar
Container runtime	`containerd`	Estándar CNCF, integrado con RKE2/kubeadm
Filesystem raíz	XFS o ext4 + LVM thin pools	Snapshots, ampliación en caliente
Sincronización horaria	`chrony` con servidores propios	TLS, logs correlados, certificados cortos lo exigen
Red de gestión	VLAN dedicada, ACLs en switch	Aislar plano de control del tráfico de carga
Red de cluster	LACP + jumbo frames + BGP (si vas a Cilium)	NVLink intra-nodo no salva la red de servicio
BMC / IPMI	Acceso fuera de banda con TLS y MFA	Recuperación cuando el sistema operativo no arranca

Antipatrones que te dejan clavado en nivel 0.

Servidores mascota (con nombre propio, configurados a mano, no reemplazables).
Cambios aplicados con vi directo sobre /etc/... sin commit a un repo.
Despliegue con docker-compose sin healthchecks ni reinicio automático.
Inventario que vive en una hoja Excel que nadie actualiza.

Orden de despliegue dentro del nivel. Imagen del sistema desde PXE/cloud-init con configuración inicial (LVM, hostname, red, SSH key, chrony) → bootstrap de bastion/jump host → inventario en Ansible (o equivalente declarativo aunque luego se reemplace) → drivers NVIDIA + container runtime → smoke test (un contenedor CUDA pasa nvidia-smi). En este punto, el servidor está listo para que entre Kubernetes.

Nivel 1 — Repetible: cluster Kubernetes operativo

La capacidad que da. Programar contenedores con scheduler, abstracción de red entre pods, volúmenes persistentes, lifecycle de cargas, escalado horizontal manual.

El test del nivel. "¿Puedo perder un nodo y que las cargas se reprogramen sin intervención humana?". Si sí, estás en nivel 1. Si no — porque los pods están pinneados a nodos, porque no hay réplicas, porque las PVCs no se reattachean — sigues en 0 con Kubernetes encima.

Piezas mínimas del nivel.

Pieza	Decisión sugerida en 2026	Alternativa principal
Distribución k8s	RKE2 (CIS-hardened por defecto, sin sobrecosto comercial)	k3s para edge muy pequeño, kubeadm puro para casos custom
CNI	Cilium con kube-proxy replacement, BGP, Gateway API	Calico (sin BGP no compite contra Cilium en 2026)
CSI block + filesystem + object	Rook-Ceph (RBD + CephFS + RGW S3-compatible)	OpenEBS Mayastor + Garage para deployments pequeños
Ingress	Cilium Gateway API (mejor unificar con CNI)	NGINX Ingress, Traefik
Cert básico	Self-signed bootstrap	(cert-manager entra en nivel 3)
Manejo de cargas	`kubectl apply` + Helm desde terminal	Sin GitOps todavía
Container registry	Cualquier registry interno (o externo de confianza) con TLS	(registry interno gestionado entra en nivel 2)

Antipatrones que te bajan a nivel 0.

Servicios desplegados con kubectl apply desde la terminal de una persona y sin guardar el YAML en ninguna parte.
Volúmenes persistentes sin política de backup.
“Cluster de un nodo” como producción permanente — un solo punto de fallo arquitectónico.
CNI sin NetworkPolicy disponible o sin BGP cuando la red lo requiere.

Orden de despliegue dentro del nivel. RKE2 instalado en al menos tres nodos para control plane HA → Cilium instalado en modo kube-proxy replacement + BGP control plane → Rook-Ceph en al menos tres nodos cubriendo block (RBD) + filesystem (CephFS) + object (RGW S3-compatible) con replicación 3× o Erasure Coding según pool → smoke test (un Deployment con PVC arranca, los pods se reschedulean al cordon de un nodo, los datos persisten).

Nivel 2 — Definido: el cluster se reconstruye desde git

La capacidad que da. El estado del cluster vive en un repositorio. Cualquier cambio pasa por commit. Cualquier persona puede reconstruir el cluster (o uno equivalente) desde el repo y los backups. La observabilidad básica avisa cuando algo se rompe.

El test del nivel. “Si pierdo el cluster entero, ¿puedo recrearlo en X horas desde el repo + los backups, sin intervención manual fuera del bootstrap?”. Las dos horas son negociables; lo que define el nivel es que el repo + los backups bastan, no que la persona-que-sabe esté disponible.

Piezas mínimas del nivel.

Pieza	Decisión sugerida en 2026	Por qué
Forge	Forgejo (o Gitea, GitLab CE)	OSS auto-alojado, fork comunitario de Gitea, gobernanza abierta
Reconciliador GitOps	Flux	CNCF graduado, multi-tenancy nativo, lightweight
Registry de imágenes	Forgejo Container Registry	Junto al código, sin pieza extra
TSDB métricas	VictoriaMetrics + vmagent	Throughput superior a Prometheus puro, retención larga, compatible PromQL
Visualización	Grafana	Estándar de facto
Logs	Loki o Vector	OSS, integrado con Grafana
Alerting	Alertmanager + Keep (orquestador OSS)	Keep añade enrutamiento multi-canal sin lock-in
Backups DB	Barman Cloud (Postgres)	Estándar para CNPG
Backups objeto / dataset	Ceph RGW multisite + snapshots CephFS	Cross-pool y cross-site

Antipatrones que te bajan a nivel 1.

kubectl apply aplicado en producción fuera del repo (drift no detectado).
Branches main con permisos de escritura para humanos sin revisión.
Repo monolítico sin separación tenant/infra/apps (cambios cruzados no auditables).
Métricas que no se conservan más de 7 días (sin SLO observable a un mes vista).
Alerting que dispara para todo (fatiga) o para nada (silencio).

Orden de despliegue dentro del nivel. Forgejo desplegado primero (es prerrequisito de todo lo demás) → Flux instalado y apuntando al repo de manifests → repositorio inicial con Helm releases de Cilium y Rook-Ceph reconciliados por Flux (sustituyendo los kubectl apply del nivel 1) → VictoriaMetrics + Grafana + Loki vía Helm/Flux → backups Postgres y snapshots Ceph programados → smoke test (tira el cluster, restaura desde repo + backup, los servicios vuelven).

Nivel 3 — Gestionado: identidades, certificados, secretos y políticas

La capacidad que da. Cualquier humano que opera el cluster lo hace con identidad propia (no kubeconfig compartido), con MFA y con permisos limitados. TLS interno automático. Secretos versionados encriptados. Políticas que rechazan configuraciones inseguras antes de que entren al cluster. Auditoría completa de quién hizo qué.

El test del nivel. “Si un atacante consigue el portátil de un administrador, ¿qué puede hacer en producción?”. En nivel 3 la respuesta es “poco”: MFA bloquea el segundo factor, las políticas Kyverno bloquean cambios destructivos sin aprobación, las NetworkPolicies impiden lateral movement, los secretos están encriptados con KMS externo, el audit log queda. En nivel 2, “todo”.

Piezas mínimas del nivel.

Pieza	Decisión sugerida en 2026	Por qué
IdP / OIDC	Defguard	OSS español, WireGuard + OIDC + 2FA, multi-org
Federación con cluster	OIDC en kube-apiserver, OIDC en Forgejo, OIDC en Grafana	SSO consistente
PKI interna	cert-manager + Trust Manager	Estándar de facto, ACME y CA interna
ACME externo	Let’s Encrypt para certs de borde	Sin pago, automatizado
Secretos en git	SOPS + age o KMS externo	Versionable, encriptado en repo
Sync de secretos	External Secrets Operator	Pull desde KMS / Vault al cluster
Policy as code	Kyverno (o OPA Gatekeeper)	Kyverno tiene menos curva de aprendizaje
NetworkPolicy	Cilium NetworkPolicy + L7	Default deny per namespace
Runtime security	Tetragon (Cilium)	eBPF, complementa NetworkPolicy con detección
Vulnerability scanning	Trivy en pipeline CI + admission	SBOM por imagen, bloqueo de CVE críticas
Audit log	kube-apiserver con `--audit-policy-file` enviado a Loki	Trazabilidad regulatoria

Políticas Kyverno mínimas a tener vivas.

Deny de imágenes :latest o sin sha digest.
Deny de pods sin securityContext.runAsNonRoot=true.
Deny de pods sin resources.limits (CPU + memoria).
Deny de Services sin label owner=<equipo>.
Deny de cambios en namespaces críticos (kube-system, flux-system) sin label de aprobación.

Antipatrones que te bajan a nivel 2.

kubeconfig compartido entre administradores.
Secretos en data: plano del manifest commiteado al repo.
NetworkPolicy ausente en namespaces nuevos por defecto (allow-all implícito).
kubectl edit o kubectl patch en producción sin pasar por el repo.

Orden de despliegue dentro del nivel. Defguard desplegado y enrolado con WireGuard / OIDC → integración OIDC con kube-apiserver, Forgejo y Grafana → cert-manager instalado y emitiendo certificados internos (CA propia para mTLS, Let’s Encrypt para borde) → SOPS configurado y External Secrets Operator instalado → migración de secretos plano → encriptado → Kyverno con políticas iniciales y modo audit, después enforce → NetworkPolicy default-deny por namespace → Tetragon habilitado → smoke test (intentar saltarse cada política y comprobar que las admisiones rechazan).

Nivel 4 — Optimizado para GPU: el cluster ya sabe lo que es una H100

La capacidad que da. El scheduler de Kubernetes ve las GPUs, las distingue, las puede particionar (MIG) o multiplexar (time-slicing), exponer métricas DCGM, autoescalar con KEDA usando métricas de la propia carga LLM (vllm:num_requests_running, vllm:gpu_cache_usage_perc), transportar trazas con semantic conventions GenAI. Todo lo necesario para que el stack de inferencia LLM se apoye en una plataforma que entiende su naturaleza.

El test del nivel. “Si pongo un pod que pide nvidia.com/gpu: 1, ¿se programa en la GPU correcta, con el slice correcto, con métricas DCGM expuestas, con observabilidad GenAI lista para recibir spans?”. Si sí, estás en nivel 4. Si la respuesta requiere “depende de qué nodo y quién lo despliegue”, todavía no.

Piezas mínimas del nivel.

Pieza	Decisión sugerida en 2026	Por qué
GPU device plugin	NVIDIA GPU Operator	Despliega drivers, container toolkit, DCGM y MIG manager con un operator
Particionamiento HW	MIG (Multi-Instance GPU) en H100 cuando aplique	Aislamiento hardware real, no time-slicing
Métricas GPU	DCGM Exporter	SM utilization, VRAM, temperatura, throttling, NVLink bandwidth
Métricas LLM	vLLM Prometheus endpoint + scrape	TTFT, TPOT, KV cache, prefix hit rate
Autoscaling	KEDA con ScaledObject Prometheus	Escala por métricas LLM, no por CPU
Operadores LLM	vLLM Production Stack / OME (Operator Model Engine)	Manejo declarativo de modelos / adapters
Trazas	OpenTelemetry Collector con receivers OTLP + processors + exporters	Semantic conventions `gen_ai.*` (post)
LeaderWorkerSet	API LeaderWorkerSet (k8s 1.30+)	Topología tensor parallel coherente con NVLink
Topology Manager	habilitado con `single-numa-node`	Pin de pods GPU a NUMA correcta

Decisión clave: MIG, time-slicing o pasthrough.

MIG divide una H100 en 1g.10gb, 2g.20gb, 3g.40gb, 7g.80gb (slices con aislamiento HW real). Útil para servir varios modelos pequeños o reservar capacidad por tenant con garantía. Limitación: hasta 7 instancias por GPU, perfiles predefinidos.
Time-slicing comparte una GPU entre varios pods sin aislamiento HW. Útil para dev/test, no para producción multi-tenant con SLA.
Passthrough asigna la GPU entera a un pod. Útil para tensor parallel sobre múltiples GPUs del mismo nodo (LLM grande con TP=4).

Para una plataforma LLM productiva, la regla práctica: passthrough para los modelos grandes con TP, MIG para embeddings y modelos pequeños que cohabitan, nunca time-slicing en producción.

Antipatrones que te bajan a nivel 3.

Instalar drivers NVIDIA a mano fuera del GPU Operator (rotura silenciosa al actualizar Kubernetes).
Servir un LLM con requests.gpu: 1 sin haber decidido MIG / passthrough (terminas con GPUs idle por fragmentación o pods que se pisan).
KEDA autoscalando por CPU (HorizontalPodAutoscaler clásico) en pods que están casi siempre al 10% de CPU pero al 95% de KV cache.
OpenTelemetry desplegado pero sin semantic conventions gen_ai.* (las trazas no son LLM-aware).

Orden de despliegue dentro del nivel. NVIDIA GPU Operator instalado vía Helm/Flux con la versión de driver que case con el motor LLM elegido → DCGM Exporter habilitado y métricas visibles en Grafana (dashboards NVIDIA importados) → MIG manager configurado para los nodos donde tenga sentido (mezcla typical en cluster 4×H100 SXM: dos GPUs con passthrough completo para el LLM general TP=4, dos GPUs particionadas en 2×3g.40gb cada una para LLMs pequeños + embeddings) → OpenTelemetry Collector con processors attributes para enriquecer spans con etiquetas propias (tenant_id, priority_tier) + exporters a Langfuse y a Tempo → KEDA instalado con ScaledObject de ejemplo apuntando a vllm:num_requests_running → vLLM Production Stack o OME para declarar modelos como CRD → smoke test (un Deployment de vLLM declarado vía CRD arranca, sirve un token, expone métricas, la traza llega a Langfuse, KEDA escala bajo carga sintética).

Nivel 5 — Handoff: el cluster es plataforma LLM, las siete capas entran encima

Llegado al nivel 4, el cluster cumple el contrato que el post de las siete capas asumía como punto de partida. El nivel 5 no añade infraestructura: añade el stack LLM propiamente dicho. Por completitud, los siete componentes del nivel 5 son:

Gateway (Envoy AI Gateway) — entra primero, dirige tráfico a inferencia LLM y embeddings.
Inferencia LLM (vLLM Production Stack o OME con vLLM) — sobre las GPUs ya descubiertas por el GPU Operator del nivel 4.
Embeddings + reranker (Infinity, TEI) — pod separado del LLM, ya cubierto en el post anterior.
Vector store + datos relacionales (Qdrant, PostgreSQL CNPG, Ceph RGW para pesos y adapters, CephFS para datasets) — la mayoría ya existía en nivel 2 como datos; ahora se especializa para RAG.
Observabilidad LLM-aware (Langfuse) — se enchufa a la cadena OTel del nivel 4.
Control plane GitOps — el del nivel 2 sigue siendo la única autoridad legítima.
Dependency tracking (Hubble flows + Otterize) — sobre Cilium que ya existía en nivel 1.

El criterio para promocionar de nivel 4 a nivel 5 no es técnico: es contractual. El cluster ya soporta LLMs; la decisión es cuándo abrir tráfico real de clientes. La promoción exige: golden eval del modelo verde, runbook de incidentes firmado, SLOs negociados, plan de continuidad, mapeo a ENS / NIS2 / 42001 si aplica.

Las matemáticas que importan: cuánto cuesta saltarse un nivel

Para cuantificar la tesis del post, una estimación con orden de magnitud del coste de subir cada nivel a tiempo versus subirlo después de tener producción. Las cifras son tiempo de ingeniería con un equipo de plataforma pequeño (2-3 personas), asumiendo plantillas y experiencia previa.

Nivel	Tiempo a montar sobre cluster vacío	Tiempo a retrofit con producción rodando
0 → 1	1-2 semanas	1-2 semanas (poco refactor downstream)
1 → 2	2-3 semanas	4-8 semanas (migrar todo a git)
2 → 3	2-4 semanas	8-16 semanas (rebuild de imágenes, migración de secretos, RBAC retroactivo)
3 → 4	1-2 semanas	4-8 semanas (reconfigurar GPU, mover modelos a MIG, instrumentar `gen_ai.*`)
4 → 5	1-2 semanas	2-4 semanas
Total 0 → 5	~10-15 semanas	~20-40 semanas si se hace en orden equivocado

Multiplicador típico observable en la práctica: 2× a 3× el coste si se hace en orden equivocado. Y eso asumiendo que se llega a hacer — muchos proyectos no superan el nivel 2 nunca porque “lo de la identidad” siempre puede esperar a otro sprint. Cuando llega el incidente, ya es tarde para empezar.

Más allá del tiempo, el coste operativo (incidentes nocturnos, escapes de seguridad, deuda invisible) crece exponencialmente con el desfase entre el nivel real y el nivel necesario. Un cluster en nivel 2 sirviendo LLMs productivos en clientes regulados es una bomba de relojería: técnicamente funciona, organizativamente no.

Diagrama final: la escalera completa con piezas

La escalera no es decorativa: cada nivel enable el siguiente. No se puede tener observabilidad LLM-aware (nivel 4) sin OTel desplegado vía Flux (nivel 2). No se puede tener TLS interno automático (nivel 3) sin un PKI raíz que viva en algún sitio (registro y certificados gestionados desde el nivel 2). No se puede tener KEDA escalando por métricas vLLM (nivel 4) sin Prometheus / VictoriaMetrics scrapeando (nivel 2). Los niveles no son una jerarquía conceptual: son una jerarquía de dependencias de instalación.

Decisiones de diseño típicas que rompen el progreso

Errores que se ven repetidamente y que tiran el cluster atrás de nivel:

1. Saltar de nivel 1 a nivel 4 directamente. “Tenemos prisa por servir el LLM, lo de identidad y GitOps lo hacemos después”. Después es siempre dos órdenes de magnitud más caro y siempre llega después del primer incidente.

2. Confundir Helm con GitOps. Tener Helm charts no es nivel 2. Es nivel 1 con plantillas. Nivel 2 exige que un reconciliador (Flux/ArgoCD) aplique las charts desde un repo, detecte drift y avise.

3. cert-manager sin policy de uso. Tener certificados auto-renovados pero usar TLS sólo en el ingress, sin mTLS interno entre servicios, deja la promesa de TLS coja y baja el nivel 3 a un cosplay del 3.

4. NVIDIA drivers a mano. Funciona el día uno y se rompe el día del primer upgrade de kernel. La regla: drivers siempre vía GPU Operator, nunca paquetes del sistema operativo.

5. Métricas Prometheus pero retención de 7 días. Sin retención larga (≥ 90 días) no hay SLO honesto. VictoriaMetrics con 1 año de retención cuesta poco más que Prometheus con 7 días, y desbloquea cumplimiento y postmortems serios.

6. OIDC sólo para kube-apiserver. Si Forgejo, Grafana, Defguard y vLLM cada uno tiene su propio sistema de auth, no tienes SSO, tienes islas. Un nivel 3 honesto exige federación.

7. Kyverno en modo audit permanente. Las políticas que no rechazan no son políticas, son alertas. En algún momento hay que pasar a enforce. Mientras tanto, sigues en nivel 2 con cara de 3.

8. MIG sin decisión consciente del perfil. Configurar MIG con el perfil por defecto sin haber medido el tamaño de los modelos que van a cohabitar deja GPUs fragmentadas con slices que nadie usa. La regla: MIG sólo si has medido y has decidido los perfiles por adelantado.

Todos comparten una raíz: declarar el nivel sin pasar el test del nivel. Decir “ya hicimos GitOps” cuando todavía se aplican cosas con kubectl edit en prod. Decir “ya hicimos identidad” cuando hay un kubeconfig admin compartido. Decir “estamos listos para LLM” cuando no hay DCGM Exporter ni Langfuse enchufado.

Aplicado a hardware on-premise típico: cluster 4×H100 SXM

Sobre el cluster genérico de referencia (4×H100 SXM 80 GB, NVLink, 640 GB RAM), un setup razonable después de pasar los cinco niveles distribuye así los componentes:

control plane (3 nodos sin GPU, hostnames cp-01..03)
├── kube-apiserver, etcd, controller-manager, scheduler
├── Flux, Forgejo, cert-manager, External Secrets, Kyverno
└── Tetragon (DaemonSet también aquí)

worker plane (≥ 3 nodos sin GPU, hostnames worker-cpu-01..03)
├── Cilium agent (DaemonSet)
├── Rook-Ceph OSDs + MONs + MDS (CephFS) + RGW (S3)
├── VictoriaMetrics + Grafana + Loki
├── Defguard (StatefulSet)
└── Langfuse + OTel Collector

worker plane GPU (≥ 2 nodos con 4×H100 SXM, hostnames worker-gpu-01..02)
├── NVIDIA GPU Operator (driver + container toolkit)
├── DCGM Exporter (DaemonSet)
├── MIG manager (configurando el perfil decidido)
├── vLLM (Deployment) — LLM general TP=4 ocupa 4 GPUs (passthrough)
├── vLLM (Deployment) — LLM código TP=2 ocupa 2 GPUs
├── Infinity (embeddings) — 2 réplicas cohabitan en 2 slices MIG
└── KEDA scaler escuchando métricas vLLM

La regla operativa: el plano de control y el plano CPU se separan del plano GPU. Un incidente en el plano GPU no debe llevarse por delante el plano de control (que es lo que recupera el cluster). Y el plano CPU concentra todo lo que mueve estado relevante (Forgejo, Rook-Ceph, Postgres CNPG, Langfuse): es el corazón a proteger.

El hardware GPU se especializa al máximo: pods GPU solamente corren en nodos GPU, y los nodos GPU no corren nada CPU-bound aparte del overhead operativo (Cilium, GPU Operator, DCGM). Esto se enforza con nodeSelector + taints/tolerations + Kyverno policy que rechaza pods sin requests GPU programándose en nodos GPU.

Lo que no hemos cubierto (próximos posts)

Este post recorre el camino vertical hacia arriba. Quedan piezas horizontales y otras transversales que merecen su propio artículo:

Multi-site activo/standby: cómo se federan dos clusters con Cilium Cluster Mesh y qué cambia en cada nivel cuando hay dos sites en lugar de uno.
Migración entre niveles con tráfico real: cómo se retrofitea un cluster que ya está en producción al nivel siguiente sin downtime.
La operación día a día: runbooks por nivel, qué dashboards mirar cada mañana, qué SLOs definir por componente.
El plano de coste: cuánto cuesta cada nivel en hardware, energía, horas de ingeniería, licencias OSS opcionales (soporte comercial de Rancher, Cilium Enterprise, etc.) y cuándo cada gasto se justifica.
Cumplimiento operacionalizado: cómo se mapean los niveles 3 y 4 a controles ENS Alto, NIS2 e ISO/IEC 42001 sin convertir el cluster en un ejercicio de paperwork.

Ver también

Anatomía de un stack de inferencia LLM on-premise — lo que se monta encima de un cluster en nivel 4. Este post es su prequel arquitectónico.
El catálogo OSS para LLMOps en seis etapas — fichas individuales de muchas de las piezas citadas aquí.
Tracing LLM con OpenTelemetry GenAI — el OTel del nivel 4 con detalle de las semantic conventions gen_ai.*.
Pipeline LLMOps de seis etapas — el marco operacional que vive sobre el cluster nivel 5.

Referencias

RKE2 Documentation — docs.rke2.io
Cilium documentation — docs.cilium.io
Rook-Ceph — rook.io
Flux GitOps toolkit — fluxcd.io
Forgejo — forgejo.org
cert-manager — cert-manager.io
External Secrets Operator — external-secrets.io
Kyverno — kyverno.io
NVIDIA GPU Operator — docs.nvidia.com/datacenter/cloud-native/gpu-operator
DCGM Exporter — github.com/NVIDIA/dcgm-exporter
KEDA — keda.sh
LeaderWorkerSet API — github.com/kubernetes-sigs/lws
vLLM Production Stack — docs.vllm.ai/en/latest/serving/production_stack.html
OpenTelemetry Semantic Conventions for GenAI — opentelemetry.io/docs/specs/semconv/gen-ai
CIS Kubernetes Benchmark
NIST SP 800-207 — Zero Trust Architecture

Anatomía de un stack de inferencia LLM on-premise: las siete capas que tienen que sostenerse las unas a las otras

Sat, 30 May 2026 16:00:00 +0200

TL;DR

El stack de inferencia LLM on-premise no es un servidor de modelos: es un edificio de siete capas que se sostienen las unas a las otras. La capa de inferencia (vLLM / SGLang) sirve tokens, pero sin la capa de embeddings dedicada el RAG no funciona; sin la capa de gateway el cliente acopla su SDK al motor concreto; sin la capa de observabilidad LLM-aware (Langfuse + OpenTelemetry GenAI) cualquier degradación de calidad pasa inadvertida; sin la capa de control plane GitOps (Flux + Forgejo) cualquier cambio manual deja deuda invisible; y sin la capa de dependency tracking (Hubble + intent-based policies) decomisionar un Service rompe en silencio aplicaciones que ya nadie recuerda que lo usaban. Este post nace de un incidente concreto: un pipeline que reportaba status: completed y matched_jobs: 0 durante días porque seguía invocando un Ollama que ya había sido escalado a cero, mientras un except mal escrito etiquetaba la ConnectError genérica como “ChromaDB indexing error” y el vector store —inocente— se llevaba la culpa. Cada uno de los tres síntomas era el grito de una capa que faltaba o estaba mal diseñada. El cuerpo del post recorre las siete capas con su pieza canónica OSS, las decisiones de diseño que las rompen, las matemáticas de dimensionado sobre un cluster genérico 4×H100 SXM (320 GB de VRAM, NVLink) y un diagrama final del stack conectado. La tesis: un stack que pasa el test del incidente no se mide por su throughput pico, se mide por cuánto tarda en gritar cuando algo se desvía del diseño.

Estás aquí: las siete capas vistas desde arriba

Antes de bajar al detalle, el mapa. Las siete capas no son siete servidores: son siete responsabilidades que el stack tiene que cubrir. Una capa puede colapsar en un pod (gateway) o repartirse entre varios componentes (observabilidad = traces + métricas + flow logs). Lo que no puede es faltar.

Las capas 1–4 están en el camino de la request: si caen, el cliente lo nota en segundos. Las capas 5–7 están en el camino del diseño y la operación: si caen, no hay error visible inmediato — y por eso son las que producen incidentes silenciosos, que es como acaba la mayoría de los incidentes serios. Este post argumenta que la calidad del stack se mide en las capas 5, 6 y 7, porque las 1–4 son commodities donde todo el mundo elige aproximadamente las mismas piezas.

La analogía: el edificio de oficinas con servicios compartidos

Imagina un edificio de oficinas de doce plantas con varios inquilinos. Tiene una portería (gateway: filtra quién entra), tiene ascensores (inferencia LLM: mueven la carga pesada), tiene escaleras y montacargas (embeddings: tráfico ligero pero constante, casi nadie repara en ellos hasta que se rompen), tiene fontanería y depósitos de agua (vector store: lo que de verdad guarda el estado), tiene cuadro eléctrico y sensores (observabilidad: lo que avisa cuando algo está consumiendo más de lo previsto), tiene un administrador de la finca (control plane GitOps: la única autoridad legítima para mover algo), y tiene un libro de inquilinos (dependency tracking: quién está conectado a qué servicio compartido).

Cuando entra un cliente nuevo en la planta tercera y pide instalar un servidor que necesita más amperaje del previsto, el problema no es eléctrico: es de administración. Si el cliente puede ir directo al cuadro y enchufar lo que quiera, el edificio sobrevive un tiempo y luego salta un magnetotérmico a las tres de la mañana. Si el cliente tiene que pasar por el administrador, el administrador consulta el libro de inquilinos (¿hay alguien más colgando de ese mismo circuito?), revisa la planificación eléctrica (¿estamos al límite?) y autoriza o redirige. El edificio se mantiene en pie no por su instalación eléctrica sino por la disciplina de paso por el administrador.

El stack de inferencia LLM funciona idéntico. Las capas físicas (1–4) son las que se ven y las que la gente del marketing pone en la slide. Las capas de gobierno (5–7) son las que distinguen una plataforma de un montón de pods con suerte.

Ahora vamos al incidente que motiva todo el post.

El anzuelo: el log que mentía durante seis días

La aplicación se llama internamente jobhunter. Es un pipeline cron que cada seis horas barre fuentes públicas de ofertas de empleo, filtra por geo UE, embedde los anuncios nuevos, los indexa en un vector store y los hace match contra perfiles de búsqueda. El último paso dispara notificaciones.

Durante seis días el pipeline reportó en cada run lo mismo:

status: completed
total_found: 756
new: 23
matched_jobs: 0 ← cero, run tras run

Y en los logs:

[INFO] httpx: POST chromadb:8000/api/v2/.../collections/<id>/delete → 200 OK
[INFO] matcher: Purged 12 expired jobs from ChromaDB
[ERROR] pipeline: ChromaDB indexing error: All connection attempts failed
[INFO] httpx: POST chromadb:8000/api/v2/.../collections/<id>/get → 200 OK
[ERROR] pipeline: Matching error: All connection attempts failed

Es un log que invita a culpar a ChromaDB. Y de hecho el primer post-mortem que se escribió internamente apuntaba a una incompatibilidad de versiones del cliente Python contra el servidor v2. Hipótesis razonable, técnicamente plausible, completamente falsa.

La causa real: semanas atrás se había migrado el LLM general de Ollama a vLLM en la plataforma. La migración fue limpia para las dos aplicaciones que dependían directamente del modelo grande — sus manifests pasaron a apuntar al nuevo endpoint. Lo que nadie hizo fue mirar quién más estaba llamando al Service ollama.ollama.svc:11434. jobhunter lo invocaba para generar los embeddings de las ofertas. Cuando se escaló el deployment de Ollama a cero, el Service quedó vacío, y cualquier conexión saliente recibió un ConnectError("All connection attempts failed") genérico de httpcore. El try/except que envolvía toda la etapa de matching capturó la excepción y la rotuló como “ChromaDB indexing error” — porque ese era el envoltorio léxico del bloque, no porque ChromaDB tuviera nada que ver. ChromaDB respondía 200 a delete y a get en los mismos logs.

Tres factores hicieron que el incidente sobreviviera seis días:

El except nombraba el envoltorio en lugar del stage que falló. El log decía “ChromaDB indexing error” cuando el error era de embeddings contra un Service inexistente.
El pipeline retornaba status: completed aunque hubiera errores. Ningún alerting basado en status se disparó. La métrica que sí habría disparado (matched_jobs sostenido en cero) no estaba instrumentada.
La imagen del pipeline rodaba como :latest sin versionar, sin SBOM, sin reproducibilidad. Cuando empezó a fallar, era imposible saber con qué cliente de Ollama estaba compilada.

Cada uno de los tres síntomas es el grito de una capa que faltaba. El primero pide observabilidad LLM-aware que distinga stages (capa 5). El segundo pide que la lógica de pipeline y las métricas Prometheus se comporten como contratos (capa 5, dimensión SLI/SLO). El tercero pide GitOps con imágenes pinneadas y SBOM auditable (capa 6). Y el incidente entero —decomisionar un Service sin saber quién lo consume— grita dependency tracking (capa 7).

El resto del post recorre las siete capas con esa lente: qué resuelve cada una, qué pieza OSS la implementa en 2026, y qué decisión típica de diseño la rompe.

Capa 1 — Gateway: el SDK del cliente no debe acoplarse al motor

Lo que tiene que resolver. Que el cliente envíe POST /v1/chat/completions con el SDK OpenAI estándar y no se entere de qué motor (vLLM, SGLang, TensorRT-LLM), qué modelo concreto, qué adapter LoRA o incluso qué pool de GPUs está sirviendo la request. Autenticación, rate limit, routing por body.model y por tenant, header injection para tracing.

Pieza canónica OSS en 2026. Envoy AI Gateway (Envoy con extensiones GenAI: routing por modelo, token-based rate limit, fallback chains) o Cilium Gateway API con filtros propios. Para casos donde el cliente quiere multi-provider sin distinguir on-prem y SaaS, LiteLLM Proxy es el equivalente ligero.

Lo que rompe la capa. Exponer directamente el endpoint del motor de inferencia. Si los clientes llaman a http://vllm-prod.svc:8000, cualquier cambio de motor, de modelo o de pool obliga a tocar el código de todas las apps. La regla: el motor cambia, el contrato no. El SDK OpenAI es estándar; el routing detrás del gateway es donde vive la libertad de diseño.

Donde fallaba jobhunter. No había gateway. La app llamaba directamente a ollama.ollama.svc:11434. Cuando Ollama murió, no hubo capa intermedia que pudiera responder fallback, retry contra otro pool, o al menos error 503 con cuerpo descriptivo.

Capa 2 — Inferencia LLM: vLLM como elección por defecto, SGLang cuando el prefix caching manda

Lo que tiene que resolver. Servir tokens con throughput y latencia bajo control: continuous batching, PagedAttention para que el KV cache no fragmente la VRAM, FP8 para que un modelo de 32B quepa con margen, multi-LoRA para personalización por tenant sin replicar el base, structured output para function calling con garantía de schema.

Pieza canónica OSS en 2026. vLLM es la elección por defecto: cubre el estado del arte (PagedAttention, continuous batching, FlashAttention, quantization FP8, multi-LoRA, structured output, speculative decoding). SGLang entra cuando el workload tiene prefix caching alto (chat largo con system prompts grandes, agentes con instrucciones repetidas) — su RadixAttention compone mejor que el prefix caching estándar. Para inferencia muy especializada con kernels propietarios NVIDIA, TensorRT-LLM, asumiendo el lock-in de hardware.

Lo que rompe la capa. Asumir que un único modelo “lo hace todo”. Un LLM de chat de 32B no sirve /v1/embeddings — si lo intentas, vLLM responde BadRequestError: "The model does not support Embeddings API". Asumir que sí lo hacía fue una de las heridas concretas del incidente: la app esperaba un endpoint que el modelo no implementaba.

Decisión de diseño que cuesta más adelante. Servir el LLM con cuantización agresiva (INT4) sin un eval de calidad calibrado para tu corpus. INT4 con AWQ o GPTQ ahorra VRAM, pero degrada respuestas en castellano técnico o jurídico de forma medible. La regla: cualquier cambio de cuantización pasa por el mismo golden eval que un cambio de modelo.

Capa 3 — Embeddings: separados del LLM, dimensión fija, vida propia

Lo que tiene que resolver. Generar vectores densos para el corpus RAG y para las queries de retrieval. El modelo de embeddings es otra cosa que el LLM de chat: arquitectura distinta (encoder, no decoder), tamaño distinto (cientos de millones de parámetros, no decenas de miles), API distinta (un endpoint /embeddings que recibe texto y devuelve un vector de dimensión fija).

Pieza canónica OSS en 2026. Infinity o Hugging Face Text Embeddings Inference (TEI) para servir modelos de la familia bge-*, multilingual-e5-*, nomic-embed-* con throughput alto y soporte multi-modelo. OpenVINO Model Server cuando hay hardware Intel disponible. sentence-transformers como fallback embebido en la propia aplicación cuando el corpus es pequeño y el deployment es restringido.

Lo que rompe la capa. Tratarla como “el LLM también lo hace”. No lo hace si es chat-only; y aunque lo haga (algunos modelos tienen endpoint dual), mezclar serving de chat y de embeddings en el mismo proceso castiga el throughput de ambos. La separación física es el diseño.

Dato técnico que se olvida. El vector store y el modelo de embeddings forman una unidad indivisible. Cambiar el modelo de multilingual-e5-large (1024 dim) a multilingual-e5-small (384 dim) no es una sustitución: es crear una colección nueva (mi_corpus_v2) y reembebir todo el corpus. Si haces upsert sobre la colección antigua, te encuentras con un dim mismatch en runtime que tira el pod. Esto que parece obvio se viola constantemente porque el modelo de embeddings se elige una vez y se olvida.

Capa 4 — Vector store + datos relacionales + storage: lo que de verdad guarda el estado

Lo que tiene que resolver. Persistir los vectores con filtros eficientes (tenant_id, created_at, source), persistir los metadatos relacionales (usuarios, configs, prompts versionados, traces), y persistir los pesos del modelo, los adapters LoRA, los datasets y los corpus originales.

Piezas canónicas OSS en 2026.

Qdrant para colecciones grandes (>200 k vectores), filtros payload-aware, multi-tenant via colección o via campo.
pgvector para colecciones pequeñas con joins relacionales obligatorios (querer hacer WHERE doc.author = ... AND vector <=> $1 en la misma SQL).
PostgreSQL operado por CloudNativePG (CNPG) para los relacionales: backups Barman Cloud, replicación, conexión vía pooler.
MinIO para objeto S3-compatible: bucket por tenant, replicación cross-site, pesos y adapters versionados por sha256.
Redis para queues, rate-limit counters y cache de retrievals frecuentes.

Lo que rompe la capa. Asumir que el vector store es stateless ephemeral. Es justo lo contrario: es el componente donde más caro sale perder estado. Sin backups verificados del vector store, una corrupción de índice obliga a reembebir el corpus entero — y eso, en un corpus de millones de documentos, son horas o días de GPU.

Decisión de diseño que paga después. Olvidar versionar la colección por dimensión y modelo de embeddings. Convención sugerida: mi_corpus__embed-multie5l__1024d__v3. El nombre lleva metadata; cualquier cambio en cualquiera de los tres atributos fuerza colección nueva. Es feo pero protege contra el upsert accidental con dim incorrecta.

Capa 5 — Observabilidad: traces LLM-aware + métricas infra + flow logs

Lo que tiene que resolver. Que cualquier inferencia se pueda recuperar a partir de su trace_id, con todos los atributos gen_ai.* (semantic conventions) + atributos propios (tenant_id, adapter_id, priority_tier), latencia desglosada (queue → prefill → decode → red), tokens consumidos, tools invocados, modelo y adapter exactos. Y en paralelo: métricas Prometheus de vLLM (vllm:num_requests_running, vllm:gpu_cache_usage_perc, vllm:prefix_cache_hit_rate), de GPU (DCGM Exporter), de red (Hubble flow logs con drops y NetworkPolicy enforcement).

Piezas canónicas OSS en 2026.

OpenTelemetry Collector como transporte único de traces, métricas y logs, con receivers OTLP y exporters separados por destino.
Langfuse self-hosted para el lado LLM-aware: tracing, prompt versioning, evals con LLM-as-judge (post y post).
VictoriaMetrics + Grafana para métricas TSDB de alto throughput y retención larga.
Hubble (Cilium) para flow logs L3/L4/L7 y visualización de NetworkPolicy.
DCGM Exporter para métricas GPU.

Lo que rompe la capa. Empaquetar todo el stage del pipeline en un único try/except que rotule la excepción con el nombre del envoltorio. La regla operativa: un try/except por stage, con el rótulo del stage en el mensaje y una métrica Prometheus con labels={"stage": "<name>"}. Así “ChromaDB indexing error” nunca habría sido el log para un fallo de embeddings; habría sido “Embeddings call failed: ConnectError(ollama:11434)”.

Regla complementaria. El pipeline devuelve status: completed si y solo si no hubo errores. Con errores devuelve completed_with_errors o failed, y la métrica pipeline_errors_total{stage} se incrementa. Un alert basado en increase(pipeline_errors_total[1h]) > 0 se dispara antes del segundo run fallido. Sin esta disciplina, la observabilidad existe pero no avisa.

Capa 6 — Control plane GitOps: la única autoridad legítima

Lo que tiene que resolver. Que el estado del cluster sea el estado declarado en git. Que cualquier divergencia entre git y el cluster sea visible y, en componentes críticos, auto-reconciliada o auto-alertada. Que cada imagen desplegada tenga un tag inmutable (sha digest o semver pin), un SBOM (Trivy) y trazabilidad hasta el commit que la introdujo.

Piezas canónicas OSS en 2026.

Flux (o ArgoCD) como reconciliador.
Forgejo (o Gitea, GitLab CE) como forge OSS auto-alojado.
cert-manager + Trust Manager para PKI interna.
External Secrets Operator + SOPS para secretos versionados encriptados.
Kyverno (o OPA Gatekeeper) para policies vinculantes: deny de imágenes :latest, deny de pods sin NetworkPolicy, deny de Services sin owner label.
Trivy para SBOM y vulnerability scanning de imágenes en el pipeline CI.

Lo que rompe la capa. Imágenes con tag mutable (:latest, :main). Cualquier kubectl edit en producción que no se refleja en git. Branches main con permisos de escritura para humanos sin revisión. La regla: si un humano puede mutar el cluster sin pasar por un commit firmado, no tienes GitOps, tienes una pizarra de Pepe.

Cómo se aplica al incidente. Si la imagen del pipeline hubiera estado pinneada a un sha digest (registry.interno.local/jobhunter@sha256:9af2...), el equipo habría podido auditar inmediatamente qué cliente de Ollama llevaba. Con :latest, ni eso.

Capa 7 — Dependency tracking: la capa que el incidente puso de manifiesto

Lo que tiene que resolver. Saber quién llama a qué Service, tanto en declarativo (qué dice el repo gitops) como en observado (qué se ha visto pasar por la red en los últimos N días). Y, en plataformas maduras, propagar esa información como policy: si nadie declara ni nadie observa tráfico al Service ollama.ollama.svc, decomisionarlo es seguro; si alguien lo declara o lo usa, decomisionarlo abre un ticket.

Piezas canónicas OSS en 2026.

Hubble (Cilium) para los flow logs observados: hubble observe --to-namespace ollama --since 14d da la lista de namespaces de origen que han hablado con Ollama en las últimas dos semanas.
Otterize para intent-based policy: cada Deployment declara “yo necesito hablar con ollama-svc”, y el operator genera la NetworkPolicy correspondiente y mantiene un catálogo navegable de quién intenta hablar con qué.
kubectl-grep manual como fallback: kubectl get deployments,cronjobs,statefulsets -A -o yaml | grep -E 'ollama[.-]' saca la lista declarativa.
NetworkPolicy as code revisada en CI: cada PR que toca un Service requiere que la política asociada se mantenga o se actualice explícitamente.

Pre-decom checklist que el incidente sugiere codificar como hook en CI:

SVC="ollama.ollama.svc.cluster.local"

# (a) grep declarativo en el repo gitops
git -C $GITOPS_REPO grep -l "$SVC" || echo "OK declarativo"

# (b) grep observado en Hubble (últimos 14 días)
hubble observe --to-fqdn "$SVC" --since 336h --output json \
 | jq -r '.source.namespace' | sort -u || echo "OK observado"

# (c) grep live en el cluster
kubectl get all -A -o yaml | grep -E "$SVC" || echo "OK live"

Si los tres devuelven vacío, el decom es seguro. Si cualquiera tiene contenido, hay deuda downstream sin cerrar. El incidente de jobhunter es exactamente lo que pasa cuando este check no existe: el equipo que decomisionó Ollama miró la lista de aplicaciones que sabía que dependían directamente; nadie miró la lista de las que dependían en silencio.

Las matemáticas que importan: dimensionar el stack sobre 4×H100 SXM (320 GB)

Cluster genérico de referencia para todo lo que sigue: 4×H100 SXM 80 GB, NVLink entre las cuatro, 640 GB de RAM de sistema, 2×NVMe NVMe-oF para storage local de pesos y caches, redundancia 25/100 GbE hacia el switch. Total VRAM agregada: 320 GB.

El presupuesto VRAM no es libre. Una primera regla de reparto razonable para un stack que sirve un LLM general grande, un modelo especializado en código mediano, embeddings y reranker, con margen para multi-LoRA y para el KV cache:

Componente	Modelo de referencia	Quant	Peso del modelo	KV cache reservado	VRAM total
LLM general (TP=4)	70B-instruct	FP8 W8A8	70 GB	60 GB	130 GB
LLM código (TP=2)	32B-coder	FP8 W8A8	32 GB	28 GB	60 GB
Embeddings	multilingual-e5-large	FP16	1.3 GB	n/a	8 GB (×2 réplicas)
Reranker	bge-reranker-v2-m3	FP16	0.6 GB	n/a	4 GB
Multi-LoRA pool (sobre LLM general)	hasta 16 adapters	bf16	16 × 0.4 GB ≈ 6 GB	reusa KV del LLM	6 GB
Reservado para fragmentación + overhead					~30 GB
Total comprometido					~238 GB / 320 GB
Margen libre					~82 GB

El margen libre del 26% no es desperdicio: es lo que permite que el scheduler de vLLM no preempte requests bajo presión moderada, que el continuous batching pueda agrupar lotes grandes sin abortar, y que un fallover desde el otro site pueda promocionar un standby sin OOM.

Throughput esperado, con el LLM general de 70B en FP8 y tensor parallel 4, en una H100 SXM con continuous batching activo y prefix caching del 35–55% (típico en chat multi-turno con system prompts compartidos):

$$ \text{tokens/segundo agregado} \approx 1500 \text{ a } 2500 $$

para concurrencia entre 32 y 64 requests, con TTFT P95 sub-segundo en prompts cortos (<2k tokens) y TPOT P95 alrededor de 40–60 ms/token percibido por el cliente. Estos números son órdenes de magnitud razonables, no garantías: el throughput real depende del mix de prompts, de si el speculative decoding (EAGLE-3) está activo y burnt-in, y del coste de la red entre gateway y pods de inferencia.

Throughput de embeddings sobre dos réplicas de multilingual-e5-large con batch dinámico:

$$ \text{embeddings/segundo} \approx 3000 \text{ a } 6000 \quad (\text{batch óptimo} \sim 64) $$

Suficiente para reindexar un corpus de 1 millón de documentos en una hora aproximada, asumiendo chunks de 512 tokens y dos chunks por documento de media. Para corpus de decenas de millones de documentos, el reembebido se hace por delta vía CDC sobre la fuente (cubierto en RAG corpus curation), no por barrido.

Latencia de retrieval sobre Qdrant con HNSW (M=16, ef_construct=200) en una colección de 5 millones de vectores 1024-dim filtrada por tenant_id:

$$ \text{P95 latencia retrieve top-50} \approx 8 \text{ a } 25 \text{ ms} $$

Por debajo del coste del reranking cross-encoder (bge-reranker-v2-m3 sobre top-50 = ~30–60 ms más), y por debajo de cualquier llamada al LLM. El cuello de botella en un pipeline RAG bien dimensionado nunca es el vector store: es la decodificación del LLM.

Diagrama final: el stack completo conectado

Las líneas continuas son el camino de la request: cliente → gateway → motor de inferencia → vector store/embeddings → respuesta. Las líneas azules discontinuas son la telemetría: cada componente emite OTel al collector, que enruta traces a Langfuse, métricas a VictoriaMetrics y logs a Loki. Las líneas rojas discontinuas son la reconciliación: el control plane GitOps mantiene cualquier capa en su estado declarado y avisa de divergencia.

El diagrama no es decorativo: cada flecha es un contrato estable entre dos capas. Si una capa cambia (vLLM → SGLang, multilingual-e5 → bge-m3, Qdrant → pgvector), las flechas se mantienen. Esa estabilidad de contratos es la propiedad arquitectónica que hace que un equipo pueda migrar componentes sin romper apps downstream.

Decisiones de diseño típicas que rompen el stack

Lista corta de errores que se ven repetidamente en stacks que parecían bien diseñados sobre el papel:

1. Acoplar el SDK del cliente al motor de inferencia. Quitar el gateway porque “vLLM ya habla OpenAI-compatible” funciona el día uno y duele el día que hay que poner un fallback, un canary o un segundo modelo.

2. Compartir el endpoint LLM y embeddings. Un qwen2.5-32b-Instruct es chat-only; BadRequestError: "The model does not support Embeddings API" es el grito del diseño que confundió las dos capas.

3. Reusar la colección del vector store al cambiar el modelo de embeddings. Dimensiones distintas no admiten upsert. Versionar la colección por (modelo, dim, version) es feo pero salva el día del cambio.

4. try/except que envuelve un pipeline entero con un rótulo del envoltorio. El log miente porque el rótulo es léxico, no causal. Cada stage en su try/except con su rótulo y su métrica.

5. status: completed con errores. El pipeline tiene que distinguir completed, completed_with_errors y failed, y el alerting tiene que disparar en los dos últimos. Sin esto, la observabilidad existe en teoría y no avisa en la práctica.

6. Imágenes con tag mutable. :latest y :main no son tags, son alias. Sin sha digest, no hay reproducibilidad ni SBOM auditable.

7. Decomisionar un Service sin pre-decom check. El check de tres greps (declarativo + observado + live) tarda dos minutos y cuesta seis días de incidente cuando se salta.

8. Limits.memory por defecto en pods que cargan modelos. Un sidecar que carga sentence-transformers + torch + tokenizer necesita 2–4 GB; con limits.memory: 1Gi te encuentras con OOM en el primer pod restart, y a veces sin alert si el liveness probe responde por otra ruta.

Todas son variantes del mismo principio: el stack no falla en su capa más cara (la inferencia, donde nadie subestima el coste), falla en las capas baratas y aburridas (gateway, observabilidad, GitOps, dependency tracking) donde es tentador ahorrar.

Aplicado a hardware on-premise típico: cluster 4×H100 SXM

Sobre el cluster genérico de referencia (4×H100 SXM 80 GB, NVLink, 640 GB RAM), el reparto en pods sugerido:

nodo-gpu-01 (4×H100 SXM, NVLink intra-nodo)
├── vllm-llm-general (TP=4) ~130 GB VRAM (4 GPUs)
└── (comparte GPUs con multi-LoRA pool sobre el mismo deployment)

nodo-gpu-02 (4×H100 SXM, segundo nodo)
├── vllm-llm-codigo (TP=2) ~60 GB VRAM (2 GPUs)
├── infinity-embeddings (×2) ~16 GB VRAM (compartido en 1 GPU con MIG opcional)
├── tei-reranker ~4 GB VRAM (cohabitante)
└── reserva fallover ~120 GB VRAM libre para canary / standby

En un único nodo no cabe todo cómodamente; dos nodos con dos H100 SXM cada uno bastarían para el setup conservador, y el resto del cluster (CPU-bound: gateway, vector store, observabilidad, control plane) corre en nodos sin GPU.

La regla operativa: la inferencia se concentra, el resto del stack se distribuye. Concentrar la inferencia maximiza el aprovechamiento de NVLink (tensor parallel cross-GPU sin pasar por PCIe); distribuir el resto evita que un evento en el nodo GPU se lleve por delante el control plane.

Una configuración aún más conservadora —para PYMEs con un solo nodo 4×H100 SXM como punto de partida— sirve LLM general (TP=4) y embeddings/reranker en cohabitación con MIG (Multi-Instance GPU para particionar una H100 en slices aisladas hardware). El LLM de código se difiere a una segunda fase. Es viable y consciente del coste; lo que no es viable es prescindir de las capas 5, 6 y 7.

Lo que no hemos cubierto (próximos posts)

Este post se centra en el diseño estático del stack. Quedan piezas que merecen su propio artículo:

El plano multi-site activo/standby: Cilium Cluster Mesh, replicación Qdrant cross-cluster, RTO/RPO realistas, cuándo activo-activo paga y cuándo no.
El plano de fine-tuning continuo: cómo el pipeline LoRA cierra el bucle desde feedback de producción a adapter promovido, en el espíritu del post de retrain.
El plano de safety/guardrails: dónde encaja Llama Guard, Presidio para PII y XGrammar para structured output garantizado, conectado a la capa 1 del gateway.
El plano de coste: instrumentación gen_ai.usage.* a nivel tenant y modelo, dashboards de tokens/euro, decisiones de elasticidad GPU vía KEDA.
El plano de cumplimiento: cómo el stack se mapea a ENS Alto, NIS2 e ISO/IEC 42001 sin convertir el deployment en un ejercicio de compliance que paraliza la entrega.

Cada uno cae en una serie distinta del blog y se cubrirá con la misma disciplina: pieza concreta, decisión justificada, error típico que se ve en la práctica.

Referencias

Pipeline LLMOps de seis etapas — el marco general en el que este stack opera.
El catálogo OSS para LLMOps en seis etapas — ficha por ficha de cada herramienta del stack.
Anatomía de una petición LLM en producción — la misma arquitectura vista desde la perspectiva de una request individual.
OSS vs hyperscalers en LLMOps — comparación con las stacks de AWS/Azure/GCP.
Tracing LLM con OpenTelemetry GenAI — la columna vertebral de la capa 5.
Multi-LoRA serving — la pieza que da personalización per-tenant sin replicar el base.
RAG corpus curation y Reranker y hybrid retrieval — todo lo que entra en la capa 3-4 para que el RAG no degrade.
Quantization para inferencia LLM — el porqué del FP8 W8A8 del dimensionado.

Documentación oficial relevante

vLLM Production Stack — docs.vllm.ai
SGLang RadixAttention — github.com/sgl-project/sglang
Envoy AI Gateway — aigateway.envoyproxy.io
Langfuse self-hosted — langfuse.com/docs/self-hosting
OpenTelemetry Semantic Conventions for GenAI — opentelemetry.io/docs/specs/semconv/gen-ai
Hubble flow observability — docs.cilium.io/en/stable/observability/hubble
Otterize intent-based access — docs.otterize.com
Flux GitOps toolkit — fluxcd.io