Mes: octubre 2026

Por: Julio Cesar Sandria Reynoso
Maestro en Inteligencia Artificial
15 de Octubre de 2026

¿Puede una computadora antigua convertirse en un servidor de inteligencia artificial? Evaluamos 22 modelos con Ollama.

Una experiencia del Instituto de Robótica de Xalapa (iRoX) para aprovechar computadoras existentes mediante inteligencia artificial local: Benchmark iRoX V0.8.7.

Introducción

La inteligencia artificial generativa suele asociarse con centros de datos y tarjetas gráficas de alto rendimiento. Sin embargo, también podemos aprovechar computadoras que han dejado de utilizarse y convertirlas en servidores locales de IA. En iRoX nos preguntamos qué tan útil puede ser una computadora antigua para ejecutar modelos de lenguaje con Ollama.

No buscamos competir con los grandes servicios comerciales, sino identificar modelos utilizables, comparar la calidad de sus respuestas y medir cuánto tardan en generarlas. El experimento terminó con 22 modelos evaluados, 220 respuestas históricas y dos candidatos recomendados para necesidades diferentes.

1. El origen del proyecto

En septiembre de 2026 documentamos en Robótica Sandria la instalación de una IA generativa con Ubuntu y Ollama. El equipo tenía originalmente 8 GB de RAM y un disco duro mecánico (HDD, hard disk drive). Después ampliamos la memoria a 32 GB y actualizamos el almacenamiento a una unidad de estado sólido (SSD, solid state drive) para probar modelos mayores.

Componente	Configuración durante el benchmark
Procesador	Intel Pentium G4400, 3.30 GHz
RAM	32 GB (2 × 16 GB)
Almacenamiento principal	SSD de 120 GB
Tarjeta gráfica con GPU	NVIDIA GTX 750 Ti, 2 GB
Sistema operativo	Ubuntu Server 24.04 LTS
Motor	Ollama
Inferencia principal	CPU

La GPU (Graphics Processing Unit o Unidad de Procesamiento Gráfico) no se utilizó como acelerador principal. Una pregunta todavía pendiente es si los 32 GB de RAM eran necesarios para los modelos finalmente elegidos o si una ampliación menor habría bastado.

2. ¿Qué medimos?

Un benchmark es un conjunto de pruebas ejecutadas bajo condiciones definidas. En este estudio consideramos calidad de respuesta, tiempo medio por prueba, capacidad de ejecución y fiabilidad. La prioridad fue comparar la calidad y el tiempo total de respuesta en un mismo servidor. Estos resultados son una evaluación operativa, no una validación científica general de los modelos.

3. Evolución del benchmark iRoX

El proyecto comenzó con un cliente Python para comunicarse con Ollama. Se añadieron registros de tiempo, respuestas y métricas; un banco de diez pruebas; ejecución por lotes; exportación CSV; conservación de respuestas; evaluación automática; y auditorías de discrepancias. Las versiones V0.6 consolidaron el banco de pruebas y las series V0.7 y V0.8 profundizaron en la revisión de calidad y trazabilidad. Este artículo utiliza los resultados consolidados V0.8.7.

4. El banco de diez pruebas

ID	Área
MAT-001	Matemáticas
MAT-002	Matemáticas
LOG-001	Lógica
LOG-002	Lógica
PROG-001	Programación
PROG-002	Programación
ROB-001	Robótica
IA-001	Inteligencia artificial
DAT-001	Análisis de datos
STEM-001	Ciencia, tecnología e ingeniería

Una actividad solicitaba analizar los tiempos 2, 3, 3, 4 y 8 segundos. La media correcta es 4 segundos y la mediana 3. También se evaluaron tareas de Python y situaciones de robótica, como el uso de sensores para seguir una línea. Cada uno de los 22 modelos recibió diez pruebas.

5. Los 22 modelos evaluados

La tabla muestra las puntuaciones consolidadas de iRoX V0.8.7, los tamaños registrados para los modelos y los tiempos medios por prueba. El tamaño del archivo del modelo no equivale a la RAM máxima consumida durante su ejecución.

Posición	Modelo	Tamaño	Calidad /100	Tiempo medio (s)
1	gemma3:4b	3.11 GB	98.33	166.39
2	sam860/LFM2:700m	754.91 MB	93.33	31.74
3	gemma2:2b	1.52 GB	93.33	40.75
4	qwen2.5:1.5b	940.38 MB	88.33	29.10
5	sam860/olmo2:1b-Q5_K_M	1.00 GB	86.67	40.79
6	llama3.2:3b	1.88 GB	85.00	105.86
7	llama3.2:latest	1.88 GB	85.00	116.40
8	qwen2.5:3b	1.80 GB	80.00	108.50
9	granite4:3b	1.96 GB	80.00	113.45
10	llama3.2:1b	1.23 GB	71.67	36.81
11	phi3:latest	2.03 GB	68.33	79.63
12	jewelzufo/unsloth_granite-4.0-h-350m-GGUF:latest	212.36 MB	60.00	2.59
13	qwen3:8b	4.87 GB	60.00	493.59
14	llama2-uncensored:latest	3.56 GB	57.50	55.59
15	tinyllama:latest	608.16 MB	45.00	30.04
16	hf.co/CoreWorxLab/caal-qwen3.5-2b:latest	1.19 GB	40.00	59.25
17	jewelzufo/MiniCPM5-1B:latest	656.19 MB	37.50	67.48
18	smollm:1.7b-instruct-v0.2-q2_K	643.34 MB	22.50	90.49
19	moondream:latest	1.62 GB	18.33	12.57
20	smollm2:135m-instruct-q4_K_M	100.58 MB	15.00	20.74
21	qwen3:4b	2.33 GB	10.00	256.45
22	Alieno/ailo-152m-v3:latest	155.63 MB	5.00	0.76

Fuente: resultados históricos consolidados de iRoX Benchmark V0.8.7. Los tiempos no están normalizados por número de tokens. Una puntuación baja puede reflejar fallos de formato, truncamiento o incompatibilidad de la tarea con el modelo; no demuestra inutilidad general.

6. Selección de los cinco finalistas

Para el análisis final seleccionamos los cinco modelos con mejores resultados de calidad en nuestro banco de pruebas, considerando también sus tiempos y tamaños.

Modelo	Tamaño del modelo	Calidad /100	Tiempo medio (s)
gemma3:4b	3.11 GB	98.33	166.39
sam860/LFM2:700m	754.91 MB	93.33	31.74
gemma2:2b	1.52 GB	93.33	40.75
qwen2.5:1.5b	940.38 MB	88.33	29.10
sam860/olmo2:1b-Q5_K_M	1.00 GB	86.67	40.79

gemma3:4b obtuvo la puntuación más alta (98.33/100), con 166.39 segundos de promedio por prueba. sam860/LFM2:700malcanzó 93.33/100 y tardó 31.74 segundos en promedio: fue aproximadamente 5.24 veces más rápido en tiempo total por prueba. Esa razón no significa que genere tokens 5.24 veces más rápido, porque la longitud de las respuestas puede diferir.

7. El desafío de evaluar modelos con otros modelos

Para automatizar la revisión usamos, entre otros procedimientos, un modelo juez: granite3.3:2b. Descubrimos que un juez de IA también puede equivocarse. Por ejemplo, aprobó una función que utilizaba n % 1 == 0 para determinar si un número es par, aunque la condición correcta para enteros es n % 2 == 0. También aceptó una media de 4.2 para el conjunto de datos cuya media correcta era 4.

Esto confirmó la importancia de conservar las respuestas originales, verificar los resultados deterministas y revisar las discrepancias antes de modificar puntuaciones.

8. Auditoría final V0.8.7

Revisamos 33 casos de los cinco finalistas. Se detectaron siete discrepancias entre las puntuaciones históricas y las del juez. Tras contrastar evidencias, se aceptó una corrección y se conservaron seis puntuaciones históricas. La corrección afectó a sam860/LFM2:700m en ROB-001: de 100 a 66.67 puntos por una explicación insuficiente de la corrección de dirección del robot mediante sus motores. Su promedio global pasó de 96.67 a aproximadamente 93.33.

La auditoría no equivale a una revisión independiente exhaustiva de las 220 respuestas.

9. La decisión: dos modelos complementarios

Gemma 3 de 4 mil millones de parámetros: prioridad en calidad

Recomendamos gemma3:4b para explicaciones educativas, apoyo en programación y consultas técnicas en las que se tolere una respuesta más lenta.

LFM2 de 700 millones de parámetros: prioridad en rapidez

Recomendamos sam860/LFM2:700m para consultas breves, asistentes educativos sencillos e interacciones frecuentes. gemma2:2b permanece como alternativa de respaldo.

10. ¿Valió la pena ampliar la RAM de 8 a 32 GB?

La ampliación aportó capacidad para cargar modelos y trabajar con mayores contextos, pero todavía no podemos demostrar que toda esa memoria fuera indispensable para los modelos seleccionados. También cambiaron el almacenamiento y parte del entorno de software, de modo que no sería válido atribuir cualquier mejora solamente a la RAM. En inferencia sobre CPU importan el procesador, el ancho de banda de memoria, el tamaño del modelo y la configuración de ejecución.

11. Lo que aprendimos

Una computadora antigua puede ejecutar IA local, pero el modelo más grande no siempre es la mejor elección. La velocidad y la calidad deben medirse por separado; el tiempo total no sustituye a los tokens por segundo. Las evaluaciones automáticas necesitan verificaciones objetivas. Guardar respuestas, parámetros y resultados permite auditar sin repetir inferencias costosas. Finalmente, una inversión en hardware debe justificarse con mediciones comparables.

12. Próximo proyecto: iRoX-Bench Lite

Proponemos desarrollar iRoX-Bench Lite, una herramienta que ayude a estudiantes, docentes e instituciones a evaluar computadoras reutilizadas como servidores de IA. Queremos que en minutos u horas identifique modelos viables, memoria utilizada, velocidad, calidad aproximada y mejoras de hardware potencialmente justificadas.

El plan contempla un diagnóstico rápido de 15–30 minutos, una evaluación estándar de 60–120 minutos y pruebas ampliadas cuando sean necesarias. Son objetivos de diseño, no tiempos garantizados.

Conclusiones

Tras evaluar 22 modelos con 220 pruebas, encontramos dos opciones útiles para el servidor estudiado: gemma3:4b cuando importa la calidad y sam860/LFM2:700m cuando importa la rapidez. Más allá de estos resultados, el objetivo es crear un procedimiento sencillo que permita a otras personas evaluar equipos existentes antes de desecharlos o invertir en actualizaciones.

Antes de desechar una computadora, vale la pena investigar qué puede hacer con las herramientas actuales.

Referencias y recursos

1. Sandria, J. C. (2026). Instalación de una IA generativa con Ubuntu y Ollama. Robótica Sandria.
2. Instituto de Robótica de Xalapa (2026). Benchmark iRoX V0.8.7: resultados consolidados de 22 modelos. Documentación interna del proyecto.
3. Ollama. Documentación oficial y API.
4. ggml-org. llama.cpp.
5. EleutherAI. Language Model Evaluation Harness.
6. MLCommons. MLPerf Inference.
7. Vaswani, A., et al. (2017). Attention Is All You Need. NeurIPS 30.
8. ChatGTP. chatgpt.com.

Nota metodológica: Las puntuaciones corresponden a la evaluación operativa iRoX V0.8.7. Algunas calificaciones históricas no se han verificado exhaustivamente mediante revisión independiente. Los resultados describen el comportamiento observado en este servidor y no deben extrapolarse automáticamente a otros equipos o aplicaciones.

Por: Julio César Sandria Reynoso
Maestro en Inteligencia Artificial
6 de octubre de 2026

Guía Técnica para la configuración y puesta en marcha de un servidor de Inteligencia Artificial con Ubuntu Server, Ollama y NVIDIA en una computadora antigua.

Este documento detalla el proceso completo de configuración, instalación, optimización y prueba de un servidor de Inteligencia Artificial local desplegado sobre Ubuntu Server 24.04.5 LTS, aprovechando hardware dedicado e integración mediante API remota y scripts en Python.

1. Especificaciones del Hardware del Servidor

La computadora usada como servidor de inteligencia artificial en el Instituto de Robótica de Xalapa cuenta con el siguiente perfil técnico optimizado para cargas de trabajo locales:

Componente	Detalle Técnico	Estado / Nota de rendimiento
Procesador (CPU)	Intel(R) Pentium(R) CPU G4400 @ 3.30GHz (2 núcleos / 2 hilos, Skylake)	Sin soporte para instrucciones AVX/AVX2. Operación orientada a gestión y soporte de RAM.
Memoria RAM	32 GB DDR4 Synchronous 2667 MHz (2 módulos de 16 GB)	Excelente capacidad para almacenar modelos de lenguaje de tamaño intermedio.
Tarjeta Gráfica (GPU)	NVIDIA GeForce GTX 750 Ti (Arquitectura Maxwell, GM107, 2 GB VRAM)	Controlador propietario instalado con éxito. Soporte funcional para operaciones base de CUDA.
Almacenamiento	SSD ADATA SP580 (120 GB) + Disco mecánico adicional de 500 GB	Espacio suficiente para sistema operativo, dependencias y almacenamiento de modelos LLM.
Red	Realtek PCI Express Gigabit Ethernet	Conectividad estable para servicio local de IA y peticiones en red.

Cabe mencionar que el equipo usado fue ampliado con memoria RAM y la reinstalación de la tarjeta gráfica que tuvo años atrás y que no se usó al preparar el artículo precedente: Instalación de una IA Generativa con Ubuntu y Ollama.

2. Configuración del Entorno Gráfico y Controladores NVIDIA

Para habilitar el soporte de hardware en la tarjeta gráfica NVIDIA GTX 750 Ti, se superaron incidencias iniciales de comunicación con el kernel mediante una purga limpia e instalación del controlador estable.

Resultado Exitoso: Al ejecutar el comando nvidia-smi, el sistema reportó correctamente la versión de controlador 580.178.04 y CUDA 13.0 vinculada a la GeForce GTX 750 Ti.

# Purgar instalaciones previas conflictivas
sudo apt purge nvidia* -y
sudo apt autoremove -y

# Instalar el controlador propietario estable
sudo apt install nvidia-driver-535 -y
sudo reboot

3. Instalación y Configuración del Servicio Ollama

Ollama fue instalado y configurado como un demonio del sistema mediante systemd para garantizar su ejecución automática en segundo plano y su disponibilidad ante reinicios.

# Descarga e instalación automatizada de Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Ejecutar ollama con modelo qwen2.5:1.5b. /exit para salir
ollama run qwen2.5:1.5b
>>> Escribe una historia corta sobre un robot curioso
>>> /exit

# Creación del archivo de servicio systemd (/etc/systemd/system/ollama.service)
[Unit]
Description=Ollama Service
After=network-online.target

[Service]
ExecStart=/usr/local/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
Environment="PATH=$PATH"

[Install]
WantedBy=default.target

4. Exposición de la API en la Red Local

Para permitir que otros equipos de la red local se comuniquen con el servidor de IA, se configuró la variable de entorno OLLAMA_HOST modificando el servicio systemd:

sudo systemctl edit ollama.service

# Contenido de la anulación (override.conf):
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

# Recargar y reiniciar el servicio
sudo systemctl daemon-reload
sudo systemctl restart ollama

5. Desarrollo de Clientes y Ejemplos de Programación en Python

Se configuró un entorno de desarrollo en la computadora cliente (macOS) utilizando entornos virtuales (venv) y la librería oficial ollama para consumir el modelo qwen2.5:1.5b desplegado en el servidor.

Programa 1: Respuesta en Streaming en Tiempo Real

import ollama

client = ollama.Client(host='http://192.168.1.50:11434')

stream = client.chat(
    model='qwen2.5:1.5b',
    messages=[
        {
            'role': 'user',
            'content': 'Escribe una historia corta sobre un robot curioso.',
        },
    ],
    stream=True,
)

print('IA: ', end='', flush=True)
for chunk in stream:
    print(chunk['message']['content'], end='', flush=True)

print()

Programa 2: Uso de Prompt de Sistema (Roles)

import ollama

client = ollama.Client(host='http://192.168.1.50:11434')

stream = client.chat(
    model='qwen2.5:1.5b',
    messages=[
        {
            'role': 'system',
            'content': 'Eres un profesor experto en robótica industrial. Responde siempre de forma técnica, concisa y orientada a la enseñanza.',
        },
        {
            'role': 'user',
            'content': 'Explícame brevemente qué es la cinemática directa.',
        },
    ],
    stream=True,
)

print('IA: ', end='', flush=True)
for chunk in stream:
    print(chunk['message']['content'], end='', flush=True)

print()

Programa 3: Chat Continuo con Historial y Streaming

import ollama

client = ollama.Client(host='http://192.168.1.50:11434')

mensajes = [
    {
        'role': 'system',
        'content': 'Eres un profesor experto en robótica industrial y optimización. Responde de forma técnica y concisa.'
    }
]

print("Iniciando chat continuo con Ollama. Escribe 'salir' para terminar.\n")

while True:
    texto_usuario = input("Tú: ")
    if texto_usuario.lower() in ['salir', 'exit', 'quit']:
        break

    mensajes.append({'role': 'user', 'content': texto_usuario})

    stream = client.chat(
        model='qwen2.5:1.5b',
        messages=mensajes,
        stream=True
    )

    print("IA: ", end='', flush=True)
    respuesta_completa = ""

    for chunk in stream:
        contenido = chunk['message']['content']
        print(contenido, end='', flush=True)
        respuesta_completa += contenido

    print("\n")
    mensajes.append({'role': 'assistant', 'content': respuesta_completa})

6. Monitoreo Avanzado y Análisis Comparativo del Sistema con btop

Para garantizar la estabilidad y comprobar la correcta distribución de la carga de trabajo entre la CPU, la RAM y la tarjeta gráfica, se utilizó la herramienta btop. A continuación se detalla el comportamiento del servidor bajo dos escenarios distintos de operación.

Instalación de btop en Ubuntu Server

# Actualizar repositorios e instalar btop
sudo apt update
sudo apt install btop -y

# Ejecutar el monitor
btop

Análisis Escenario A: Servidor en Reposo o con Peticiones Ligeras

Durante la operación normal o al recibir peticiones estándar de chat, el modelo qwen2.5:1.5b permanece residente en la memoria RAM (ocupando aproximadamente 1.3 GiB de forma estable en el proceso llama-server). El uso de la CPU se mantiene bajo y la tarjeta gráfica registra un uso mínimo.

Análisis Escenario B: Servidor bajo Carga Masiva (Procesamiento de Textos Extensos)

Para comprobar la respuesta del servidor bajo una carga pesada, se ejecutó un script en el equipo cliente que envía un bloque de texto masivo para calcular la matriz de atención y el contexto (*KV Cache*).

Programa de Prueba con Bloque de Texto Extenso

import ollama

client = ollama.Client(host='http://192.168.1.50:11434')

# Creamos un bloque de texto grande para forzar el uso de memoria de contexto
bloque_texto = (
    "La robótica móvil autónoma y los sistemas de optimización combinatoria "
    "requieren algoritmos eficientes de navegación y búsqueda de rutas como A* "
    "y Dijkstra, integrando mapeo SLAM y sensores LiDAR en entornos dinámicos. "
) * 150

print("Enviando documento extenso al servidor de IA...")

stream = client.chat(
    model='qwen2.5:1.5b',
    messages=[
        {
            'role': 'system',
            'content': 'Eres un asistente técnico analítico. Resume y extrae los conceptos principales del texto proporcionado.'
        },
        {
            'role': 'user',
            'content': f'Por favor, analiza a detalle el siguiente documento:\n\n{bloque_texto}'
        }
    ],
    stream=True
)

print("IA: ", end='', flush=True)
for chunk in stream:
    print(chunk['message']['content'], end='', flush=True)

print("\n\nProceso finalizado.")

Al ejecutar este script, el comportamiento de los recursos en btop cambia drásticamente:

• Uso del CPU al 100% (C0 y C1): Los dos núcleos del Intel Pentium G4400 se saturan por completo realizando los cálculos secuenciales del modelo.
• Proceso Activo (llama-server): El consumo de CPU del proceso asciende al 99.0%, absorbiendo toda la capacidad de procesamiento disponible.
• Actividad Gráfica (GPU): El uso de la GPU se incrementa (alrededor del 38%), mientras que la ocupación de la VRAM se mantiene en 1.1 GiB / 2.0 GiB, apoyando parcialmente en el procesamiento.
• Temperatura: La temperatura de la CPU experimenta un incremento controlado (por ejemplo, a 47 °C), manteniéndose en un rango totalmente seguro.

7. Preguntas Frecuentes y Análisis de Arquitectura (Hardware y Rendimiento)

Pregunta: ¿Valió la pena ampliarle la RAM a la computadora de 8GB a 32GB si en reposo modelos ligeros como qwen2.5:1.5b apenas consumen 1.3 GB? ¿Y qué hay de la tarjeta gráfica GTX 750 Ti que se consideraba tecnología antigua?

Respuesta Técnica: Sí, ampliar la RAM a 32 GB y conservar la GTX 750 Ti fue una excelente decisión de arquitectura por los siguientes motivos:

• Escalabilidad de Modelos: Aunque un modelo de 1.5B parámetros es ligero, modelos de mayor tamaño (como 7B u 8B) requieren entre 4.5 GB y 5.5 GB solo para cargar sus pesos. Con 8 GB totales, el sistema operativo (Ubuntu Server) se quedaría sin margen y generaría errores críticos por falta de memoria o paginación en disco (*Swap*). Con 32 GB hay total holgura.
• Gestión del KV Cache y Contextos Largos: Al procesar documentos masivos, código fuente extenso o historiales de chat kilométricos, la memoria temporal para la matriz de atención (*KV Cache*) crece de manera importante, la cual es absorbida sin problemas por la RAM.
• El Rol Real de la GTX 750 Ti: Aunque sus 2 GB de VRAM limitan la capacidad de alojar modelos completos (lo que obliga a delegar el cálculo pesado a la CPU al 100%), la tarjeta gráfica no está de adorno. Funciona como un coprocesador acelerador (registrando picos de uso del 38% bajo carga) para resolver operaciones matriciales específicas, además de gestionar la salida gráfica de forma independiente sin consumir la valiosa RAM del sistema.

8. Estrategia de Acceso Multiusuario y Herramientas Cliente en Red Local

Pregunta: Ya tenemos este servidor en un entorno escolar y daremos acceso a entre 2 y 5 colaboradores máximo. ¿Qué herramientas podemos instalar en las computadoras para que accedan al servidor y utilicen la IA configurada para analizar archivos y correr comandos de forma automatizada?

Respuesta Técnica: Para un grupo reducido de 2 a 5 usuarios concurrentes conectados al servidor Ollama (http://192.168.1.50:11434), existen excelentes alternativas dependiendo del flujo de trabajo:

• Open WebUI (Interfaz tipo ChatGPT centralizada): Se despliega fácilmente mediante Docker en el servidor Ubuntu. Permite crear cuentas individuales para cada colaborador con historiales privados, soporte para carga y análisis de archivos (PDFs, documentos, código) mediante RAG, y acceso directo desde el navegador web de cada computadora (ej. http://192.168.1.50:3000) sin requerir hardware pesado local.
• AnythingLLM (Especializado en bases documentales): Excelente para indexar directorios completos de archivos institucionales o académicos y consultar información de forma privada y estructurada.
• Continue.dev (Para automatización de código y comandos): Extensión de código abierto para editores como VS Code que permite a los colaboradores modificar código, explicar scripts y generar comandos de terminal directamente desde su entorno de desarrollo, utilizando la potencia del servidor central.

9. Referencias Bibliográficas y Documentación Técnica

• Ollama Documentation & API Guides: Documentación oficial sobre la API REST y configuración de red. Disponible en: Ollama FAQ & Configuration Guide.
• Open WebUI Project Guide: Guía de despliegue mediante contenedores y gestión multiusuario. Disponible en: Open WebUI Documentation.
• Continue.dev Open-Source Assistant: Documentación técnica sobre asistentes de código y editores locales. Disponible en: Continue Docs.
• NVIDIA Driver & CUDA Documentation: Guías de controladores y plataforma de computación acelerada. Disponible en: NVIDIA CUDA Platform.

10. Conclusiones y Validación

El servidor rsa-userver24-xps se encuentra completamente operativo. La arquitectura implementada permite:

• Ejecutar modelos de lenguaje eficientes como qwen2.5:1.5b utilizando los recursos optimizados del servidor.
• Monitorear y comparar el rendimiento del hardware bajo distintas cargas mediante btop y nvidia-smi.
• Atender peticiones descentralizadas desde múltiples equipos de la red local mediante la API REST y scripts avanzados en Python con streaming, roles, historial y pruebas de rendimiento.
• Escalar el acceso a múltiples colaboradores mediante interfaces web y herramientas de asistencia técnica e integración documental.