La tesis: las GPU son un producto genérico, el stack es la ventaja
La versión honesta de toda propuesta de inferencia administrada es la misma. Cualquiera puede rentar una H100. Lo que de verdad es difícil (y lo que usted tendría que reconstruir si sirviera el modelo por su cuenta) es la capa entre la GPU y la API:
- Kernels y decodificación a la medida: decodificación especulativa, caché de prefijos/KV, cuantización que no arruina la calidad. La diferencia entre vLLM sin ajustes y un stack afinado a menudo es de 2–4× en throughput con la misma tarjeta.
- Arranques en frío y autoescalado: cargar un modelo de 70B en una GPU nueva toma decenas de segundos; las plataformas que ganan lo ocultan. Escalar a cero sin la penalización del arranque en frío es ingeniería genuinamente difícil.
- Alta disponibilidad multinube / en VPC: repartir una carga de trabajo entre regiones y nubes (o dentro de su propia VPC) para mantener la disponibilidad, con un solo endpoint. Esta es la parte que un solo servidor autoalojado, por su estructura, no puede igualar (el problema de la concurrencia).
- Runtimes especializados: los embeddings, la transcripción/diarización y el TTS en streaming requieren cada uno una forma de servicio distinta a la del chat. Cada vez más, las plataformas ofrecen runtimes diseñados para cada uno.
Ese último punto es donde esta categoría se está separando de “solo un endpoint compatible con OpenAI”. La competencia interesante en 2026 no está en los tokens por segundo del chat, sino en las modalidades que no son chat.
El campo, según nuestra lectura
Se dividen a grandes rasgos en dos bandos: plataformas de optimización por software (afinan el stack sobre GPU genéricas) y plataformas de silicio propio (su velocidad viene de sus propios chips). Ambas son legítimas; sacrifican cosas distintas.
La formulación más clara de “el stack es la ventaja”. Kernels a la medida y caché integrados, arranques en frío rápidos, nube administrada o su VPC, y runtimes especializados: embeddings BEI (afirma >2× de throughput / ~10% menos latencia frente a las alternativas), transcripción y diarización optimizadas, TTS en streaming para agentes de voz y Chains para inferencia compuesta/de varios pasos, con hardware y autoescalado por paso. Ingenieros asignados al cliente, no solo autoservicio. Su lista de clientes es nativa de IA (Cursor, Notion, Abridge, Writer). La afirmación de throughput de BEI es justo el tipo de cosa que deberíamos medir en lugar de repetir; vea más abajo.
Un catálogo grande servido sobre sus propios kernels optimizados, con llamadas a funciones y ajuste fino. La opción predeterminada pragmática cuando quiere muchos modelos abiertos, rápidos, detrás de una sola API.
El estante de modelos abiertos más amplio, más una parte de entrenamiento y ajuste fino. Conviene cuando el requisito es “servir muchos modelos abiertos distintos” en lugar de una sola carga de trabajo afinada.
Precios por token agresivos sobre un catálogo abierto amplio. A menudo es el piso de costo para servir modelos abiertos genéricos; vale la pena compararlo con nuestra tasa de aprobación medida antes de suponer que barato == suficiente para la tarea.
Su ventaja es el hardware, no solo el software: chips LPU / RDU / a escala de oblea que alcanzan cifras de tokens por segundo que las GPU genéricas no pueden. Decisivo para agentes limitados por la latencia y para voz. La contrapartida: un menú de modelos más reducido, y usted queda atado a su infraestructura. Evaluamos Groq, SambaNova y Cerebras por separado.Medido, no afirmado: cronometramos gpt-oss-120b de Cerebras a ~845 tok/s con una sola solicitud (junio de 2026); genuinamente rápido (5–8× un flujo típico en GPU), pero cerca de la mitad de la cifra anunciada de ~1,679 tok/s. El “hasta” de las afirmaciones de velocidad pesa mucho; la brecha es lo importante. Note también que Cerebras Code cambió su modelo subyacente de Qwen3 Coder a GLM-4.7 (Zhipu / z.ai): un modelo de origen chino que ahora corre en silicio estadounidense a escala de oblea, un detalle de transparencia que vale la pena conocer.
Microservicios de inferencia optimizados y preempaquetados que usted ejecuta en GPU de NVIDIA, en cualquier lugar. La opción de “traerlo a su propia infraestructura” del propio fabricante del silicio; la referencia frente a la que se posicionan los independientes.
Donde se pone interesante: los runtimes que no son de chat
Hoy nuestros benchmarks miden la calidad del chat. Pero los productos diferenciados de estas plataformas son cada vez más los embeddings, la transcripción y el TTS, y cada uno tiene su propia pregunta de “cuál es realmente el mejor” que nadie responde de forma neutral:
- Embeddings. El throughput y la latencia importan muchísimo para la ingesta de RAG a escala. La afirmación de 2× de BEI de Baseten es una cifra concreta y comprobable, una extensión natural de lo que ya hacemos para el chat.
- Transcripción + diarización. Precisión y costo por hora de audio, más el tiempo hasta el primer token para uso en vivo.
- TTS en streaming. El tiempo hasta el primer byte es la métrica para agentes de voz y telefonía; justo la capa sobre la que se apoya un runtime de agentes.
Pendiente para nosotros. Podemos extender a estas modalidades la misma disciplina medida y neutral frente a los proveedores que aplicamos al chat, empezando por la afirmación de throughput de los embeddings BEI de Baseten. Eso es una tarea de benchmark, no una frase de marketing, y está en la cola.
Plataforma administrada frente a hacerlo usted mismo: la lectura de SecondClaw
Para infraestructura privada/autoalojada (la pregunta de SecondClaw), la elección no es “API en la nube frente a nuestras propias GPU”. Es una división en tres, y por lo general la plataforma administrada le gana a hacerlo todo usted mismo:
- H100 propia + vLLM: máximo control y residencia de los datos, pero el ajuste de kernels, los arranques en frío, el autoescalado y la alta disponibilidad quedan a su cargo. Son meses de ingeniería para igualar lo que una plataforma ofrece desde el primer día. Se justifica solo cuando nada puede salir de su edificio, o con un volumen constante muy alto en una sola tarea.
- Plataforma administrada → su VPC (un solo inquilino): el camino intermedio. Tanto Baseten como NIM ofrecen ejecutar su stack optimizado dentro de su propia nube. Obtiene la capa de optimización sin reconstruirla; la pregunta abierta para un inquilino regulado es si el aislamiento de un solo inquilino cumple con el nivel de cumplimiento exigido.
- Plataforma administrada (en la nube de la plataforma): lo más rápido para lanzar, sin operar GPU, pero los datos pasan por un tercero, que es justo lo que el autoalojamiento existe para evitar. Está bien para cargas de trabajo no sensibles, no para el caso de soberanía.
El veredicto honesto refleja el del autoalojamiento: una plataforma administrada que replica la capa de optimización que a usted le costaría construir es la opción predeterminada correcta, a menos que el motivo sea una soberanía de datos estricta; en ese caso, paga por una VPC de un solo inquilino o por hacerlo todo usted mismo, y acepta el costo.
Lo que sacamos del panorama
- La categoría es real y está subestimada. “El servicio administrado de modelos abiertos” es el punto intermedio que falta entre las API de frontera y hacerlo usted mismo, y para la mayoría de los equipos supera al autoalojamiento puro en todos los ejes excepto la residencia estricta de los datos.
- Ya cubrimos la parte de la calidad de los modelos. Todas las plataformas de aquí son un proveedor evaluado en nuestros benchmarks, así que un cliente recibe nuestra tasa de aprobación medida por modelo, no la tabla de clasificación del proveedor.
- La siguiente señal neutral que agregar no es de chat. Los embeddings, la transcripción y el TTS tienen la misma brecha de “quién es realmente el mejor” que tenía el chat antes de que lo midiéramos. El throughput de BEI es el primer objetivo concreto.
- La realidad del autoalojamiento: los límites honestos de hacerlo usted mismo; esta es la alternativa administrada.
- Lo que están construyendo los proveedores: el panorama hermano, una capa más arriba (runtimes de agentes).
- Proveedores: todas las plataformas de aquí, con nuestros resultados medidos por modelo.
- Código abierto · Costo y TCO: las cuentas del punto de equilibrio entre lo administrado y hacerlo usted mismo.
- Servir un modelo local: el trabajo de optimización que estas plataformas hacen por usted.