Ollama on KnightLi Blog

Guía de despliegue local de Claude Code + Ollama: crear un asistente de programación AI gratuito con CC Switch

Fri, 15 May 2026 23:27:50 +0800

Claude Code se ha vuelto un asistente de programación AI muy popular. Su atractivo no está solo en conversar sobre código, sino en leer un proyecto, modificar archivos, ejecutar comandos, instalar dependencias y seguir corrigiendo errores como un Agent operativo.

El problema es el coste. Cuando el proyecto crece, el contexto se alarga y varias rondas de trabajo tipo Agent pueden consumir cuota de API muy rápido. Si solo quieres experimentar, modificar herramientas pequeñas, escribir scripts o trabajar con proyectos privados locales, surge una pregunta natural: ¿se puede mantener la experiencia de Claude Code, pero ejecutar el modelo en local?

La herramienta clave de esta configuración es CC Switch. Permite que Claude Code se conecte al servicio local de Ollama mediante una API compatible con OpenAI, de modo que las solicitudes se reenvían al modelo local en lugar de ir directamente a la API oficial de Claude.

Qué Problema Resuelve Esta Configuración

Puedes entender el flujo completo así:

1
2
3

Claude Code desktop
+ CC Switch API forwarding layer
+ Ollama local model

Claude Code sigue encargándose del flujo de programación y de las operaciones sobre el proyecto. CC Switch gestiona la configuración del proveedor de modelos y la compatibilidad de API. Ollama ejecuta el modelo en la máquina local.

Esto no significa que un modelo local se convierta de pronto en Claude. Su valor real está en poder usar el flujo tipo Agent de Claude Code en escenarios locales, privados, sin conexión o de menor coste.

Preparación Básica

Antes de empezar, prepara estos componentes:

Instala Git.
Instala Ollama.
Descarga un modelo local adecuado para programación.
Instala CC Switch.
Ten Claude Code disponible en tu máquina.

Para el modelo, puedes empezar con opciones orientadas a código, como Qwen Coder, DeepSeek Coder u otros modelos con buen comportamiento en generación de código y llamadas a herramientas. Cuanto más grande sea el modelo, mejores pueden ser los resultados, pero también aumentará la presión sobre la memoria y la GPU.

Si tu equipo tiene memoria limitada, empieza con un modelo más pequeño. Primero confirma que el flujo funciona bien y luego prueba modelos más grandes.

Configuración Clave De CC Switch

Después de iniciar Ollama, su dirección local de API suele ser:

`1`	`http://127.0.0.1:11434/v1`

En CC Switch, elige un tipo de proveedor compatible con OpenAI. Una opción habitual es:

`1`	`OpenAI Chat Completions`

Después apunta el base URL a la dirección local de Ollama.

Para el campo de API key, Ollama local normalmente no necesita una clave real, pero muchas herramientas siguen exigiendo una variable de entorno o un valor de relleno. Puedes usar:

`1`	`ANTHROPIC_API_KEY`

o cualquier otra variable de relleno aceptada por tu configuración local.

Hay un punto de configuración que merece especial atención:

`1`	`"inferenceModels"="[\"haiku\",\"sonnet\",\"opus\"]"`

Esto mapea los roles de modelo que Claude Code espera hacia el proveedor local. En la práctica, debes vincular haiku, sonnet y opus con los nombres de modelo expuestos por Ollama o CC Switch. Si este mapeo es incorrecto, Claude Code puede fallar al llamar al modelo o volver a una configuración inesperada.

Dónde Destaca Claude Code

La mayor ventaja de Claude Code no es una finalización aislada, sino el flujo completo de desarrollo:

leer y entender la estructura del proyecto;
localizar archivos relacionados con una tarea;
editar código directamente;
ejecutar comandos y pruebas;
observar errores e iterar;
completar tareas de varios pasos en una sola sesión.

Por eso muchas personas quieren conservar Claude Code aunque cambien a un modelo local. Una interfaz de chat normal puede generar fragmentos de código, pero no trabaja de forma natural dentro de un repositorio. Claude Code se parece más a un asistente de desarrollo capaz de actuar.

Qué Papel Cumple Ollama

Ollama se encarga de ejecutar y gestionar los modelos locales. Gestiona la descarga, la carga y la inferencia local.

La ventaja es clara: las solicitudes permanecen en tu máquina, el uso repetido no genera facturas de API y también puedes trabajar cuando la red está limitada. Para código privado, también resulta más aceptable que enviar cada ventana de contexto a un modelo en la nube.

La contrapartida también es clara. Los modelos locales dependen mucho del hardware y de la calidad del modelo. Un modelo pequeño puede manejar ediciones simples, explicaciones y generación de scripts, pero puede sufrir con refactorizaciones grandes entre varios archivos o decisiones de arquitectura delicadas.

Dónde Están Los Límites De La Experiencia

Esta configuración no debe verse como un reemplazo completo de los modelos cloud más potentes de Claude.

Puedes encontrarte con estos problemas:

comprensión más débil de contextos largos;
llamadas a herramientas inestables en tareas complejas;
inferencia lenta en máquinas solo con CPU;
más alucinaciones de rutas de archivo o APIs inexistentes;
planificación menos fiable en varias rondas;
menor tasa de éxito en refactorizaciones de repositorios grandes.

La expectativa más razonable es usarlo como un asistente de desarrollo local gratuito, no como un sustituto perfecto de un modelo cloud de primera línea.

La Compatibilidad Multimodal Sigue Siendo Inestable

Algunos usuarios quieren que Claude Code maneje capturas de pantalla, imágenes de UI, diagramas u otras entradas multimodales. Esta parte depende del modelo local y de la capa de reenvío.

Si el modelo de Ollama seleccionado no admite visión, o si CC Switch no traduce correctamente el formato de solicitud, las funciones multimodales pueden fallar. Incluso con un modelo de visión, el comportamiento puede diferir de la API oficial de Claude.

Por ahora, esta configuración es más adecuada para flujos de texto y código. Conviene tratar el soporte multimodal como algo experimental.

Para Quién Tiene Sentido Probarlo

Esta configuración es adecuada para:

desarrolladores que quieren probar el flujo de Claude Code a bajo coste;
usuarios que escriben scripts, herramientas pequeñas y automatizaciones con frecuencia;
equipos que prefieren mantener el código en máquinas locales;
principiantes que quieren un asistente de programación AI sin gasto continuo de API;
personas que evalúan distintos modelos locales para código.

Es menos adecuada si dependes mucho de contexto largo, monorepos grandes, calidad estricta de revisión de código o refactorizaciones complejas de proyectos completos.

Recomendaciones De Uso

Empieza con tareas pequeñas.

Por ejemplo:

explicar un solo archivo;
refactorizar una función pequeña;
generar un script de shell;
corregir un error simple;
añadir una función pequeña;
escribir pruebas unitarias para un módulo acotado.

Después de cada cambio, ejecuta pruebas o al menos revisa el diff. Un modelo local puede ser útil, pero no conviene aceptar a ciegas todas sus ediciones.

Si el modelo pierde el contexto con frecuencia, reduce el alcance de la tarea. En lugar de pedirle “refactoriza todo el proyecto”, pídele “refactoriza esta función” o “añade validación en este archivo”.

Resumen

Claude Code + CC Switch + Ollama es una combinación interesante. Mantiene el flujo de desarrollo tipo Agent de Claude Code y mueve la inferencia a un modelo local.

Sus mayores ventajas son el menor coste, la privacidad local y un flujo de desarrollo cómodo. Sus límites también son evidentes: la calidad del modelo, el rendimiento del hardware, el contexto largo y la estabilidad de las llamadas a herramientas afectan directamente la experiencia final.

Si ya usas Ollama y quieres un flujo de programación AI local más práctico, vale la pena probar esta configuración. Solo recuerda empezar con tareas pequeñas, verificar cada cambio y tratar el modelo local como un asistente, no como un ingeniero automático.

Modelos LLM locales recomendados para una GPU RTX 3060

Fri, 08 May 2026 09:25:24 +0800

La versión más común de la RTX 3060 tiene 12GB de VRAM. No es una GPU de IA de gama alta, pero funciona muy bien para LLM locales, especialmente modelos de 7B, 8B, 9B y 12B.

Si solo quieres una regla rápida:

En una RTX 3060 12GB, prioriza modelos de alrededor de 8B en cuantización Q4_K_M o Q5_K_M. Elige Q4 para más estabilidad y prueba Q5 si quieres mejor calidad.

No empieces persiguiendo modelos de 32B o 70B. Aunque puedan ejecutarse con cuantización muy baja y CPU offload, la velocidad y la experiencia normalmente no son adecuadas para uso diario.

Primero mira el límite de VRAM

Al ejecutar LLM locales en una RTX 3060 12GB, el límite real es la VRAM.

Tamaño del modelo	Cuantización recomendada	Experiencia en RTX 3060 12GB
3B / 4B	Q4, Q5, Q8	Muy fácil, rápido
7B / 8B / 9B	Q4_K_M, Q5_K_M	Lo más recomendado; buen equilibrio
12B / 14B	Q4_K_M	Se puede probar, cuidado con contexto grande
30B+	Q2 / Q3 o offload parcial	Se puede experimentar, no diario
70B+	Cuantización extrema o mucha CPU/RAM	Más bien experimental

Un LLM local no solo consume VRAM por el archivo del modelo. También consumen contexto, KV cache, batch size, framework de inferencia y drivers.

Por eso 12GB de VRAM no significa cargar sin más un archivo de modelo de 12GB. Es mejor dejar margen para el sistema y el contexto.

Recomendación 1: Qwen3 8B

Si usas principalmente chino, Qwen3 8B es uno de los primeros modelos que vale la pena probar en una RTX 3060.

Sirve para:

Preguntas y respuestas en chino.
Resumen y reescritura.
Asistente diario de conocimiento.
Explicación simple de código.
RAG local.
Flujos Agent ligeros.

Elección recomendada:

1
2
3

Qwen3 8B GGUF
Q4_K_M: primera opción
Q5_K_M: mejor calidad, más presión de VRAM

La familia Qwen suele funcionar bien con chino. Para escritura diaria, organización de información y comprensión de instrucciones en chino, Qwen3 8B es un buen punto de partida.

Recomendación 2: Llama 3.1 8B Instruct

Llama 3.1 8B Instruct es un modelo general estable, con buena capacidad en inglés y ecosistema maduro.

Sirve para:

Preguntas en inglés.
Ayuda ligera con código.
Chat general.
Resumen de documentos.
Pruebas de prompts.
Comparar herramientas de inferencia.

Elección recomendada:

1
2
3

Llama 3.1 8B Instruct GGUF
Q4_K_M: mejor velocidad y estabilidad de VRAM
Q5_K_M: mejor calidad de respuesta

Si procesas sobre todo material en inglés, o quieres un modelo con muchos tutoriales y buena compatibilidad, Llama 3.1 8B sigue siendo una buena base.

Recomendación 3: Gemma 3 12B

Gemma 3 12B está más cerca del límite práctico de una RTX 3060 12GB.

Consume más VRAM que los modelos 8B, pero con cuantización Q4 todavía puede funcionar en una tarjeta de 12GB. Es una opción para quien quiera probar un modelo algo mayor en una sola GPU.

Sirve para:

Preguntas generales de mayor calidad.
Procesamiento de contenido en inglés.
Resúmenes y análisis algo más complejos.
Probar una mejora sobre modelos 8B.

Elección recomendada:

1
2
3

Gemma 3 12B GGUF
Q4_K_M u oficial QAT Q4
No abras demasiado el contexto

Si falta VRAM, reduce primero la longitud de contexto o vuelve a un modelo 8B. Para una 3060, 12B es “probable”, no una recomendación automática.

Recomendación 4: DeepSeek R1 Distill Qwen 8B

Si quieres probar modelos locales con estilo de razonamiento, puedes usar modelos como DeepSeek R1 Distill Qwen 8B.

Sirve para:

Problemas simples de razonamiento.
Análisis por pasos.
Aprender el estilo de salida de modelos de razonamiento.
Experimentos locales de bajo costo.

Elección recomendada:

1
2

DeepSeek R1 Distill Qwen 8B GGUF
Q4_K_M

Estos modelos a veces generan procesos de razonamiento más largos, así que la velocidad y el uso de contexto pueden sentirse más pesados que en modelos instruct normales. Para chat diario no siempre son más cómodos que Qwen3 8B, pero sirven bien para experimentar.

Recomendación 5: Phi / MiniCPM / modelos pequeños

Si tu 3060 es de 8GB, o tu RAM también es limitada, considera primero modelos de 3B o 4B.

Sirven para:

Preguntas rápidas.
Resúmenes simples.
Integración en pequeñas herramientas locales.
Chat de baja latencia.
Pruebas en equipos antiguos.

No siempre igualan la calidad de 8B o 12B, pero son ligeros, rápidos y fáciles de desplegar.

Cómo elegir cuantización

El formato local común es GGUF, con cuantizaciones como Q4, Q5, Q6 y Q8.

Cuantización	Características	Mejor para
Q4_K_M	Pequeña, rápida, calidad suficiente	Primera opción en 3060
Q5_K_M	Mejor calidad, más consumo	Probar con modelos 8B
Q6 / Q8	Más cerca de calidad original, más grande	Modelos pequeños o más VRAM
Q2 / Q3	Ahorra VRAM, baja calidad notable	Experimentar con modelos grandes

Para RTX 3060 12GB, lo más práctico es:

1
2
3

Modelos 8B: Q4_K_M o Q5_K_M
Modelos 12B: primero Q4_K_M
Modelos mayores: no recomendados como uso diario

Qué herramienta usar

Los principiantes pueden empezar con Ollama, porque instalar y ejecutar modelos es sencillo.

Comandos comunes:

1
2

ollama run qwen3:8b
ollama run llama3.1:8b

Si quieres controlar mejor archivos GGUF, GPU layers y longitud de contexto, usa llama.cpp o herramientas gráficas basadas en llama.cpp.

Opciones comunes:

Ollama: lo más simple, ideal para empezar.
LM Studio: interfaz gráfica amigable, útil para descargar y cambiar modelos.
llama.cpp: control más fino, bueno para ajustar rendimiento.
text-generation-webui: muchas funciones, útil para probar backends.

Para chat local y preguntas simples, Ollama o LM Studio bastan.

No abras demasiado el contexto

Muchos modelos anuncian soporte de contexto largo, pero en una RTX 3060 no conviene usar siempre el máximo.

Cuanto más largo el contexto, más KV cache se usa y mayor presión de VRAM. Incluso si el modelo carga, un contexto largo puede reducir la velocidad.

Sugerencia:

1
2
3

Chat normal: 4K a 8K
Resumen de documentos: 8K a 16K
RAG de documentos largos: divide primero; no pegues todo de una vez

La 3060 funciona mejor con “contexto medio + buen modelo + buena recuperación” que intentando meter cientos de miles de tokens.

Elegir según uso

Si escribes principalmente en chino:

1
2

Primero: Qwen3 8B Q4_K_M
Alternativa: DeepSeek R1 Distill Qwen 8B

Si escribes principalmente en inglés:

1
2

Primero: Llama 3.1 8B Instruct Q4_K_M
Alternativa: Gemma 3 12B Q4_K_M

Si quieres velocidad:

1
2
3

Modelos 3B / 4B
8B Q4_K_M
Contexto entre 4K y 8K

Si quieres más calidad:

1
2
3

8B Q5_K_M
12B Q4_K_M
Acepta menor velocidad

Si quieres ayuda con código:

1
2

Modelos de código 8B sirven para explicar y pequeños cambios
Para ingeniería compleja, usa modelos cloud más fuertes

Los modelos locales en 3060 son útiles para explicar código, completar funciones, generar scripts pequeños y ayudar sin conexión. Para grandes refactors, bugs complejos y tareas Agent entre archivos, no esperes rendimiento al nivel de Claude Sonnet o GPT-5.

Expectativas razonables

La RTX 3060 12GB puede convertir los LLM locales de “juguete” en herramienta diaria, pero no replica modelos cloud de primera línea en casa.

Ventajas:

Bajo costo.
Más VRAM que tarjetas de 8GB.
Buena experiencia con modelos 8B.
Uso offline.
Procesamiento local de datos sensibles.

Límites:

Modelos grandes no van fluidos.
Contexto largo consume VRAM.
Menor velocidad que tarjetas de gama alta.
Modelos locales pequeños tienen razonamiento complejo limitado.
Multimodalidad y flujos Agent consumen más recursos.

La ruta estable es: usar 8B como asistente local diario, probar 12B para mejor calidad y dejar tareas complejas a modelos cloud.

Resumen

Modelos locales recomendados para RTX 3060 12GB:

Chino general: Qwen3 8B Q4_K_M
Inglés general: Llama 3.1 8B Instruct Q4_K_M
Prueba de más calidad: Gemma 3 12B Q4_K_M
Experimento de razonamiento: DeepSeek R1 Distill Qwen 8B Q4_K_M
Experiencia rápida con poca VRAM: modelos pequeños 3B / 4B

Elige primero Q4_K_M; en modelos 8B puedes probar Q5_K_M. Empieza con Ollama o LM Studio.

No trates la 3060 como un servidor de grandes modelos. Úsala como asistente local de conocimiento, procesador privado de documentos, ayuda ligera de código y tarjeta de experimentación, y encajará mejor con sus capacidades reales.

Referencias

Qwen3 8B GGUF: https://huggingface.co/Qwen/Qwen3-8B-GGUF
Llama 3.1 8B GGUF: https://huggingface.co/macandchiz/Llama-3.1-8B-Instruct-GGUF
Gemma 3 12B GGUF: https://huggingface.co/unsloth/gemma-3-12b-it-GGUF
llama.cpp: https://github.com/ggml-org/llama.cpp
Ollama: https://ollama.com

C贸mo solucionar que Ollama use CPU en lugar de GPU

Fri, 24 Apr 2026 18:30:00 +0800

Al ejecutar LLMs locales, uno de los problemas más frustrantes es este: tu máquina claramente tiene una GPU, sin embargo, Ollama sigue apoyándose en gran medida en la CPU, y el rendimiento es dolorosamente lento.

La versión corta es que esto generalmente no se debe a un único problema. Las causas más comunes son:

Ollama no está detectando ninguna GPU utilizable
El driver, el entorno ROCm o CUDA no están configurados correctamente
El servicio Ollama se inició sin las variables de entorno adecuadas
El modelo es demasiado grande y ha recurrido a la CPU o tiene una carga mixta de CPU/GPU
En plataformas AMD, puede haber problemas de compatibilidad adicionales, como una incompatibilidad de versión de ROCm, ajustes gfx, o problemas de visibilidad del dispositivo

La forma más rápida de solucionar el problema es seguir las comprobaciones a continuación en orden.

false

1. Primero, confirma si Ollama realmente no está usando la GPU

La comprobación más directa es:

`1`	`ollama ps`

Concéntrate en la columna PROCESSOR.

100% GPU: el modelo se está ejecutando completamente en la GPU
100% CPU: la GPU no se está usando en absoluto
Resultados como 48%/52% CPU/GPU: parte del modelo está en VRAM, y parte se ha volcado a la memoria del sistema

Si ves 100% CPU, el siguiente paso es centrarse en la configuración del entorno y del servicio. Si ves una carga mixta, eso no significa necesariamente que la GPU esté rota. En muchos casos, simplemente significa que la VRAM no es suficiente.

false

2. Descartar primero el malentendido más común: el modelo no cabe en VRAM

Mucha gente asume que una vez que se instala una GPU, Ollama siempre funcionará completamente en ella. Eso no es así.

Si el modelo es demasiado grande, el contexto es demasiado largo, o algún otro modelo cargado ya está ocupando VRAM, Ollama puede recurrir a:

GPU parcial + CPU parcial
100% CPU completo

En este punto, las dos pruebas más sencillas son:

Intentar un modelo más pequeño primero Por ejemplo, pruébalo con un modelo 4B o 7B antes de saltar directamente a modelos mucho más grandes.
Descargar otros modelos activos y probar de nuevo Ejecuta ollama ps primero y asegúrate de que nada más esté ocupando VRAM.

Si los modelos más pequeños usan la GPU, pero los más grandes no, el problema real suele ser la capacidad de VRAM, y no el driver.

false

3. Comprobar si el driver de la GPU y el runtime de bajo nivel están funcionando realmente

Si incluso modelos pequeños se ejecutan solo en CPU, el siguiente paso es revisar el entorno subyacente.

NVIDIA

Primero, confirma que el driver está funcionando y que el sistema puede ver la GPU. Una comprobación común es:

`1`	`nvidia-smi`

Si esto ya falla, es muy poco probable que Ollama use la GPU correctamente.

AMD / ROCm

Si estás usando una AMD GPU, especialmente con ROCm, empieza con:

1
2

rocminfo
rocm-smi

Si estas herramientas no pueden listar el dispositivo correctamente, el problema sigue estando por debajo de Ollama, por lo que no tiene sentido depurar la capa de la aplicación todavía.

En AMD, el problema más común no es simplemente ¿está instalado el driver?, sino más bien:

La versión de ROCm no coincide con la versión del OS
La arquitectura actual de la GPU tiene soporte incompleto
El dispositivo existe, pero el runtime no se está exponiendo correctamente a Ollama

false

4. Reinicia el servicio de Ollama, no solo tu terminal

Esta es una trampa muy común.

Muchas personas instalan drivers, cambian variables de entorno, arreglan ROCm, y luego simplemente abren una nueva terminal y continúan con ollama run. Pero si Ollama se está ejecutando como un servicio en segundo plano, aún puede estar usando el entorno antiguo.

Por lo tanto, el enfoque más seguro es:

Reiniciar completamente el servicio Ollama
Reiniciar la máquina si es necesario

Si lo estás ejecutando como un servicio en Linux, asegúrate de que el proceso del servicio fue realmente reiniciado en lugar de reutilizar el antiguo.

false

5. Comprobar si las variables de entorno están llegando realmente al servicio

Esto es especialmente importante en sistemas AMD ROCm.

Algunas máquinas funcionan bien cuando se ejecutan comandos manualmente en un shell, pero el servicio Ollama sigue usando solo CPU. En ese caso, la razón habitual es que el proceso del servicio nunca recibió las variables que estableciste en tu shell.

Las variables comunes a revisar incluyen:

1
2

ROCR_VISIBLE_DEVICES
HSA_OVERRIDE_GFX_VERSION

Específicamente:

ROCR_VISIBLE_DEVICES limita o selecciona qué GPUs puede ver ROCm
HSA_OVERRIDE_GFX_VERSION se usa a menudo como solución de compatibilidad en algunas plataformas AMD

Si solo exportas estas variables en la terminal actual, pero Ollama es iniciado por systemd, un servicio de fondo de escritorio u otro demonio, es posible que no surtan efecto.

En otras palabras, que “parece estar establecido en mi terminal” no significa que Ollama lo esté usando realmente.

false

6. En plataformas AMD, céntrate en la compatibilidad de ROCm

Según los metadatos de la página pública, el video original sobre este tema está vinculado a AMD Max+ 395, strix halo, y AMD ROCm. En configuraciones como estas, que Ollama no logre usar la GPU a menudo depende más de la coincidencia de versiones que de los sistemas NVIDIA.

Empieza revisando lo siguiente:

Si la versión instalada de ROCm es compatible con el OS y la GPU actuales
Si la GPU pertenece a una arquitectura con soporte sólido de ROCm
Si necesitas establecer HSA_OVERRIDE_GFX_VERSION
Si una versión anterior de Ollama o un runtime de inferencia antiguo está causando problemas de compatibilidad

Si rocminfo funciona y la GPU es visible para el sistema, pero Ollama sigue ejecutándose solo en CPU, el problema a menudo radica en la combinación de versiones en lugar de en los parámetros del modelo.

false

7. En Docker, WSL o entornos remotos, comprueba también el mapeo de dispositivos

Si no estás ejecutando en hardware físico (bare metal) sino dentro de:

Docker
WSL
Contenedores remotos (Remote containers)
Entornos virtualizados

entonces necesitas comprobar una capa más: si el dispositivo GPU realmente se está exponiendo dentro de ese entorno.

Un síntoma típico se ve así:

La máquina anfitriona (host machine) puede ver la GPU
Ollama dentro del contenedor o subsistema sigue usando solo CPU

En ese caso, el problema puede no ser Ollama en sí. El contenedor o subsistema simplemente puede no tener acceso a la GPU.

false

8. Revisar los registros al final, pero revisarlos por la razón correcta

Si ya has pasado por los pasos anteriores, el siguiente movimiento más efectivo no es reinstalar sin parar, sino mirar directamente los registros de inicio y tiempo de ejecución de Ollama.

Concéntrate en dos tipos de mensajes:

Si se detectó una GPU
Si hay errores de controlador, carga de bibliotecas o inicialización de dispositivos

Si los registros dicen claramente algo como “no compatible GPU found” o “failed to initialize ROCm/CUDA”, la dirección de la solución de problemas se vuelve mucho más clara de inmediato.

false

Orden de Solución de Problemas

Si solo quieres el camino más corto, usa este orden:

Ejecuta ollama ps y confirma si está usando GPU, CPU o carga mixta.
Intenta con un modelo más pequeño para descartar límites de VRAM.
Utiliza nvidia-smi, rocminfo y rocm-smi para verificar primero el entorno de bajo nivel.
Reinicia completamente el servicio Ollama.
Revisa las variables de entorno del servicio, especialmente ROCR_VISIBLE_DEVICES y HSA_OVERRIDE_GFX_VERSION en AMD.
Si estás en Docker o WSL, verifica el mapeo de dispositivos.
Finalmente, inspecciona los logs para encontrar el error exacto.

false

Conclusión

Cuando Ollama utiliza CPU en lugar de GPU, la causa raíz generalmente cae en uno de tres grupos:

La GPU no está siendo detectada en absoluto
La GPU es detectable, pero el entorno de ejecución no está alcanzando a Ollama
La GPU está funcionando, pero el modelo es demasiado grande y retrocede a CPU o memoria mixta

Una vez que se separan esos tres casos, la solución de problemas se vuelve mucho más rápida. Si estás en una plataforma AMD, presta especial atención a la coincidencia de versiones de ROCm, la visibilidad del dispositivo y las variables de compatibilidad, en lugar de centrarte solo en el comando Ollama en sí.

Original video: https://www.bilibili.com/video/BV1cHoYBqE8k/ false

Notas de Ollama Multi-GPU: agrupación de VRAM, selección de GPU y malentendidos comunes

Sun, 19 Apr 2026 00:18:00 +0800

Al ejecutar la inferencia local con Ollama, surgen rápidamente algunas preguntas: si ya tengo una GPU y mi placa base todavía tiene ranuras PCIe vacías, ¿ayuda agregar más GPU? ¿Es necesario que las GPU sean idénticas? ¿Se puede combinar VRAM? ¿Acelerará la inferencia como un marco de entrenamiento de múltiples GPU?

Esta nota resume cómo se comporta Ollama con múltiples GPU. La versión corta:

Ollama admite múltiples GPU.
El valor principal de varias GPU generalmente es adaptar modelos más grandes a la VRAM disponible, sin obtener un escalado lineal de tokens.
De forma predeterminada, si un modelo cabe completamente en una GPU, Ollama tiende a cargarlo en una sola GPU.
Si un modelo no cabe en una GPU, Ollama puede distribuirlo entre las GPU disponibles.
Ollama puede ver modelos de GPU mixtos, pero el rendimiento y la ubicación pueden no ser los ideales.
SLI/NVLink no es necesario para el uso de múltiples GPU.
Para limitar qué GPU puede usar Ollama, use CUDA_VISIBLE_DEVICES, ROCR_VISIBLE_DEVICES o GGML_VK_VISIBLE_DEVICES.

Comportamiento oficial: GPU única primero, GPU múltiple cuando sea necesario

Las preguntas frecuentes de Ollama describen directamente la lógica de carga de múltiples GPU: al cargar un nuevo modelo, Ollama estima la VRAM requerida y la compara con la memoria de GPU disponible actualmente. Si el modelo cabe completamente en una GPU, carga el modelo en esa GPU. Si no cabe en una sola GPU, el modelo se distribuye entre todas las GPU disponibles.

La razón es el rendimiento. Mantener un modelo en una GPU generalmente reduce las transferencias de datos a través del bus PCIe durante la inferencia, por lo que suele ser más rápido.

Así que no pienses en Ollama multi-GPU como si “más tarjetas significan automáticamente varias veces más rápido”. Un modelo más preciso es:

El modelo pequeño cabe en una GPU: normalmente funciona con una GPU.
El modelo grande no cabe en una GPU: se divide en varias GPU.
Todavía no hay suficiente VRAM: parte del modelo vuelve a la memoria del sistema y la velocidad cae notablemente.

Utilice este comando para ver dónde está cargado el modelo:

`1`	`ollama ps`

La columna “PROCESADOR” puede mostrar algo como:

1
2
3

100% GPU
48%/52% CPU/GPU
100% CPU

Si ve “48%/52% CPU/GPU”, parte del modelo ya está en la memoria del sistema. En ese caso, agregar más memoria GPU o usar una GPU con VRAM más grande suele ser más útil que seguir dependiendo de la CPU/RAM.

Multi-GPU no es un simple apilamiento informático

La inferencia LLM local no es lo mismo que SLI en los juegos. Con Ollama en múltiples GPU, el patrón común es que se colocan diferentes capas o tensores en diferentes dispositivos. Esto puede hacer que un modelo más grande encaje en la VRAM disponible combinada, pero es posible que aún sea necesario que los datos se muevan entre dispositivos durante la inferencia.

Por lo tanto, los beneficios de múltiples GPU generalmente se dividen en dos categorías:

Beneficio de VRAM: los modelos más grandes encajan más fácilmente, o menos parte del modelo recurre a CPU/RAM.
Beneficio de rendimiento: generalmente es más obvio cuando un modelo no cabría en una GPU o se extendería en gran medida a la CPU.

Si un modelo 8B o 14B ya cabe por completo en un solo RTX 3090, forzarlo en dos GPU puede no ser más rápido. Incluso puede ralentizarse debido a la sobrecarga de transferencia entre GPU. La estrategia predeterminada de Ollama de “usar una GPU cuando sea necesario” evita ese costo innecesario de PCIe.

No se requiere SLI o NVLink

Ollama multi-GPU no depende de SLI. Se pueden programar varias GPU PCIe normales siempre que el controlador y Ollama puedan detectarlas. NVLink o un ancho de banda PCIe superior puede ayudar en algunos escenarios entre GPU, pero no es un requisito. Muchos servidores y estaciones de trabajo GPU usados pueden ejecutar varias GPU a través de PCIe normal.

A lo que debes prestar atención es al ancho de banda PCIe. La diferencia entre x1, x4, x8 y x16 afecta la rapidez con la que se carga un modelo en VRAM. Si cambia con frecuencia de modelo grande, el ancho de banda PCIe se vuelve más importante. Después de cargar un modelo, PCIe generalmente importa menos durante la generación, pero la división entre GPU aún puede agregar gastos generales.

Reglas más seguras:

Prefiere las bandas x16/x8 a las bandas x1 estilo minería.
El ancho de banda PCIe es más importante cuando se cambian modelos grandes con frecuencia.
Si un modelo permanece residente en VRAM durante mucho tiempo, el ancho de banda PCIe es menos visible.
Para máquinas con múltiples GPU, verifique la topología PCIe de la placa base y los carriles conectados a la CPU.

Limite las GPU NVIDIA que utiliza Ollama

En sistemas NVIDIA con múltiples GPU, use CUDA_VISIBLE_DEVICES para controlar qué GPU puede ver Ollama.

Ejecución temporal:

`1`	`CUDA_VISIBLE_DEVICES=0,1 ollama serve`

Utilice sólo la segunda GPU:

`1`	`CUDA_VISIBLE_DEVICES=1 ollama serve`

Obligar a Ollama a no utilizar GPU NVIDIA:

`1`	`CUDA_VISIBLE_DEVICES=-1 ollama serve`

Los documentos oficiales señalan que los ID numéricos pueden cambiar de orden, por lo que los UUID de GPU son más confiables. Primero verifique los UUID:

`1`	`nvidia-smi -L`

Salida de ejemplo:

1
2

GPU 0: NVIDIA GeForce RTX 3090 (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
GPU 1: NVIDIA GeForce RTX 3070 (UUID: GPU-yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy)

Luego especifique el UUID:

`1`	`CUDA_VISIBLE_DEVICES=GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ollama serve`

Si Ollama está instalado como un servicio systemd de Linux, coloque la variable en el entorno del servicio:

`1`	`sudo systemctl edit ollama.service`

Agregar:

1
2

[Service]
Environment="CUDA_VISIBLE_DEVICES=0,1"

Recargar y reiniciar:

1
2

sudo systemctl daemon-reload
sudo systemctl restart ollama

Selección de dispositivos AMD y Vulkan

Para AMD ROCm, use ROCR_VISIBLE_DEVICES para controlar las GPU visibles:

`1`	`ROCR_VISIBLE_DEVICES=0,1 ollama serve`

Para obligar a Ollama a no usar GPU ROCm, use una identificación no válida:

`1`	`ROCR_VISIBLE_DEVICES=-1 ollama serve`

Los documentos de GPU de Ollama también mencionan el soporte experimental de Vulkan. Para GPU Vulkan, use GGML_VK_VISIBLE_DEVICES:

`1`	`OLLAMA_VULKAN=1 GGML_VK_VISIBLE_DEVICES=0 ollama serve`

Si los dispositivos Vulkan causan problemas, desactívelos:

`1`	`GGML_VK_VISIBLE_DEVICES=-1 ollama serve`

Es más probable que las configuraciones de múltiples GPU de AMD tengan problemas de compatibilidad con el controlador, la versión ROCm y la versión GFX. Los documentos oficiales también mencionan los requisitos del controlador ROCm de Linux y las anulaciones de compatibilidad, como HSA_OVERRIDE_GFX_VERSION. Si combina diferentes generaciones de GPU AMD, primero verifique que cada tarjeta funcione por sí sola antes de probar con varias GPU.

Exponer varias GPU en Docker

Si ejecuta Ollama en Docker, las configuraciones de NVIDIA generalmente requieren nvidia-container-toolkit y luego --gpus para exponer los dispositivos.

Exponga todas las GPU:

docker run -d \
  --gpus=all \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

Exponer GPU específicas:

docker run -d \
  --gpus '"device=0,1"' \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

También puedes combinar esto con variables de entorno:

docker run -d \
  --gpus=all \
  -e CUDA_VISIBLE_DEVICES=0,1 \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

Si nvidia-smi no puede ver las GPU dentro del contenedor, Ollama tampoco puede usarlas. Primero solucione los problemas de transferencia de GPU de Docker y luego Ollama.

¿Qué es `OLLAMA_SCHED_SPREAD`?

En algunas discusiones sobre configuración de múltiples GPU, es posible que vea OLLAMA_SCHED_SPREAD=1 o OLLAMA_SCHED_SPREAD=true. Está relacionado con el programador de Ollama y se usa a menudo cuando las personas desean que los modelos o solicitudes se distribuyan más ampliamente entre las GPU.

Ejemplo:

`1`	`OLLAMA_SCHED_SPREAD=1 ollama serve`

O con systemd:

1
2

[Service]
Environment="OLLAMA_SCHED_SPREAD=true"

Pero no es un cambio mágico. Habilitarlo no implica un escalado lineal de tokens y aún puede ejecutarse en OOM cuando se cargan varios modelos, las estimaciones de VRAM son ajustadas, la longitud del contexto aumenta o la caché KV se expande. El comportamiento principal de las preguntas frecuentes todavía se aplica: si una GPU puede contener completamente el modelo, una GPU suele ser más eficiente; Si una GPU no puede contenerlo, entonces resulta útil la división entre varias GPU. Trate OLLAMA_SCHED_SPREAD como un experimento de programación avanzada, no como una configuración multi-GPU requerida. Primero, comprenda el comportamiento predeterminado y luego ajústelo según ollama ps, registros y nvidia-smi.

Cómo comprobar si se están utilizando varias GPU

Comandos útiles:

`1`	`ollama ps`

`1`	`watch -n 0.5 nvidia-smi`

Ver los registros del servicio de Ollama:

`1`	`journalctl -u ollama -f`

Si usa Docker:

`1`	`docker logs -f ollama`

Esté atento a:

Si Ollama descubre GPU compatibles.
Si el modelo muestra “100% GPU” o una división CPU/GPU.
Si cada GPU tiene VRAM asignada.
Si la VRAM crece en varias GPU durante la carga del modelo.
Si los tokens de generación mejoran en comparación con el desbordamiento de CPU/RAM.
Si la descarga de OOM o de modelos ocurre con frecuencia.

La utilización de la GPU por sí sola puede resultar engañosa. La inferencia LLM no siempre mantiene las GPU completamente cargadas, especialmente con varias GPU, tamaños de lote bajos, contextos pequeños, CPU lentas o enlaces PCIe lentos.

Malentendidos comunes

Malentendido 1: Dos GPU de 12 GB equivalen a una GPU de 24 GB

No exactamente. Varias GPU pueden colocar un modelo en varios dispositivos, pero el acceso entre dispositivos tiene una sobrecarga. Resuelve el problema de “no encaja”, pero no es equivalente a la velocidad y estabilidad de una GPU de gran VRAM.

Malentendido 2: No se pueden mezclar diferentes modelos de GPU

No necesariamente. Si el controlador, la capacidad informática y las bibliotecas de tiempo de ejecución son compatibles con las tarjetas, Ollama puede ver varias GPU. Pero las configuraciones mixtas suelen estar limitadas por una tarjeta más lenta, una VRAM más pequeña y una topología PCIe. La configuración más predecible sigue siendo el mismo modelo, el mismo tamaño de VRAM y controladores de la misma generación con buen soporte.

Malentendido 3: La GPU múltiple siempre es más rápida que la GPU única

No siempre. Si el modelo se adapta completamente a una GPU rápida, una GPU única puede ser más rápida. La GPU múltiple es útil principalmente para modelos grandes, contextos prolongados o VRAM de GPU única insuficiente.

Malentendido 4: Se requiere NVLink / SLI

No. Ollama puede utilizar sistemas PCIe múltiples-GPU ordinarios. NVLink no es un requisito previo.

Malentendido 5: Agregar una GPU no requiere reiniciar los servicios

No siempre es cierto. Es posible que sea necesario reiniciar los servicios systemd de Linux, las aplicaciones en segundo plano de Windows y los contenedores Docker antes de que redescubran dispositivos y variables de entorno.

Sugerencias de selección de GPU

Para la inferencia local de Ollama, la prioridad aproximada es:

La VRAM de una sola GPU más grande suele ser más fácil de administrar.
Las GPU idénticas son más fáciles de solucionar que las GPU mixtas.
Los carriles PCIe más completos facilitan la carga de modelos grandes.
Primero se debe verificar la capacidad de computación CUDA o la compatibilidad con ROCm en las tarjetas más antiguas.
La alimentación, la refrigeración y el flujo de aire del chasis de varias GPU deben planificarse con antelación.

Para plataformas económicas de segunda mano:

Dual RTX 3090 sigue siendo una opción común de alta VRAM.
Las tarjetas Tesla más antiguas, como la P40/M40, tienen una gran VRAM, pero la potencia, la refrigeración, la compatibilidad con el controlador y el rendimiento necesitan compensaciones.
Las tarjetas como RTX 4070/4070 Ti tienen buena eficiencia, pero la VRAM de una sola tarjeta puede ser limitante.
Puede ser divertido experimentar con varias tarjetas antiguas de 8 GB, pero no son ideales para ejecutar modelos grandes a largo plazo.

Resumen

La compatibilidad con múltiples GPU de Ollama se entiende mejor como “primero la expansión de VRAM y luego la aceleración del rendimiento”. Si el modelo cabe completamente en una GPU, la ruta predeterminada de una sola GPU suele ser más rápida. Si una GPU no puede contenerlo, varias GPU pueden distribuir el modelo entre dispositivos y evitar un gran desbordamiento de CPU/RAM, lo que hace que se puedan utilizar modelos más grandes.

En la práctica, use ollama ps para verificar dónde está cargado el modelo, luego use las herramientas nvidia-smi o ROCm para observar la asignación de VRAM. Para la selección de GPU, use CUDA_VISIBLE_DEVICES en NVIDIA, ROCR_VISIBLE_DEVICES en AMD ROCm y GGML_VK_VISIBLE_DEVICES para Vulkan. Si se ejecuta en Docker, primero asegúrese de que el contenedor pueda ver las GPU.

La multi-GPU no es mágica. Puede ayudar a adaptar modelos más grandes, pero no garantiza una aceleración lineal. La ruta estable sigue siendo preferir GPU únicas con gran VRAM o configuraciones idénticas de múltiples GPU, considerando al mismo tiempo la compatibilidad con controladores, PCIe, alimentación, refrigeración y cuantificación de modelos.

Referencias

Preguntas frecuentes de Ollama: ¿Cómo carga Ollama modelos en múltiples GPU?: https://github.com/ollama/ollama/blob/main/docs/faq.mdx
Documentos de Ollama GPU: soporte de hardware/selección de GPU: https://github.com/ollama/ollama/blob/main/docs/gpu.mdx
Centro Docker de Ollama: https://hub.docker.com/r/ollama/ollama
Kit de herramientas de contenedor NVIDIA: https://github.com/NVIDIA/nvidia-container-toolkit

Implemente el Agente Hermes localmente en Windows con WSL + Ollama y Connect Telegram

Sat, 18 Apr 2026 00:48:22 +0800

Si desea ejecutar “Agente Hermes” en “Windows” con la menor fricción posible, una ruta práctica es:

mantener Windows como sistema host
ejecuta Ubuntu dentro de WSL
utilizar Ollama para servir el modelo local
permitir que “Agente Hermes” se conecte directamente al punto final local de Ollama

Este enfoque mantiene el entorno relativamente limpio, le permite ejecutar la mayoría de los comandos en un flujo de trabajo estilo Linux y evita preparar una máquina Linux separada.

Flujo general

Puede dividir la configuración en 4 pasos:

Habilite WSL e instale Ubuntu
Instale Python, Node.js, Git y otros conceptos básicos dentro de Ubuntu
Instale Ollama y extraiga un modelo local.
Instale Hermes Agent, luego conecte Telegram

Si su objetivo es simplemente hacer que Hermes Agent se ejecute primero, al final del paso 3 ya estará cerca.

1. Instale WSL y Ubuntu

Ejecute esto en PowerShell con privilegios de administrador:

`1`	`wsl --install`

Una vez finalizada la instalación, reinicie la PC y luego continúe con Ubuntu:

`1`	`wsl --install -d Ubuntu`

Después de eso, abra Ubuntu en WSL. La mayoría de los comandos restantes se ejecutan allí.

2. Actualice Ubuntu e instale el entorno base

Actualice el sistema primero:

1
2

sudo apt update
sudo apt upgrade -y

Luego instale Python, herramientas de extracción, Node.js y Git.

Instalar Python

`1`	`sudo apt install python3-pip python3-venv -y`

Instalar zstd

`1`	`sudo apt install -y zstd`

Instalar Node.js

1
2

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs

Instalar Git

1
2

sudo apt update
sudo apt install -y git

Puede verificar rápidamente la instalación con:

1
2
3

node -v
npm -v
git --version

3. Instala Ollama y tira de Gemma 4

Instalar Ollama:

`1`	`curl -fsSL https://ollama.com/install.sh \| sh`

Si desea un modelo local para Hermes Agent, comenzar con “Gemma 4” es razonable.

Por ejemplo:

`1`	`ollama run gemma4:e4b`

Si tu máquina es más débil, también puedes intentar:

`1`	`ollama run gemma4:e2b`

Las variantes más grandes incluyen:

1
2

ollama run gemma4:26b
ollama run gemma4:31b

Para la mayoría de las configuraciones normales de Windows + WSL, gemma4:e4b suele ser el punto de partida más práctico.

4. Instalar y configurar el Agente Hermes

Instálalo con:

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

Después de la instalación, apúntelo al punto final local de Ollama:

`1`	`http://127.0.0.1:11434`

Utilice el nombre del modelo local que realmente instaló, por ejemplo:

`1`	`gemma4:e4b`

Si el instalador le pide que actualice el shell, ejecute:

`1`	`source ~/.bashrc`

Comandos comunes del agente Hermes

Estos son los comandos que utilizarás con más frecuencia:

Empezar

hermes

Vuelva a ingresar a la configuración

`1`	`hermes setup`

Configurar la puerta de enlace de chat

`1`	`hermes setup gateway`

Actualizar

`1`	`hermes update`

Pasos básicos de conexión a Telegram

Si desea que Hermes Agent envíe y reciba mensajes a través de Telegram, el paso principal sigue siendo:

`1`	`hermes setup gateway`

Luego prepare los dos elementos del lado de Telegram que necesita:

crear un bot con BotFather
obtenga su ID de usuario con @userinfobot

Una vez que tenga esos conceptos básicos, continúe completándolos en la configuración de la puerta de enlace del Agente Hermes.

¿A quién se adapta esta configuración?

Este flujo de trabajo es una buena opción si:

Windows es su sistema de escritorio principal
no desea mantener un host Linux separado
primero desea ejecutar un agente local y luego expandirlo a plataformas de chat
prefieres modelos locales en lugar de depender de las API de la nube

Si principalmente desea experimentar un Agente local en lugar de crear una implementación de producción completa de inmediato, esta ruta ya es bastante práctica.

Algunas cosas a tener en cuenta

WSL sigue siendo una capa de compatibilidad, por lo que en casos extremos puede que no se comporte exactamente como Linux nativo.
Que un modelo grande funcione sin problemas aún depende de su RAM, VRAM y CPU/GPU
gemma4:e4b es un punto de partida realista, pero la experiencia real aún depende de la máquina
La integración de la plataforma Hermes Agent es un paso de extensión; hacer que la ruta del modelo local funcione primero y luego agregar Telegram suele ser más estable

Conclusión

Si desea implementar Hermes Agent localmente en Windows con la menor fricción posible, el orden más sencillo es:

WSL -> Ubuntu -> Ollama -> Gemma 4 -> Agente Hermes -> Telegram

Primero ejecute el modelo local y luego agregue la integración de la puerta de enlace. Por lo general, eso le brinda una tasa de éxito mucho mayor. Para la mayoría de los usuarios, esto es más fácil de solucionar que acumular cada componente al principio y también deja espacio para una expansión posterior.

Referencia original

Esta publicación está reescrita y organizada en base a:

Blog de Xchaoge: 太简单了！Agente Hermes 本地部署（无需API）接入 Telegram + 微信

Cómo acceder a una API local de Ollama por LAN en Windows

Sat, 11 Apr 2026 16:43:52 +0800

Si quieres que otros dispositivos de la misma LAN accedan a tu API local de Ollama, sigue estos pasos.

Configurar el host de escucha

Primero, configura Ollama para escuchar en todas las interfaces de red:

OLLAMA_HOST=0.0.0.0:11434

Abrir el firewall

En la configuración avanzada de Windows Firewall, crea una regla de entrada y permite el puerto objetivo, por ejemplo 8080:

Pulsa Win + S, busca y abre “Windows Defender Firewall”.
Haz clic en “Advanced settings”.
Selecciona “Inbound Rules” -> “New Rule…”.
Elige “Port” y haz clic en “Next”.
Selecciona el protocolo, normalmente TCP, introduce el puerto en “Specific local ports”, por ejemplo 8080, y haz clic en “Next”.
Elige “Allow the connection” y haz clic en “Next”.
En “Profile”, selecciona Domain, Private y Public, y haz clic en “Next”.
Pon un nombre a la regla, por ejemplo OpenPort8080, y haz clic en “Finish”.

Ejecutar Ollama

Ejecuta el modelo con Ollama.

Acceder al modelo mediante la API

curl http://192.168.x.xxx:11434/api/generate -d '{
  "model": "gemma4",
  "prompt": "¿Qué modelo es este?"
}'

Guía local de Gemma 4: de ejecutarlo con un comando a integrarlo en desarrollo

Fri, 10 Apr 2026 22:54:17 +0800

Si quieres ejecutar Gemma 4 en local, puedes elegir entre cuatro rutas prácticas según tu objetivo y tu hardware.

1) Inicio más rápido: Ollama (recomendado)

Es la opción con menos fricción para pruebas rápidas, chat diario y uso de API local.

`1`	`ollama run gemma4`

Puntos clave:

Funciona en Windows, macOS y Linux
Gestiona automáticamente la aceleración por hardware
Ofrece una API local compatible con el estilo de OpenAI

2) Flujo con interfaz gráfica: LM Studio / Unsloth Studio

Si prefieres una UI de escritorio en lugar de comandos de terminal:

LM Studio: permite buscar y ejecutar variantes cuantizadas de Gemma 4 desde Hugging Face, por ejemplo 4-bit u 8-bit, con visibilidad del uso de recursos.
Unsloth Studio: soporta inferencia y fine-tuning con poca VRAM, a menudo más cómodo para GPUs de 6GB-8GB.

3) Equipos modestos y máximo control: llama.cpp

Buena opción para hardware antiguo, escenarios centrados en CPU o usuarios que quieren controlar más parámetros de inferencia.

Con archivos de modelo .gguf y cuantización, Gemma 4 puede funcionar con presupuestos de hardware mucho más bajos.

4) Integración de desarrollo: Transformers / vLLM

Si necesitas integrar Gemma 4 en tu propia aplicación:

Transformers: integración directa en proyectos Python
vLLM: inferencia de alto rendimiento para entornos GPU más potentes

Selección rápida

Necesidad	Herramientas recomendadas	Requisito de hardware
Solo quiero ejecutarlo ya	Ollama	Bajo
Prefiero una interfaz tipo ChatGPT	LM Studio	Medio
Tengo VRAM limitada (6GB-8GB)	Unsloth / llama.cpp	Bajo
Estoy creando aplicaciones locales de AI	Ollama / Transformers / vLLM	Medio a alto
Necesito fine-tuning	Unsloth Studio	Medio a alto

Sugerencia de tamaño de modelo

Gemma 4 llega en varios tamaños, por ejemplo E2B, E4B y 31B.

En portátiles comunes, empieza por E2B/E4B cuantizados
Prueba variantes más grandes solo cuando tu flujo base ya sea estable

Qué son los modelos en la nube de Ollama y cómo usarlos

Thu, 09 Apr 2026 18:42:32 +0800

Si usas normalmente Ollama para ejecutar modelos locales, entender los modelos en la nube será sencillo.

La diferencia central es solo una:
los modelos locales hacen inferencia en tu ordenador; los modelos en la nube hacen inferencia en la nube de Ollama y devuelven el resultado.

Qué es un modelo en la nube

Los modelos en la nube de Ollama conservan la forma de llamada de Ollama, pero cambian la ubicación del cálculo de local a la nube.

Las ventajas son:

Menor presión sobre el hardware local
Más fácil usar modelos grandes que tu máquina local no puede mover
Se mantiene el flujo de trabajo familiar de Ollama

Diferencia frente a modelos locales

Comparación	Modelo local	Modelo en la nube
Ubicación de ejecución	Máquina local	Nube
Requisitos de hardware	Altos	Bajos
Latencia	Más baja	Depende de la red
Privacidad	Más fuerte	La solicitud se envía a la nube

Si te importa más la privacidad, baja latencia y uso offline, el modelo local es más adecuado.
Si tu hardware local no alcanza pero quieres probar modelos más grandes, el modelo en la nube es más cómodo.

Cómo reconocer modelos en la nube

Actualmente, los modelos en la nube de Ollama suelen llevar el sufijo -cloud, por ejemplo:

`1`	`gpt-oss:120b-cloud`

La lista de modelos disponibles puede cambiar; toma la página oficial de Ollama como referencia final.

Cómo usarlos

Primero inicia sesión:

`1`	`ollama signin`

Después ejecuta directamente el modelo en la nube:

`1`	`ollama run gpt-oss:120b-cloud`

Si lo llamas desde código, también puedes configurar API Key:

`1`	`export OLLAMA_API_KEY=your_api_key`

Ejemplo en Python:

import os
from ollama import Client

client = Client(
    host="https://ollama.com",
    headers={"Authorization": "Bearer " + os.environ["OLLAMA_API_KEY"]},
)

messages = [
    {"role": "user", "content": "为什么天空是蓝色的？"}
]

for part in client.chat("gpt-oss:120b-cloud", messages=messages, stream=True):
    print(part["message"]["content"], end="", flush=True)

Resumen

Los modelos en la nube de Ollama pueden entenderse en una frase:

el comando casi no cambia; solo que el modelo ya no corre en tu máquina local.

Si tu ordenador no puede mover modelos grandes pero quieres seguir llamando modelos al estilo Ollama, los modelos en la nube son una opción directa.

Descargar modelos GGUF desde Hugging Face e importarlos en Ollama

Thu, 09 Apr 2026 11:00:07 +0800

Si cierto modelo no tiene una versión preparada en la biblioteca oficial de Ollama, o si quieres usar un archivo GGUF específico de Hugging Face, puedes descargarlo manualmente e importarlo después en Ollama.

Paso 1: descargar el archivo GGUF desde Hugging Face

Primero busca en Hugging Face el archivo GGUF correspondiente al modelo objetivo. Normalmente verás varias versiones cuantizadas, por ejemplo:

Q4_K_M
Q5_K_M
Q8_0

Qué versión elegir depende de tu VRAM, memoria y del equilibrio que quieras entre velocidad y calidad. Después de descargarlo, coloca el archivo .gguf en un directorio fijo para referenciarlo directamente en el Modelfile.

Paso 2: escribir el Modelfile

Crea un archivo Modelfile en el mismo directorio que el modelo. La forma mínima es:

`1`	`FROM ./model.gguf`

Si el nombre del archivo es distinto, cámbialo por el nombre real, por ejemplo:

`1`	`FROM ./gemma-3-12b-it-q4_k_m.gguf`

Si solo quieres ponerlo en marcha primero, normalmente esta línea FROM basta.

Paso 3: importar a Ollama

Después ejecuta:

`1`	`ollama create myModelName -f Modelfile`

myModelName es el nombre local del modelo que quieres usar dentro de Ollama
-f Modelfile indica que se crea el modelo desde este archivo de configuración

Cuando la creación termine correctamente, ese archivo GGUF se convertirá en un modelo local que puede llamarse directamente.

Paso 4: ejecutar el modelo

Después de crearlo, ejecútalo directamente:

`1`	`ollama run myModelName`

A partir de ahí, su uso es básicamente igual al de un modelo descargado con ollama pull.

Cómo ver el Modelfile de un modelo existente

Si no estás seguro de cómo escribir el Modelfile, puedes mirar directamente la configuración de un modelo existente:

`1`	`ollama show --modelfile llama3.2`

Este comando imprimirá el contenido del Modelfile de llama3.2, útil como referencia:

Cómo debería escribirse FROM
Cómo se organizan la plantilla y el system prompt
Cómo se declaran los parámetros

Cuándo conviene esta ruta

Estos escenarios son adecuados para importar manualmente desde Hugging Face:

La biblioteca oficial de Ollama todavía no tiene el modelo que necesitas
Quieres usar una versión cuantizada concreta
Ya descargaste manualmente el archivo GGUF
Quieres controlar con más detalle la forma de empaquetar el modelo

Si ya existe una versión oficial lista, usar pull suele ser más sencillo; pero cuando necesitas una cuantización específica o empaquetado personalizado, GGUF + Modelfile es más flexible.

Precauciones habituales

La ruta después de FROM debe coincidir con la ubicación real del archivo .gguf.
Si el nombre de archivo contiene espacios o caracteres especiales, se recomienda renombrarlo a algo más simple.
Las distintas cuantizaciones GGUF influyen mucho en memoria y velocidad; importarlo con éxito no significa que vaya a ejecutarse con fluidez.
Si el modelo es de chat, normalmente tendrás que ajustar después la plantilla de prompt según su formato para obtener resultados más estables.

Conclusión

Descargar un archivo GGUF desde Hugging Face e importarlo en Ollama no es complicado. Prepara el archivo del modelo, escribe un Modelfile mínimo y ejecuta ollama create; con eso puedes conectar modelos GGUF de terceros a Ollama.

Diagnóstico y soluciones para descargas muy lentas con ollama pull

Thu, 09 Apr 2026 10:42:39 +0800

ollama pull model_name:tag puede descargar muy lento en algunas regiones, y el proceso no siempre es estable.

Si el problema que encuentras es que la descarga de un modelo grande se interrumpe repetidamente a mitad de camino, con errores como TLS handshake timeout o unexpected EOF, es muy probable que el problema no esté solo en registry.ollama.ai, sino en la ruta real de descarga después de la redirección.

Este artículo registra una idea de diagnóstico simple y directa: primero obtener la dirección real de descarga del archivo del modelo, luego confirmar dónde termina realmente el tráfico y por último optimizar solo los dominios clave.

Obtener la dirección de descarga del archivo del modelo

Puedes usar el siguiente proyecto para extraer directamente el manifest y las direcciones de descarga de blobs correspondientes al modelo de Ollama:

https://github.com/Gholamrezadar/ollama-direct-downloader

Tomando gemma4:latest como ejemplo, se pueden extraer enlaces parecidos a los siguientes.

Dirección del manifest

`1`	`https://registry.ollama.ai/v2/library/gemma4/manifests/latest`

Direcciones de blobs

https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:56380ca2ab89f1f68c283f4d50863c0bcab52ae3f1b9a88e4ab5617b176f71a3

Si solo quieres verificar rápido, también puedes descargar directamente el manifest y los blobs con curl:

curl -L "https://registry.ollama.ai/v2/library/gemma4/manifests/latest" -o "latest"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11" -o "sha256-f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a" -o "sha256-4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2" -o "sha256-7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2"

Dirección real después de la redirección

Al intentar descargar uno de los blobs con wget, verás que la solicitud no se queda siempre en registry.ollama.ai, sino que redirige a una dirección de almacenamiento de objetos Cloudflare R2:

wget https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
--2026-04-09 09:22:04--  https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
Resolving registry.ollama.ai (registry.ollama.ai)... 104.21.75.227, 172.67.182.229, 2606:4700:3034::ac43:b6e5, ...
Connecting to registry.ollama.ai (registry.ollama.ai)|104.21.75.227|:443... connected.
HTTP request sent, awaiting response... 307 Temporary Redirect
Location: https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/4c/4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a/data?... [following]
--2026-04-09 09:22:05--  https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/4c/4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a/data?...
Resolving dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com (dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com)... 172.64.66.1, 2606:4700:2ff9::1
Connecting to dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com|172.64.66.1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9608338848 (8.9G) [application/octet-stream]

En el log se ven varios puntos clave:

registry.ollama.ai devuelve 307 Temporary Redirect
La dirección final cae en *.r2.cloudflarestorage.com
La transferencia real del archivo grande la soporta en realidad el dominio de almacenamiento de objetos posterior

Este paso es importante, porque demuestra que si tu proxy o reglas de routing solo cubren registry.ollama.ai, pero no tratan *.r2.cloudflarestorage.com, la descarga seguirá pudiendo ser lenta o interrumpirse repetidamente.

Ajustar la configuración de red

Después de confirmar la ruta real de descarga, la dirección de diagnóstico queda mucho más clara.

Si estás usando proxy, reglas de routing o DNS personalizado, se recomienda revisar primero:

Si registry.ollama.ai y *.r2.cloudflarestorage.com pasan por la misma ruta estable
Si las reglas de proxy solo cubren el primero y se olvidan del segundo
Si la salida actual es adecuada para descargas sostenidas de varios GB o decenas de GB

La clave de este tipo de problema no es “si se puede abrir la web oficial”, sino “si la ruta de almacenamiento de objetos después de la redirección es estable y puede transferir durante largo tiempo”. Muchas veces, lo que de verdad hay que optimizar es la capa Cloudflare R2, no el dominio registry anterior.

Comparación antes y después del ajuste

Abajo hay una descarga real de gemma4:31b-it-q8_0.

Antes del ajuste, la velocidad era baja y aparecía error a mitad de camino:

PS C:\Users\knightli> ollama run gemma4:31b-it-q8_0
pulling manifest
pulling a0feadb736f5:  38% ▕██████████████████████                                    ▏  12 GB/ 33 GB  1.2 MB/s   4h40m
Error: max retries exceeded: unexpected EOF

Después del ajuste, al descargar de nuevo el mismo modelo, la velocidad y estabilidad mejoraron claramente:

1
2
3

PS C:\Users\knightli> ollama run gemma4:31b-it-q8_0
pulling manifest
pulling a0feadb736f5:  46% ▕████████████████████████████████████████████████████████████████▏ 15 GB/ 33 GB  8.5 MB/s  35m23s

Esto no significa que todos los entornos de red obtengan el mismo resultado, pero al menos muestra algo: el cuello de botella probablemente no está en el cliente Ollama, sino en la ruta real de descarga de archivos grandes.

Conectar OpenClaw con Gemma 4 local: guía completa de configuración

Wed, 08 Apr 2026 18:18:00 +0800

Este artículo muestra cómo conectar OpenClaw a un modelo Gemma 4 local, exponiendo la interfaz mediante Ollama.

Si todavía no completaste el despliegue local, puedes consultar primero:

Cómo ejecutar Gemma 4 en un portátil: guía de despliegue local en 5 minutos

Paso 1: iniciar el servicio API de Ollama

Primero inicia el servicio de Ollama:

`1`	`ollama serve`

Puedes probar rápidamente si la API funciona con el siguiente comando:

curl http://localhost:11434/api/generate -d '{
  "model": "gemma4:12b",
  "prompt": "你好"
}'

Si devuelve salida del modelo, significa que la API local ya está disponible.

Paso 2: configurar OpenClaw para acceder a Ollama

La ruta habitual del archivo de configuración de OpenClaw es:

`1`	`~/.openclaw/config.yaml`

Edita config.yaml y añade una entrada de modelo local dentro de models:

models:
  # 你已有的模型配置...

  gemma4-local:
    provider: ollama
    base_url: http://localhost:11434
    model: gemma4:12b
    timeout: 120s

Paso 3: establecer el modelo predeterminado (opcional)

Si quieres que Gemma 4 sea el modelo predeterminado, añade:

`1`	`default_model: gemma4-local`

Paso 4: reiniciar y verificar OpenClaw

Reinicia OpenClaw:

`1`	`openclaw restart`

Consulta la lista de modelos:

`1`	`openclaw models list`

Inicia una conversación de prueba:

`1`	`openclaw chat --model gemma4-local "你好"`

Si la conversación devuelve respuesta con normalidad, OpenClaw ya se conectó correctamente a Gemma 4 local.

Diagnóstico habitual

connection refused: confirma primero si ollama serve está ejecutándose.
Modelo no encontrado: comprueba que el nombre del modelo coincida con ollama list (por ejemplo gemma4:12b).
Timeout de respuesta: puedes aumentar timeout y probar primero con un modelo más pequeño.

Cómo ejecutar Gemma 4 en un portátil: guía de despliegue local en 5 minutos

Wed, 08 Apr 2026 18:06:00 +0800

Si quieres ejecutar Gemma 4 localmente en un portátil, Ollama es una de las opciones más sencillas actualmente. Incluso sin configurar un entorno complicado, normalmente se puede poner en marcha en unos 5 minutos.

Paso 1: instalar Ollama

Abre https://ollama.com y descarga el instalador correspondiente a tu sistema.
Completa la instalación según el sistema:

macOS: arrástralo a Applications.
Windows: ejecuta el instalador .exe.
Linux: usa el script de instalación ofrecido en el sitio oficial.

Tras la instalación, Ollama se ejecutará como servicio en segundo plano. Salvo durante la instalación inicial, en el uso diario suelen bastar comandos simples.

Paso 2: descargar el modelo Gemma 4

Abre una terminal y ejecuta:

`1`	`ollama pull gemma4:4b`

Si tu equipo tiene más rendimiento, puedes cambiarlo por 12b o 27b. Cuando termine la descarga, el modelo quedará guardado localmente.

Para ver los modelos descargados:

`1`	`ollama list`

Paso 3: iniciar el modelo

`1`	`ollama run gemma4:4b`

Esto abrirá una conversación interactiva en la terminal. Escribe una pregunta y pulsa Enter; para terminar la sesión puedes introducir:

/bye

Si prefieres una interfaz de chat web, puedes usarlo junto con Open WebUI. Esta herramienta envuelve Ollama en una UI de navegador y normalmente se configura en pocos minutos con Docker.

Consejos de optimización para portátiles

Apple Silicon (M2/M3/M4): por defecto usa Metal y la aceleración suele funcionar muy bien; 12B también puede ofrecer una buena experiencia.
Tarjeta NVIDIA: cuando detecta una GPU compatible, suele usar CUDA automáticamente. Conviene actualizar los drivers con antelación.
Inferencia solo con CPU: se puede ejecutar, pero los modelos grandes serán claramente más lentos; en la mayoría de escenarios CPU-only conviene priorizar 4B.
Liberar memoria: antes de cargar modelos grandes, cierra en lo posible aplicaciones que consuman mucha memoria. Como referencia práctica, cada mil millones de parámetros suelen necesitar entre 0.5GB y 1GB de memoria.

Cómo elegir modelo

Gemma 4 1B: adecuado para preguntas y respuestas ligeras, resúmenes básicos y consultas rápidas; su capacidad de razonamiento complejo es limitada.
Gemma 4 4B: adecuado para la mayoría de tareas diarias (ayuda de escritura, ayuda de código, resumen de materiales), con buen equilibrio entre velocidad y calidad.
Gemma 4 12B: adecuado para contextos más largos y tareas más complejas; es más estable en escenarios de código y razonamiento.
Gemma 4 27B: adecuado para tareas exigentes; el resultado se acerca más a modelos grandes en la nube, pero requiere mucho más hardware.

Cómo comprobar si un modelo de Ollama ya se cargó en la GPU

Mon, 06 Apr 2026 10:15:18 +0800

Si quieres confirmar si un modelo de Ollama se está ejecutando realmente en la GPU, el método más directo es revisar la información de uso de procesador de los modelos cargados actualmente.

Comando

`1`	`ollama ps`

Salida de ejemplo

1
2

NAME        ID            SIZE    PROCESSOR   UNTIL
llama3:70b  bcfb190ca3a7  42 GB   100% GPU    4 minutes from now

Cómo interpretar la columna `PROCESSOR`

100% GPU: el modelo está cargado por completo en la memoria de la GPU.
100% CPU: el modelo está cargado por completo en la memoria del sistema (no usa GPU para inferencia).
48%/52% CPU/GPU: una parte del modelo está en memoria del sistema y otra en memoria de GPU; es una carga mixta.

Consejos prácticos

Si esperas usar GPU pero ves 100% CPU, revisa primero el driver de la tarjeta gráfica, el entorno CUDA/ROCm y los parámetros de ejecución de Ollama.
Cuando el modelo es grande y la memoria de GPU no alcanza, suele aparecer una carga mixta CPU/GPU.
Al diagnosticar problemas de rendimiento, ejecuta primero ollama ps y luego mira los datos de velocidad; así podrás ubicar antes el cuello de botella.

Resumen

ollama ps es el primer paso para saber si un modelo está usando realmente la GPU. Basta con fijarse en la columna PROCESSOR para confirmar rápidamente dónde está cargado el modelo y decidir la siguiente dirección de optimización.

Ubicación predeterminada de modelos de Ollama y método de migración (para evitar llenar la unidad C)

Mon, 06 Apr 2026 09:38:00 +0800

Cuando ejecutas modelos grandes localmente, lo primero que suele quedarse sin espacio es la unidad del sistema. Ollama descarga los modelos de forma predeterminada en el directorio del usuario o en un directorio del sistema. Si no planificas la ruta con antelación, la unidad C puede llenarse muy rápido.

Directorios predeterminados habituales de modelos de Ollama

Windows: C:\Users\<用户名>\.ollama\models
macOS: ~/.ollama/models
Linux: /usr/share/ollama/.ollama/models (puede variar según el método de instalación)

Windows: migrar el directorio de modelos a una unidad que no sea del sistema

Se recomienda mover el directorio de modelos, por ejemplo, a D:\OllamaModels. El método clave es configurar la variable de entorno del sistema OLLAMA_MODELS.

1. Crear el directorio de destino

Por ejemplo, crea primero: D:\OllamaModels

2. Configurar la variable de entorno del sistema

Nombre de variable: OLLAMA_MODELS
Valor de variable: D:\OllamaModels

Puedes añadirla desde “Propiedades del sistema -> Opciones avanzadas -> Variables de entorno”, o configurarla con la línea de comandos (PowerShell como administrador):

`1`	`[System.Environment]::SetEnvironmentVariable("OLLAMA_MODELS", "D:\OllamaModels", "Machine")`

3. Reiniciar Ollama (o reiniciar el sistema)

Después de que la variable de entorno entre en vigor, reinicia el servicio o la aplicación de Ollama. Si no estás seguro de si ya se aplicó, reiniciar el equipo es la opción más estable.

4. Verificar que el nuevo directorio esté activo

Después de descargar o hacer pull de cualquier modelo, comprueba si aparecen archivos nuevos bajo D:\OllamaModels.

5. Limpiar el directorio antiguo (después de confirmar)

Cuando confirmes que los modelos funcionan correctamente en el nuevo directorio, elimina el contenido del directorio antiguo para recuperar espacio en la unidad C.

Preguntas frecuentes

Qué hacer si después de configurarlo sigue escribiendo en la unidad C

Confirma que la variable de entorno sea una “variable del sistema”, no una variable temporal de la sesión actual.
Confirma que el proceso de Ollama se haya reiniciado.
Comprueba que el nombre de la variable sea exacto: debe ser OLLAMA_MODELS.

Hay que migrar los archivos de modelos antiguos

Si no quieres volver a descargarlos, puedes detener Ollama, copiar manualmente los modelos antiguos al nuevo directorio y después iniciar Ollama para verificar.

Desinstalar Ollama por completo en Linux (incluida la limpieza de residuos)

Mon, 06 Apr 2026 09:16:29 +0800

Si necesitas eliminar Ollama por completo en Linux, puedes seguir el orden siguiente. Este artículo limpia el servicio, el ejecutable, el directorio de modelos y también el usuario y grupo ollama.

Avisos antes de desinstalar

Los comandos siguientes eliminarán los archivos de modelos locales de Ollama (normalmente en /usr/share/ollama). Confirma antes si necesitas hacer una copia de seguridad.
Los comandos usan sudo por defecto. Asegúrate de que la cuenta actual tenga permisos de administrador.

1. Detener y eliminar el servicio systemd

sudo systemctl stop ollama
sudo systemctl disable ollama
sudo rm -f /etc/systemd/system/ollama.service
sudo systemctl daemon-reload

2. Eliminar el ejecutable de Ollama

OLLAMA_BIN="$(command -v ollama)"
if [ -n "$OLLAMA_BIN" ]; then
  sudo rm -f "$OLLAMA_BIN"
fi

3. Eliminar directorios de bibliotecas relacionados con Ollama (si existen)

Si tu método de instalación escribió archivos de Ollama en directorios lib, puedes limpiarlos así:

1
2
3

for d in /usr/local/lib/ollama /usr/lib/ollama /lib/ollama; do
  [ -d "$d" ] && sudo rm -rf "$d"
done

4. Eliminar el directorio de modelos y datos

`1`	`sudo rm -rf /usr/share/ollama`

5. Eliminar el usuario y grupo del sistema (si existen)

1
2

id -u ollama >/dev/null 2>&1 && sudo userdel ollama
getent group ollama >/dev/null 2>&1 && sudo groupdel ollama

6. Verificar si la desinstalación terminó

1
2

command -v ollama || echo "ollama binary not found"
systemctl status ollama || true

Si las comprobaciones anteriores ya no encuentran ollama, la desinstalación se ha completado.

Explicación de la cuantificación de LLM: cómo elegir FP16, Q8, Q5, Q4 o Q2

Sun, 05 Apr 2026 22:09:11 +0800

El objetivo principal de la cuantificación es simple: intercambiar una pequeña cantidad de precisión por un tamaño de modelo más pequeño, un menor uso de VRAM y una inferencia más rápida.
Para la implementación local, elegir el formato de cuantificación correcto suele ser más importante que buscar un recuento de parámetros mayor.

¿Qué es la cuantización?

La cuantización significa comprimir los parámetros del modelo desde formatos de mayor precisión (como “FP16”) a formatos de bits más bajos (como “Q8” y “Q4”).

Una analogía simple:

Modelo original: como una foto de alta calidad, clara pero grande.
Modelo cuantificado: como una foto comprimida, ligeramente menos detallada pero más ligera y rápida.

Formatos de cuantificación comunes

Cuantización	Precisión/Ancho de broca	Tamaño	Pérdida de calidad	Uso recomendado
FP16	flotante de 16 bits	Más grande	Casi ninguno	Investigación, evaluación, máxima calidad
Q8_0	Entero de 8 bits	Más grande	Casi ninguno	PC de alta gama, calidad + rendimiento
Q5_K_M	5 bits mixto	Medio	Ligero	Conductor diario, elección equilibrada
Q4_K_M	Mixto de 4 bits	Más pequeño	Aceptable	Valor predeterminado general, valor fuerte
Q3_K_M	Mezclado de 3 bits	Muy pequeño	Notable	Dispositivos de baja especificación, ejecutar primero
Q2_K	Mixto de 2 bits	Más pequeño	Significativo	Límites extremos de recursos, respaldo

Reglas de denominación de cuantificación

Tome gemma-4:4b-q4_k_m como ejemplo:

gemma-4:4b: nombre del modelo y escala de parámetros.
q4: cuantificación de 4 bits.
k: K-quants (un método de cuantificación mejorado).
m: nivel medio (las opciones comunes también incluyen s/small y l/large).

Selección rápida por VRAM

RAM/VRAM	Cuantización recomendada
4 GB	Q3_K_M / Q2_K
8 GB	Q4_K_M
16 GB	Q5_K_M / Q8_0
32GB+	FP16 / T8_0

Comience con una versión que se ejecute de manera estable en su máquina, luego avance con precisión paso a paso en lugar de saltar directamente al modelo más grande.

Consejos prácticos

Comience con Q4_K_M de forma predeterminada y pruebe primero las tareas reales.
Si la calidad de la respuesta no es suficiente, suba a Q5_K_M o Q8_0.
Si la VRAM o la velocidad son el principal cuello de botella, baje a Q3_K_M.
Utilice el mismo conjunto de prueba cada vez que cambie de formato de cuantificación.

Conclusión

Calidad primero: FP16 o Q8_0.
Saldo primero: Q5_K_M.
Valor predeterminado general: Q4_K_M.
Reserva de baja especificación: Q3_K_M o Q2_K.

La clave no es “cuanto más grande, mejor”, sino “el resultado más estable y utilizable bajo los límites de su hardware”.

Publicaciones relacionadas

Comparación y selección de modelos Gemma 4
Desinstalar completamente Ollama en Linux
Ruta de almacenamiento y migración del modelo Ollama
Cómo comprobar si Ollama usa GPU

Comparación de modelos Google Gemma 4: cómo elegir entre 2B/4B/26B/31B

Sun, 05 Apr 2026 08:30:00 +0800

Gemma 4 se centra en la “multimodalidad” y la “inferencia local fuera de línea”, con una gama completa desde modelos livianos hasta modelos de alto rendimiento. Para la mayoría de los usuarios de implementación local, la clave no es elegir el modelo más grande, sino el que mejor se adapte a las necesidades de hardware y tareas.

Comparación de modelos Gemma 4

La siguiente tabla es para una selección rápida del modelo. El rendimiento real y el uso de recursos deben validarse en su propio entorno.

Modelo	Tamaño del parámetro	Posicionamiento	Fortalezas clave	Principales limitaciones	Escenarios recomendados
Gema 4 2B	2B	Ultraligero	Baja latencia, bajo uso de recursos, barrera de implementación más baja	Rendimiento limitado en razonamientos complejos y largas cadenas de tareas	Móvil, IoT, preguntas y respuestas ligeras, automatización sencilla
Gema 4 4B	4B	Ligero mejorado	Mayor comprensión y generación que 2B, aún fácil de implementar localmente	Límite limitado para codificación pesada y tareas complejas de agentes	Asistente local, trabajo documental básico, tareas diarias multilingües
Gema 4 26B	26B	Alto rendimiento (MoE)	Mejor razonamiento y uso de herramientas, adecuado para flujos de trabajo de producción	Requisito de VRAM y umbral de hardware significativamente mayores	Asistente de codificación, flujos de trabajo complejos, agentes internos empresariales
Gema 4 31B	31B	Alto rendimiento (denso)	Mejor capacidad general y mayor estabilidad en tareas complejas	Mayor coste de recursos y complejidad de ajuste	Razonamiento avanzado, tareas de codificación complejas, automatización intensa

Cómo elegir: comenzar desde hardware y tareas

Si su principal preocupación es si funciona sin problemas, utilice esta guía:

VRAM 8GB: prioriza 2B/4B.
VRAM 12GB: prioriza 4B o variantes cuantificadas de modelos más grandes.
VRAM 24GB: céntrese en 26B y evalúe 31B cuantificados según la carga de trabajo.
Mayor VRAM o multi-GPU: considere configuraciones 31B de alta precisión.

Primero, priorice la estabilidad y la velocidad de inferencia y luego aumente gradualmente el tamaño del modelo.

Cuatro casos de uso típicos

1) Asistente General Local

Modelo preferido: 4B
Por qué: fuerte equilibrio entre coste y calidad, adecuado para un uso local a largo plazo.

2) Codificación y automatización

Modelo preferido: 26B
Por qué: más estable en tareas de varios pasos, llamadas a herramientas y generación de scripts.

3) Razonamiento avanzado y agentes complejos

Modelo preferido: 31B
Por qué: mayor solidez en un contexto complejo.

4) Dispositivos perimetrales y uso ligero sin conexión

Modelo preferido: 2B
Por qué: es más fácil de implementar en dispositivos con recursos limitados.

Sugerencias de implementación (Ollama)

Un enfoque práctico es iterar en pequeños pasos:

Comience con 4B para establecer una línea de base (latencia, memoria, calidad).
Cree un conjunto de pruebas fijo a partir de tareas reales (por ejemplo, 20 preguntas comunes + 10 tareas de automatización).
Compare 26B/31B con el conjunto en cuanto a precisión, latencia y costo de VRAM.
Actualice sólo cuando la ganancia sea clara.

Esto evita saltar a un modelo grande demasiado pronto y sufrir retrasos, bajo rendimiento y gastos generales de mantenimiento.

Conclusión

El valor real de Gemma 4 no es sólo un mayor número de parámetros, sino también un modelo práctico que permite pasar de ser liviano a uno de alto rendimiento:

Para una implementación rápida y de bajo costo: comience con “2B/4B”.
Para flujos de trabajo de IA locales de nivel de producción: priorice “26B”.
Para razonamiento avanzado y automatización intensa: pase a 31B.

En la mayoría de los casos, la mejor opción de Gemma 4 no es el modelo más grande, sino el que mejor se adapta a su hardware y objetivos de tareas.

Publicaciones relacionadas

Guía de Cuantización LLM (FP16/Q8/Q5/Q4/Q2)
Desinstalar completamente Ollama en Linux
Ruta de almacenamiento y migración del modelo Ollama
Cómo comprobar si Ollama usa GPU
Cómo instalar y ejecutar Gemma 4 en Android
Cómo ejecutar Gemma 4 en una computadora portátil: guía de configuración local de 5 minutos

Ollama on KnightLi Blog

Guía de despliegue local de Claude Code + Ollama: crear un asistente de programación AI gratuito con CC Switch

Qué Problema Resuelve Esta Configuración

Preparación Básica

Configuración Clave De CC Switch

Dónde Destaca Claude Code

Qué Papel Cumple Ollama

Dónde Están Los Límites De La Experiencia

La Compatibilidad Multimodal Sigue Siendo Inestable

Para Quién Tiene Sentido Probarlo

Recomendaciones De Uso

Resumen

Modelos LLM locales recomendados para una GPU RTX 3060

Primero mira el límite de VRAM

Recomendación 1: Qwen3 8B

Recomendación 2: Llama 3.1 8B Instruct

Recomendación 3: Gemma 3 12B

Recomendación 4: DeepSeek R1 Distill Qwen 8B

Recomendación 5: Phi / MiniCPM / modelos pequeños

Cómo elegir cuantización

Qué herramienta usar

No abras demasiado el contexto

Elegir según uso

Expectativas razonables

Resumen

Referencias

C贸mo solucionar que Ollama use CPU en lugar de GPU

1. Primero, confirma si Ollama realmente no está usando la GPU

2. Descartar primero el malentendido más común: el modelo no cabe en VRAM

3. Comprobar si el driver de la GPU y el runtime de bajo nivel están funcionando realmente

NVIDIA

AMD / ROCm

4. Reinicia el servicio de Ollama, no solo tu terminal

5. Comprobar si las variables de entorno están llegando realmente al servicio

6. En plataformas AMD, céntrate en la compatibilidad de ROCm

7. En Docker, WSL o entornos remotos, comprueba también el mapeo de dispositivos

8. Revisar los registros al final, pero revisarlos por la razón correcta

Orden de Solución de Problemas

Conclusión

Notas de Ollama Multi-GPU: agrupación de VRAM, selección de GPU y malentendidos comunes

Comportamiento oficial: GPU única primero, GPU múltiple cuando sea necesario

Multi-GPU no es un simple apilamiento informático

No se requiere SLI o NVLink

Limite las GPU NVIDIA que utiliza Ollama

Selección de dispositivos AMD y Vulkan

Exponer varias GPU en Docker

¿Qué es OLLAMA_SCHED_SPREAD?

Cómo comprobar si se están utilizando varias GPU

Malentendidos comunes

Malentendido 1: Dos GPU de 12 GB equivalen a una GPU de 24 GB

Malentendido 2: No se pueden mezclar diferentes modelos de GPU

Malentendido 3: La GPU múltiple siempre es más rápida que la GPU única

Malentendido 4: Se requiere NVLink / SLI

Malentendido 5: Agregar una GPU no requiere reiniciar los servicios

Sugerencias de selección de GPU

Resumen

Referencias

Implemente el Agente Hermes localmente en Windows con WSL + Ollama y Connect Telegram

Flujo general

1. Instale WSL y Ubuntu

2. Actualice Ubuntu e instale el entorno base

Instalar Python

Instalar zstd

Instalar Node.js

Instalar Git

3. Instala Ollama y tira de Gemma 4

4. Instalar y configurar el Agente Hermes

Comandos comunes del agente Hermes

Empezar

Vuelva a ingresar a la configuración

Configurar la puerta de enlace de chat

Actualizar

Pasos básicos de conexión a Telegram

¿A quién se adapta esta configuración?

Algunas cosas a tener en cuenta

Conclusión

Referencia original

Cómo acceder a una API local de Ollama por LAN en Windows

Configurar el host de escucha

Abrir el firewall

¿Qué es `OLLAMA_SCHED_SPREAD`?

Cómo interpretar la columna `PROCESSOR`