RunPod publica una guía para migrar de la API de OpenAI a un LLM propio con pesos abiertos

RunPod ha publicado una guía para migrar de la API de OpenAI a un modelo de lenguaje autoalojado con pesos abiertos. Va dirigida a equipos hartos de los límites de peticiones y de unas facturas que crecen al ritmo del tráfico. El anuncio no incluye cifras concretas de ahorro. Se trata de material de un proveedor: RunPod vende una nube de GPU, y la lógica de la guía responde a ese interés. Aun así, en los últimos dos años la ruta de migración se ha vuelto casi estándar, y conviene analizarla con sentido crítico.

Por qué los equipos abandonan la API

Una API gestionada arrastra tres problemas crónicos. El primero son los límites: los topes de peticiones y de tokens por minuto frenan el crecimiento del producto antes de lo deseado. El segundo es la impredecibilidad de la factura: se paga por cada token, y una función que funciona bien puede convertirse de golpe en la principal partida de gasto. El tercero es la dependencia de decisiones ajenas: el proveedor puede cambiar el comportamiento del modelo, subir el precio o retirar una versión. En algunas empresas se suma además la duda sobre adónde van a parar los datos.

El autoalojamiento sustituye el pago por token por el alquiler de GPU por tiempo. Las cuentas salen cuando la tarjeta trabaja de forma estable y con mucha carga. Si las peticiones son escasas e irregulares, el hardware ocioso se come fácilmente todo el beneficio y la API sigue siendo más barata.

Cómo es la migración

El esquema que describe RunPod, y que siguen la mayoría de los equipos, es breve. Primero se elige un modelo abierto para la tarea: Llama, Qwen, Mistral o, por ejemplo, gpt-oss, de la propia OpenAI. Después se levanta un servidor de inferencia como vLLM, capaz de ofrecer un endpoint compatible con OpenAI. Gracias a ello, apenas hay que tocar el código del cliente: basta con cambiar la dirección, la clave y el nombre del modelo.

En RunPod se puede desplegar de dos maneras: en un pod dedicado con GPU o en modo serverless, donde los workers escalan según la carga y no se pagan mientras están inactivos.

Referencias sobre hardware y compatibilidad:

• En el código cambian tres parámetros: base_url, clave de API y nombre del modelo.
• Según OpenAI, gpt-oss-120b cabe en una sola GPU de 80 GB de memoria y tiene licencia Apache 2.0.
• gpt-oss-20b está pensado para unos 16 GB de memoria.
• Pod es adecuado para cargas estables; Serverless, para cargas variables.
• Se paga por el tiempo de uso de la GPU, no por tokens.

Dónde están los problemas

Un modelo abierto no tiene por qué comportarse como GPT con tus prompts. En razonamiento complejo y contexto largo la brecha puede ser notable, y cada modelo implementa a su manera el function calling y la salida estructurada. Un endpoint compatible con OpenAI garantiza el formato de la petición, pero no la calidad de la respuesta.

El segundo grupo de riesgos es la operación. En serverless existe el arranque en frío, en el que la primera petición tras un periodo de inactividad puede tardar bastante más de lo normal. La monitorización, las colas y la actualización de los pesos y de las versiones del servidor pasan a ser cosa tuya, no del proveedor. Para un equipo pequeño, esto puede costar más que los tokens ahorrados.

Cómo comprobarlo con tu propio tráfico

Antes de cambiar producción, conviene seguir unos pasos:

1. Activar el registro de peticiones y respuestas reales para obtener un conjunto de pruebas fiable. 2. Ejecutar ese conjunto con el modelo candidato y compararlo con el actual según tus propios criterios, no según benchmarks públicos. 3. Lanzar el nuevo modelo en modo sombra con una pequeña parte del tráfico, por ejemplo entre el 5 % y el 10 %. 4. Calcular el coste de mil peticiones con la carga real de la GPU, incluido el tiempo ocioso. 5. Mantener la API de OpenAI como ruta de respaldo en caso de fallo o de calidad insuficiente.

Si después de esto las cifras cuadran, la migración está justificada. Si no, la guía de RunPod sigue siendo útil: muestra cuánto cuesta realmente la independencia de una API ajena.