¿Cuándo deberías combinar inferencia de LLM local y en la nube?

Cuándo el híbrido supera al modelo puramente local o puramente en la nube

El factor decisivo es la variabilidad de la demanda, no el costo bruto por solicitud. Si tu tráfico es constante — aproximadamente el mismo número de solicitudes, aproximadamente el mismo tamaño de modelo, todos los días — elige el entorno único más económico para esa carga estable y no compliques más. Las configuraciones híbridas solo valen la pena cuando la demanda varía lo suficiente como para que provisionar localmente para el pico deje el hardware inactivo la mayor parte del tiempo.

Un segundo factor es la necesidad ocasional de un modelo más grande del que puede ejecutar tu hardware local. Si el 95% de tu carga de trabajo cabe cómodamente en hardware local, pero unas pocas solicitudes por semana necesitan un modelo mucho más grande, comprar suficiente hardware local para cubrir ese caso raro suele ser un desperdicio — enrutar solo esas solicitudes a una GPU en la nube alquilada es más económico en general.

Los requisitos de residencia de datos también pueden justificar el híbrido, en la dirección opuesta al costo: mantén todo lo sensible estrictamente local, y enruta a la nube solo las cargas de trabajo no sensibles y menos urgentes. En ese caso, la división la determina la política, no los límites del hardware.

Cómo diseñar la lógica de enrutamiento

Tres patrones de enrutamiento cubren la mayoría de las configuraciones reales, en orden aproximadamente creciente de complejidad.

• ▸**Enrutamiento por tamaño de solicitud:** el patrón más simple. Revisa cada solicitud entrante — tamaño de modelo requerido, longitud de contexto, o una marca de prioridad explícita — y envía a la nube todo lo que supere un umbral fijo, y el resto al hardware local. Fácil de razonar y depurar, pero no se adapta a qué tan ocupado está ya el sistema local.
• ▸**Bursting según profundidad de cola:** solo envía solicitudes a la nube una vez que la cola local se acumula más allá de un umbral definido. Esto se adapta a la carga real en lugar de seguir una regla estática por solicitud, pero requiere monitoreo y algo más de lógica de aplicación para rastrear el estado de la cola y tomar la decisión de enrutamiento.
• ▸**Local primero con respaldo en la nube:** intenta cada solicitud localmente primero, y solo recurre a la nube ante un tiempo de espera agotado o un fallo local explícito (por ejemplo, falta de memoria en una solicitud grande). Fácil de implementar sobre una configuración puramente local existente, pero añade latencia a las solicitudes que terminan recurriendo a la nube, ya que primero esperan el intento local fallido.
• ▸En los tres patrones, una capa de compatibilidad de API entre tu aplicación y ambos backends de inferencia mantiene la decisión de enrutamiento invisible para el resto de tu aplicación — el código de la aplicación solo llama a un endpoint, y la lógica de enrutamiento decide detrás de escena qué backend atiende realmente la solicitud.
• ▸Para el lado del costo de esta decisión — cuánto cuesta realmente una GPU en la nube por hora, y cómo se compara con el costo amortizado de tu hardware local — consulta Costo de GPU en la Nube por Hora y Precios de RunPod vs. Vast.ai para cifras específicas de proveedores que puedes usar en las decisiones de umbral anteriores.