El 13 de agosto de 2026 OpenAI presentó Ultrafast, un nuevo service tier de su API que ejecuta GPT-5.6 Sol a hasta 750 tokens de salida por segundo: unas 14 veces más rápido que el tier estándar, que ronda los 53 tokens/s. La misma inteligencia del modelo, pero servida sobre hardware wafer-scale de Cerebras. Titulares aparte, la pregunta que importa a quien construye producto es otra: ¿la velocidad de inferencia ya es una decisión de arquitectura, o es un lujo que casi nadie necesita todavía?
Respuesta corta: depende de dónde esté tu cuello de botella. Y en la mayoría de productos, no está en la inferencia.
Qué ha pasado, en concreto
OpenAI lanzó Ultrafast en preview limitado dentro de su API. Los datos verificables:
- Rendimiento: hasta 750 tokens/s de salida frente a ~53 tokens/s en Standard. La misma calidad de GPT-5.6 Sol, sin recorte de inteligencia.
- Tecnología: corre sobre el Wafer-Scale Engine de Cerebras, que mantiene los pesos del modelo en el propio chip y elimina el cuello de botella de ancho de banda de memoria. La velocidad no sale de un modelo más pequeño, sino de silicio distinto.
- Disponibilidad: waitlist, acceso restringido a una cohorte inicial (Jane Street, Podium, Rogo) y sin fecha de disponibilidad general.
- Precio: no publicado. El Sol estándar ya cuesta 5 $/1M tokens de entrada y 30 $/1M de salida; Ultrafast se sitúa por encima, pero cuánto es una incógnita.
Como demostración de fuerza, OpenAI destaca que Sol en Ultrafast resolvió las 2.500 preguntas de Humanity's Last Exam en 11 h 11 min. Es un dato de throughput agregado, no de latencia percibida por un usuario. Conviene no confundirlos.
Qué implica para tu producto
Aquí es donde hay que bajar del titular. "Velocidad" no es una sola cosa. En un producto real hay tres métricas distintas y solo una la arregla Ultrafast del todo:
- TTFT (time to first token): cuánto tarda en aparecer la primera palabra. Es lo que el usuario percibe como "responde rápido". Depende del modelo y la cola, y mejora, pero no es donde Ultrafast marca la diferencia brutal.
- Throughput (tokens/s): velocidad de generación una vez arranca. Aquí es donde el 14× pega fuerte: respuestas largas, generación de código, informes.
- Latencia total de la petición: red + retrieval + inferencia + render. Si tu RAG tarda 1,2 s en recuperar contexto y tu app 400 ms en pintar, acelerar la generación de 3 s a 0,2 s cambia menos de lo que parece.
La regla que aplicamos en proyectos con LLM en producción: la latencia de inferencia solo domina cuando el output es largo o cuando encadenas muchas llamadas secuenciales. En un bucle agéntico con 8 pasos que se bloquean entre sí, cada segundo se multiplica por 8; ahí 750 tokens/s cambia la experiencia. En un chat de una sola respuesta corta con RAG por delante, el cuello de botella es otro.
| Ultrafast tiene sentido si… | Probablemente no lo necesitas si… |
|---|---|
| UX conversacional o de voz en tiempo real | El flujo es asíncrono o por lotes (batch, colas) |
| Pipelines agénticos con pasos secuenciales que se bloquean | Cada petición es una sola respuesta corta |
| Generación de output largo (código, informes) | El retrieval o la red dominan la latencia total |
| Investigación financiera o trading donde el segundo cuesta dinero | El precio por token es tu principal restricción |
Nuestra recomendación
Nosotros no reescribiríamos el stack de inferencia todavía, y no por conservadurismo, sino por tres motivos concretos:
- Es un preview en waitlist. No se construye producción sobre un tier sin disponibilidad general ni SLA. Si tu roadmap depende de una lista de espera, no es un plan; es una apuesta.
- No hay precio. Sin coste por token no puedes hacer FinOps de IA ni modelar el margen unitario. "Rápido pero de coste desconocido" es exactamente el tipo de decisión que revienta un P&L seis meses después.
- Es lock-in de hardware. Ultrafast vive sobre silicio específico de un proveedor. Antes de acoplarte, conviene tener una capa de abstracción tipo LLM gateway que te deje enrutar por tier o por proveedor sin tocar el producto.
Lo que sí haríamos hoy, y recomendamos a cualquier equipo con IA en producción: medir antes de optimizar. Instrumenta TTFT, throughput y latencia total por separado. Si la inferencia no está en tu ruta crítica —y en muchos productos no lo está—, Ultrafast resuelve un problema que no tienes. Si sí lo está (voz, agentes multipaso, output largo), apúntate a la waitlist, pero diseña el sistema para que la velocidad sea un feature flag enrutable, no un cimiento.
La lectura de fondo va más allá de OpenAI: la velocidad de inferencia está dejando de ser una constante para convertirse en una palanca de producto que se compra aparte. Eso abre diseños nuevos —interfaces que antes no eran viables por latencia— pero también una trampa nueva: pagar premium por velocidad en flujos donde el usuario ni la nota. La disciplina de evaluar con datos y no con intuición es la que separa una decisión de arquitectura de un gasto por FOMO.
¿Tienes un producto con IA donde la latencia empieza a doler y no sabes si el problema es el modelo, el retrieval o la arquitectura? En Dribba llevamos desde 2011 construyendo producto con equipo senior in-house, y diseñamos orquestaciones de agentes en producción pensadas para medir y enrutar, no para casarse con un proveedor. Hablamos.
