Definir el resultado útil antes de buscar rendimiento
En interacción, mide la espera del primer token y la de la respuesta completa. Para un corpus sin conexión, mide el tiempo necesario para obtener todas las salidas esperadas. En ambos casos, fija la regla de aceptación: exactitud en respuestas conocidas, calidad de una clasificación o extracción de campos verificada. Un JSON sintácticamente válido puede contener aún una respuesta falsa.
Separa la espera en cola, el procesamiento y el trayecto completo observado por tu cliente cuando tus herramientas lo permitan. Una medición interna del motor no tiene los mismos límites que la de la aplicación. La documentación de las métricas de vLLM distingue en particular la espera, el primer token y la duración total: conserva esa distinción en tus registros, sea cual sea el motor elegido.
Fuentes técnicas: vLLM — métricas de solicitudes y de latencia
Transformar tus solicitudes en criterios de elección
Prepara entradas cortas, habituales y largas con identificadores estables. Conserva el modelo, el tokenizer, la plantilla de conversación y los parámetros de generación. Cuenta los tokens realmente transmitidos, incluido el historial y los documentos añadidos por la aplicación. Anota por separado el batch solicitado, la concurrencia enviada y las solicitudes efectivamente procesadas de forma simultánea: no son necesariamente los mismos números.
| Entrada que fijar | Medición y unidad | Consecuencia para la elección |
|---|---|---|
| Prompt completo y límite de salida | Tokens de entrada y de salida por solicitud | Verificar los casos largos y las respuestas cortadas en el límite |
| Solicitudes simultáneas y ritmo de llegada | Solicitudes activas, en espera y terminadas | Determinar la carga sostenible con el plazo exigido |
| Precisión, cuantización y caché | Pico de memoria por GPU, en bytes o Gio | Descartar los ajustes que superen la memoria en la carga prevista |
| Regla de calidad y referencias | Salidas aceptadas / salidas esperadas; métrica de negocio | Comparar solo las variantes que respetan el mismo criterio |
| Alcance del cronómetro | Primer token, respuesta completa o corpus: segundos | Comparar duraciones con los mismos límites |
| Calendario hasta los archivos recuperados | Ventana total, en horas o días | Elegir después un plan de 3, 7 o 30 días |
Medir la memoria con contexto y concurrencia
Para un modelo autorregresivo que genera token por token, la caché KV conserva estados de atención. Su tamaño depende del modelo y de los tokens conservados. Una caché dinámica puede crecer durante la generación; una caché estática reserva un tamaño máximo. Algunas capas con ventana deslizante limitan ese crecimiento. Por eso, prueba las longitudes y la concurrencia previstas con la estrategia que realmente utilices.
La cuantización de los pesos y la de la caché son dos decisiones distintas. Por ejemplo, bitsandbytes sustituye algunas capas lineales por versiones cuantizadas; eso no describe todas las asignaciones de tu ejecución. Tras un cambio de precisión, vuelve a verificar memoria y calidad en lugar de suponer que todo el pico disminuye en la misma proporción.
Con PyTorch, registra por separado el pico de los tensores asignados y el de la memoria reservada por el asignador. No los sumes. Indica la GPU medida y la unidad: 1 GiB corresponde a 2³⁰ bytes. Estos contadores no representan necesariamente toda la ocupación del dispositivo. La sección de memoria detalla sus límites.
Fuentes técnicas: Hugging Face Transformers 5.17 — estrategias de caché KV · Hugging Face Transformers 5.17 — cuantización bitsandbytes · PyTorch 2.14 — gestión y contadores de memoria CUDA
Un ensayo medible sobre 300 documentos
Ejemplo para realizar con tu corpus autorizado: extraer fecha, importe y categoría de 300 documentos. Revisa los valores esperados, precisa el tratamiento de los campos ausentes y fija el umbral de aceptación antes del ensayo. El número de documentos describe el protocolo; no se presupone ningún tiempo, puntuación ni rendimiento.
- Fija los 300 identificadores, la revisión del modelo, los prompts, los límites de tokens y la regla de parsing. Mantén los documentos largos identificables en el balance.
- Ejecuta una referencia con una consulta a la vez. Separa carga, calentamiento y medición; conserva las predicciones y los errores por documento.
- Aumenta después un solo parámetro: batch para un procesamiento por lotes, o concurrencia para un motor de consultas. Mantén las mismas entradas y criterios de calidad.
- Para cada pasada, registra duración, pico de memoria, número de identificadores recuperados sin duplicados y salidas aceptadas. Repite las mediciones y conserva los valores brutos con su dispersión.
- Si una variante falla, anota el motivo: memoria, truncamiento, formato o calidad. Un batch reducido o una reanudación crea una decisión que documentar, no un fallo que borrar.
Fuentes técnicas: IteraGPU — protocolo detallado de comparación con calidad equivalente
Usar los recursos de IteraGPU Lab v1 en el alcance correcto
El notebook y su script complementario proponen un cálculo de pesos y una medición sobre una pequeña red sintética. Su código de medición se ejecutó en una RTX 5070 local con PyTorch 2.11.0, sobre una configuración pequeña en float32. Este ensayo verifica ese caso de ejecución; no mide ni un LLM, ni una caché KV, ni las GPU del catálogo con tus consultas.
Usa el notebook para entender los contadores y luego mide tu carga real con su entorno. El protocolo de calidad y la tabla bruta sirven para preparar la comparación. Las salidas del notebook distribuido y las líneas de resultados del CSV permanecen en blanco; el procedimiento no instala ningún modelo ni controlador. Lee los requisitos previos del README antes de la ejecución.
- Notebook de memoria IteraGPU Lab v1
Cálculos y pequeña red sintética para entender la medición de memoria.
- Protocolo de calidad para completar
Entradas fijas, aceptación de salidas y comparación de los ensayos.
- Tabla bruta en blanco
Una línea por pasada real, con parámetros, mediciones y veredicto.
- Requisitos previos y límites de IteraGPU Lab v1
Instrucciones y alcance preciso del ensayo local ya realizado.
Pasar de las mediciones a una oferta
Tu ficha de elección debe reunir entorno compatible, memoria por tarjeta, contexto, concurrencia, calidad alcanzada y plazos medidos. Compara las configuraciones que cumplen estos criterios y luego los planes de 3, 7 y 30 días según el calendario completo: preparación, procesamiento, evaluación, reanudaciones y exportación. La calculadora del apartado de benchmarks usa el plan completo y corpus útiles realmente validados.
Conserva esta ficha y las versiones del código en tu cuaderno. Tú eliges tus programas y tus procesamientos; IteraGPU no inspecciona el contenido de tus archivos, prompts o cálculos. Una elección de entorno al hacer el pedido expresa tu necesidad de preparación: no constituye una prueba de que tu modelo ya se haya instalado o probado.
Preguntas prácticas
¿Bastan 24 GB para mi modelo de inferencia?
La capacidad de 24 GB no basta para responder sin conocer el modelo y la carga. Verifica en conjunto pesos, asignaciones de ejecución, contexto y solicitudes simultáneas. La configuración debe terminar los casos largos con la calidad exigida; un tamaño de archivo o una estimación de los pesos por sí solos no lo demuestran.
¿Qué rendimiento hay que comparar para un corpus sin conexión?
Compara primero el tiempo necesario para terminar y evaluar el mismo corpus. Si publicas un rendimiento, indica el número de salidas útiles aceptadas, el tiempo considerado y los errores. Un rendimiento en tokens por segundo sin longitud de respuesta ni control de calidad no basta para decidir entre dos configuraciones.
¿Un exceso de memoria obliga a cambiar de GPU?
Un exceso de memoria exige primero identificar el ajuste y la entrada que lo provocaron. Puedes examinar batch, concurrencia, longitud o precisión, conservando el objetivo del proyecto. Toda reducción que cambie los documentos procesados o las respuestas esperadas obliga a una nueva verificación de calidad; puede ser necesaria más memoria si hay que conservar esas restricciones.
¿El notebook proporcionado valida mi aplicación de inferencia?
El notebook proporcionado no valida tu aplicación: mide una pequeña red sintética y explica los contadores de memoria. La prueba local documentada solo abarca ese caso. Tu aplicación debe evaluarse con su modelo, sus entradas, su entorno y sus propios criterios de aceptación antes de cualquier conclusión sobre capacidad o rendimiento.