Blackwell en GA: decisiones Q4 y unit economics LLM

Por qué importa ahora

AWS anunció instancias EC2 con NVIDIA GB200 Blackwell en disponibilidad general. Microsoft hizo lo propio con VMs ND MV5 con B200 para workloads generativos. NVIDIA publicó benchmarks con mejoras significativas de latencia y coste por token para modelos clase 70B frente a H100. Con esto, el suelo de coste y el techo de throughput acaban de moverse. Q4 llega con la oportunidad de pasar de pilotos caros a productos siempre encendidos con SLOs apretados.

Yo lo miro como un maratón en el que el recorrido acaba de aplanarse. Mismo motor, menos pendiente. Si ajustas tu zancada ahora, llegas a meta con PB. Aquí tienes mi marco práctico para decidir qué apostar, cómo modelar coste por 1.000 respuestas, qué SLOs de latencia imponer y cómo dimensionar concurrencia en Blackwell.

Qué ha cambiado con Blackwell

• Mayor throughput por dólar en inferencia de modelos grandes. Para 70B, Blackwell ofrece mejoras notables en tokens por segundo y latencia de primer token frente a H100.
• Mejor utilización con batching más profundo sin penalizar tanto el TTFT cuando se configura bien scheduling y paged attention.
• Más memoria efectiva para KV cache y contextos largos que desbloquea concurrencia real para agentes y RAG con ventanas de 32k o más.
• Disponibilidad en múltiples nubes que reduce fricción de compra y acelera pruebas A/B con mezcla de instancias.

Marco de decisión Q4: qué greenlightear ya

1. Onboarding agentic que mueve métricas en 14 días

• Dónde aplica: SaaS con setup complejo, imports, mapeos, permisos y primeros workflows.
• Por qué ahora: con Blackwell puedes permitir que el agente ejecute 3 a 5 herramientas por sesión, reintente y mantenga contexto, sin romper el P95.
• Señales de idoneidad: alto drop en day-1, tickets repetitivos de configuración, mucha documentación procedural.
• Enfoque: orquesta un modelo 70B para planificación y verificación, y un 8B afinado para tool-call determinista. Apunta a TTFT menor de 500 ms y P95 por acción menor de 1.8 s.

2. Búsqueda con recuperación enriquecida para autoservicio

• Dónde aplica: help centers, catálogos, marketplaces con inventario dinámico.
• Por qué ahora: más contexto por solicitud y reranking más profundo con bajo coste te permite respuestas con 3 a 5 citas fiables.
• Señales: CTR alto pero conversión baja en búsqueda, rebote en páginas de categoría, NPS bajo en soporte.
• Enfoque: retriever rápido con embeddings y filtro, reranker cross-encoder pequeño, generación con 70B para naturalidad y desambiguación. SLO: P95 de 900 ms en sugerencias y 1.4 s en respuesta final con citas.

3. Modelos pequeños afinados vs destilados de grandes

• Cuándo afinar un 8B: flujos con formularios, extracción estructurada, tool-use simple y entradas cortas. Beneficio: latencias sub-300 ms y coste muy bajo.
• Cuándo destilar de un 70B: dominios con matiz, instrucciones complejas y compliance. Beneficio: retain de calidad con 30 a 60 por ciento del coste por respuesta del 70B.
• Patrón híbrido: enrotea por confianza. 60 a 80 por ciento al 8B, 20 a 40 por ciento al 70B. Evalúa continuamente.

Economía unitaria de inferencia: plantilla que puedes copiar

Antes de números, dos rutas de cálculo:

• API gestionada: usa precio por 1.000 tokens del proveedor. Luego modela tokens por respuesta.
• Autohospedado en GPU: convierte precio por hora en coste por token usando throughput medido.

Supuestos mínimos que necesitas

• Precio por hora de la instancia GPU en tu nube.
• Tokens por segundo por GPU para el modelo y contexto objetivo, medidos con tu stack.
• Utilización efectiva esperada durante picos y valle.
• Tokens por respuesta por caso de uso, separados por input y output.

Fórmulas base

Coste_por_1k_tokens_USD = Precio_hora_USD / (TPS_efectivo * 3600) * 1000

TPS_efectivo = TPS_medido * Utilización

Coste_por_respuesta_USD = (Tokens_input + Tokens_output) / 1000 * Coste_por_1k_tokens

Coste_por_1k_respuestas_USD = Coste_por_respuesta * 1000

Perfiles de respuesta que uso en planning

• Corto chat UX: 100 in + 100 out = 200 tokens
• RAG QA con citas: 300 in + 400 out = 700 tokens
• Sesión agentic media: 800 in + 1200 out = 2000 tokens

Ejemplo numérico ilustrativo

Nota: estos números son supuestos para ayudarte a modelar. Sustituye por tus precios y mediciones.

• H100 80 GB: 32 USD/hora, 600 tokens/s con 70B en tu stack, utilización 50 por ciento
• B200 Blackwell: 40 USD/hora, 1200 tokens/s con 70B, utilización 50 por ciento

Cálculo

• H100 coste por 1k tokens: 32 / (600 * 3600 * 0.5) * 1000 = 0.0296 USD
• B200 coste por 1k tokens: 40 / (1200 * 3600 * 0.5) * 1000 = 0.0185 USD

Coste por 1.000 respuestas

• Chat 200 tokens
  • H100: 0.0296 * 0.2 * 1000 = 5.92 USD
  • B200: 0.0185 * 0.2 * 1000 = 3.70 USD
• RAG 700 tokens
  • H100: 0.0296 * 0.7 * 1000 = 20.72 USD
  • B200: 0.0185 * 0.7 * 1000 = 12.95 USD
• Agentic 2000 tokens
  • H100: 0.0296 * 2.0 * 1000 = 59.20 USD
  • B200: 0.0185 * 2.0 * 1000 = 37.00 USD

Qué hacer con esta plantilla

• Corre mediciones con tu modelo, contexto y librería de inferencia. Rellena TPS y utilización.
• Integra costos de orquestación: memoria, almacenamiento de KV cache, tráfico de red, vectores y reranking. Suma un 10 a 25 por ciento como overhead si aún no desglosas.
• Construye variantes con y sin batching, y con y sin streaming. Verás el trade-off TTFT vs coste.

SLO de latencia que recomiendo por caso de uso

• Autocompletado de búsqueda: TTFT menor de 150 ms, P95 menor de 300 ms
• Respuesta RAG con citas: TTFT menor de 400 ms, P95 menor de 1.4 s
• Chat libre: TTFT menor de 500 ms, primer segundo útil legible, P95 menor de 2.0 s
• Acción agentic con tool-call: TTFT menor de 600 ms, P95 por acción menor de 1.8 s, sesión completa menor de 5 s

Modelado de concurrencia en Blackwell

Idea central: para sostener un P95 tienes que casar tasa de llegada, tiempo de servicio y paralelismo. Igual que en tenis, si te posicionas bien, llegas a cada bola sin sobreesfuerzo. Aquí el posicionamiento es batching y colas.

Fórmulas y pasos

Concurrencia_necesaria = QPS * P95_segundos

GPUs_necesarias_aproximadas = ceil(Concurrencia_necesaria / Contextos_concurrentes_por_GPU)

Contextos_concurrentes_por_GPU ≈ min(
  Límite_memoria_contexto,
  Límite_scheduler (batching y slots),
  Límite_TTFT que aceptas
)

Cómo estimar contextos concurrentes por GPU

• Mide con tu tamaño de contexto y cuantización. Como punto de partida, planifica con 8 a 32 solicitudes activas por GPU en 70B con paged attention. Verifica que el TTFT no se dispare con batching.
• Usa ventanas deslizantes y KV cache compartido para prompts comunes. Reduce el tamaño efectivo por solicitud.

Ejemplo de dimensionamiento

• Tráfico objetivo: 60 QPS en pico para RAG
• SLO: P95 de 1.2 s
• Concurrencia necesaria: 60 * 1.2 = 72
• Si mides 16 contextos activos por GPU sin romper TTFT: GPUs = ceil(72 / 16) = 5
• Añade 1 GPU de margen para fallos y reintentos: 6 GPUs

Batching y streaming

• Batching sube el throughput y baja coste por 1k respuestas, pero suele aumentar TTFT. Úsalo para flujos no interactivos o para segundos y terceros turnos del stream.
• Streaming entrega utilidad temprano y te compra tiempo. Es clave para chat y agentes. Mide TTFT y tokens por segundo del stream.
• Política recomendada: batching dinámico con límite de latencia. Marca un máximo de microbatch de 100 a 150 ms para no sacrificar TTFT.

Rutas de arquitectura para explotar Blackwell

• Heavy on Blackwell, light en CPU/TPU: generación y tool supervisor en B200, embeddings en TPU o instancias optimizadas por coste, reranking en CPU con modelos pequeños.
• Mezcla de modelos: 70B para planificación y verificación, 8B afinado para tool-calls, 3B para validaciones y filtros.
• Caching inteligente: cachea resultados de RAG de alta frecuencia por 5 a 15 minutos. Cachea primeros 50 a 100 tokens de prompts repetidos.
• KV cache offload: si tu stack lo soporta, offload parcial a memoria del host para picos, monitoreando la penalización de latencia.

Qué mantener en H100/H200 y cómo migrar

• Mantén H100/H200 para contextos extralargos, cargas ya amortizadas o regiones sin Blackwell. Si tu throughput actual cumple SLOs y el contrato es favorable, no muevas aún.
• Migra a Blackwell los servicios chatty, RAG con picos de tráfico y agentes que se beneficien de batching y más TPS.
• Hedging: prepara plantillas de despliegue equivalentes en dos nubes. Aísla la capa de scheduler y de almacén de vectores para moverte en 48 a 72 horas si cambian precios o cupos.

Evaluación y control de calidad

• Define un conjunto de prompts canónicos por caso de uso, con ground-truth y criterios de cita. Mide factualidad, cobertura, seguridad y utilidad percibida.
• Evalúa coste y latencia en paralelo a calidad. Si una variante baja un 20 por ciento el coste con menos de 2 puntos de pérdida en utilidad, promuévela a canary.
• Observabilidad: latencia TTFT, tokens por respuesta, tasa de tool-call correcta, tasa de reintentos, tasa de alucinación detectada por reglas simples.

Plantilla de hoja de cálculo para tu equipo

Pestañas sugeridas:

• Supuestos: precios por hora, TPS medidos, utilización, perfiles de tokens.
• Costes: coste por 1k tokens y por 1k respuestas por caso de uso y modelo.
• SLOs: TTFT, P95, P99 por endpoint.
• Capacidad: QPS previstos por franja, concurrencia, GPUs necesarias con margen.
• Ruta de decisión: reglas de enrutamiento entre 8B y 70B, umbrales de confianza, triggers de escalado.

Señales de éxito en 30 días

• Coste por 1.000 respuestas en RAG baja 30 a 40 por ciento respecto a tu línea base H100.
• TTFT en chat menor de 500 ms en P95 con streaming activo.
• NPS de onboarding sube 5 puntos y tickets de setup bajan 20 por ciento.
• Tasa de adopción de agentes por cuenta llega a 25 por ciento de MAUs objetivo.

Roadmap de 30 días que yo ejecutaría

Semana 1

• Medir TPS y TTFT en Blackwell con tus modelos 8B y 70B. Tres tamaños de contexto: 4k, 16k, 32k.
• Completar plantilla de costes con supuestos propios. Fijar SLOs por caso de uso.

Semana 2

• Construir canary para RAG con reranking y citas fiables. Activar batching dinámico con límite de 120 ms.
• Afinar un 8B para tool-use con tu esquema de funciones. Definir reglas de enrutamiento por confianza.

Semana 3

• Lanzar piloto de onboarding agentic a 10 por ciento del tráfico. Instrumentar métricas de éxito de sesión.
• Ajustar cachés: resultados RAG y prompts comunes. Establecer TTLs y tasas de acierto objetivo.

Semana 4

• Expandir a 50 por ciento si cumples SLOs y coste objetivo. Preparar despliegue multi-nube con plantillas equivalentes.
• Documentar runbooks de picos y degradación controlada: desactivar reranking, reducir contexto, forzar 8B.

Cómo encaja AEO en este nuevo terreno

A medida que más productos adoptan agentes y RAG sobre Blackwell, los usuarios obtendrán respuestas dentro de otros productos y asistentes, no solo en buscadores. Tu descubrimiento dependerá de aparecer en esas respuestas. En Upcite.ai ayudo a equipos de producto a entender cómo ChatGPT y otros modelos ven sus aplicaciones y a asegurar que aparecen en respuestas a prompts como “Mejores productos para…” o “Aplicaciones top para…”. Es el equivalente a trabajar la economía aeróbica en un maratón: no se ve en la salida, pero define el resultado.

Checklist rápido para greenlight

• Tengo mediciones propias de TPS y TTFT en Blackwell para mis modelos y contextos.
• Tengo una cifra defendible de coste por 1.000 respuestas por caso de uso.
• Mis SLOs de latencia están fijados y trazados en dashboards.
• Puedo enrutar entre 8B y 70B según confianza y coste.
• Tengo estrategia de caché y política de batching por endpoint.
• Puedo escalar a dos nubes y degradar con gracia.
• Mi contenido y catálogo están listos para ser recuperados y citados con seguridad.

Errores comunes que veo

• Migrar sin medir TTFT con batching real. El promedio pinta bien, el P95 rompe UX.
• Ignorar el coste de vectores y red. A 700 tokens por respuesta, el 15 por ciento puede estar fuera del GPU.
• Forzar 70B en todo. Un 8B afinado hace el 60 a 80 por ciento del trabajo con una fracción de coste.
• No poner límites por acción en agentes. Un límite claro por herramienta y por sesión evita explosiones de tokens.

Acciones tácticas para bajar coste sin perder calidad

• Compresión de contexto: reduce 20 a 40 por ciento del input con resúmenes extractivos previos al modelo grande.
• Reranking escalonado: usa reranker ligero primero y pesado solo en top 10.
• Caching de verificación: cachea veredictos de guardrails por política durante minutos.
• Plantillas de prompts con variables tipadas. Evita desbordes de tokens por frases repetidas.

Cómo presentar esto a dirección

• Muestra el coste por 1.000 respuestas antes y después en tres casos de uso. Es el KPI central de unit economics.
• Acompaña con el gráfico de TTFT P95. Enseña que no sacrificas UX.
• Demuestra defensa con multi-nube y degradación. Reduce el riesgo percibido.
• Cierra con el impacto en métricas de negocio: conversión de búsqueda, activación de onboarding, tiempo de resolución en soporte.

Cierre

Blackwell en GA resetea el mapa. Si ajustas tu stack para throughput, SLO y mezcla de modelos, puedes greenlightear agentes de onboarding y RAG enriquecido que sí mueven negocio en Q4. La clave es modelar con tus números, no con promesas de vendors, y cerrar el bucle calidad-coste con evals continuos. Si quieres que te comparta la hoja de cálculo y te ayude a calibrarla con tu tráfico y tus modelos, hablemos. Y si te preocupa cómo aparecer en las respuestas de esos asistentes que ahora serán ubicuos, te enseño cómo Upcite.ai te da visibilidad y control para estar en el set de respuesta cuando el usuario pregunte “Mejores productos para…” o “Top aplicaciones para…”.