> /home/jd
ES / EN

Lo que aprendí al someter a carga un traductor local

Una retrospectiva sobre los límites de una prueba con Ollama y las condiciones necesarias para convertirla en un benchmark reproducible.

Durante el prototipo de traducción local de este portfolio preparé un texto deliberadamente largo y repetitivo para mantener ocupado al modelo durante más tiempo. La intención era comprobar si el flujo completo —lectura de Markdown, traducción con Ollama, reconstrucción del documento y escritura del resultado— podía terminar sin agotar memoria ni interrumpirse.

La prueba cumplió esa función exploratoria, pero el nombre “test de estrés de GPU” prometía mucho más de lo que la evidencia permitía afirmar. Este es el análisis que debí publicar desde el principio.

Qué ejecutaba el prototipo

El traductor utilizaba un modelo Llama 3 de 8B servido por Ollama. Para los artículos técnicos recorría nodos de Markdown, protegía imágenes con placeholders y enviaba cada fragmento al endpoint local. La solicitud histórica incluía, entre otras opciones:

Javascript
{
  model: "llama3",
  options: {
    num_ctx: 4096,
    num_gpu: 99,
    temperature: 0.1,
    top_p: 0.3
  },
  stream: false
}

num_gpu: 99 pedía descargar tantas capas como fuera posible en la GPU, pero esa configuración no demostraba por sí misma dónde se ejecutó cada capa. Para afirmarlo habría sido necesario registrar la respuesta de Ollama y observar CPU, GPU, RAM y VRAM durante cada corrida.

Qué comprobó realmente

La prueba aportó evidencia limitada pero útil:

  • el pipeline podía procesar un documento mayor que las notas habituales;
  • el timeout de diez minutos no se activó durante esa ejecución;
  • los placeholders de imágenes sobrevivieron a la ida y vuelta;
  • el resultado inglés se escribió sin que el proceso terminara abruptamente.

Eso fue una prueba de resistencia del pipeline de traducción, no un benchmark de GPU. No registré la versión exacta del modelo, cuantización, tokens de entrada y salida, tiempo de calentamiento, consumo de memoria, temperatura, potencia ni varias repeticiones comparables. Sin esas mediciones no corresponde publicar cifras de rendimiento ni atribuir el resultado a una pieza concreta de hardware.

El fallo más importante no fue de rendimiento

El corpus de prueba contenía repeticiones artificiales y afirmaciones generales sobre inteligencia artificial. El traductor terminó, pero produjo construcciones poco naturales y conservó conclusiones de hardware que no estaban respaldadas por telemetría. Una salida técnicamente completa podía seguir siendo editorialmente inaceptable.

Esa diferencia cambió el criterio de éxito. La pregunta dejó de ser “¿puede procesar todo el archivo?” y pasó a ser “¿reduce el trabajo total sin degradar el significado?”. En este caso, la revisión y reconstrucción manual costaban más que una adaptación inglesa deliberada.

Cómo diseñaría hoy un benchmark reproducible

DimensiónEvidencia mínima
EntornoCPU, GPU, RAM, sistema operativo y versiones de Ollama y del driver.
ModeloNombre, digest, cuantización, contexto y parámetros efectivos.
CargaCorpus versionado, cantidad de tokens, prompt y hash del archivo.
TiempoCalentamiento separado, duración total y tokens por segundo.
RecursosUso de CPU/GPU, RAM/VRAM, temperatura y errores de descarga de capas.
RepeticiónVarias corridas bajo las mismas condiciones y reporte de dispersión.
CalidadMuestra revisada, taxonomía de errores y comparación con una referencia.

También separaría tres mediciones: inferencia del modelo, transformación del Markdown y revisión humana. Optimizar únicamente la primera puede empeorar el tiempo total si la salida introduce omisiones o cambios semánticos.

Decisión

La prueba sirvió para descubrir un límite del diseño, no para demostrar la capacidad de una GPU. El traductor automático fue retirado y el portfolio adoptó un flujo editorial en el que cada versión inglesa se revisa y aprueba de forma independiente. La arquitectura y los motivos de esa decisión están documentados en la retrospectiva del traductor con Ollama.

Conservar esta experiencia tiene valor precisamente por su resultado: un benchmark profesional no es un archivo grande que termina, sino una pregunta acotada, un entorno registrado y evidencia que otra persona puede interpretar o repetir.