Redes de LLM autohospedadas: un único gateway en lugar de un host por modelo

El autoalojamiento de modelos de tipo open-weight suele comenzar de forma sencilla: un modelo, un nombre de host y un flujo operativo sin problemas. Los problemas surgen cuando aparecen un segundo y un tercer modelo. Cada nuevo archivo de pesos tiende a requerir configuraciones adicionales de red, interconexión y aplicaciones, aunque el producto solo solicitara otro identificador de modelo. Al colocar una pasarela delante de los servidores backend se logra un único punto de acceso, mientras los modelos se añaden o eliminan detrás de ella. La lección es arquitectónica, no específica del producto: deje de enseñar a cada cliente la topología de cada servidor con GPU.

Comenzó con un modelo

Un punto de control de tipo Qwen de open-weight se ejecutaba localmente y se accedía a través de un nombre de host:

llm.my-app.com

La aplicación llamaba a ese punto de acceso con el nombre del modelo y el resto de los datos de la solicitud. El tráfico funcionaba bien y los paneles de control se mostraban correctamente. Luego, una instancia más rápida de Gemma quiso tener su propio servidor de escucha para rutas sensibles a la latencia:

flash.llm.my-app.com

Eso también funcionó. Los modelos de imágenes y las copias de evaluación de los puntos de control de clase DeepSeek atrajeron a aún más servidores:

images.llm.my-app.com

deepseek-v4.llm.my-app.com

Qwen en entorno de producción permaneció sin cambios, mientras que el desarrollo se centraba en el endpoint del experimento. Cada paso era razonable por separado. En conjunto, crearon una red de URLs base que solo la persona que las configuró podía recordar.

Funcionó, pero algo parecía incorrecto

Ninguno de los pasos era difícil, y ese era el problema. Cada modelo repetía la misma secuencia: desplegar pesos, exponer un servicio, configurar la red, conectar las VPCs para que los hosts privados del modelo pudieran acceder a la aplicación, y luego indicarle a la aplicación una nueva URL base. Nada de eso constituye al “modelo” en sí; se trata simplemente de tareas técnicas genéricas. No se podía decirles a los compañeros de equipo “utilicen nuestro servicio de LLM y elijan este modelo”; necesitaban que se les especificara exactamente qué host utilizar, y la conversación tenía que reiniciarse cada vez que aparecía un nuevo endpoint. Incorporar a un contratista significaba enviarles un glosario privado de nombres de hosts en lugar de un catálogo único.

El experimento con DeepSeek lo hizo evidente

Evaluar una implementación separada de tipo DeepSeek sin afectar a Qwen en producción significaba añadir otro punto de acceso al entorno de desarrollo. Técnicamente no había nada roto. La pregunta persistente seguía siendo: ¿por qué añadir un modelo implica necesariamente añadir componentes de red? Lo que cambiaba eran los pesos del modelo; la infraestructura de la aplicación no debería tener que modificarse al mismo ritmo. Si cada experimento requiere cambiar el DNS y las conexiones de interconexión, la investigación se ralentiza al ritmo de los tickets relacionados con cambios en la red.

Entonces, ¿cómo exponen los proveedores a gran escala sus modelos?

Los principales proveedores no crean una URL base pública distinta para cada modelo. Los usuarios finales no tienen que lidiar con familias de servidores como estas:

gpt-4.api.openai.com
gpt-5.api.openai.com
some-other-model.api.openai.com

Ellos mantienen una única API y seleccionan el modelo dentro de la solicitud. Si los proveedores pueden presentar docenas de modelos a través de una misma interfaz, las flotas autohospedadas pueden buscar lograr el mismo formato. El contrato con el cliente se vuelve estable; la flota detrás de él puede cambiar constantemente.

La idea: colocar un proxy delante de los modelos

Las aplicaciones siempre deben comunicarse con una base estable:

llm.my-app.com

y elegir el modelo en el cuerpo de la solicitud:

{
  model: "qwen-3.8",
  ...
}

{
  model: "gemma-3",
  ...
}

{
  model: "deepseek-v4",
  ...
}

Los backends pueden moverse entre diferentes máquinas, regiones o entornos de ejecución; el contrato con el cliente permanece igual. Esa es la misma abstracción que ya venden los proveedores de nube, solo dirigida a flotas de código abierto bajo su control.

Crear un proxy versus adoptar una pasarela

Un forwarder ingenuo —es decir, un modelo para enviar, enrutar y devolver datos— parece sencillo hasta que es necesario convertirlo en un servicio compartido. Entonces aparecen las claves virtuales, el control de uso, el control de acceso, la configuración del modelo, los límites de velocidad, el registro de actividades y una interfaz de administración. Ya no se trata de un proxy simple; es una puerta de enlace para LLM. Reconstruir esos controles desde cero implica abordar años de casos especiales (rotación de claves, presupuestos por equipo, registros de auditoría). LiteLLM se enfoca en esa capa de control para que los equipos no tengan que hacerlo.

Por qué LiteLLM es la opción adecuada

Las aplicaciones mantienen un único punto de conexión:

llm.my-app.com

LiteLLM enruta hacia backends heterogéneos:

My Application
                        │
                        ▼
                 llm.my-app.com
                        │
                        ▼
                   LiteLLM
                  /   |    \
                 /    |     \
              Qwen  Gemma  DeepSeek

Agregar un modelo experimental se convierte en: desplegar sus pesos, registrarlos en la puerta de enlace y mantener sin cambios la URL de la aplicación. Los nombres de host ya no se filtran en el código del producto. Los desarrolladores eligen los modelos de la misma manera que eligen las temperaturas: dentro de la solicitud, y no editando archivos de entorno para cada experimento.

La implementación fue sencilla

LiteLLM se entrega como una imagen Docker y, por lo general, requiere PostgreSQL para almacenar de forma persistente datos como claves y gastos:

LiteLLM container
        │
        ├── PostgreSQL
        │
        └── Open-weight model servers

Los servidores de modelos se centran únicamente en la inferencia; el gateway se encarga del plano de control por encima de ellos. Las máquinas con GPU ya no necesitan ser accesibles directamente desde cada microservicio. La comunicación entre componentes se concentra en el nivel del gateway en lugar de mediante una red tipo N por M entre las aplicaciones y los hosts de modelos.

Lo que realmente cambió

Antes del gateway, agregar un modelo significaba tener que repetir todo el proceso de configuración de redes:

New model
   ↓
New deployment
   ↓
New networking
   ↓
New hostname
   ↓
Application changes

Después, ese proceso se reduce a simplemente registrar el modelo en una puerta de entrada estable:

New model
   ↓
Deploy it
   ↓
Register it with the gateway
   ↓
Use the existing endpoint

La lección clave: las aplicaciones no deben necesitar saber dónde se ejecuta un LLM, solo qué modelo solicitar. LiteLLM es una forma práctica de establecer ese límite. El problema original no era el producto de puerta de enlace, sino el segundo modelo. Una vez que se identifica este patrón, cada modelo posterior ya sea refuerza la red de nombres de host o un único catálogo. Elija el catálogo.

Notas operativas importantes

• Trate el registro de modelos como una acción gestionada mediante cambios: quién puede agregar servidores backend, cómo se asignan las claves a los equipos y cómo caducan los experimentos.
• Mantenga las verificaciones de estado de los servidores backend separadas del endpoint público para que un modelo inactivo no parezca una interrupción total.
• Documente la única URL base en los documentos de incorporación y se niegue a publicar nombres de host adicionales para los equipos de aplicaciones, a menos que haya un requisito estricto de aislamiento.

Esos hábitos preservan la abstracción que se creó al introducir la pasarela.