Ollama Preguntas frecuentes
Este capítulo condensa el conocimiento de resolución de problemas en un manual de consulta rápida: comienza con la localización en los registros, clasifica por síntomas y cubre seis grandes categorías de problemas: memoria de video insuficiente, fallos de descarga, conflictos de puertos, anomalías de GPU, sobrecarga y compatibilidad tras actualizaciones.
El primer paso universal: mira primero los registros
Los mensajes de error de Ollama suelen ser muy breves; la verdadera causa casi siempre está en los registros.
| Entorno | Comando / ubicación para ver |
|---|---|
| macOS | cat ~/.ollama/logs/server.log |
| Linux（systemd） | journalctl -u ollama --no-pager --follow --pager-end |
| Windows | %LOCALAPPDATA%\Ollama\server.log |
| Docker | docker logs <nombre_del_contenedor> |
| serve manual | Los registros se imprimen directamente en la terminal actual |
Cuando los registros predeterminados no contienen detalles, activa el modo de depuración y reinicia el servicio para ver procesos clave como la detección de GPU y la estimación de memoria de video:
# 调试模式启动 OLLAMA_DEBUG=1 ollama serve
Cuando encuentres una anomalía, clasifícala primero con el siguiente mapa de navegación y luego salta a la sección correspondiente:
Memoria de video / RAM insuficiente (OOM)
Este es el problema de tiempo de ejecución más común; los síntomas típicos son que el proceso desaparece a mitad de la generación, el sistema se congela, o aparecen fallos de asignación de memoria en los registros.
| Síntoma | Causa | Solución |
|---|---|---|
| El proceso se elimina al cargar un modelo grande | Memoria física insuficiente | Cambia a una etiqueta de menor tamaño; o usa create para cuantizar y reducir el volumen |
| Se bloquea a mitad de la generación | La acumulación de contexto provoca la expansión de la caché KV | Reduce num_ctx; activa Flash Attention y la cuantización de la caché KV |
| Fallos masivos con múltiples solicitudes | NUM_PARALLEL demasiado alto, la memoria de video se ocupa de forma múltiple | Vuelve a 1, incrementa gradualmente y observa ollama ps |
| El modelo funciona pero se divide a la CPU | La memoria de video es ligeramente inferior a la demanda | Libera la ocupación de memoria de video en segundo plano; baja un nivel la especificación de parámetros |
Tres comandos de diagnóstico: ollama ps para ver la ocupación del modelo y la proporción de división, nvidia-smi (o rocm-smi) para ver la memoria de video en tiempo real de la tarjeta gráfica, y free -h para ver la memoria del sistema.
Fallo en la descarga del modelo y reanudación de descargas interrumpidas
Los problemas de descarga casi siempre están en la ruta de red; la buena noticia es que Ollama admite reanudación por capas, por lo que el costo de reintentar es muy bajo.
| Síntoma | Causa | Solución |
|---|---|---|
| La descarga se interrumpe repetidamente | La red hacia el servidor de origen es inestable | Vuelve a ejecutar el mismo comando para reanudar; configura HTTPS_PROXY si es necesario |
| Sigue fallando después de configurar el proxy | Se configuró HTTP_PROXY por error | Conserva solo HTTPS_PROXY y elimina HTTP_PROXY |
| Error de certificado del proxy | El certificado autofirmado no es de confianza | Instala el certificado CA como certificado del sistema |
| Aviso de espacio en disco insuficiente | La capacidad de la partición de destino es insuficiente | Libera espacio, o usa OLLAMA_MODELS para migrar la ruta de almacenamiento |
Conflicto de puertos y conexión rechazada
Cuando el cliente informa "conexión rechazada", en esencia significa que no hay ningún servicio respondiendo en el puerto 11434.
| Síntoma | Causa | Solución |
|---|---|---|
| La conexión curl local es rechazada | El servicio de Ollama no está iniciado | macOS / Windows: abre la aplicación; Linux: ejecuta sudo systemctl start ollama |
| Los registros indican que el puerto está ocupado | El puerto 11434 está ocupado por otro programa | Detén el proceso que ocupa el puerto, o inicia con otro puerto: OLLAMA_HOST=127.0.0.1:11435 |
| No se puede conectar desde una máquina remota | El servicio solo escucha en la dirección de bucle local | En el servidor, establece OLLAMA_HOST=0.0.0.0 y permite el paso en el firewall |
| Tras la instalación manual en Linux, se inicia y sale inmediatamente | /tmp está montado con noexec y la biblioteca de inferencia no puede cargarse | Configura OLLAMA_TMPDIR para que apunte a un directorio ejecutable |
GPU no utilizada / error de detección
El síntoma es que ollama ps muestra 100% CPU, o aparece un error de detección de GPU en los registros. Las rutas de diagnóstico para NVIDIA y AMD son diferentes.
Sección específica para NVIDIA
Primero revisa el controlador y el entorno de paso directo, y luego trata según el código de error en los registros:
| Elemento de verificación | Método |
|---|---|
| Versión del controlador | nvidia-smi debe generar una salida normal; actualiza al controlador más reciente |
| Paso directo en contenedores | Si docker run --gpus all ubuntu nvidia-smi no funciona, es un problema de Container Toolkit |
| Módulo del controlador anómalo | Vuelve a cargar con sudo rmmod nvidia_uvm && sudo modprobe nvidia_uvm y reintenta |
| Deja de funcionar después de reanudar de la suspensión | Tras despertar de la suspensión en Linux, hay que recargar el módulo nvidia_uvm |
| Docker pierde la GPU tras funcionar mucho tiempo | Añade native.cgroupdriver=cgroupfs en /etc/docker/daemon.json y reinicia Docker |
Los códigos de error de CUDA en los registros son útiles para un diagnóstico rápido: 3 indica no inicializado, 46 indica dispositivo no disponible, 100 indica que no hay dispositivo, 999 indica error desconocido; la mayoría apuntan al controlador o a la configuración de paso directo.
Sección específica para AMD
| Síntoma | Causa | Solución |
|---|---|---|
| No se detecta en absoluto en Linux | El usuario no está en el grupo video / render | Añade el usuario de ejecución al grupo correspondiente y reinicia el servicio |
| Aparece discovery timeout (tiempo de espera de detección agotado) en los registros | El controlador ROCm es demasiado antiguo (inferior a v7) | Usa amdgpu-install para actualizar a ROCm v7 y reinicia |
| Las tarjetas antiguas no son compatibles | La arquitectura no está en la lista oficial de compatibilidad | Prueba a usar HSA_OVERRIDE_GFX_VERSION para especificar una arquitectura similar |
| Algunas tarjetas antiguas en Windows no tienen ROCm | Limitación de la pila de controladores | Usa la ruta predeterminada de Vulkan; si hay anomalías, revisa GGML_VK_VISIBLE_DEVICES |
Investigación sistemática del error 503 por sobrecarga y respuesta lenta
Combina los métodos de los capítulos anteriores en un flujo fijo; en seis pasos identificarás la mayoría de los problemas de rendimiento:
Primer paso: usa ollama ps para confirmar si PROCESSOR está al 100% en GPU; si aparece división, vuelve primero a la optimización de memoria de video.
Segundo paso: revisa en los registros si hay registros de espera en cola, descargas o fallos de detección.
Tercer paso: recibir un 503 indica que la cola está llena; revisa el volumen de solicitudes concurrentes y OLLAMA_MAX_QUEUE, y evalúa si es necesario ampliar la capacidad.
Cuarto paso: en escenarios de uso compartido por múltiples usuarios, verifica la relación multiplicativa entre OLLAMA_NUM_PARALLEL y la memoria de video.
Quinto paso: verifica la política de keep_alive; descargar y recargar con frecuencia hace que la latencia hasta el primer token se dispare.
Sexto paso: usa el campo usage de la API para calcular token/s y compáralo con la línea base histórica para cuantificar el efecto de cada ajuste.
Problemas de compatibilidad tras la actualización y cómo revertir
Cuando el comportamiento es anómalo tras una actualización, tres acciones resuelven la mayoría de los casos:
# 1. Linux 手动升级前先清理旧库，避免新旧混用 sudo rm -rf /usr/lib/ollama # 2. 回退到指定版本 curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.5.7 sh # 3. AMD 显卡同步升级 ROCm v7 驱动后重启
Los caracteres corruptos en la terminal de Windows son un problema de fuente de la terminal antigua, no del modelo; basta con cambiar a Windows Terminal.
Otras extensiones