Elegir una pasarela de API de IA ya no es el mismo problema que hace dos años. En 2024, la mayoría de los desarrolladores llamaban a OpenAI directamente o levantaban LiteLLM localmente. Ahora hay opciones alojadas con paneles de precios, límites de crédito por clave y catálogos de modelos que abarcan decenas de proveedores. La categoría ha crecido lo suficiente como para que elegir mal signifique deshacer más tarde trabajo de integración real.
Este artículo compara cuatro pasarelas que aparecen repetidamente en conversaciones de desarrolladores: CometAPI, Portkey, LiteLLM y Cloudflare AI Gateway. El objetivo no es elegir un ganador —cada una tiene sentido para situaciones distintas—, sino explicar qué hace realmente cada una para que puedas ajustar la herramienta a tu caso de uso.
Nota sobre nombres de modelos: Los identificadores de modelo usados en este artículo (como
gpt-5.4,claude-opus-4-7) son identificadores de la plataforma CometAPI. No son nombres oficiales de OpenAI o Anthropic, cuyos propios convenios de nombres difieren.
Qué hacen realmente estas herramientas
Antes de comparar funciones, conviene precisar qué hace una pasarela de API de IA. Como mínimo: se sitúa entre tu aplicación y uno o más proveedores de IA, reenviando solicitudes y devolviendo respuestas. Más allá de ese mínimo, las pasarelas divergen significativamente.
Algunas pasarelas —Cloudflare AI Gateway, por ejemplo— son principalmente una capa de paso que añade registro y caché sin tocar tu clave de API ni los precios. Otras, como CometAPI, actúan como revendedor: tú les pagas, ellos pagan al proveedor subyacente, y la diferencia de precios forma parte de la propuesta de valor. LiteLLM es diferente de nuevo: es software que ejecutas tú mismo, no un servicio alojado.
Entender esta distinción importa antes de evaluar cualquier función específica.
Comparación de características
La tabla siguiente usa información de la documentación oficial o el panel público de cada producto a mayo de 2026. Las funciones marcadas con un guion (—) no estaban confirmadas en fuentes oficiales en el momento de escribir esto.
| Característica | CometAPI | Portkey | LiteLLM | Cloudflare AI Gateway |
|---|---|---|---|---|
| Despliegue | Alojado (SaaS) | Alojado + autoalojado | Autoalojado (código abierto) | Alojado (edge de Cloudflare) |
| Catálogo de modelos | 500+ modelos entre proveedores | 1.600+ LLMs vía API unificada | Depende de tu configuración | OpenAI, Anthropic, Workers AI |
| Modelo de precios | Revendedor (pagas a CometAPI) | Pass-through + tarifa de plataforma | Solo costo de infraestructura | Pass-through (nivel gratuito disponible) |
| API compatible con OpenAI | Sí (api.cometapi.com/v1) | Sí (api.portkey.ai/v1) | Sí (local o remoto) | Sí (vía URL de la pasarela) |
| Límites de crédito por clave | Sí (panel) | Sí | Sí (mediante configuración) | — |
| Ratios de precios por grupo | Sí (0.8x predeterminado, 0.1x interno) | — | — | — |
| Registro de solicitudes | Sí (4 tipos de logs) | Sí | Sí | Sí |
| Supervisión de tasa de éxito | Sí (vista de tiempo de actividad de 30 días) | Sí | Sí | Sí |
| Nivel gratuito | Sí (cuentas nuevas) | Sí | Código abierto (costo de infraestructura) | Sí |
| Opción de autoalojamiento | No (empresa: servidor dedicado) | Sí | Sí (caso de uso principal) | No |
Fuentes: CometAPI dashboard, Portkey homepage, LiteLLM GitHub, Cloudflare AI Gateway documentation
Conexión a cada pasarela
Las cuatro pasarelas exponen un endpoint compatible con OpenAI, lo que significa que la misma estructura de cliente funciona para todas —cambias el base_url, las credenciales y, en el caso de Portkey, cómo especificas el modelo—.
Python
import osfrom openai import OpenAIdef require_env(name: str) -> str: """Raise a clear error if a required environment variable is missing.""" val = os.environ.get(name) if not val: raise ValueError(f"Missing required environment variable: {name}") return val# ── CometAPI ────────────────────────────────────────────────────────────────# Hosted reseller with 500+ models. Use CometAPI model identifiers (e.g. "gpt-5.4").cometapi_client = OpenAI( base_url="https://api.cometapi.com/v1", api_key=require_env("COMETAPI_KEY"),)# ── Portkey ─────────────────────────────────────────────────────────────────# Hosted gateway with observability and 1,600+ LLMs.# Route to a provider by prefixing the model name: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet", etc.# x-portkey-api-key is required; it authenticates requests to Portkey's gateway.portkey_client = OpenAI( base_url="https://api.portkey.ai/v1", api_key=require_env("PORTKEY_API_KEY"), default_headers={ "x-portkey-api-key": require_env("PORTKEY_API_KEY"), },)# ── LiteLLM ──────────────────────────────────────────────────────────────────# Self-hosted proxy. Provider credentials (OPENAI_API_KEY etc.) are set server-side.# By default the proxy does not validate the client API key — "anything" works.# If you have enabled virtual keys on your LiteLLM instance, pass a virtual key instead.litellm_client = OpenAI( base_url=os.environ.get("LITELLM_BASE_URL", "http://localhost:4000"), api_key=os.environ.get("LITELLM_API_KEY", "anything"),)# ── Cloudflare AI Gateway ───────────────────────────────────────────────────# URL-based pass-through. Keep your real provider API key — Cloudflare does not replace it.cf_account_id = require_env("CF_ACCOUNT_ID")cf_gateway_id = require_env("CF_GATEWAY_ID")cloudflare_client = OpenAI( base_url=( f"https://gateway.ai.cloudflare.com/v1" f"/{cf_account_id}/{cf_gateway_id}/openai" ), api_key=require_env("OPENAI_API_KEY"),)def ask(client: OpenAI, model: str, question: str) -> str: """ Minimal wrapper showing the common call pattern across all four gateways. Model format varies by gateway: CometAPI: "gpt-5.4", "claude-opus-4-7", etc. (CometAPI identifiers) Portkey: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet", etc. LiteLLM: whatever model names you configured in your proxy Cloudflare: standard OpenAI model names, e.g. "gpt-4o" This function does not handle finish_reason, tool_calls, or provider errors. For production error handling, see: How to Debug Failed AI API Generations. """ response = client.chat.completions.create( model=model, messages=[{"role": "user", "content": question}], ) return response.choices[0].message.content or ""
Node.js
import OpenAI from "openai";function requireEnv(name) { const val = process.env[name]; if (!val) throw new Error(`Missing required environment variable: ${name}`); return val;}// ── CometAPI ────────────────────────────────────────────────────────────────const cometClient = new OpenAI({ baseURL: "https://api.cometapi.com/v1", apiKey: requireEnv("COMETAPI_KEY"),});// ── Portkey ─────────────────────────────────────────────────────────────────// Route to a provider by prefixing the model: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet"const portkeyClient = new OpenAI({ baseURL: "https://api.portkey.ai/v1", apiKey: requireEnv("PORTKEY_API_KEY"), defaultHeaders: { "x-portkey-api-key": requireEnv("PORTKEY_API_KEY"), },});// ── LiteLLM ──────────────────────────────────────────────────────────────────// Self-hosted. Default mode accepts any API key value.// Set LITELLM_BASE_URL if your server runs on a different host or port.const litellmClient = new OpenAI({ baseURL: process.env.LITELLM_BASE_URL ?? "http://localhost:4000", apiKey: process.env.LITELLM_API_KEY ?? "anything",});// ── Cloudflare AI Gateway ───────────────────────────────────────────────────const cfClient = new OpenAI({ baseURL: `https://gateway.ai.cloudflare.com/v1/${requireEnv("CF_ACCOUNT_ID")}/${requireEnv("CF_GATEWAY_ID")}/openai`, apiKey: requireEnv("OPENAI_API_KEY"),});/** * Minimal wrapper showing the common call pattern. * Model format varies by gateway — see Python example above for details. * Does not handle finish_reason or error recovery; add those for production use. */async function ask(client, model, question) { const response = await client.chat.completions.create({ model, messages: [{ role: "user", content: question }], }); return response.choices[0].message.content ?? "";}
El patrón de conexión es el mismo en las cuatro. Las diferencias significativas aparecen en otra parte: qué puedes observar, qué puedes controlar y qué ocurre cuando algo falla.
Para qué sirve realmente cada herramienta
CometAPI
La principal oferta de CometAPI es un catálogo alojado con más de 500 endpoints de modelos, incluyendo modelos de generación de imágenes y video junto con modelos de texto. La tarificación funciona mediante un sistema de ratios basados en grupos: el grupo predeterminado aplica un multiplicador de 0.8x sobre las tarifas base de CometAPI. Puedes configurar distintos grupos de ratios para uso interno (0.1x) frente a clientes de pago, lo que hace práctico construir un producto con niveles sin gestionar cuentas separadas.
El panel te ofrece cuatro tipos de logs (llamadas estándar de API, generación de imágenes, generación de video, Midjourney), una vista de tiempo de actividad de 30 días y límites de crédito por clave. Los límites de crédito te permiten dar claves de API a clientes o contratistas con un techo de gasto rígido, lo que resuelve un problema real cuando distribuyes acceso a una cuenta compartida.
Lo que CometAPI no ofrece: autoalojamiento (los clientes enterprise pueden solicitar un servidor dedicado, pero no es una opción de autoalojamiento estándar), limitación de tasa a nivel de pasarela o SSO.
Mejor para: Desarrolladores indie y equipos pequeños que quieren enrutar entre muchos modelos —incluyendo imagen y video— con una sola clave de API y una relación de facturación, y que necesitan controles de presupuesto por clave.
Portkey
Portkey es una pasarela alojada construida en torno a la observabilidad. Te da acceso a 1.600+ LLMs a través de una API unificada, con el enrutamiento manejado anteponiendo el nombre del proveedor al modelo (@openai/gpt-4o, @anthropic/claude-3-5-sonnet). Esto significa que no necesitas configuraciones de cliente separadas para cada proveedor: un solo cliente de Portkey los maneja todos, y solo cambias la cadena del modelo.
Más allá del enrutamiento, Portkey ofrece trazado de solicitudes, versionado de prompts y enrutamiento de fallback que configuras en el panel en lugar de en el código. La opción de autoalojamiento significa que puedes ejecutar Portkey en tu propia infraestructura si la conformidad lo requiere.
El repositorio de GitHub de la pasarela de código abierto de Portkey se mantiene activamente: consulta el recuento actual de estrellas directamente en lugar de fiarte de cualquier número citado aquí, ya que cambia frecuentemente.
Mejor para: Equipos que necesitan trazabilidad, enrutamiento multiproveedor desde una única configuración de cliente o que desean gestionar la exposición de claves de API entre desarrolladores.
LiteLLM
LiteLLM es un paquete de Python y servidor proxy, no un servicio alojado. Lo ejecutas tú mismo. Esta es una distinción significativa: no hay un tercero manejando tus solicitudes o conservando tus claves de API. Las credenciales de los proveedores (tu clave real de OpenAI, Anthropic, etc.) se establecen como variables de entorno del lado del servidor; el cliente solo apunta al proxy local.
De forma predeterminada, LiteLLM no valida la clave de API que envían los clientes: cualquier valor funciona. Si habilitas la gestión de claves virtuales, los clientes pasan claves virtuales que LiteLLM valida contra su propia base de datos. En cualquier caso, el proxy traduce solicitudes en formato OpenAI al formato que espera el proveedor ascendente, para que tu código de aplicación no cambie cuando agregas un nuevo proveedor.
La contrapartida es la carga operativa: eres responsable de ejecutar, escalar y actualizar el servidor.
Mejor para: Equipos con capacidad de devops, organizaciones con restricciones de residencia de datos que prohíben proxys de API de terceros o cualquiera que quiera enrutamiento entre proveedores sin confiar el contenido de las solicitudes a un vendedor SaaS.
Cloudflare AI Gateway
Cloudflare AI Gateway es estructuralmente diferente de las otras tres. No cambias tu clave de API ni pagas a Cloudflare por el acceso a modelos. En su lugar, reemplazas la URL base del proveedor por una URL gestionada por Cloudflare que añade registro, caché y limitación de tasa en el edge.
Como Cloudflare se sitúa entre tu aplicación y el proveedor, puede almacenar en caché solicitudes idénticas, útil si tu aplicación envía los mismos prompts repetidamente. El nivel gratuito cubre la mayoría de los casos de desarrolladores indie. La limitación es el alcance: Cloudflare no agrega modelos entre proveedores. Sigues necesitando cuentas y claves separadas para cada proveedor que uses.
Mejor para: Desarrolladores que ya están en la infraestructura de Cloudflare o cualquiera que quiera caché y registro sobre cuentas de proveedores existentes sin introducir una nueva relación de facturación ni cambiar las claves de API.
Correspondencia de escenarios
| Escenario | Herramienta recomendada | Motivo |
|---|---|---|
| App indie, quieres probar 10+ modelos con una sola clave | CometAPI | Catálogo amplio, configuración sencilla, límites por clave |
| Necesitas generación de imagen + video en la misma integración | CometAPI | Endpoint unificado para modelos de texto, imagen y video |
| Equipo de 5, necesitas rastrear quién usa qué modelo | Portkey | Trazado de solicitudes, gestión de equipo |
| Enrutar a 1.600+ LLMs con una configuración de cliente | Portkey | Enrutamiento @proveedor/modelo, sin configuración por proveedor |
| Quieres fallback entre proveedores sin cambios de código | Portkey | Configuración declarativa de fallback en el panel |
| Empresa con requisitos de residencia de datos | LiteLLM (autohospedado) | Ningún tercero maneja el tráfico |
| Presupuesto cero, cómodo con autogestión | LiteLLM | Código abierto, sin coste de plataforma |
| Ya usas OpenAI directamente, quieres caché | Cloudflare AI Gateway | Solo intercambiar la URL, sin nueva relación de facturación |
| Necesitas RBAC para múltiples equipos | Portkey o LiteLLM | Ambos tienen gestión de equipos/roles; CometAPI y Cloudflare no |
Lo que estas cuatro no cubren
Esta comparación cubre las pasarelas que aparecen con más frecuencia en conversaciones de desarrolladores indie. El mercado incluye otras opciones que vale la pena conocer: Helicone se centra en la observabilidad sin actuar como proxy, OpenRouter se especializa en enrutamiento hacia modelos de pesos abiertos y de investigación, y AWS Bedrock es el servicio de IA gestionado de Amazon orientado a cargas de trabajo empresariales. Si tus requisitos no encajan con ninguna de las cuatro anteriores, esos son los siguientes lugares a revisar.
Realizar la transición
Si actualmente llamas a un proveedor directamente y estás considerando una pasarela, el cambio de código es pequeño. Para CometAPI, agregas una variable de entorno y cambias el base_url. Para Portkey, agregas un encabezado y cambias cómo especificas el modelo (@openai/gpt-4o en lugar de gpt-4o). Para Cloudflare, cambias la URL sin tocar tu clave de API del proveedor. Para LiteLLM, primero ejecutas un servidor local y luego apuntas tu cliente a él.
La cuestión mayor no es cómo hacer el cambio, sino si realmente lo necesitas. Si llamas a un solo proveedor, no tienes problemas de visibilidad de costos y no necesitas enrutamiento entre modelos, una pasarela añade complejidad sin beneficio. Si estás usando múltiples proveedores, distribuyendo claves a contratistas o descubres que las facturas inesperadas son un problema recurrente, el costo de integración vale la pena.
Preguntas frecuentes
¿Puedo usar estas pasarelas juntas?
Sí. Algunos equipos ejecutan LiteLLM autoalojado para cargas sensibles y CometAPI para el resto. Cloudflare AI Gateway puede situarse delante de las solicitudes a CometAPI si quieres la capa de caché de Cloudflare encima, aunque esto añade un salto de red.
¿Estas pasarelas almacenan mis prompts?
Depende de la herramienta y tu configuración. Portkey y CometAPI registran solicitudes por defecto; ambos tienen ajustes de retención. LiteLLM solo almacena lo que configures, en tu propia infraestructura. El comportamiento de registro de Cloudflare se describe en su documentación de AI Gateway. Lee los términos de privacidad de cualquier servicio alojado antes de enviar contenido sensible a través de él.
¿Qué pasa si la pasarela se cae?
Para pasarelas alojadas (CometAPI, Portkey, Cloudflare), una caída de la pasarela significa que tu aplicación no puede alcanzar al proveedor de IA por esa ruta. LiteLLM ejecutándose localmente tiene las mismas características de disponibilidad que tu propio servidor. Antes de comprometerte con cualquier pasarela alojada para producción, revisa su SLA y si ofrece fallback directo al proveedor si la propia pasarela no está disponible.
¿Hay una forma gratuita de evaluar cada una antes de comprometerse?
Sí. CometAPI y Portkey tienen niveles gratuitos. LiteLLM es de código abierto y solo cuesta la infraestructura donde lo ejecutes. Cloudflare AI Gateway es gratuito dentro de límites generosos. Puedes probar las cuatro con los mismos prompts de test antes de decidir.
¿Cómo elijo los nombres de modelo correctos para cada pasarela?
Cada pasarela tiene su propia convención. CometAPI usa sus propios identificadores (gpt-5.4, claude-opus-4-7). Portkey usa el formato @provider/model-name (@openai/gpt-4o, @anthropic/claude-3-5-sonnet). LiteLLM utiliza los nombres de modelo que definas en la configuración de tu proxy. Cloudflare pasa los nombres de modelo estándar del proveedor sin cambios. Consulta la documentación de cada pasarela para su lista de modelos actual antes de escribir código.
¿Cambiar de pasarela afecta mis límites de tasa actuales?
Sí. Si pasas de llamadas directas a OpenAI a una pasarela que gestiona la relación con el proveedor (como CometAPI), tus límites de tasa efectivos los determina la cuenta de la pasarela con OpenAI, no tu cuenta personal. Verifica el comportamiento de límites de tasa con la pasarela antes de migrar tráfico de producción.