El TSMC de las fábricas de IA, Fireworks

TL;DR

Fireworks es una plataforma de Specialized Intelligence de modelos abiertos y propios fundada en 2022 por ingenieros ex Meta (incluido el equipo fundador del núcleo de PyTorch) / Google, con sede en San Mateo, California.

Su pila, de abajo arriba, son seis módulos: Infrastructure (Cloud + Sovereign) → Training → Fireworks Lab → Models (propios / biblioteca abierta / pesos del cliente) → Inference → Model ensembling (Nexus + API).

Fireworks revela que de los más de 40 billones (40T+) de tokens que procesa al día, más del 95% no son llamadas directas a pesos abiertos públicos, sino modelos propietarios afinados, entrenados con aprendizaje por refuerzo (RL) u optimizados en parámetros con datos privados del cliente. Si el 90% del tráfico de una plataforma corre Llama o DeepSeek públicos, es un mayorista de cómputo público; cuando el 95% de la salida son modelos propietarios procesados a medida para distintos clientes, tiene el atributo de TSMC (Foundry).

Figura 1. Mezcla de tokens en la Serie D. Divulgación de la compañía, julio de 2026.

Equipo y desarrollo

Historia de financiación

Instantánea Series C (2025-10): 10.000+ compañías; > 10T tokens/día; ARR > $280M. Instantánea Series D (2026-07): ya > 40T tokens/día; ARR > $1B+; > 95% de los tokens de modelos especializados con datos propietarios del cliente u optimizados para un trabajo concreto.

Equipo fundador y equipo estable

Siete cofundadores: Lin Qiao, Dmytro Dzhulgakov, Benny Chen, Chenyu Zhao, Dmytro Ivchenko, James Reed, Pawel Garbacki. Cerca de la mitad vinieron del equipo original de PyTorch.

Lin Qiao — Co-Founder, CEO

• Educación: Grado y máster en informática, Universidad de Fudan; doctorado en informática, University of California, Santa Barbara (UCSB).
• Carrera: IBM desde circa 2003 (incluido el motor analítico BLU de Almaden Research); 2011–2015 LinkedIn, Tech Lead / Manager, en Espresso, Gobblin y el ciclo de vida de datos; se unió a Meta en 2015-07, gerente de Data Infrastructure, Senior Director of Engineering de 2018-02 a 2022-09. El equipo pasó de unos 5 a 300+, cubriendo Caffe2, PyTorch y la pila de train/serve de Meta. Línea pública: el equipo conservó el front end de PyTorch y reconstruyó el back end (incluido TorchScript); una migración de librería de 6 meses se convirtió en unos 5 años de reconstrucción de la pila, con una narrativa pico de más de 5 billones de inferencias al día.

Dmytro “Dima” Dzhulgakov — Co-Founder, CTO

• Educación / origen: Grado y máster en matemáticas aplicadas, NTU Kharkiv Polytechnic Institute; ucraniano. Fundó QBit, educación de programación para adolescentes, y un IDE de control industrial en NPF Informatica. Internships en Google Zurich y Facebook. Bio de X: “Ex-Pro Competitive Programmer.”
• Meta (circa 2011-12 a 2022-09): personalización de Ads y predicción de eventos a escala; desarrollador núcleo de Caffe2; coiniciador de la primera plataforma de AI de producción de toda Facebook; maintainer núcleo de PyTorch, uniendo investigación (FAIR) y toolchain de producto; ONNX; coautor del paper DLRM de 2019. Espejos de CV de terceros: org de 400+ en fase Tech Executive (Med).

Benny Chen (Benny Yufei Chen) — Co-Founder

• Educación / origen: Nacido en Nueva Zelanda. Entrevista Open Source CEO y podcast MindMakers: informática / Computer Science and Engineering en UCLA (circa 2015).
• Meta (unos 8–9 años, de intern a Principal): Ads infrastructure lead. En varias entrevistas: inferencia de modelos de ads en GPU y ASIC (él mismo: mover ads models a ASIC desde 2017, aún mundo V100); luego planificación de capacidad, vio la demanda interna de GPU “up and to the right”, la señal directa para dejar Meta y fundar.

Chenyu Zhao — Co-Founder (el único fichaje de Google)

• Educación: Grado en Electrical Engineering and Computer Science, UC Berkeley (Equilar).
• Google (unos diez años): Título oficial /team: Google Vertex AI Lead. Bio de Slush 2026: senior engineering manager de la plataforma Google Cloud AI. Bosquejo de terceros: ayudó a construir Vertex AI, gestionó un equipo MLOps / AutoML de ~50 (Med). En una conversación pública AMD × Crusoe dijo venir de GCP.

Dmytro Ivchenko — Co-Founder, Engineer

• Educación / origen: Máster en análisis de sistemas, Igor Sikorsky Kyiv Polytechnic Institute; con Dzhulgakov, uno de los dos cofundadores ucranianos citados por la prensa.
• Carrera: Desarrollo en Bloomberg y FatWire; LinkedIn Senior Staff, lideró Galene y Recruiter; desde 2016 en Meta, Staff / Senior Staff / Principal. Oficial /team: PyTorch for ranking lead.

James Reed (James K. Reed) — Co-Founder

• Educación: Grado en ingeniería informática, Virginia Tech, Summa Cum Laude. Internships en Google y Qualcomm.
• Meta: compilador de PyTorch. Staff Software Engineer; lideró o profundizó torch.fx, PiPPy (Pipeline Parallelism for PyTorch, luego fusionado en el núcleo de PyTorch), TorchScript, ONNX. Paper MLSys 2022 torch.fx: Practical Program Capture and Transformation for Deep Learning in Python (con Zach DeVito, Jason Ansel y otros). Patentes: predication in computational models (USPTO 10,553,207 y otras).

Pawel Garbacki (Paweł Garbacki) — Co-Founder, Researcher

• Educación / origen: Nacido en Varsovia. Grado/máster en matemáticas e informática, Universidad de Varsovia; máster en informática, VU Amsterdam; doctorado en informática, Delft + VU Amsterdam (director Dick Epema, OpenReview 2003–2008). Papers tempranos en P2P / Tribler.
• Carrera: Intern de investigación, IBM T.J. Watson; Google Staff / Tech Lead; 2013–2016 Pinterest, miembro fundador de Ads; 2016-10 a 2022-11 Meta Principal Engineer, News Feed Core Machine Learning.

Líneas de producto y modelo de negocio

Seis módulos de negocio

Posicionamiento de la compañía: no un Frontier Lab cerrado; un sistema operativo de Specialized Intelligence propiedad de la empresa — inferencia abierta + fine-tune/RL + orquestación, con coste y control apuntados a las API cerradas.

Módulo 1: Infrastructure

El cómputo base no está atado a la capacidad cloud propia de Fireworks.

• Fireworks Cloud (piscina global de GPU gestionada): 30+ regions, últimas NVIDIA + AMD, Foundry ciudadano de primera puede compensar el commit de Azure, ZDR / residencia regional / SOC 2 Type II / ISO 27001/42001
• Fireworks Sovereign (Fireworks on your cloud): la inferencia se queda en el K8s / cloud / centro del cliente; misma API, sin cambio de código; puede desbordar a Cloud.

Fireworks Cloud (piscina global de GPU gestionada)

Un Virtual Cloud alquilado a 20+ proveedores. Training Available solo en 5 regiones (Virginia / Ohio / Minnesota / Malasia / Taiwán). A100 sigue en Illinois; tres zonas AMD sin precio horario público. Fuentes: Microsoft Foundry (cuenta para Azure MACC); AWS Marketplace / SageMaker / Bedrock AgentCore; Google Cloud Marketplace.

Fireworks Sovereign (Enterprise Private Preview)

El mismo motor de serving en GPU propias / ya contratadas del cliente; el cliente conserva arquitectura y política; Fireworks hace calificación, deploy, upgrade, monitorización y respuesta a incidentes.

Sovereign equivale a BYOC gestionado; Airgap es el SKU de aislamiento más duro.

Módulo 2: Training

Las empresas llamaban directamente a modelos generales cerrados gigantes como Claude Opus o GPT-5/6. Ahora usan Fireworks para afinar / RL un modelo abierto de tamaño medio (p. ej. 30B Muse Glimmer o GLM 5.3 Flash) sobre un solo trabajo interno y ponerlo en producción: más pequeño, más especializado, el coste de inferencia cae en picado, baja la latencia. Como train y serve están en la misma plataforma (sin exportar cientos de GB de pesos a un segundo clúster), la iteración de semanas pasa a horas.

• Cursor (Federico Cassano): la asignación de recursos de una compañía AI native — los mejores ingenieros de algoritmos deben escribir entornos sandbox de código (Environment) y funciones de recompensa (Reward), no kernels CUDA ni clústeres GPU.
• Vercel (Malte Ubl): por qué Compound AI — la herramienta de generación front-end v0 no es un modelo gigante para todo, sino router + codegen + un modelo pequeño Auto-fix; las bases rotan cada semana, y con Fireworks una Recipe puede moverse a la última base abierta SOTA.
• Genspark (Kay Zhu): de alquilar una API a poseer los pesos cierra el bucle en 4 semanas.

Cualquier entrenamiento (sobre todo RL) tiene dos movimientos — ① Rollout / Sample (correr trayectorias: el modelo responde o llama herramientas) y ② Train (actualizar: puntuar, gradiente, pesos). Fireworks ofrece cuatro caminos según quién escribe el Loop y cómo se usan las GPU.

Resultados de entrenamiento

Módulo 3: Fireworks Lab

Fireworks Lab es un embed de alto ARPU y bajo COGS de GPU para bloquear el presupuesto núcleo de un gran cliente y dejar evaluadores y loops de entrenamiento. Las GPU se facturan en los SKU públicos del Módulo 2 Training / Módulo 5 Inference; Lab factura tiempo de investigador.

Entrega por proyecto: el cliente conserva modelo, eval harness, tuberías de datos, loop de entrenamiento y recipes — cuando la base se fortalece, el estándar se mueve con ella. Embed de alto ARPU y bajo COGS de GPU para bloquear el presupuesto núcleo de un gran cliente y dejar evaluadores y loops de entrenamiento.

• Ciclo de unos 6–10 semanas, un time-boxed build contado hacia atrás desde una fecha. (Genspark Deep Research, Heidi clinical scribe).
• Apertura diagnosis: capacidad, baseline, criterios de éxito, alcance.
• Paquetes de trabajo (página Training «We build with you»):
  • Data readiness: derechos, volumen, si sirve para producción; confirmar «podemos ganar antes de gastar más».
  • Eval design: escribir evals con los expertos del cliente; poner modelos propios y ajenos en la misma regla.
  • Training strategy: base, método, economía de serving, reentrenar con nuevas traces / una nueva base.
• Comparte la misma pila train-serve que el Módulo 2 Training; Lab vende tiempo de investigador y método, no un SKU de GPU. Si faltan algoritmos, Lab es la capa de servicio encima de Managed / Training API.

Módulo 4: Models

El suministro de modelos son tres carriles:

• Fireworks models (propios)
• Model library (laboratorios abiertos)
• Your models (pesos del cliente)

Fireworks models (propios)

Ember-1 es un especialista de razonamiento corto sobre Kimi K3. Motivo: K3 a veces gasta >90% de los tokens generados en razonamiento interno; los agents multi-turno reinyectan ese reasoning y el contexto crece casi al cuadrado; bajar el effort de K3 pierde calidad. El equipo corrió 50+ experimentos de Serverless Training y 200+ evals, sin datos de clientes.

Línea externa: unos 40% menos tokens, calidad cercana a K3; en cinco benchmarks de industria a ~1 punto de Claude Opus 5, ~1/5 del coste por tarea (marketing / eval interna). En Doximity Bedside Bench (500 casos clínicos / 10 especialidades) se sitúa en la frontera de Pareto coste/tarea frente a GPT-5.6 Sol, GPT-6 Astra y Claude Opus 5.

Tabla pública de comparación (autotest de la compañía)

Dos A/B de coding en producción: unos -35% tokens / tarea, calidad plana; uno ya cortó. Tráfico interno: los desarrolladores no notaron el cambio. Una tabla interna también da reasoning tokens -71.3%, output 49.3K → 29.9K, score 0.751 → 0.753. Ahora es Research Preview: los modelos de investigación nuevos tienen dos semanas de Serverless y luego gradúan según demanda de la comunidad. El entrenamiento de Ember-1 está abierto; el cliente puede especializar más. Serverless y Dedicated lo sirven.

Model library

Selección de modelos abiertos por escena

Suministro cerrado frente a sustitutos abiertos

Your models (pesos del cliente)

• La salida del entrenamiento es 100% del cliente, sujeta a la licencia de la base; firectl model download exporta Hugging Face PEFT; también se pueden subir adapters / pesos custom compatibles.
• Un solo LoRA puede live-merge en la base, velocidad cercana a la base; Multi-LoRA unos 100 addons comparten un Dedicated.
• Specialized Model Inference (Public Preview, Forge 2026): cuelga LoRA en Serverless compartido, al precio token de la base, sin GPU ociosa. Hoy solo GLM 5.3 Flash (accounts/fireworks/models/glm-5p3-flash), como máximo 3 adapters por base, rank ≤ 64; el cuarto devuelve ResourceExhausted. Flujo: Train/import → Load < 5 minutos → la primera petición < 1 minuto deja el LoRA en cache → después latencia cercana a la base. Requiere firectl ≥ 1.8.15. Las demás bases siguen necesitando Dedicated. <a href="https://docs.fireworks.ai/serverless/specialized-model-inference/overview.md">https://docs.fireworks.ai/serverless/specialized-model-inference/overview.md</a>

Precios

Módulo 5: Inference

Los productos de inferencia, según crece el tráfico, son tres rampas: Serverless (coche compartido de tokens) → Reserved Throughput (dólares por minuto para sostener el SLA) → Dedicated / GPU Reserve (alquilar tarjetas enteras por segundo / por año).

• Serverless: piscina multi-tenant, sin cold start, sin selector de GPU. Compatible OpenAI y Anthropic, por token.
• Reserved Throughput (Serverless SLA): se compra cuota en dólares/minuto, use-it-or-lose-it por minuto, no se acumula. La página de precios escribe throughput SLA + 99.9% uptime terms (los docs solo escriben throughput SLA; el texto completo de créditos no es público).
• GPU Reserve / Reserved capacity: típico empresarial 1 año; capacidad garantizada, cuotas más altas, GPU-hora más baja, regiones Pre-GA / silicio nuevo.

Módulo 6: Model ensembling (Nexus + API)

Dos caras: la herramienta humana (Fireworks Nexus) y la API de sistema (Fireworks API). Línea de producto: conservar ChatGPT / Claude / el harness de código; los turnos cotidianos van abiertos, los más duros cerrados; factura de equipo −50%+; en la API «cambiar una base URL», compatible OpenAI / Anthropic. El FAQ de Nexus es explícito: no es solo un LLM router — CLI más tools, Auto por turno, Settings con presupuesto; las tres juntas hacen una «organización multi-modelo».

Nexus Auto

Cerrado + abierto juntos con Nexus: para que el desarrollador siga usando Claude Opus y GPT dentro de Claude Code, Cursor u OpenCode, Fireworks usa un pass-through cliente/pasarela en Nexus (antes FireRouter) — pones tu propia Key de Anthropic/OpenAI; los turnos duros van a los servidores oficiales; los rutinarios a modelos abiertos o Ember-1 / Qwen Plus en las salas de Fireworks. Así un proveedor de cómputo se mantiene del lado correcto de los términos de modelos cerrados y recorta más del 50% de la factura cerrada.

Fireworks API (cara de sistema)

Fireworks API (cara de sistema) es esencialmente la Serverless Inference API ya despiezada arriba (más los Routers / interfaces de deploy).

Frente a OpenRouter

En superficie, Fireworks Nexus y OpenRouter entran en «acceso unificado multi-modelo y routing inteligente (Model Routing)» y ambos enchufan Cursor, Claude Code, OpenCode; el modelo de negocio, la lógica de routing y el lugar en la cadena son distintos — y en la cadena de cómputo, Fireworks es uno de los proveedores upstream de inferencia abierta más importantes de OpenRouter.

• OpenRouter es un «bazar neutral de agregación de modelos (marketplace B2D horizontal)»: el trabajo es «encontrar un modelo entre proveedores, comparar precio, failover». No cría flota; hace pasarela unificada y cobra recargas o spread mayorista.
• Fireworks Nexus es un «add-on de recorte de coste de agent atado a su propio motor (embudo de integración vertical)»: el trabajo es «sin cambiar el hábito de Claude Code / Cursor / OpenCode, descargar el 70% de las tareas rutinarias de los modelos cerrados caros a los abiertos de Fireworks, por turno», para llenar sus propios motores Serverless/Dedicated de alto margen.
  • Cuando el desarrollador corre nexus claude o nexus codex, la herramienta conserva el login de Claude o la API Key propia de OpenAI/Anthropic (las claves se quedan en el llavero local, no se suben)
  • La empresa no tiene que tirar contratos Anthropic/OpenAI ni suscripciones de escritorio ChatGPT/Claude, y puede estirar 2 a 3× un presupuesto anual de AI que de otro modo se quema en 4 meses (el dolor de ingeniería de Uber en textos públicos).

Foso de ingeniería

Las nubes tempranas de modelos abiertos alquilaron GPU bare metal y envolvieron vLLM/SGLang open source, y cayeron en una guerra de precios homogeneizada. La tesis de Fireworks para sostener margen bruto y trabar el 95%+ de tráfico de modelos a medida es que cerró tres fallas industriales:

1. Cerrar la falla de «sesgo numérico train–serve»: En post-entrenamiento y RL de MoE gigantes (Kimi K3, DeepSeek V4.1), el camino clásico entrena en Megatron/FSDP a BF16 y exporta a vLLM a FP8/FP4. Diferencias de operadores, redondeo de baja precisión y el router MoE activando expertos distintos bajo ruido mínimo producen «curva de reward arriba en entrenamiento, colapso de accuracy en producción». Fireworks construyó un kernel train-serve idéntico (FireAttention), alineado nativamente a BF16, block FP8 y NVFP4 de NVIDIA, y MoE Router Replay, forzando backprop y sampling por el mismo camino de expertos, con KL serve-vs-train en KLD < 0.007 (rechazo de token < 3%).
2. Cerrar la falla de «GPU ociosa en RL asíncrono»: En 2026 el paradigma empresarial de modelos a medida pasó de SFT estático a Agentic RL / RFT. En el loop, el 70%–85% del tiempo GPU es Rollout (muestrear Trajectory enormes en código o tools), no el paso de gradiente. Si train y serve están separados, sincronizar un Checkpoint de cientos de GB deja GPU esperando. RL Rollouts y Serverless Training API usan arquitectura async; Delta-compressed Weight Updates envían ~2% del cambio de pesos, con prefetch de fondo, para hot-swap de memoria GPU sub-minuto (< 1 minuto), declarado a 10.000+ GPU de RL concurrente.
3. Cerrar la falla de «coste de contexto largo de agent multi-turno» (Session Affinity + Nexus): Un trabajo de coding agent suele cruzar decenas de turnos, contexto a 100K–1M tokens. Fireworks implementa Session Affinity en el scheduler, clavando las peticiones consecutivas de una sesión Agent al nodo que ya tiene su KV Cache, hit declarado hasta 99.6% (sin fee de escritura de cache; lecturas a mitad de precio o menos). En el terminal, Nexus como «router consciente de dificultad y cache» descarga búsqueda de archivos, reescrituras ordinarias y tests — más del 70% del desarrollo diario — a modelos abiertos rápidos de Fireworks, y solo el razonamiento de arquitectura más duro pasa a una API cerrada, recortando la factura de coding AI 50%–72%.

Why Fireworks？

Frente a TSMC

El paso de la industria de semiconductores del monopolio IDM a Fabless (sin diseño de oblea) + Foundry (fabricación especializada).

• IDM temprano ↔ Frontier Lab cerrado (OpenAI / Anthropic): al principio solo un gigante IDM como Intel, diseñaba, fabricaba y vendía piezas con marca Intel. Eso mapea a OpenAI y Anthropic de hoy: preentrenan un modelo general cerrado, lo sirven en clúster interno, venden una API caja negra.
• Auge Fabless ↔ 10.000+ empresas verticales que poseen datos privados: Apple, NVIDIA, AMD, Qualcomm no gastaron cada uno cientos de miles de millones en una fab; dibujaron el chip y lo mandaron a TSMC. En la era AI, Cursor, Harvey, Notion, Uber, Vercel son el Fabless — tienen el workflow, los datos privados verticales y las funciones de recompensa RL (los «dibujos» del modelo especializado), pero no quieren que una API cerrada trabe margen y latencia, ni van a nutrir un equipo de cien personas de kernels CUDA y sistemas distribuidos de 10.000 GPU para poseer una «línea de tokens».
• Nacimiento de Foundry ↔ Fireworks AI: Fireworks es la foundry especializada que toma esos decenas de miles de «dibujos de modelo especializado» y los convierte en flujos de tokens de producción de alto throughput y bajo coste.

Comparación de ingeniería

Frente a vLLM y SGLang

Si solo se mira levantar un modelo abierto en una sola caja, continuous batching y memoria paginada, el motor de Fireworks y vLLM (PagedAttention y alto throughput general) y SGLang (RadixAttention de reuso de prefijo y decode JSON estructurado) resuelven de verdad la misma clase de problema.

Pero vLLM/SGLang se detienen en inferencia pura, mientras Fireworks abrió identidad train-serve y RL online.