Define el entregable que justifica tu alquiler
Para un procesamiento de archivos, define el volumen que hay que recorrer, el formato de salida y la regla de reanudación. Un archivo terminado debe poder reconocerse sin releer toda la ejecución. Para un servicio interactivo, define el tamaño máximo de las solicitudes, el tiempo de espera aceptable y el comportamiento cuando se alcanza la capacidad. Un mismo modelo puede exigir dos organizaciones muy distintas según estas restricciones.
Conserva una muestra representativa con casos cortos, habituales y cercanos a tus límites. En un pipeline de embeddings, asocia cada vector al identificador y a la versión de su entrada. En una generación de texto, registra los parámetros de generación usados para la evaluación. Debes poder explicar una diferencia de resultado sin atribuirla de inmediato a la GPU.
Elige la memoria para toda la carga de inferencia
El peso de los archivos del modelo no describe toda la memoria utilizada durante la inferencia. También hay que considerar los tensores temporales, las entradas, las salidas conservadas y, en los modelos correspondientes, la caché de claves y valores de la atención. Esta caché puede volverse importante cuando las secuencias se alargan o cuando se procesan varias solicitudes a la vez.
Empieza por una tarjeta cuya memoria permita tu prueba representativa con un margen medido. Los modelos de 24, 32, 48, 80 GB y más responden a necesidades distintas; ninguna capacidad garantiza que un modelo dado funcione con todos sus ajustes. Reducir la precisión o cuantificar puede cambiar la huella, pero obliga a verificar el soporte del software y la calidad de las salidas con tus propias entradas.
Quédate con la GPU compatible con tu cadena de software
Enumera el motor de inferencia, sus operadores particulares y las extensiones de las que dependes antes de elegir el hardware. Una aplicación PyTorch puede ofrecer varias rutas de ejecución, mientras que una extensión especializada solo admite una. Verifica la cadena completa en CUDA para NVIDIA o en ROCm para AMD, incluida la carga del modelo y su preprocesamiento.
Mantén un comando mínimo que recorra el pipeline hasta escribir un resultado. Solo después activa tus optimizaciones una a una. Cada cambio de precisión, de compilación o de motor debe conservar un control de calidad comparable. Una carga exitosa demuestra que los pesos son legibles; no demuestra que todas las rutas de cálculo necesarias funcionen.
Ajusta el batch según tu objetivo de procesamiento
Ejemplo de método: forma tres grupos de textos por longitud y procesa cada uno con un batch de 1, de 2 y de 4 entradas. Estos tamaños sirven como puntos de prueba, no como recomendación universal. Para cada combinación, anota las entradas terminadas, el tiempo total, la memoria máxima observada y los errores. Detén la progresión cuando aparezca un límite en lugar de ocultar los fallos en un promedio.
Para un servicio interactivo, añade el tiempo pasado en la cola de espera. Un batch más grande puede cambiar el rendimiento y el tiempo de respuesta percibido por una solicitud; un solo promedio no basta para elegir. Para un procesamiento sin conexión, asegúrate de que la agrupación no altere el orden de los resultados. Elige finalmente una configuración que respete tu criterio de calidad y tu restricción de tiempo.
Pasa a varias GPU si tu aplicación sabe repartir el trabajo
Si cada ejemplar del modelo cabe en una tarjeta, puedes organizar varios trabajadores que consuman particiones distintas de las entradas. Entonces hay que coordinar los identificadores, las reanudaciones y la recogida de las salidas. Si el modelo debe repartirse entre tarjetas, usa una estrategia de paralelismo compatible con tu motor y verifica sus requisitos de comunicación.
Los lotes solicitados describen la cantidad de hardware, no el batch de la aplicación ni un espacio de memoria fusionado. Para B200, un lote comprende dos tarjetas; para las demás ofertas, un lote comprende una tarjeta. Indica en tu expediente el número de trabajadores previsto, la parte de entradas confiada a cada uno y la manera de constatar que un trabajo ha finalizado realmente.
Elige un periodo que incluya las verificaciones y la exportación
Para un primer alquiler de 3 días, plantea un objetivo limitado: instalar, validar el pipeline y producir un primer resultado aprovechable. Una duración de 7 días puede servir para recorrer más variantes; 30 días para repetir un procesamiento y consolidar su explotación. Son formas de organizar el trabajo, no promesas de plazos de ejecución.
A la salida, conserva los pesos o su versión, la configuración, los controles de calidad, las métricas realmente obtenidas y los resultados exportados. Tú eliges tus programas y tus procesamientos con autonomía; Kernodeck no inspecciona su contenido. Prepara tú mismo tus accesos, tus copias de seguridad y las autorizaciones necesarias para el uso de los modelos y los datos.