HiWay2LLM vs Portkey
Comparativa honesta entre HiWay2LLM y Portkey. Observabilidad profunda vs optimización del coste por request, modelos de pricing, gobernanza de prompts, y cuándo elegir uno u otro.
Portkey gana cuando tu equipo necesita observabilidad profunda, gobernanza de prompts y virtual keys para acotar presupuestos. HiWay gana cuando el coste por request es el KPI principal. Si tu dolor n.º 1 es 'no sé qué hace cada request', Portkey. Si es 'esta factura no para de crecer', HiWay.
Portkey y HiWay2LLM se presentan los dos como LLM gateways, los dos se ponen delante de los mismos proveedores upstream, y los dos hablan la API de OpenAI. Si solo lees las landings, parecen intercambiables. Bajo el capó optimizan por dos cosas muy distintas.
El centro de gravedad de Portkey es la observabilidad y la gobernanza: logs por request profundos, versioning de prompts, guardrails, virtual keys para acotar los presupuestos de equipo. Es a lo que recurres cuando hay que saber, en auditoría, qué hizo cada request y quién la lanzó.
El centro de gravedad de HiWay es el coste por request: un router que lee cada prompt entrante y elige el modelo más barato capaz de responder, con 0% de markup sobre la inferencia y BYOK. Es a lo que recurres cuando tu factura crece más rápido que tus ingresos.
Aquí va el match cara a cara, sin bullshit.
Decisión rápida
- ¿Tu dolor real es "no veo qué hace mi tráfico LLM"? Portkey. Es el job para el que está pensado.
- ¿Tu dolor real es "esta factura no para de crecer"? HiWay. El routing por complejidad más cero markup apuntan exactamente a eso.
- ¿Necesitas versioning de prompts, A/B tests, una prompt library compartida? Portkey tiene un producto de prompt management completo. HiWay no.
- ¿Estás en la UE o necesitas hosting RGPD con DPA firmado? HiWay está alojado en OVH en la UE. Verifica las opciones de residencia de Portkey en su doc pública.
- ¿Quieres la capa lo más fina posible en el hot path? HiWay. Portkey despliega un perímetro más amplio.
Pricing
Portkey corre en un modelo SaaS por tramos: un tier gratuito para volúmenes pequeños, después tiers de pago que escalan con las features (retención de observabilidad, seats, SSO empresarial, opción on-prem). Pricing publicado según su doc pública a 2026-04-22 — revisa su sitio para el detalle exacto. El encuadre importante: pagas por la capa de observabilidad y gobernanza, y su valor crece con el tamaño del equipo.
HiWay te factura una tarifa flat mensual por la capa de routing. La inferencia la factura el proveedor directamente a tu tarjeta al wholesale (BYOK, 0 % markup en tokens):
| Plan | Precio | Requests enrutados / mes |
|---|---|---|
| Free | 0 € | 2.500 |
| Build | 15 €/mes | 100.000 |
| Scale | 39 €/mes | 500.000 |
| Business | 249 €/mes | 5.000.000 |
| Enterprise | bajo demanda | cuotas a medida, SSO, DPA |
La apuesta: una infra flat-fee que escala con los requests, no con los seats o las ventanas de retención. Más el smart routing que hace downgrade automático de los requests simples a modelos más baratos — 40-85 % de ahorro en un mix típico — y bate los 15 €/mes de la suscripción Build en pocas horas de uso real, a cualquier escala.
Regla simple: si tu equipo tiene muchos engineers y necesita gobernanza profunda de prompts, el pricing per-seat/feature de Portkey se justifica. Si tu equipo es pequeño y tu problema es el volumen, la tarifa flat por request de HiWay suele ser más barata.
Feature por feature
| Feature | HiWay2LLM | Portkey |
|---|---|---|
Bring your own keys (BYOK) Los dos soportan BYOK — Portkey vía virtual keys, HiWay nativamente | ||
Smart routing por complejidad de request Portkey enruta por reglas y fallbacks que tú defines, no scoreando el prompt | ||
Prompt library + versioning Portkey despliega un producto de prompt management completo | ||
Guardrails (PII, contenido, schema) Portkey tiene una capa de guardrails más profunda | ||
Observabilidad por request + retención La observabilidad es el producto core de Portkey | ||
Virtual keys para presupuestos de equipo Las virtual keys de Portkey son más granulares | ||
API OpenAI-compatible | ||
Fallback automático entre proveedores | ||
Hosting UE (RGPD) Revisa las opciones de residencia actuales de Portkey | ||
Cero logging de prompts por defecto Portkey loguea by design — es el producto | ||
Modelo de pricing | flat €/mes por tier de requests, 0% markup inferencia | SaaS por tramos, escalado por features/seats |
Job principal | optimización de costes | observabilidad + gobernanza |
native · partial or plugin · not offered
Cuándo elegir cuál
Coge HiWay2LLM si
- Tu gasto LLM mensual es la cifra que quieres mover, y quieres un router que elija activamente modelos más baratos
- Quieres BYOK con cero markup sobre la inferencia y un pricing flat por request
- Estás en la UE o sirves a clientes UE y necesitas hosting RGPD + DPA firmado
- Quieres la capa lo más fina posible en el hot path — no una suite de observabilidad completa que solo usarás a medias
- Cero logging de prompts por defecto es un requisito de compliance, no un nice-to-have
- Quieres burn-rate alerts y topes presupuestarios duros, no solo dashboards retrospectivos
Coge Portkey si
- Tu equipo necesita una prompt library compartida con versiones, A/B tests y rollbacks
- Observabilidad profunda por request con retención larga es un must-have, no un quizás
- Necesitas guardrails granulares (detección PII, validación de schema, filtros de contenido) integrados a la gateway
- Virtual keys por miembro de equipo con presupuestos por clave es como quieres acotar el acceso
- Tu dolor es el audit-readiness y la gobernanza, no el coste por request
- Estandarizas una org de ingeniería grande sobre una sola LLM gateway y quieres el perímetro de features más amplio
Migración — qué cambia de verdad en tu código
Si estás en Portkey hoy, cambiar es un drop-in a nivel SDK. Conservas la misma estructura messages, el mismo streaming, la misma lib cliente. Reemplazas la base URL y los headers Portkey por la base URL y la clave HiWay.
from openai import OpenAI
client = OpenAI(
base_url="https://api.portkey.ai/v1",
api_key="PORTKEY_API_KEY",
default_headers={
"x-portkey-virtual-key": "VIRTUAL_KEY_ID",
},
)
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "Hola"}],
)from openai import OpenAI
client = OpenAI(
base_url="https://app.hiway2llm.com/v1",
api_key="hw_live_...",
)
response = client.chat.completions.create(
model="auto", # deja que el router elija
messages=[{"role": "user", "content": "Hola"}],
)Dos pasos extra antes de cambiar: añade tus claves de proveedor una vez en el dashboard de HiWay (Settings → Providers), y deja model: "auto" si quieres que el router elija — o pin un modelo concreto si quieres forzarlo.
Observabilidad primero vs routing primero — la fractura de categoría
Los dos productos son gateways, pero vienen de problemas de partida distintos. Ese origen sigue moldeando lo que obtienes.
Portkey nació de la observabilidad. El valor core es: cada request que sale de tu app es capturado, indexado, buscable, ligado a la versión del prompt, scoreado contra guardrails. Por eso existe el producto. El routing y los fallbacks son features alrededor de ese core. Si tu dolor es "no puedo responder a la pregunta qué acaba de hacer el LLM", Portkey está hecho para ti.
HiWay nació del coste. El valor core es: cada request es scoreado en menos de 1 ms y enviado al modelo más barato capaz de gestionarlo. La observabilidad existe — logs por request, cost breakdowns, audit trails — pero es una feature de soporte, no el producto. Si tu dolor es "esta factura crece cada mes", HiWay está hecho para ti.
Esta división importa porque los dos jobs tiran del diseño en direcciones opuestas. La observabilidad profunda quiere loguearlo todo para siempre. La optimización del coste quiere loguear lo menos posible (más barato, más rápido, más privado). Puedes apilar el uno sobre el otro, pero el job principal moldea el producto.
En la práctica, los setups más limpios que vemos meten un router orientado a coste como HiWay en el hot path (sensible a la latency, overhead mínimo, cero logging por defecto) y una herramienta de observabilidad al lado para tráfico muestreado o en modo audit. Los dos no son mutuamente excluyentes. Pero pedirle a un solo producto que haga bien las dos cosas suele acabar haciéndolo mediocre en las dos.
Datos & compliance
El producto core de Portkey es la observabilidad, lo que significa que by design captura y retiene los datos de prompt/respuesta. Es una feature, no un bug — el objetivo es justamente inspeccionar qué han hecho tus LLMs. Retención, región, cifrado son configurables según su doc pública. Si tienes datos regulados pasando por los prompts (salud, finanzas, jurídico), prepara el despliegue con cuidado.
HiWay está operado desde Francia por Mytm-Group, alojado en OVH en la UE. Cero logging de prompts por defecto — los prompts pasan por memoria y nunca se persisten. Firmamos un DPA bajo demanda (incluso en plan free) y publicamos nuestros subencargados. Si necesitas loguear para tu propio debug, es opt-in por workspace con una ventana de retención configurable.
Defaults distintos, jobs distintos. Coge el cuyo default encaje con tu postura de compliance.
FAQ
Preguntas frecuentes
Balance
Portkey y HiWay son los dos productos reales que resuelven problemas reales. No son los mismos. Portkey responde cuando tu dolor es "hay que ver, gobernar y auditar cada llamada LLM que hace el equipo". HiWay responde cuando tu dolor es "esta factura crece y el modelo más barato capaz debería elegirse solo". Coge según la frase que te oyes pronunciar más a menudo.
Si el coste es la cifra que quieres mover, mete tu gasto actual en el calculador de ahorros y mira qué hace con él el routing por complejidad.
BYOK, alojado en la UE, sin tarjeta bancaria