Groq procesó cinco reseñas en 2 segundos y Ollama en 81: lo que el test no cuenta

Supongamos que quieres separar automáticamente las reseñas de los clientes en positivas y negativas. Hay dos opciones: ejecutar un modelo en tu propio ordenador o enviar los textos mediante una API en la nube. Las preguntas son muy prácticas: cuánto tendrás que esperar una respuesta, cuánto costará el procesamiento y adónde irán los datos de los clientes.

Machine Learning Mastery publicó un ejemplo didáctico de esta comparación. En la ejecución del autor, el modelo local procesó cinco reseñas en 80,71 segundos y el modelo en la nube, en 2,02 segundos. La diferencia es de casi cuarenta veces. Sin embargo, aún es pronto para elegir infraestructura a partir de estas cifras: el experimento compara modelos distintos y las condiciones de la ejecución local no están suficientemente documentadas.

Cómo funciona la comparación

El autor construye dos clasificadores con los métodos fit() y predict(), familiares para quienes utilizan scikit-learn. El primero usa Scikit-Ollama y Llama 3 en local. El segundo funciona con Scikit-LLM y envía solicitudes al modelo gpt-oss-20b mediante la API de Groq. Ambos reciben las mismas cinco frases en inglés y dos categorías disponibles: positiva y negativa.

Una función común ejecuta el clasificador, mide el tiempo total y contrasta las respuestas con etiquetas definidas de antemano. Es un punto de partida útil: las frases de demostración pueden sustituirse por reseñas de tu tienda, consultas al servicio de atención al cliente o mensajes breves de usuarios. La interfaz permite mantener la misma lógica de medición al cambiar el sistema que realiza el procesamiento.

En los resultados publicados, el modelo local clasificó correctamente cuatro de las cinco frases y el modelo en la nube acertó las cinco. La exactitud fue del 80% y del 100%. El tiempo incluye las llamadas a fit() y predict(), por lo que los segundos indicados corresponden a toda la ejecución medida, no a la latencia de una solicitud individual.

Por qué todavía no hay un ganador

El principal problema es que el modelo y el entorno de ejecución cambian a la vez. Por tanto, el experimento no permite separar el efecto de la infraestructura de las diferencias entre Llama 3 y gpt-oss-20b. Utilizar la misma función de medición facilita el procedimiento, pero no garantiza por sí solo que los sistemas sean comparables.

Además, el artículo no incluye las especificaciones del hardware local, una serie de ejecuciones repetidas ni resultados separados tras el calentamiento del modelo. Sin esa información, es imposible saber hasta qué punto los 80,71 segundos serían representativos en otro ordenador. Una única cifra total tampoco muestra la variación de las latencias, que puede afectar a la experiencia de uso.

Los resultados de exactitud ilustran el problema con aún más claridad. La única discrepancia apareció en una reseña que puede traducirse como "Está bien, nada especial, pero funciona". El autor la etiquetó como positiva y el modelo local, como negativa. La tarea no contempla una clase neutral. Así, toda la diferencia de veinte puntos porcentuales depende de una frase ambigua y del esquema de etiquetado elegido.

El coste tampoco se mide. La función simplemente imprime la cadena "$0" que se le proporciona. Para la ejecución local, esa cifra no contempla el hardware ni la electricidad; para la ejecución en la nube, no explica las condiciones del acceso gratuito ni los límites de uso. La afirmación de privacidad absoluta también requiere un matiz: ejecutar el modelo en Google Colab, una opción que admite el tutorial, ya implica utilizar infraestructura externa.

Qué puedes aplicar a tu proyecto

El valor práctico del artículo está en la estructura del experimento. Empieza con una muestra representativa de mensajes reales y unas reglas de etiquetado claras. Si tu producto recibe reseñas neutrales, decide de antemano si necesitan una categoría propia. De lo contrario, algunos supuestos "errores del modelo" resultarán ser desacuerdos sobre el significado de las etiquetas.

Después, fija las versiones de los modelos, los parámetros de ejecución y el hardware. Repite las mediciones y evalúa por separado la primera solicitud y el rendimiento tras el calentamiento. Para un servicio, conviene conocer no solo el tiempo medio, sino también la latencia de las respuestas lentas, el comportamiento bajo carga concurrente y la tasa de fallos.

Por último, calcula el coste para el volumen previsto de solicitudes y comprueba los requisitos de transferencia de datos. La prueba muestra cómo crear rápidamente un primer prototipo de comparación. La decisión de ejecutar en local o en la nube debe basarse en los resultados de tu propia tarea: las cinco reseñas publicadas no ofrecen una base suficiente.