Runpod muestra cómo desplegar un worker Serverless para GPU desde una plantilla de GitHub en tres pasos

Runpod ha publicado una guía práctica sobre workers Serverless. El camino desde una carpeta vacía hasta un endpoint con GPU en funcionamiento cabe en tres acciones: crear un worker a partir de una plantilla de GitHub, probarlo y desplegarlo. La propuesta es pagar por el tiempo en que el worker procesa solicitudes, no por el alquiler de una tarjeta gráfica. El material no incluye precios ni benchmarks. Sí deja ver con claridad el cálculo de la compañía: eliminar los pasos innecesarios entre el código del modelo y la inferencia en producción.

Cómo funciona un worker

Un worker de Runpod es un contenedor Docker con una función handler. Esta recibe un JSON con los datos de entrada, los pasa por el modelo y devuelve otro JSON. De todo lo demás se encarga la plataforma: la cola de solicitudes, el arranque y la parada de contenedores, y el enrutamiento.

La plantilla de GitHub aporta un esqueleto listo: la estructura del repositorio, el Dockerfile, el archivo del handler y un ejemplo de entrada de prueba. El desarrollador solo tiene que añadir su propia lógica: la carga de pesos, la generación de imágenes, el reconocimiento de voz o la respuesta de un modelo de lenguaje.

Parámetros principales del esquema:

• formato: contenedor Docker con handler en Python y el SDK de Runpod;
• punto de partida: fork o clon del repositorio de plantilla en GitHub;
• verificación: ejecución local del handler con un JSON de prueba antes de pasar a la nube;
• despliegue: imagen en un registro o compilación desde el repositorio, y después el endpoint en la consola;
• facturación: pago por tiempo de ejecución; en las tarifas Serverless de Runpod se cobra por segundo;
• escalado: los workers se levantan con la carga y se apagan cuando están inactivos.

Por qué importa el pago por uso en la IA

Las GPU siguen siendo la partida más cara del presupuesto de casi cualquier producto de IA. Una tarjeta dedicada que pasa la mitad del día sin trabajar se come el margen más rápido que cualquier error de código. En cargas con picos, como un chatbot, un generador de imágenes o el procesamiento por lotes de documentos, la utilización media suele estar lejos del cien por cien. El modelo Serverless traslada ese riesgo del cliente a la plataforma.

En este terreno Runpod compite con Modal, Replicate y otras nubes de inferencia. Las diferencias suelen reducirse a tres factores: el precio por segundo de GPU, la velocidad del arranque en frío y la comodidad del despliegue. Las plantillas apuntan precisamente al tercero. Cuanto menos tiempo se tarda en tener el primer endpoint funcionando, más probable es que el equipo se quede en la plataforma.

Dónde está el inconveniente

La inferencia serverless tiene un coste, y no está en la tarifa. Primero, el arranque en frío. Si el modelo pesa decenas de gigabytes, el contenedor necesita tiempo para cargarlo en memoria. En escenarios interactivos, esa espera se nota. Suelen ayudar el almacenamiento en caché de pesos, las imágenes con el modelo ya empaquetado y un número mínimo de workers siempre calientes, pero cada una de estas soluciones devuelve parte de los costes por inactividad.

Segundo, la dependencia del formato. El handler está escrito para el SDK de una plataforma concreta, y migrar a otra nube exigirá reescribir el código de integración. El modelo en sí, en cambio, se traslada sin problemas.

Tercero, la depuración. La ejecución local detecta errores de lógica, pero no siempre reproduce el comportamiento en la nube, sobre todo cuando las versiones de CUDA y de los drivers son distintas.

Cómo empezar en la práctica

Para un primer experimento basta un modelo pequeño que cargue rápido. Clone el repositorio de la plantilla, sustituya el handler por el suyo y ejecútelo en local con un JSON de prueba. Solo después conviene construir la imagen y crear el endpoint.

A continuación, hay que medir dos cifras: el tiempo de arranque en frío y el coste de mil solicitudes con un perfil de carga real. Si el tráfico es uniforme y se acerca a las 24 horas, lo más probable es que un pod o una instancia dedicada salga más barato. Si las solicitudes llegan en oleadas, Serverless ahorrará dinero. Conviene decidir con las mediciones propias, no con la tabla de tarifas.