From Cloud to Metal: la evolución natural de un caso de uso de GenAI
"Nos está yendo muy bien con Claude Opus, pero la factura empieza a doler. ¿Cuál es el siguiente paso?"
Esa frase, o alguna variante, es el arranque más frecuente en las conversaciones de GenAI que tengo con clientes. Y es también el momento en el que el debate deja de ser experimental y pasa a ser arquitectónico. La fase emocionante ha terminado; empieza la de ingeniería de costes.
Quiero compartir el patrón que se repite en esas conversaciones —y, más importante, el que sigo defendiendo— porque casi toda iniciativa seria de GenAI acaba recorriendo el mismo camino. Empieza en cloud con un modelo frontier, madura con prompt engineering y fine-tuning, pasa a pesos open-source y, tarde o temprano, toca hardware real en un rack. No porque "on-prem haya vuelto", sino porque la economía de la inferencia, la madurez de los modelos open-source y la llegada de una nueva generación de GPUs han hecho cuadrar los números sin ruido. Y, para un conjunto creciente de casos de uso, el compliance toma la decisión por ti.
Fase 1 — La luna de miel en cloud
Toda conversación sobre GenAI que he tenido en los últimos tres años empieza igual: una API gestionada, típicamente Anthropic, OpenAI, Gemini o alguno de los wrappers de Bedrock / Azure / Vertex. Aquí no hay debate, y no debería haberlo. Cuando necesitas validar si una idea es siquiera usable, no quieres ir de compras de GPUs: quieres un modelo frontier de nivel productivo respondiendo tu primer curl en menos de cinco minutos.
La propuesta de valor es difícil de batir:
- Cero CapEx, OpEx predecible, pago por token.
- Calidad state-of-the-art el día uno (Claude Opus 4.7, GPT-5.5, Gemini 2.5 Pro).
- Compliance, SLAs y opciones de residencia de datos ya negociados por el hyperscaler.
- Velocidad: cada pocos meses la línea base mejora mientras tú duermes.
Es la luna de miel. Los equipos lanzan el PoC, validan el business case y consiguen sponsorship interno. El uso crece. La factura crece con él. Y, una mañana, alguien de finanzas mira la factura y la pregunta del arranque aterriza en algún buzón.
Fase 2 — La meseta de eficiencia
Uno de los errores más frecuentes es saltar de "la factura cloud duele" directamente a "vamos a auto-hospedar". No lo hagas. Existe toda una capa intermedia de optimización que debería agotarse antes, porque es barata, reversible, y a menudo ahorra más dinero del que jamás ahorrará una migración de hardware.
Es la fase de exprimir el modelo frontier:
- Prompt engineering con visión de coste. Prompts de sistema largos, definiciones de tools verbosas, few-shot examples repetidos: cada uno de esos tokens aparece al 100% en todas las llamadas. Comprimir un prompt de 4k a 1k tokens, a escala, paga un consultor.
- Prompt caching. El 90% de descuento sobre input cacheado que ofrece Anthropic no es un nice-to-have: convierte el contexto estático en un recurso casi gratis. Lo mismo con las tarifas de caché de OpenAI y Gemini.
- Routing de modelos. Gateways tipo LiteLLM o CLIProxyAPI permiten mandar clasificaciones fáciles a Haiku 4.5 o Gemini Flash (~$1/$5 y ~$0.30/$2.50 por 1M tokens) y escalar solo el razonamiento complejo a Opus o GPT-5 Pro. Un router bien ajustado tira el coste mezclado un 60–80%.
- RAG agresivo. Contexto corto y relevante, no "métele el documento entero". Caché semántica en la capa de retrieval (Redis + embeddings) absorbe las preguntas recurrentes.
- Batch + async. Tanto Anthropic como OpenAI dan 50% vía batch APIs. Para todo lo que no sea estrictamente síncrono, eso es dinero gratis.
Tras una buena pasada de optimización, muchos casos dejan de sangrar. Has extendido el runway cloud varios meses, a veces años. Pero para cierta clase de workload —volumen alto, patrones predecibles, datos sensibles— la balanza acaba volviéndose a inclinar. Y entonces entra la Fase 3.
Fase 3 — El pivote a open-source
Hace dos años, sugerir Llama o Mistral como alternativa seria a Claude o GPT era como defender un 10% de descuento a cambio de un 40% de caída de calidad. La respuesta habitual: "no compensa". Esa ecuación se ha invertido, silenciosa pero decisivamente.
Un puñado de releases de los últimos doce meses han sido inflexiones reales. Gemma 3 abrió la puerta con su modelo denso de 27B y la cuantización QAT. Gemma 4, publicado el 2 de abril de 2026 bajo licencia Apache 2.0, la cruza: una familia de cuatro tamaños (E2B para teléfonos, E4B para edge, un 26B MoE con 3,8B parámetros activos para GPUs de consumo y un 31B denso para workstations), entrada multimodal, ventana de contexto de 256K y soporte para 140+ idiomas. El 31B denso marca 85,2% en MMLU Pro, 89,2% en AIME 2026 y ocupa el #3 del leaderboard de Arena AI — cifras impensables en un modelo open-weight hace apenas un año.
Alrededor de Gemma 4, el resto del campo open-source ha madurado en paralelo. GLM-4.6 iguala a Claude Sonnet en benchmarks de coding. Qwen3.6-27B, publicado en abril 2026 bajo Apache 2.0, supera genuinamente a MoEs de 397B parámetros en tareas de coding agéntico. DeepSeek V3 y R1 reventaron MMLU y AIME con licencia permisiva. Phi-4, a 14B, es absurdamente bueno para su tamaño, y su variante reasoning-plus bate a o1-mini. Kimi K2.6 lidera SWE-Bench con MIT modificada.
El movimiento clave aquí no es reemplazar — es hacer fine-tuning para el caso de uso. Un Gemma 4 31B, afinado sobre un dominio concreto con unos pocos miles de ejemplos curados, acompañado de buen prompting y un RAG sólido, bate al modelo frontier genérico en esa tarea. El frontier siempre será más versátil; pero la versatilidad no es lo que la mayoría de workloads de producción necesita. Necesitan fiabilidad en una rebanada estrecha.
El disparador en las conversaciones recientes ha sido precisamente Gemma 4 — es el gran nombre del momento y cabe cómodo en hardware tipo workstation. Lo que nos lleva directo a la Fase 4.
Fase 4 — La prueba de realidad del hardware
Hasta hace poco, "inferencia LLM on-prem" significaba una cosa: tarjetas clase H100 en el tier premium de datacenter — decenas de miles bajos por tarjeta, pedidas a un reseller con plazos de meses. Para la mayoría de compañías medianas eso era un no-arranque, y con razón.
Desde el Q1 de 2026 la realidad del suministro se ha endurecido de forma notable: la capacidad de NVIDIA H100, H200 y B200 está prácticamente agotada, el packaging CoWoS de TSMC está asignado hasta mediados de 2027, los hyperscalers absorbieron la mayor parte de la cuota Blackwell con pedidos colocados en 2024-2025, y los compradores nuevos se enfrentan a plazos de 12-18 meses para pedidos volumétricos. Los precios de alquiler en los pocos proveedores cloud que todavía tienen capacidad han subido un 30-40% en tres meses. Esto está cambiando la decisión — pero no en la dirección que la mayoría espera. Está empujando a las organizaciones medianas hacia on-prem, no lejos de él, porque el fallback cloud se ha vuelto a la vez más caro y menos fiable.
Dos cosas han cambiado la ecuación en los últimos doce meses:
- RTX PRO 6000 Blackwell, 96 GB de VRAM, MSRP de NVIDIA en miles altos de un solo dígito USD (referencia: 8.435 $). Es una GPU de clase workstation que aloja Gemma 4 31B, Qwen3.6-27B, Phi-4 o Llama 4 Scout en cuantización Q4 con margen cómodo para contexto. Dos de ellas en el mismo chasis — decenas bajas de miles en silicio más un servidor decente — cubren la inferencia de muchísimos workloads.
- El stack software alcanzó la madurez. vLLM con PagedAttention y continuous batching, SGLang para prefix-sharing (workloads agénticos, RAG con prompts de sistema grandes), TensorRT-LLM para producción single-model. Ollama hace trivial el setup local de un desarrollador. Y ROCm 7 por fin convierte a los AMD MI300X / MI350X en ciudadanos de primera — una sola MI350X con 288 GB de HBM3e ejecuta modelos de 520B parámetros por sí sola.
Para los casos más exigentes —modelos de cientos de miles de millones de parámetros, concurrencia muy alta— H200 (141 GB HBM3e) y B200 (192 GB HBM3e) son el camino obvio. El B200 se está sirviendo a un precio parecido al del H100 antiguo, con 2,4× más memoria y ancho de banda notablemente mejor, aunque los plazos siguen siendo dolorosos por un backlog reportado de 3,6 millones de unidades.
Un efecto de segundo orden de la escasez es que el mercado refurbished ha madurado rápidamente y ha dejado de ser un rincón para hobbyistas. Las tarjetas NVIDIA A100 80GB usadas se mueven en el rango de miles bajos a altos de un solo dígito USD — alrededor de un 40-70% por debajo del precio nuevo — y hay servidores de inferencia completos refurbished (clase DGX A100, clase HGX A100) disponibles en vendedores establecidos, con garantía y componentes validados. Para workloads de inferencia, la distancia frente al H100 es sorprendentemente pequeña, y la disponibilidad del A100 es excelente precisamente porque las organizaciones están actualizándose a Blackwell y liberando su fleet de generación anterior al mercado secundario. Muchos equipos que levantan su primer rack de inferencia on-prem en 2026 lo están haciendo sobre hardware refurbished A100, o H100 temprano, recortando el CapEx a la mitad y acortando el break-even de TCO de forma significativa.
La tabla que quieren ver casi todos los clientes queda así:
| GPU | VRAM | Tier / coste relativo | Aloja (Q4) |
|---|---|---|---|
| RTX 6000 Ada | 48 GB GDDR6 | Tier workstation, miles altos de un solo dígito USD | Gemma 4 26B MoE, Phi-4 14B, Qwen2.5 32B (ajustado) |
| RTX PRO 6000 Blackwell | 96 GB GDDR7 | Tier workstation, MSRP NVIDIA ~8.435 $ | Gemma 4 31B denso, Qwen3.6-27B, Llama 4 Scout, GLM-4.6 (Q4, apretado) |
| H100 SXM / PCIe | 80 GB HBM3 | Tier premium DC, decenas bajas de miles USD | Llama 3.3 70B FP8, shards de Qwen3-235B |
| H200 | 141 GB HBM3e | Premium DC, salto notable sobre H100 | Qwen3-235B cómodo, DeepSeek V3 fragmentado |
| B200 | 192 GB HBM3e | Top NVIDIA, plazos 12-18 meses | Workloads next-gen, 200B+ denso en una sola GPU |
| AMD MI300X | 192 GB HBM3 | Clase H100/H200, precio lista habitualmente menor | Misma clase que H100/H200, ROCm 7 + vLLM |
| AMD MI350X | 288 GB HBM3e | Flagship AMD, tier premium DC | Modelos de 520B parámetros en una sola tarjeta |
| NVIDIA A100 80GB (refurbished) | 80 GB HBM2e | Mercado secundario, ~40-70% por debajo del nuevo | Llama 3.3 70B FP8 (ajustado), Gemma 4 31B FP16, Qwen3.6-27B BF16 — sweet spot coste/rendimiento para inferencia |
La razón por la que la RTX PRO 6000 Blackwell merece subrayarse en la mayoría de casos mid-size es pragmática: está en el punto dulce en el que el coste del hardware ya no domina la conversación. Un nodo de inferencia con dos tarjetas ronda el coste de dos o tres meses de una factura Claude Opus moderada.
La palanca del compliance
Todo lo anterior ha sido argumento de coste. Pero para una lista creciente de workloads, la decisión de ir on-prem no se toma en finanzas — se toma en legal y en riesgos. Y en esas salas el precio por token no importa.
Los patrones que se repiten:
- Banca y seguros. DORA y las guías de la EBA empujan los workloads críticos fuera del procesado no-UE. Incluso dentro de la UE, instituciones concretas exigen aislamiento bare-metal y acceso controlado a los endpoints de inferencia.
- Sanidad. Artículo 9 del GDPR, normativas nacionales de datos de salud y códigos de conducta sectoriales. Enviar datos de pacientes a un modelo alojado en US, aunque sea a través de un wrapper "compliant", es una conversación que ningún CISO quiere tener dos veces.
- Defensa, infraestructura crítica, sector público. ENS Alto en España, BSI-C5 en Alemania, SecNumCloud en Francia. O la inferencia corre dentro de un perímetro certificado, o no corre.
- Servicios legales y profesionales. Secreto profesional. Notas internas y trabajo sobre casos no pueden abandonar la frontera técnica del despacho.
El crossover de TCO
Para todo lo que queda fuera del bucket de compliance-obligatorio, la decisión vuelve a los números. Hagámoslos sin rodeos, porque aquí es donde se toman o se matan la mayoría de decisiones arquitectónicas.
Un modelo tipo Gemma 4 31B corriendo en un nodo de dos RTX PRO 6000 Blackwell puede servir realistamente entre 1 y 2 mil millones de tokens al mes en estado estable, 24/7, con vLLM haciendo batching bien. El volumen equivalente en Claude Sonnet 4.6 (a 3 $/15 $ por 1M tokens, con ratio conservador 1:1 input/output) sale aproximadamente 18.000 $/mes. La inversión en hardware — dos tarjetas, servidor, red, un año de colocation en un proveedor europeo razonable (~150–220 $/kW/mes) — se amortiza en seis a nueve meses.
Si el mismo rack se monta sobre tarjetas A100 80GB refurbished, el relato se vuelve aún más agresivo: un nodo de dos tarjetas se puede ensamblar en el rango de decenas bajas de miles de USD todo incluido (tarjetas + chasis), lo que empuja el break-even por debajo de los cuatro meses para el mismo workload — a cambio de un pequeño descuento en throughput y un stack de drivers ligeramente más antiguo. Para muchos casos de alta utilización, ese trade-off es precisamente el correcto en el entorno de suministro de 2026.
La línea de break-even cambia brutalmente con el tamaño de modelo y la utilización:
- Modelos pequeños (<30B) con alta utilización: semanas o pocos meses.
- Medianos (tipo 70B): unos dos años.
- Muy grandes (>200B MoE): cinco años o más.
El coste no obvio es la utilización. Si el nodo está al 40% de carga, gana el cloud. Por debajo del 65% la ventaja contra MaaS se evapora rápido. Hace falta tráfico estable o multi-tenancy para mantener las GPUs calientes. Por eso la historia on-prem es más sólida para organizaciones con un puñado de casos de uso estables de alto volumen, no para las que gestionan una cola larga de experimentos de bajo volumen.
Y un dato que suele sorprender: la electricidad es ruido. Un despliegue bien afinado de Llama-3 70B FP8 en 8×H100 quema unos 0,108 kWh por millón de tokens. A tarifa industrial europea, eso son aproximadamente 0,016 €/1M tokens. El coste de la inferencia es la amortización del hardware, no la factura de la luz.
Fase 5 — El destino es híbrido
Nadie vuelve al 100% on-prem. Esa es la idea más importante que hay que tener clara. El destino no es una migración, es un portfolio:
- On-prem para los workloads estables y de alto volumen — y para todo lo que compliance marque como "estos datos no salen del perímetro". Clasificación, summarization, code completion sobre repos internos, chat sobre bases de conocimiento internas, procesado de datos regulados.
- Cloud frontier para lo difícil y lo nuevo. Razonamiento novedoso, workflows agénticos que necesitan el mejor modelo del día, experimentos tempranos.
- Cloud frontier también como burst por encima de tu baseline on-prem. El rack absorbe la mediana; el cloud absorbe los picos — aunque, en el entorno de suministro de 2026, incluso esa capacidad de burst se ha vuelto cara y, a ratos, no disponible, lo que paradójicamente hace que un baseline on-prem correctamente dimensionado sea más importante, no menos.
Operativamente, esto implica construir —o adoptar— una plataforma de inferencia que abstraiga el origen del modelo y la envuelva con los elementos no negociables: un LLM gateway que oculte al proveedor tras una única interfaz, guardrails que impongan seguridad y prevención de fuga de datos, routing inteligente que envíe cada request al backend correcto, y caché semántica para recortar coste repetido. Tus aplicaciones no deberían tener que preocuparse de si el request acaba en tu datacenter o en api.anthropic.com.
Ya sea a través de una plataforma propia o una empaquetada, esa capa es, en mi experiencia, la decisión arquitectónica más infravalorada en cualquier plataforma GenAI a día de hoy. Una tarde de fontanería (o una instalación de producto) que da años de optionalidad.
Reflexión final
Cuando un cliente pregunta "¿dónde deberíamos ir a continuación?", raramente está preguntando por una tecnología concreta. Está preguntando si el camino que lleva tiene futuro. Mi respuesta es consistente: sí, y acaba con vosotros siendo dueños de parte de vuestro stack. No por ideología, no por miedo al lock-in — simplemente porque, llegado cierto punto, los números, la calidad de los modelos abiertos, la presión regulatoria y la madurez del tooling apuntan todos en la misma dirección.
Las organizaciones que ganarán la siguiente fase de GenAI no son las que escogieron el modelo correcto en 2024. Son las que diseñan su arquitectura hoy de modo que cambiar de modelo — y cambiar dónde corre ese modelo — sea una operación rutinaria, no un proyecto. Cloud para velocidad, open-source para optionalidad, hardware propio para economía, una plataforma adecuada para compliance y control. Esa es la fórmula. Nadie tiene que elegir una sola esquina.
Lo bonito de esta industria ahora mismo es que, por fin, las piezas son intercambiables.
Volver a artículos