Una respuesta rápida a una única pregunta breve demuestra que un modelo de lenguaje local funciona en principio. Para decidir sobre la infraestructura, resulta mucho más útil probar las futuras tareas con su carga real. Esto incluye calidad de respuesta, tiempos de espera, entradas largas, uso simultáneo y funcionamiento tras un fallo.
Un piloto es especialmente útil si antes se define qué decisión debe permitir su resultado. Por ejemplo: ¿basta el entorno existente, hace falta otro hardware o conviene más un servicio externo o híbrido? Esa pregunta guía el plan de pruebas.
Empezar con un pequeño conjunto de tareas representativas
Las tareas adecuadas proceden del flujo de trabajo previsto: una pregunta técnica breve, el resumen de un documento aprobado más largo o un borrador de script que deba revisarse. Para cada tarea se define cómo reconocer un resultado útil.
Las preguntas de conocimiento deben incluir las fuentes esperadas y casos sin base suficiente. El código necesita revisión técnica y pruebas apropiadas. Los datos originales confidenciales se usan solo en el entorno autorizado; para preparar las pruebas pueden bastar datos depurados o creados expresamente.
Evaluar calidad y velocidad por separado
Un modelo que entrega resultados incorrectos rápidamente no cumple el objetivo. Primero se evalúan la utilidad práctica, las correcciones necesarias y el tratamiento de la información que falta. Después se comparan el tiempo de respuesta y el esfuerzo necesarios para lograr esa calidad.
Se registran la versión del modelo, cuantización, software de inferencia, ajustes y datos de prueba. De lo contrario, una respuesta más rápida podría deberse a otra tarea o a otro nivel de calidad. Una colección documental cambiante también puede alterar la comparación de una aplicación RAG.
Desglosar el tiempo de espera
- Tiempo hasta el primer token
- Describe cuándo empieza la salida. La cola y el procesamiento de la entrada pueden influir en él. También conviene medir el tiempo percibido desde el envío en la aplicación hasta la respuesta visible.
- Generación de la salida
- La velocidad de generación influye en cuánto tarda una respuesta larga. Un alto rendimiento agregado del servidor no indica por sí solo la rapidez con la que cada usuario recibe su respuesta.
- Duración total
- Abarca toda la operación de la aplicación. Pueden añadirse búsqueda, preparación documental, llamadas a herramientas y trayectos de red.
- Variabilidad y errores
- Los valores habituales se consideran junto con los casos extremos más lentos. El número de mediciones, los tiempos de espera agotados y las tareas interrumpidas forman parte del resultado.
La documentación oficial de métricas de vLLM (enlace externo) distingue, entre otras, mediciones de espera, entrada y salida. Debe comprobarse qué métricas ofrece el entorno de ejecución concreto en la versión utilizada. Las medidas de distintos componentes deben describir el mismo periodo y la misma tarea.
Probar chats breves, contextos largos y concurrencia
Un contexto largo exige procesamiento y memoria adicionales. Las solicitudes simultáneas comparten los recursos disponibles. La documentación de Ollama sobre el contexto (enlace externo) y la documentación de optimización de vLLM (enlace externo) explican esas relaciones; los ajustes concretos dependen de la versión y del hardware.
Una prueba útil combina entradas breves y largas con una concurrencia adecuada al uso previsto. Además de las solicitudes regulares, se consideran los picos esperados. Si el procesamiento por lotes aumenta el rendimiento, sigue siendo necesario comprobar si los tiempos individuales son adecuados para los usuarios.
Un posible plan de pruebas
Primero ejecutar individualmente las mismas tareas técnicas. Después probar juntas solicitudes breves y tareas con documentos aprobados. A continuación reproducir un periodo de máxima demanda esperado y observar la sobrecarga. Los objetivos se acuerdan antes con los usuarios.
Este plan es un ejemplo adaptable. No contiene cifras de rendimiento DAXS medidas ni sustituye la evaluación del entorno concreto.
Distinguir arranque, funcionamiento habitual y recuperación
Tras un reinicio puede ser necesario cargar primero el modelo. Esta fase de arranque en frío se mide por separado del funcionamiento con el modelo ya cargado. Unidades NVMe rápidas pueden ayudar en la carga y las operaciones de datos; ello no implica una aceleración general de la generación de tokens en un modelo alojado íntegramente en la memoria GPU.
El piloto también incluye la pérdida de una conexión, una tarea interrumpida y el reinicio de un servicio. La aplicación debería mostrar su estado de forma comprensible y ofrecer una vía útil para reintentar o transferir el trabajo. La sobrecarga no debe producir resultados incompletos sin avisar.
Convertir los resultados en una decisión de arquitectura
Se comparan resultados útiles, esfuerzo de corrección, latencia, capacidad y operación habitual. Los costes totales incluyen administración, mantenimiento, energía, copias de seguridad y disponibilidad necesaria. Los servicios externos añaden sus costes reales de uso y los recorridos de datos acordados.
El resultado puede ser un modelo más pequeño y adecuado, recursos adicionales, una cola limitada u otro modelo operativo. Los enfoques locales, externos e híbridos se evalúan con la misma tarea. El piloto debe permitir una siguiente decisión fundamentada, sin justificar a posteriori la compra de un hardware previamente dado por necesario.
DAXS planifica la prueba, prepara un entorno adecuado y evalúa los resultados con su equipo de TI. Nuestra página especializada sobre LLM locales e infraestructuraexplica la base técnica. Para los repositorios de conocimiento conectados, la calidad de la búsqueda, las fuentes y los permisos forma parte del mismo marco de evaluación.
