Local LLM on KnightLi Blog

Ejecutar DeepSeek 4 en local: el experimento ds4 de Antirez en Apple Silicon Mac

Mon, 11 May 2026 08:51:37 +0800

Antirez ha publicado un nuevo proyecto open source: ds4. No es un framework LLM de propósito general, sino un motor de inferencia local para DeepSeek V4 Flash, centrado en Apple Silicon y el backend Metal.

URL del proyecto: https://github.com/antirez/ds4

Qué es ds4

ds4 tiene un objetivo muy claro: ejecutar DeepSeek V4 Flash localmente en un Mac.

Actualmente ofrece tres formas de uso:

CLI interactiva.
HTTP server.
Un modo Agent experimental.

Por su posicionamiento, se parece más a un proyecto de inferencia profundamente optimizado para un modelo específico que a un reemplazo de herramientas generales como llama.cpp, Ollama o vLLM.

Por qué merece atención

Hay tres razones principales por las que este tipo de proyecto merece atención.

La primera es que su autor es Antirez, creador de Redis. Lleva mucho tiempo interesado en sistemas de bajo nivel, rendimiento y herramientas simples, y sus proyectos suelen tener un estilo bastante directo.

La segunda es que DeepSeek V4 Flash apunta a una inferencia eficiente. Si la experiencia local es lo bastante buena, puede resultar muy atractivo para usuarios de Mac.

La tercera es que ds4 apunta directamente a Apple Metal. En lugar de intentar soportar todas las plataformas primero y optimizar después, parece buscar profundidad en un escenario muy definido.

Para quién es

ds4 encaja mejor con usuarios que:

Usan un Apple Silicon Mac.
Quieren ejecutar DeepSeek V4 Flash en local.
Se interesan por el rendimiento de inferencia con Metal.
Están dispuestos a probar un proyecto en fase alpha.
Quieren estudiar motores de inferencia ligeros y detalles de ejecución de modelos.

Si tu objetivo es un despliegue estable, ejecución multiplataforma o una infraestructura compatible con OpenAI API, probablemente no sea la primera opción en esta etapa. Tiene más sentido como herramienta experimental y como proyecto técnico para observar.

Cómo usarlo

El flujo básico que muestra el README del proyecto es compilar primero y ejecutar después.

1
2
3

git clone https://github.com/antirez/ds4.git
cd ds4
make

Ejecución interactiva:

./ds4

Iniciar el HTTP server:

`1`	`./ds4 --server`

Modo Agent:

`1`	`./ds4 --agent`

Para los parámetros concretos y la preparación de los archivos del modelo, conviene seguir el README del repositorio, porque el proyecto todavía cambia con rapidez.

Riesgos actuales

ds4 todavía está en una etapa temprana, así que conviene ajustar expectativas antes de usarlo:

Las funciones pueden estar incompletas.
Los parámetros, formatos de modelo y comportamientos de línea de comandos pueden cambiar.
La compatibilidad gira principalmente alrededor de Apple Silicon y Metal.
El modo Agent es más experimental y no es adecuado para usarlo directamente en producción.
Si surge un problema, quizá tengas que leer el README, los issues o el código fuente por tu cuenta.

En otras palabras, ahora mismo se parece más a un experimento open source que vale la pena probar que a una herramienta de un clic para usuarios generales.

Diferencias frente a herramientas de inferencia generales

Las herramientas de inferencia generales suelen buscar compatibilidad amplia con formatos de modelo, plataformas, backends y APIs. ds4 toma un camino más estrecho: ejecutar DeepSeek V4 Flash en local con Metal.

Esa decisión tiene ventajas y costes.

La ventaja es que la implementación puede mantenerse enfocada, lo que facilita optimizar rendimiento y experiencia alrededor de un único objetivo. El coste es un alcance limitado: no está pensado para ejecutar todo tipo de modelos ni para sustituir una plataforma completa de despliegue.

Si ya usas llama.cpp u Ollama, ds4 puede servir como herramienta complementaria de pruebas, no como sustituto inmediato de tu flujo de trabajo actual.

Resumen

Lo interesante de ds4 no es que sea otra herramienta local para grandes modelos. Lo interesante es que reduce mucho su alcance: DeepSeek V4 Flash, Apple Silicon, Metal e inferencia local.

Si tienes un Mac adecuado y te apetece experimentar con un proyecto temprano, vale la pena seguir su rendimiento, su forma de soportar modelos y la evolución de sus capacidades de server/agent. Para entornos de producción, es mejor observar un poco más y evaluarlo cuando las interfaces y la forma de uso sean más estables.

Referencias

Proyecto en GitHub: https://github.com/antirez/ds4

Cómo medir el rendimiento multi-GPU en llama.cpp: ¿2x V100 16GB son más rápidas que una sola GPU de 32GB?

Sat, 09 May 2026 15:05:41 +0800

La conclusión rápida: el multi-GPU offload de llama.cpp no significa rendimiento gratis por añadir una segunda tarjeta. Si el modelo ya cabe completo en una GPU de 32GB, 2x V100 16GB suele ser menos cómodo que una sola tarjeta de 32GB, e incluso puede ser más lento. Si el modelo no cabe en una sola tarjeta de 16GB, el valor principal de usar dos GPU es mantener el modelo en GPU, y ahí la mejora sí puede ser clara.

Primero, separa los split mode

El uso multi-GPU en llama.cpp gira principalmente alrededor de --split-mode y --tensor-split. Para hablar de rendimiento, conviene distinguir primero estos modos:

layer: divide capas entre distintas GPU. Suele ser el punto de partida más compatible.
tensor: divide el cálculo de tensores entre varias GPU. Se acerca más al paralelismo real, pero depende mucho del ancho de banda entre GPU y del soporte del backend.
row: un modo antiguo de división por filas. Todavía aparece en algunas configuraciones, pero normalmente no es la primera opción para despliegues nuevos.

En términos simples, layer es como poner diferentes pisos en diferentes tarjetas. Durante la generación de un solo token, no siempre mantiene ambas GPU completamente ocupadas. tensor se parece más a hacer que ambas tarjetas trabajen juntas en la misma capa. Tiene más paralelismo teórico, pero la comunicación entre GPU puede convertirse en el cuello de botella.

Si una GPU de 32GB puede cargar el modelo, dos de 16GB no siempre son más rápidas

Si el modelo y la KV cache caben completos en una GPU de 32GB, una sola tarjeta suele ser más estable y a menudo más rápida. En hardware de la misma generación, como 1x V100 32GB frente a 2x V100 16GB, la configuración de dos tarjetas no tiene por qué ganar.

Una expectativa conservadora es que 2x V100 16GB pueda ser entre un 10% y un 40% más lenta que una sola V100 32GB, sobre todo en chat de un solo usuario, Continue Agent y preguntas de código, donde una petición suele generar una sola respuesta.

La razón es sencilla: multi-GPU no convierte la VRAM en un único gran bloque rápido. Con división por capas, la inferencia pasa entre GPU y una tarjeta puede esperar a la otra durante la generación. Con división por tensores, ambas tarjetas pueden calcular juntas, pero los resultados intermedios necesitan sincronización entre GPU, y el ancho de banda y la latencia afectan directamente el throughput.

Así que si tus opciones son:

1x V100 32GB
2x V100 16GB

y el modelo objetivo ya cabe completo en una sola tarjeta de 32GB, la GPU única de 32GB suele ser la opción más cómoda.

Si una GPU de 16GB no puede cargar el modelo, dos tarjetas sí aportan mucho

La situación cambia por completo cuando el modelo no cabe en una GPU de 16GB, pero sí cabe repartido entre dos tarjetas de 16GB.

En ese caso, el valor de dos GPU es directo:

Una tarjeta de 16GB: puede requerir mucho CPU offload, con una caída clara de velocidad.
2x 16GB: los pesos pueden quedarse en gran parte en GPU, lo que puede ser mucho más rápido que una ejecución mixta CPU/GPU.

En este escenario, 2x V100 16GB no garantiza superar a una sola tarjeta de 32GB, pero puede ser varias veces más rápida que una sola 16GB con mucho offload a memoria del sistema. Es decir, el primer valor de dos tarjetas no es acelerar; es evitar que los pesos del modelo caigan en una RAM del sistema mucho más lenta.

V100 PCIe y V100 SXM2 son muy diferentes

Lo que más se pasa por alto en inferencia multi-GPU es el interconnect.

Si tienes V100 SXM2 con NVLink, el ancho de banda entre GPU es mucho mayor. La documentación de NVIDIA para V100 indica que NVLink puede llegar hasta 300GB/s de ancho de banda de interconexión. En ese entorno, tensor o cargas con batch más alto tienen más posibilidades de acercarse o incluso superar el rendimiento de una sola tarjeta.

Si tienes V100 PCIe, conviene ser mucho más conservador. V100 PCIe usa principalmente PCIe Gen3, y el interconnect bandwidth indicado es 32GB/s. No está en la misma categoría que NVLink, por eso dos tarjetas PCIe a menudo dan VRAM suficiente, pero no duplican la velocidad.

Por eso, para decidir si 2x V100 16GB merece la pena, no basta con sumar VRAM y decir que son 32GB. También hay que comprobar si son tarjetas PCIe o SXM2/NVLink.

Cómo elegir de forma práctica

Si el modelo cabe en una sola GPU de 32GB, prioriza una sola tarjeta. Su latencia, estabilidad y coste de ajuste suelen ser mejores.

Si el modelo no cabe en una GPU de 16GB, pero sí en dos de 16GB, merece la pena usar dos tarjetas. En ese caso, el objetivo es mantener los pesos en GPU tanto como sea posible, no esperar una mejora lineal de rendimiento.

Si tienes dos V100 PCIe, empieza con --split-mode layer y busca ejecución estable con menos caída a CPU.

Si tienes V100 SXM2/NVLink, vale más la pena probar modos relacionados con tensor, especialmente en prefill, batch más grande o servicio concurrente.

Cuándo comprar 2x16GB y cuándo comprar 1x32GB

Si solo atiendes a un usuario y trabajas sobre todo con chat, completado de código, Continue Agent o preguntas con contexto largo, y el modelo objetivo cabe en 32GB, 1x32GB suele ser mejor. Evita la planificación entre GPU, ofrece latencia más estable y simplifica la depuración.

Si ya tienes una tarjeta de 16GB y quieres una forma más barata de ejecutar modelos de 30B, 32B o cuantizaciones más grandes, 2x16GB tiene sentido. No necesariamente duplicará los token/s, pero puede mantener en GPU pesos que de otro modo tendrían que ir a CPU offload.

Si vas a comprar desde cero, puedes priorizar así:

Un solo modelo, un solo usuario, latencia importante: preferir 1x32GB.
El modelo no cabe en una sola tarjeta y el presupuesto es limitado: considerar 2x16GB.
Hay una máquina con NVLink o SXM2: 2x16GB es mucho más interesante que dos tarjetas PCIe comunes.
Quieres usar contextos más largos en el futuro: no mires solo el tamaño de los pesos; reserva VRAM para KV cache.

Consejos prácticos para layer split y tensor split

La regla práctica es: empieza con layer y luego mide tensor.

layer es un buen punto de partida. Divide el modelo por capas, tiene mejor compatibilidad y funciona mejor en sistemas PCIe de dos tarjetas. Su desventaja es que la generación puede comportarse como una tubería: en algunos momentos una tarjeta está ocupada mientras la otra espera.

tensor encaja mejor en máquinas con buena interconexión, como V100 SXM2/NVLink. Divide parte del cálculo de una misma capa entre varias GPU, así que tiene más paralelismo teórico, pero también sincroniza más a menudo entre tarjetas. En dos GPU PCIe, el coste de comunicación puede comerse la ganancia.

Puedes empezar con estas pruebas:

1
2
3

llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,1
llama-bench -m model.gguf -ngl 99 --split-mode tensor --tensor-split 1,1
llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,0

El tercer comando no es para uso permanente. Sirve como referencia de una sola tarjeta, para saber si dos GPU realmente son más rápidas o solo están repartiendo la presión de VRAM.

Por qué prefill y decode se comportan distinto

El rendimiento de un LLM local suele dividirse en dos fases:

prefill: procesa el prompt de entrada. Una métrica típica es el throughput de prompt processing, como pp512.
decode: genera la respuesta token por token. Una métrica típica es el throughput de token generation, como tg128.

prefill se parece más a cálculo matricial con batch grande. Con batch más alto es más fácil mantener las GPU ocupadas y obtener beneficio del paralelismo multi-GPU. decode genera un token tras otro. El batch es pequeño y la sincronización es frecuente, así que la comunicación entre tarjetas y la latencia de planificación se notan más.

Por eso puedes ver que dos GPU mejoran pp512, pero tg128 apenas mejora o incluso empeora. Para chat y agentes, la experiencia del usuario se parece más a tg128. Para ingestión de documentos largos, prefill por lotes o servicio concurrente, pp512 también importa.

¿Puede KV cache convertirse en el segundo cuello de botella de VRAM?

Sí. Muchas personas solo calculan los pesos del modelo y olvidan la KV cache.

Los pesos determinan si el modelo puede cargarse. La KV cache determina si puedes usar la longitud de contexto que quieres. Cuanto más largo sea el contexto, mayor la concurrencia y más grande el batch, más visible será el consumo de KV cache. Puede pasar que el modelo base quepa en 32GB, pero al abrir 32K o 64K de contexto vuelva a faltar VRAM.

Como mínimo, deja margen de VRAM para:

KV cache
CUDA graph o sobrecarga del runtime del backend
prompt batch y ubatch
escritorio, driver y otros procesos

Si usas 2x16GB, la VRAM no es un pool único de 32GB completamente equivalente. Algunos buffers, KV cache o tensores intermedios todavía pueden quedar limitados por la memoria restante en una sola tarjeta. Para probar contexto largo, usa directamente el --ctx-size objetivo y la concurrencia objetivo, no solo compruebes si el modelo arranca.

Cómo medir tus dos tarjetas con llama-bench

llama-bench es mejor que chatear directamente para comparar hardware, porque separa prompt processing y token generation en métricas comparables. El ejemplo básico del README oficial es:

`1`	`llama-bench -m model.gguf`

Para dos V100, al menos mide estos grupos:

# Single-card baseline
CUDA_VISIBLE_DEVICES=0 llama-bench -m model.gguf -ngl 99

# Dual-card layer split
CUDA_VISIBLE_DEVICES=0,1 llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,1

# Dual-card tensor split
CUDA_VISIBLE_DEVICES=0,1 llama-bench -m model.gguf -ngl 99 --split-mode tensor --tensor-split 1,1

Fíjate sobre todo en dos columnas:

pp512: prompt processing, más relevante para entradas largas y prefill por lotes.
tg128: token generation, más relevante para chat de un solo usuario y respuesta de agentes.

Mantén fijos el modelo, la cuantización, el contexto, batch, versión del driver y versión de llama.cpp. Ejecuta cada grupo varias veces y compara medianas, no un único resultado. Por último, prueba también tu flujo real, como Continue Agent, un OpenAI-compatible server o tus propias peticiones RAG, porque un benchmark bonito no siempre significa una mejor experiencia interactiva.

Conclusión en una frase

La ventaja principal de 2x V100 16GB es la capacidad de VRAM, no una velocidad de generación garantizada. Si el modelo cabe en una sola tarjeta, una GPU de 32GB suele ser más rápida y estable. Si el modelo no cabe en una sola 16GB, dos tarjetas de 16GB valen mucho porque evitan gran parte del CPU offload. Que sean más rápidas o no depende del split mode, batch, tamaño del modelo y de si las dos V100 están conectadas por PCIe o NVLink.

Referencias:

Benchmarks de inferencia AI en RTX 5090 / 5080: como elegir para LLM locales, video 4K y 3D en tiempo real

Fri, 08 May 2026 10:07:19 +0800

Para los usuarios de AI local, la serie RTX 50 no llama la atencion solo por los FPS en juegos. Blackwell, la memoria GDDR7 y los Tensor Cores de quinta generacion cambian lo que puede hacer una estacion de trabajo AI de escritorio. Si ejecutas LLM locales, generacion de imagen, mejora de video o 3D en tiempo real, la GPU ya no es solo un dispositivo de render.

RTX 5090 y RTX 5080 no se deben comparar solo por el nombre. Ambas usan Blackwell y soportan DLSS 4, Tensor Cores de quinta generacion y FP4, pero la experiencia real en AI local depende de la VRAM, el ancho de banda, el soporte de software y la compatibilidad con cada modelo.

La conclusion corta: RTX 5090 es la opcion insignia para AI local con una sola tarjeta, modelos grandes, contexto largo, imagen y video AI. RTX 5080 encaja mejor en presupuestos mas ajustados, modelos mas pequenos y flujos que caben en 16GB de VRAM. Ambas mejoran frente a la generacion anterior, pero no todas las aplicaciones AI aprovechan Blackwell desde el primer dia.

Primero mira la diferencia de hardware

RTX 5090 incluye 32GB GDDR7, bus de memoria de 512-bit, 21760 CUDA Core y 3352 AI TOPS. En pruebas publicas, Puget Systems tambien destaca un ancho de banda de unos 1.79TB/s, frente a los 24GB y unos 1.01TB/s de RTX 4090. Para cargas AI, esa diferencia importa.

RTX 5080 es mas contenida: 16GB GDDR7, bus de 256-bit, 10752 CUDA Core y 1801 AI TOPS. Su ancho de banda ronda los 960GB/s, una mejora clara frente a RTX 4080, pero la VRAM sigue en 16GB.

Eso deja roles bastante claros:

RTX 5090 destaca por 32GB de VRAM y alto ancho de banda, utiles para modelos mayores, contexto mas largo y tareas multimodales pesadas.
RTX 5080 controla mejor coste y consumo, y sirve para modelos pequenos o medianos, generacion de imagen, video ligero y desarrollo.
Si una tarea ya esta limitada por VRAM, la potencia de calculo de RTX 5080 no compensa facilmente el limite de 16GB.
Si la tarea esta limitada por optimizacion de software, RTX 5090 no siempre se separara de RTX 4090 segun sus especificaciones teoricas.

En inferencia AI local, la regla suele ser simple: la VRAM decide si algo corre, el ancho de banda decide que tan rapido se siente. Por eso RTX 5090 resulta mas atractiva para LLM locales.

LLM locales: 32GB pesan mas

Al correr LLM, la VRAM se usa sobre todo para pesos del modelo, KV cache y sobrecarga de ejecucion. Cuanto mayor el modelo, mas largo el contexto y mayor la concurrencia, mas presion aparece.

Los 16GB de RTX 5080 cubren muchos modelos 7B, 8B y 14B, y permiten probar algunos modelos mayores con cuantizacion 4-bit. Pero si quieres modelos de clase 30B, contexto mas largo, o WebUI, RAG, voz y llamadas a herramientas al mismo tiempo, 16GB se vuelven un cuello de botella rapidamente.

RTX 5090 con 32GB da mas margen para inferencia local. Encaja mejor para:

Ejecutar modelos cuantizados alrededor de 30B.
Mantener mas contexto en modelos 7B y 14B.
Usar asistentes locales de codigo, Q&A con base de conocimiento y depuracion de Agents.
Cargar embeddings, rerankers o componentes multimodales junto al modelo principal.
Reducir cambios de modelo y recortes de contexto en una sola maquina.

Aun asi, 32GB no son magia. Los modelos 70B, incluso en 4-bit, suelen exigir cuidado con contexto, parametros de ejecucion y fragmentacion de memoria. Para servicio con alta concurrencia, siguen teniendo mas sentido varias GPU o GPU de servidor.

En uso personal, la ventaja de RTX 5090 es sobre todo menor friccion: mas modelos posibles, contexto mas comodo y espacio para interfaces graficas y herramientas auxiliares.

FP4 es potencial, no aceleracion instantanea en todo

Un cambio importante de Blackwell es el soporte FP4 en los Tensor Cores de quinta generacion. NVIDIA explica en material de TensorRT que FP4 puede reducir memoria y movimiento de datos, y ayudar en inferencia local de modelos generativos como FLUX.

Esto importa para imagen y para futuros LLM. Menor precision implica menos VRAM y menos presion sobre el ancho de banda. En una GPU de mucho ancho de banda como RTX 5090, FP4 puede amplificar la ventaja si modelos y frameworks lo soportan bien.

Pero el beneficio depende del software:

Si existe una version cuantizada FP4 adecuada del modelo.
Si el framework de inferencia soporta los operadores necesarios.
Si TensorRT, ComfyUI, PyTorch, ONNX o plugins ya estan adaptados.
Si la perdida de precision es aceptable para la tarea.
Si el usuario acepta ajustar el flujo de trabajo para ganar rendimiento.

Por eso no conviene juzgar la AI de RTX 50 solo por picos FP4. Blackwell da la base de hardware, pero la experiencia real depende de las aplicaciones. Los usuarios tempranos veran algunos beneficios antes; el usuario comun tendra que esperar a que madure el ecosistema.

Imagen y video 4K: ancho de banda y VRAM van juntos

Stable Diffusion, FLUX, superresolucion de video, interpolacion, denoise, matting y video generativo son sensibles a VRAM. A mayor resolucion, mas memoria; a mas nodos, mas sobrecarga; ControlNet, LoRA, high-res fix y batch aumentan la presion.

RTX 5080 puede completar muchas tareas de imagen dentro de 16GB. Para imagenes de 1024px, LoRA ligeros y flujos ComfyUI normales, ya es suficientemente rapida. Los problemas llegan con lienzos mayores, nodos mas complejos, batch mas alto o video generativo de secuencias largas.

RTX 5090 muestra mas ventaja en flujos de video 4K:

32GB de VRAM sirven mejor para frames de alta resolucion, secuencias largas y graficos de nodos complejos.
Un ancho de banda de unos 1.79TB/s ayuda a reducir cuellos de botella de movimiento de datos.
Tres codificadores NVENC de novena generacion ayudan en exportacion, transcodificacion y creacion.
Cuando FP4 y TensorRT maduren, los modelos de imagen podrian mejorar mas.

Las pruebas publicas de video AI tambien traen una advertencia: la optimizacion de aplicaciones aun no alcanzo al hardware. Puget Systems encontro que RTX 5090 no siempre supera por mucho a RTX 4090 en DaVinci Resolve AI y Topaz Video AI, y RTX 5080 tampoco siempre se separa mucho de RTX 4080. En video AI importan plugins, drivers e implementaciones, no solo especificaciones.

Si tu flujo ya soporta Blackwell, TensorRT o FP4, RTX 50 es mas prometedora. Si dependes de software comercial aun no optimizado, el beneficio depende de la version concreta.

3D en tiempo real y modelado AI: RTX 5090 para escenas pesadas

El modelado 3D en tiempo real, render neural, generacion de activos 3D y aceleracion AI del viewport suelen usar CUDA, RT Core, Tensor Core y VRAM a la vez. No se trata solo de tokens por segundo: tambien cuentan complejidad de escena, materiales, geometria, ray tracing, denoise AI y FPS del viewport.

RTX 5080 puede cubrir muchos juegos 4K, previsualizacion en tiempo real y proyectos creativos medianos. Para creadores independientes es una opcion potente y realista.

RTX 5090 encaja mejor en:

Previsualizacion de escenas 3D complejas.
Materiales de alta resolucion y grandes bibliotecas de activos.
Denoise AI, upscaling y ayuda generativa de modelado al mismo tiempo.
Cargas pesadas en D5 Render, Blender, Unreal Engine y herramientas similares.
Modelar mientras corre un asistente AI local o un generador de referencias.

NVIDIA afirma que RTX 50 mejora AI generativa, edicion de video y render 3D en apps creativas, pero en produccion todo depende de si el software usa las nuevas rutas de hardware. Lo mas fiable sigue siendo probar con tus propios proyectos.

Como elegir

Si tu objetivo son LLM locales, mira primero la VRAM. RTX 5080 de 16GB corre muchos modelos ligeros, pero es mas una tarjeta local AI de entrada alta. RTX 5090 con 32GB se acerca mas a una estacion de trabajo LLM local de una sola GPU.

Si tu objetivo es imagen, RTX 5080 cubre muchos flujos diarios. Si usas alta resolucion, muchos nodos, batch, FLUX o video generativo, la VRAM extra de RTX 5090 importa mas.

Si tu objetivo es video AI 4K, RTX 5090 es mas segura, pero hay que confirmar software. Topaz, DaVinci Resolve, ComfyUI, plugins TensorRT y drivers pueden cambiar el resultado.

Si tu objetivo es 3D en tiempo real, RTX 5080 satisface muchas necesidades creativas; RTX 5090 es mejor para escenas pesadas, varias aplicaciones en paralelo y sesiones largas.

Si ya tienes RTX 4090, actualiza con cuidado. RTX 5090 tiene mas VRAM y ancho de banda, pero parte del software AI aun no libera todo Blackwell. Si no necesitas claramente 32GB, mas ancho de banda o los nuevos codificadores, puede valer la pena esperar.

Si vienes de RTX 30 o anterior, el salto a RTX 50 sera mucho mas visible. Pasar de 8GB, 10GB o 12GB a 16GB o 32GB amplia directamente lo que puedes correr localmente.

Resumen

RTX 5090 y RTX 5080 llevan las GPU de consumo mas lejos en AI local, pero no son para el mismo usuario.

RTX 5090 aporta 32GB GDDR7, ancho de banda muy alto y una configuracion creativa mas completa. Sirve para modelos locales mayores, imagen mas compleja, video AI pesado y 3D en tiempo real en una sola maquina.

RTX 5080 permite entrar en Blackwell con menor coste. Sirve para modelos pequenos y medianos que caben en 16GB, imagen diaria, pruebas de desarrollo y creacion de alto rendimiento.

La regla de compra es simple: primero comprueba si tus modelos y proyectos caben en VRAM, luego si tu software ya esta optimizado para Blackwell, y solo al final mira los AI TOPS teoricos. En AI local, terminar de forma estable vale mas que el numero pico.

Referencias

Despliegue privado local de DeepSeek V4: elegir entre chips nacionales y clusters de GPU de consumo

Fri, 08 May 2026 09:39:35 +0800

Tras el lanzamiento de DeepSeek V4, muchas empresas empezaron a hacerse una pregunta: ¿se puede evitar una API externa y desplegar el modelo en un centro de datos propio, una nube privada o un cluster dedicado?

La necesidad es muy real. Finanzas, sanidad, gobierno, fabricacion, legal y equipos de I+D a menudo no pueden enviar documentos internos, codigo, contratos, tickets o datos de clientes directamente a modelos de nube publica. En estos escenarios, el atractivo de DeepSeek V4 no esta solo en la capacidad del modelo, sino en que ofrece a las empresas una opcion mas cercana a una infraestructura LLM controlable.

Sin embargo, desplegar DeepSeek V4 localmente no es tan simple como descargar el modelo y buscar unas cuantas GPU. Especialmente en modelos MoE muy grandes como Pro, el numero total de parametros, parametros activos, longitud de contexto, KV cache, concurrencia y framework de inferencia determinan directamente el coste de hardware. Lo que una empresa debe hacer no es perseguir a ciegas la version completa, sino confirmar primero que forma de despliegue necesita el negocio.

Aclarar primero el objetivo del despliegue

El despliegue privado local en empresas suele tener tres objetivos:

Que los datos no salgan del dominio: documentos internos, codigo, materiales de clientes, logs y bases de conocimiento no abandonan el entorno empresarial.
Estabilidad y control: servicios de modelo, permisos, auditoria, logs y ritmo de actualizaciones quedan bajo control de la empresa.
Reducir coste a largo plazo: con llamadas frecuentes, la inferencia local puede ser mas controlable que comprar API externas durante mucho tiempo.

Si solo unos pocos empleados preguntan de vez en cuando, el despliegue local no siempre compensa. La privatizacion encaja mejor con escenarios frecuentes, estables, sensibles en datos y con flujos claros, por ejemplo:

Preguntas sobre una base de conocimiento interna.
Revision de codigo y asistentes de desarrollo.
Resumen de tickets de atencion al cliente.
Analisis de contratos, historias clinicas e informes.
Asistentes para consultas de bases de datos.
Automatizacion de flujos con Agent.

Estos escenarios comparten rasgos: datos sensibles, llamadas estables y posibilidad de incorporarse a la gobernanza empresarial mediante permisos y logs.

No perseguir Pro completo desde el primer dia

Las versiones comunes de DeepSeek V4 incluyen Pro y Flash. Segun materiales publicos, Pro se orienta a razonamiento mas fuerte y tareas Agent complejas, mientras Flash enfatiza coste y velocidad de respuesta. Al elegir, una empresa no deberia asumir que todo el negocio necesita Pro.

Puedes dividir por complejidad de tarea:

Preguntas simples, resumen, clasificacion y generacion de etiquetas: priorizar Flash o modelos mas pequenos.
RAG para bases de conocimiento internas: Flash cubre muchos escenarios; RAG, permisos y calidad de recuperacion importan mas.
Code Agents, razonamiento complejo y analisis de contexto largo: entonces evaluar Pro.
Tareas de alto valor y baja frecuencia: se puede usar Pro, pero no necesariamente con alta concurrencia.
Asistentes de oficina comunes: no hace falta ocupar durante mucho tiempo los recursos de inferencia mas caros.

La ventaja de los modelos MoE es que cada inferencia solo activa una parte de los parametros, pero eso no significa que la presion de hardware sea pequena. Almacenamiento de pesos, paralelismo de expertos, comunicacion de red, cache de contexto y planificacion concurrente siguen siendo pesados. Especialmente con contexto de nivel 1M token, lo que consume recursos no suele ser una respuesta aislada, sino el contexto largo, la concurrencia multiusuario y las sesiones persistentes.

Ruta de chips nacionales: adecuada para nube privada empresarial

Si una empresa ya tiene un pool de computo nacional, o requisitos de Xinchuang, cumplimiento o control de cadena de suministro, puede evaluar primero chips nacionales como Ascend y Cambricon.

Las ventajas de esta ruta son:

Encaja mejor con requisitos de localizacion y control de cadena de suministro.
Es adecuada para centros de datos empresariales, nubes dedicadas y proyectos de gobierno/empresa.
Facilita unificar permisos, auditoria, aislamiento de recursos y operaciones.
Es mas amable para servicios estables a largo plazo.

Pero la ruta de chips nacionales tambien requiere mirar tres problemas reales.

Primero, adaptacion del framework. Que el modelo pueda ejecutarse no depende solo de la potencia del chip, sino de si el framework de inferencia, operadores, bibliotecas de comunicacion, formatos de cuantizacion, paralelismo de expertos MoE y optimizacion de contexto largo estan maduros.

Segundo, experiencia de ingenieria. La empresa necesita mas que “arranco correctamente”; necesita servicio estable: multiinquilino, limitacion de tasa, monitorizacion, recuperacion ante fallos, despliegues grises, auditoria de logs y aislamiento de permisos.

Tercero, diferencias de ecosistema. El mismo modelo no tendra exactamente el mismo rendimiento, precision, soporte de cuantizacion y herramientas de despliegue en NVIDIA, Ascend, Cambricon u otras plataformas. Antes de producción hay que hacer pruebas de carga reales, no mirar solo la potencia nominal.

Por tanto, los chips nacionales encajan mejor con empresas de presupuesto claro, requisitos altos de cumplimiento y voluntad de invertir en ingenieria de plataforma. No es la ruta mas facil, pero puede ser la que mejor encaje con la gobernanza a largo plazo.

Clusters de GPU de consumo: adecuados para pilotos y equipos pequenos

Si el objetivo es validar primero el valor de negocio, un cluster de GPU de consumo es mas facil para empezar. GPU como RTX 4090, RTX 5090, RTX 3090 y RTX 3060 12GB tienen mas herramientas comunitarias, modelos cuantizados y referencias de inferencia local, por lo que el coste de prueba y error es menor.

La ruta de GPU de consumo encaja con:

Pilotos internos de equipos de I+D.
Preguntas sobre bases de conocimiento en pymes.
Asistentes de codigo de baja concurrencia.
Procesamiento offline de documentos.
Herramientas internas sin requisitos estrictos de SLA.

Pero tambien tiene limites claros:

La VRAM es pequena y cuesta alojar directamente un modelo grande completo.
La comunicacion multi-GPU es debil, y la comunicacion entre maquinas es mas complicada.
La estabilidad a plena carga durante largo tiempo es peor que en soluciones de servidor.
Chasis, alimentacion, refrigeracion, drivers y operaciones se convierten en costes ocultos.
No conviene prometer alta disponibilidad empresarial desde el principio.

Un enfoque mas realista es ejecutar primero Flash, versiones destiladas, versiones cuantizadas o modelos pequenos en GPU de consumo, hacer funcionar el flujo de negocio y decidir despues si migrar a GPU de servidor o a una plataforma de computo nacional tras validar volumen de llamadas, efecto y gobernanza de datos.

Posible arquitectura de despliegue

Una arquitectura privada empresarial relativamente estable puede dividirse en seis capas:

Capa de modelo: DeepSeek V4 Pro, V4 Flash o modelos destilados mas pequenos segun la tarea.
Capa de inferencia: SGLang, vLLM, llama.cpp, stacks de inferencia NPU de fabricantes o servicios propios.
Capa de gateway: autenticacion unificada, limitacion de tasa, auditoria, enrutamiento de modelos y logs de llamadas.
Capa de conocimiento: base vectorial, busqueda de texto completo, analisis de documentos, filtrado por permisos y RAG.
Capa de aplicacion: atencion al cliente, asistentes de codigo, analisis de documentos, preguntas sobre informes y flujos Agent.
Capa de operaciones: monitorizacion, alertas, estadisticas de coste, despliegues grises, rollback y auditoria de seguridad.

Las capas que mas se subestiman son el gateway y la capa de conocimiento. Muchos proyectos fallan no porque el modelo sea inutilizable, sino porque permisos, recuperacion, logs, gestion de contexto, plantillas de prompt y flujos de negocio no estan bien hechos.

Al desplegar LLM dentro de una empresa, el modelo debe tratarse como una capacidad de infraestructura, no como una pagina de chat aislada. El valor real aparece cuando el modelo entra en los flujos y puede procesar de forma estable los datos y tareas propios de la empresa.

Criterios para elegir hardware

El hardware no debe evaluarse solo por “si puede correr”, sino tambien por “si puede prestar servicio de forma estable”.

Puedes elegir por etapas:

Etapa de validacion

El objetivo es demostrar si merece la pena hacer el negocio.

Usar 1-4 GPU de consumo.
Priorizar Flash, modelos pequenos, modelos destilados o modelos cuantizados.
Mantener baja la concurrencia y centrarse en la tasa de finalizacion de tareas.
No prometer alta disponibilidad.

En esta etapa no conviene comprar hardware a gran escala demasiado pronto. Primero confirma si los empleados realmente lo usan, si el negocio ahorra tiempo y si las respuestas pueden entrar en el flujo.

Etapa piloto

El objetivo es que un departamento o una linea de negocio lo use de forma estable.

Usar 4-16 GPU o un conjunto de nodos NPU nacionales.
Agregar gateway unificado, logs y control de permisos.
Construir RAG, analisis de documentos, enrutamiento de modelos y cache.
Empezar a medir tokens, concurrencia, latencia y tasa de fallos.

En esta etapa hay que empezar a cuidar operaciones. El efecto del modelo es solo una parte; estabilidad, coste y gobernanza de datos son igual de importantes.

Etapa de produccion

El objetivo es entrar en servicio empresarial.

Usar GPU de servidor, clusters de computo nacional o pools de recursos de nube privada.
Establecer multiples replicas, limitacion de tasa, failover y planificacion de capacidad.
Enrutar modelos por tarea: tareas simples a modelos ligeros, tareas complejas a Pro.
Conectar con sistemas de identidad, auditoria y politicas de seguridad de la empresa.

En produccion no se recomienda enviar todas las solicitudes al modelo mas fuerte. Un enrutamiento razonable suele ahorrar mas dinero que acumular hardware.

Como elegir framework de inferencia

Modelos como DeepSeek V4 exigen mucho al framework de inferencia. Cuando intervienen MoE, contexto largo, atencion dispersa, cuantizacion y paralelismo multi-GPU, la madurez del framework afecta directamente velocidad y estabilidad.

Las opciones comunes pueden entenderse asi:

SGLang: adecuado para equipos que buscan inferencia de alto rendimiento, Agent, llamadas multi-turno a herramientas y orquestacion de servicios complejos.
vLLM: ecosistema maduro, adecuado para servicios LLM generales, pero el soporte concreto depende de la version y del progreso de adaptacion del modelo.
llama.cpp: mas adecuado para modelos pequenos, modelos cuantizados y despliegue en edge; no para alojar directamente un MoE enorme completo.
Stacks de inferencia NPU nacionales: adecuados para Xinchuang y entornos de computo nacional, pero hay que verificar operadores, cuantizacion y contexto largo.

No elijas framework solo por benchmark. Una empresa deberia probar sus entradas reales: longitud de documentos internos, concurrencia, longitud media de salida, tasa de acierto de RAG, numero de llamadas a herramientas de Agent y reintentos tras fallos.

La seguridad de datos debe hacerse fuera del modelo

El despliegue privado no significa seguridad automatica. Ejecutar el modelo localmente solo resuelve una parte de si los datos salen de la empresa.

Tambien hay que completar:

Cuentas y permisos: cada departamento solo puede acceder a su propia base de conocimiento.
Auditoria de logs: quien pregunto que, que modelo se llamo y que documentos se consultaron.
Enmascaramiento de datos: informacion de clientes, numeros de documento, telefonos, importes de contrato y otros campos sensibles deben tratarse.
Seguridad de prompts: evitar que usuarios eludan permisos o filtren prompts de sistema mediante prompts.
Revision de salidas: en escenarios importantes debe haber revision humana o por reglas.
Ciclo de vida de datos: documentos subidos, indices vectoriales, cache y registros de sesion deben poder eliminarse.

Para construir LLM locales, la empresa no puede involucrar solo al equipo de algoritmos. Seguridad, legal, operaciones y responsables de negocio tambien deben participar; si no, los riesgos se concentraran tras el lanzamiento.

El coste no son solo las GPU

El coste del despliegue local suele subestimarse. Ademas de GPU o NPU, hay que contar:

Servidores, racks, alimentacion, refrigeracion y red.
Almacenamiento y copias.
Adaptacion de framework de inferencia y desarrollo de ingenieria.
Monitorizacion operativa y gestion de incidentes.
Actualizacion de modelos, rollback y pruebas de compatibilidad.
Auditoria de seguridad y sistemas de permisos.
Prompts, RAG y flujos de trabajo del lado del negocio.

Si el volumen de llamadas es bajo, una API externa puede ser mas barata. Si el volumen es alto, los datos son sensibles y el flujo es estable, el despliegue local amortiza mejor el coste.

Una estrategia mas razonable es el despliegue hibrido:

Datos muy sensibles usan modelos locales.
Tareas generales de baja sensibilidad pueden usar API externas.
Tareas simples usan modelos pequenos.
Tareas complejas usan DeepSeek V4 Pro.
Tareas frecuentes priorizan optimizar cache, recuperacion y enrutamiento de modelos.

Ruta recomendada de implantacion

Una empresa puede avanzar en este orden:

Elegir primero 2-3 escenarios de alto valor, sin desplegar en toda la empresa.
Usar GPU de consumo o computo a pequena escala para un PoC.
Ejecutar primero Flash, modelos destilados o modelos cuantizados, conectando RAG y permisos.
Introducir Pro para comparar en tareas complejas.
Registrar volumen real de llamadas, latencia, tasa de fallos y tiempo humano ahorrado.
Despues decidir si comprar clusters de chips nacionales o GPU de servidor.
Antes de produccion, completar gateway, auditoria, monitorizacion, limitacion de tasa y rollback.

Esta ruta es mas estable que comprar un gran cluster desde el principio. El mayor riesgo para una empresa no es que el modelo no sea lo bastante fuerte, sino gastar mucho dinero y descubrir despues que el flujo de negocio no puede absorber esa capacidad.

Resumen

DeepSeek V4 abre mas imaginacion para el despliegue privado local en empresas, pero no es simplemente un “ChatGPT local”. La dificultad real esta en la ingenieria: hardware, frameworks, enrutamiento de modelos, permisos, RAG, auditoria, monitorizacion y control de costes deben considerarse juntos.

La ruta de chips nacionales encaja mejor con empresas de alto cumplimiento y planes de nube privada a largo plazo. Los clusters de GPU de consumo encajan mejor con pilotos y validacion rapida en equipos pequenos y medianos. Pro sirve para razonamiento complejo y Agent; Flash o modelos pequenos son mejores para muchas tareas comunes.

Si solo recuerdas una frase: el despliegue privado de DeepSeek V4 no debe empezar por comprar hardware, sino por escenarios de negocio, limites de datos y volumen de llamadas. Primero haz funcionar el escenario; despues decide si usar un modelo grande, que tamano debe tener y sobre que computo desplegarlo.

Referencias

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

Hermes + Qwen3.6: una solucion barata para desplegar un Agent local

Mon, 04 May 2026 06:40:30 +0800

La idea es ejecutar el modelo Qwen3.6 GGUF con llama.cpp dentro de WSL2 y conectar Hermes Agent a una API local compatible con OpenAI. Asi puedes tener un asistente de IA local siempre disponible en tu propio ordenador, sin depender de cuotas de tokens de servicios online.

Esta solucion encaja con usuarios que quieren probar un AI Agent local y, al mismo tiempo, conservar privacidad de datos y control a largo plazo. Puede servir para preguntas diarias, escritura, ayuda con codigo, organizacion de informacion y automatizacion simple. Hay que tener en cuenta que cuanto mayor sea el modelo, mas VRAM necesitara; el ejemplo original usa Qwen3.6-27B y va mas estable con 24GB de VRAM. Si tienes menos VRAM, conviene elegir un modelo mas pequeno o una cuantizacion mas baja.

Estructura de la solucion

La cadena completa es sencilla:

Instalar WSL2 y Ubuntu 24.04 en Windows.
Instalar CUDA Toolkit y compilar llama.cpp dentro de WSL2.
Descargar el modelo Qwen3.6 GGUF.
Iniciar el servicio local con llama-server.
Instalar Hermes Agent y configurarlo hacia http://localhost:8080/v1.
Opcional: escribir un script de inicio para arrancar el servicio del modelo al abrir WSL2.

Hermes aporta la capacidad de Agent, y Qwen3.6 aporta el LLM local. Combinados, convierten el ordenador en un asistente de IA local y privado.

Instalar WSL2 y Ubuntu

En una ventana de Windows PowerShell como administrador:

1
2

wsl --install
wsl --set-default-version 2

Despues de reiniciar, instala Ubuntu 24.04:

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

Al terminar, Ubuntu pedira usuario y contrasena. Ya dentro de Ubuntu, comprueba primero si la GPU NVIDIA se reconoce correctamente en WSL2:

`1`	`nvidia-smi`

Si no se reconoce la GPU, normalmente hay que actualizar primero el driver NVIDIA en Windows. WSL2 hereda el driver de Windows, pero CUDA Toolkit debe instalarse por separado dentro de WSL2.

Instalar Python y herramientas basicas

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

Tambien hacen falta herramientas de compilacion, Git y CMake:

`1`	`sudo apt install -y cmake build-essential git`

Compilar llama.cpp

Clona primero el codigo:

1
2

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

Si WSL2 ya tiene un entorno CUDA utilizable, compila directamente:

1
2

cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

CMAKE_CUDA_ARCHITECTURES=89 es adecuado para GPU Ada, por ejemplo la serie RTX 40. En otras tarjetas debes ajustarlo segun la arquitectura real.

Si al compilar aparece que falta CUDA Toolkit, instalalo primero dentro de WSL2:

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-8

Despues configura variables de entorno:

export PATH=/usr/local/cuda-12.8/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH
echo 'export PATH=/usr/local/cuda-12.8/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc

Y compila de nuevo:

cd ~/llama.cpp
rm -rf build
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

Descargar el modelo Qwen3.6 GGUF

El ejemplo original usa Qwen3.6-27B-UD-Q4_K_XL.gguf de unsloth/Qwen3.6-27B-GGUF:

1
2
3

hf download unsloth/Qwen3.6-27B-GGUF \
Qwen3.6-27B-UD-Q4_K_XL.gguf \
--local-dir ~/models/

El archivo ronda los 17GB. Si Hugging Face descarga lento, puedes cambiar a espejos como ModelScope. Si no tienes suficiente VRAM, no fuerces 27B; usa un modelo mas pequeno o una cuantizacion mas baja.

Iniciar el servicio local del modelo

Arranca llama-server segun el nombre real de tu archivo de modelo:

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080

Tras iniciar correctamente, abre en el navegador de Windows:

`1`	`http://localhost:8080`

Para que Hermes Agent u otros clientes compatibles con OpenAI lo llamen, la direccion de API suele ser:

`1`	`http://localhost:8080/v1`

Elegir Thinking mode

Qwen3.6 puede activar Thinking mode por defecto. Es util para razonamiento complejo, problemas de codigo complicados y analisis de varios pasos, pero sera mas lento.

Si quieres desactivarlo, detén el servicio y agrega --chat-template-kwargs:

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--chat-template-kwargs '{"enable_thinking":false}' \
--port 8080

Sin Thinking, las preguntas simples, escritura, autocompletado de codigo y explicacion de codigo iran mas rapido; para algoritmos complejos, Debug dificil y analisis de arquitectura, sigue siendo recomendable activarlo.

Instalar Hermes Agent

Mantén llama-server en ejecucion y abre otra terminal WSL2 para instalar Hermes Agent:

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

El script instala dependencias como Python, Node.js, ripgrep y ffmpeg. Al configurar el endpoint del modelo, elige endpoint personalizado:

1
2
3

URL: http://localhost:8080/v1
API Key: 12345678
Model: autodetect

Para el llama-server local, la API Key puede ser cualquier valor de relleno. Tras configurarlo, puedes conectar Telegram, WeChat, QQ, Discord y otros canales para que Hermes Agent use el modelo local y ejecute tareas.

Arrancar automaticamente el servicio del modelo

Puedes escribir un script para iniciar el servicio al abrir la terminal WSL2.

Crea el script:

cat > ~/start-llm.sh << 'EOF'
#!/bin/bash
echo "Starting Qwen3.6-27B llama-server..."
~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 65536 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080 \
--host 0.0.0.0 &
echo "llama-server started, PID: $!"
echo "API: http://localhost:8080/v1"
echo "Chat UI: http://localhost:8080"
EOF
chmod +x ~/start-llm.sh

Escribe en .bashrc:

echo '# Auto-start llama-server' >> ~/.bashrc
echo 'if ! pgrep -f "llama-server" > /dev/null 2>&1; then' >> ~/.bashrc
echo '    ~/start-llm.sh' >> ~/.bashrc
echo 'fi' >> ~/.bashrc

Asi, cada vez que abras WSL2, si llama-server no esta en ejecucion se iniciara automaticamente; si ya esta corriendo, se omitira para evitar duplicados.

Notas

El modelo 27B exige bastante VRAM; 24GB va mas estable. Con menos VRAM, usa un modelo mas pequeno.
--ctx-size 65536 aumenta mucho la presion de VRAM y RAM. Si no es estable, baja primero a 32768 o menos.
CUDA Toolkit dentro de WSL2 y el driver de Windows deben estar correctos; si falta uno, la compilacion o ejecucion CUDA puede fallar.
Cuando Hermes Agent se conecta al servicio local, en esencia llama a una API compatible con OpenAI. Lo clave es que http://localhost:8080/v1 responda bien.
Si quieres acceder desde el telefono u otros dispositivos, debes configurar firewall de Windows, direccion LAN y aislamiento de seguridad. No expongas el servicio local directamente a Internet.

Enlaces relacionados

Original: Hermes + Qwen3.6：本地最强 Agent 组合！零成本、无限 Token，太香了！
llama.cpp: ggerganov/llama.cpp
Hermes Agent: NousResearch/hermes-agent
Ejemplo Qwen3.6 GGUF: unsloth/Qwen3.6-27B-GGUF

free-claude-code: conectar Claude Code a OpenRouter, DeepSeek y modelos locales mediante un proxy

Fri, 01 May 2026 03:41:49 +0800

free-claude-code es un Anthropic-compatible proxy para usar con Claude Code.

La idea no es crackear Claude Code ni ofrecer un servicio Claude oficial gratuito, sino iniciar localmente un proxy compatible con la forma de la API de Anthropic y reenviar las solicitudes de Claude Code a otros backends de modelos. El README menciona backends como NVIDIA NIM, OpenRouter, DeepSeek, LM Studio, llama.cpp y Ollama.

En pocas palabras, resuelve este problema: te gusta la experiencia de Claude Code en la terminal, pero quieres conectar las peticiones del modelo a otro provider o a un modelo local.

Qué problema resuelve

La experiencia interactiva de Claude Code es muy adecuada para tareas de desarrollo.

Puede leer código en la terminal, modificar archivos, ejecutar comandos y avanzar según el contexto del proyecto. El problema es que muchos usuarios no necesariamente quieren usar siempre el mismo backend de modelo:

Quieren probar distintos modelos en OpenRouter
Quieren usar modelos como DeepSeek para reducir costes
Quieren conectar las peticiones a Ollama local
Quieren ejecutar modelos locales con LM Studio o llama.cpp
Quieren unificar en el entorno de desarrollo una entrada de proxy
Quieren comparar el rendimiento de distintos modelos dentro del flujo de Claude Code

El posicionamiento de free-claude-code es añadir una capa de proxy compatible entre Claude Code y estos servicios de modelos.

Así, Claude Code sigue enviando solicitudes con estilo Anthropic, y el proxy se encarga de adaptarlas a distintos backends.

Funcionamiento

Puede entenderse como tres capas:

El frontend es Claude Code
En medio está el proxy free-claude-code
El backend es OpenRouter, DeepSeek, un modelo local u otro servicio de modelo

Claude Code cree que está accediendo a una API Anthropic-compatible.

El proxy recibe la solicitud, elige el provider objetivo según la configuración, transforma los campos necesarios y devuelve la respuesta a Claude Code.

La ventaja de esta estructura es que no necesitas modificar Claude Code ni exigir que cada servicio de modelo soporte Claude Code de forma nativa. Mientras el proxy pueda alinear la interfaz, puede conectar más modelos al mismo flujo de trabajo.

Backends soportados

Las direcciones listadas en el README incluyen:

NVIDIA NIM
OpenRouter
DeepSeek
LM Studio
llama.cpp
Ollama

Estos backends representan varias formas de uso.

OpenRouter se parece más a una entrada agregadora de modelos, útil para probar distintos modelos comerciales y open source.

DeepSeek conviene a quienes se preocupan por capacidad en chino, capacidad de código y coste.

LM Studio, llama.cpp y Ollama se inclinan hacia la ruta de modelos locales. Sirven para ejecutar modelos en tu propia máquina o en un entorno de intranet, reducir dependencia de APIs externas y facilitar experimentos offline.

NVIDIA NIM está más orientado a inferencia empresarial y despliegue con GPU.

Por qué un Anthropic-compatible proxy

Claude Code está diseñado alrededor de la interfaz y los hábitos de modelo de Anthropic.

Si quieres conectarlo a otros modelos, el problema más directo es que las interfaces no coinciden:

Campos de solicitud distintos
Nombres de modelo distintos
Formatos de streaming distintos
Expresión de tool use distinta
Formatos de error distintos
Límites de tokens y contexto distintos

El valor de la capa proxy está ahí.

Mantiene la interfaz vista por Claude Code con una forma cercana a Anthropic y adapta el backend. Para el usuario, después de configurar el proxy, puede probar distintos modelos dentro del mismo flujo de Claude Code.

Escenarios adecuados

free-claude-code es adecuado para:

Querer usar el flujo de terminal de Claude Code
Probar modelos no Anthropic dentro de Claude Code
Reducir costes de llamadas de modelo
Conectar Claude Code a OpenRouter
Integrar DeepSeek u otros servicios de modelo compatibles
Usar Ollama, LM Studio o llama.cpp para ejecutar modelos locales
Configurar para un equipo una entrada unificada de proxy de modelos

Si solo usas Claude Code oficial normalmente y no tienes necesidades especiales de provider, coste o despliegue local, quizá no necesites este tipo de proxy.

Pero si comparas modelos con frecuencia o quieres que Claude Code acceda a modelos locales y de terceros, este tipo de herramienta es útil.

Diferencia frente a usar directamente OpenRouter u Ollama

Usar directamente OpenRouter, Ollama o LM Studio normalmente significa conversar con el modelo o llamarlo mediante API.

El punto central de free-claude-code no es sustituir esos servicios, sino conectarlos al flujo de desarrollo de Claude Code.

La diferencia está en:

Sigues usando la experiencia de terminal de Claude Code
La IA puede realizar tareas alrededor del repositorio de código
El backend de modelo puede cambiarse por otro provider
Los modelos locales también tienen oportunidad de entrar en el flujo de Claude Code
La configuración se concentra en la capa proxy, no se cambia por separado en cada herramienta

Por eso se parece más a un puente que a un nuevo cliente de chat.

Precauciones con modelos locales

Conectar Claude Code a modelos locales es atractivo, pero también tiene límites prácticos.

Primero, diferencia de capacidad del modelo.

Las tareas de Claude Code no son solo chat; incluyen entender código, planificar cambios, editar archivos y procesar salidas de comandos. Un modelo local pequeño no necesariamente puede completar estas tareas de forma estable.

Segundo, ventana de contexto.

Las tareas de código consumen mucho contexto. Si la ventana del modelo es demasiado pequeña, puede no leer archivos completos, perder restricciones o olvidar contexto durante varias rondas.

Tercero, compatibilidad con tool use.

El flujo de Claude Code depende de llamadas a herramientas y comportamiento estructurado. Aunque un backend pueda chatear, no necesariamente sigue bien protocolos de tool calling.

Cuarto, velocidad y hardware.

La velocidad del modelo local depende de la máquina, el método de cuantización y el tamaño del modelo. Si una tarea de código responde demasiado lento, la experiencia se degrada de forma notable.

Por eso, los modelos locales son más adecuados para experimentos, tareas de bajo riesgo y escenarios concretos. Para tareas de código realmente complejas, todavía hay que elegir con cuidado según la capacidad del modelo.

Límites de uso

Este tipo de proyecto puede malinterpretarse fácilmente por el título, así que conviene aclarar los límites.

Primero, no es cuota gratuita oficial de Claude Code.

Solo reenvía las solicitudes de Claude Code a otros backends de modelos. Al usar OpenRouter, DeepSeek, NVIDIA NIM u otras APIs, sigues teniendo que cumplir precios, cuotas y condiciones de uso de esos servicios.

Segundo, no es una herramienta para saltarse autorización.

Al usar cualquier proxy, hay que cumplir las licencias y términos de Claude Code, del proveedor de modelo y del propio proyecto. No debería entenderse como una forma de evitar restricciones oficiales.

Tercero, el proxy procesará el contenido de tus solicitudes.

Código, salida de comandos y contexto del proyecto pueden pasar por el proxy y por el servicio backend. Al desplegarlo, hay que considerar logs, claves, red y límites de privacidad. Para código de empresa o proyectos sensibles, es mejor usar un entorno controlado.

Cuarto, el rendimiento de distintos modelos puede variar mucho.

La misma operación de Claude Code puede comportarse de forma completamente distinta al cambiar de modelo. No asumas que todos los modelos pueden sustituir a Claude.

Relación con proxies como LiteLLM

Desde el punto de vista de diseño, free-claude-code pertenece a la categoría de “proxies de interfaz compatible”.

El objetivo común de estas herramientas es reducir el acoplamiento entre la aplicación superior y los servicios de modelos inferiores. La aplicación superior solo se enfrenta a una interfaz relativamente unificada, y los providers de abajo pueden cambiarse por configuración.

Cada proyecto tiene un foco distinto. Algunos se orientan a gateway de modelos general, otros a OpenAI-compatible API, y otros se adaptan específicamente a herramientas como Claude Code.

Lo interesante de free-claude-code es que coloca el escenario objetivo directamente en Claude Code, no en un proxy de chat genérico.

Usuarios adecuados

Es más adecuado para usuarios con cierta capacidad de configuración:

Conocen Claude Code
Saben configurar API key y provider de modelos
Entienden cómo arrancar un proxy y variables de entorno
Pueden diagnosticar problemas de red, puertos, nombres de modelo y streaming
Quieren comparar el rendimiento de distintos modelos en tareas de código

Si solo quieres algo listo para usar, la configuración oficial suele ser más tranquila.

Si estás dispuesto a montar proxy, cambiar modelos, ajustar parámetros y quieres llevar Claude Code a más entornos de modelo, este proyecto merece estudio.

Referencia

Alishahryar1/free-claude-code

Una última frase

El valor de free-claude-code no está en la palabra “free”, sino en construir un puente entre Claude Code y más backends de modelos.

Cuando quieres conservar la experiencia de desarrollo de Claude Code y al mismo tiempo probar OpenRouter, DeepSeek, modelos locales o servicios de inferencia empresariales, este tipo de Anthropic-compatible proxy tiene sentido.

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.

Gemma 4 en Raspberry Pi 5: viable, pero con respuestas lentas

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

Un intento un poco extremo: ejecutar Gemma 4 en una Raspberry Pi 5 (8GB RAM). El objetivo no fue una versión grande del modelo, sino el modelo más pequeño E2B.

La conclusión primero: puede ejecutarse y es usable, pero encaja mejor en escenarios con poca interacción. No es ideal para una experiencia conversacional con alta exigencia de tiempo real.

Entorno de prueba

Dispositivo: Raspberry Pi 5 (CPU de 4 núcleos, 8GB RAM)
Sistema: Ubuntu Server (sin interfaz gráfica)
Acceso: SSH
Forma de ejecución del modelo: LM Studio CLI (solo modo línea de comandos)
Modelo: Gemma 4 E2B (aprox. 4.5GB)

Paso 1: instalar e iniciar LM Studio CLI

Instala la versión CLI de LM Studio, inicia el servicio y consulta los comandos disponibles.

Como es un entorno puro de línea de comandos, este método de despliegue solo por CLI encaja muy bien con Raspberry Pi.

Paso 2: mover el almacenamiento de modelos a un SSD

Para evitar lecturas y escrituras frecuentes en la tarjeta SD, moví el directorio de descarga de modelos a un SSD externo.

La experiencia de conectar un SSD a Raspberry Pi 5 es claramente más práctica que en modelos anteriores. Para ejecutar modelos locales durante mucho tiempo, conviene priorizar SSD.

Paso 3: descargar y cargar Gemma 4 E2B

Después de la descarga, el modelo puede cargarse correctamente en memoria.

Según la información oficial, la serie Gemma 4 cuenta con:

Capacidad de tool calling orientada a escenarios Agent (function calling)
Capacidades multimodales (incluyendo imagen/video; los modelos pequeños también tienen capacidades relacionadas con voz)
Ventana de contexto 128K
Licencia Apache 2.0 (usable comercialmente)

Viendo las condiciones de hardware de Raspberry Pi, la variante E2B es la más adecuada para empezar a probar.

Paso 4: iniciar la API y abrir acceso en la red local

Después de cargar el modelo, primero inicié la API en el puerto local (4000) y confirmé mediante una petición HTTP que la lista de modelos podía devolverse.

El problema es que, por defecto, solo escucha en la propia máquina, así que otros dispositivos de la LAN no pueden acceder directamente.

Como los parámetros de inicio no permitían configurar directamente el host, usé socat para hacer reenvío de puerto: las peticiones al puerto externo de la Raspberry Pi se puentean al puerto interno de LM Studio, permitiendo acceso por LAN.

El resultado fue viable: desde un MacBook en la misma red local pude hacer la petición y obtener correctamente la lista de modelos.

Paso 5: integración con editor (Zed)

El servicio local de LM Studio es compatible con la forma de la OpenAI API, por lo que la mayoría de herramientas que soportan base_url personalizado pueden conectarse directamente.

En Zed añadí un nuevo LLM provider apuntando a la instancia de Gemma 4 en la Raspberry Pi, y después la prueba de chat dentro del editor funcionó.

Juicio de usabilidad real

Esta solución encaja con:

Scripts locales de automatización
Tareas auxiliares de baja concurrencia y baja exigencia de tiempo real
Aprendizaje personal y experimentos en dispositivos edge

No encaja tanto con:

Chat interactivo de alta frecuencia
Escenarios de colaboración de desarrollo sensibles a la latencia

Conclusión

Ejecutar Gemma 4 (E2B) en Raspberry Pi 5 es viable, y el resultado real fue mejor de lo esperado.

Si tu objetivo es “poder ejecutarlo offline, conectarlo a herramientas y completar tareas ligeras o medias”, esta ruta merece probarse. Si el objetivo es interacción fluida en tiempo real, sigue siendo recomendable usar hardware más potente.

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.

Instalar y ejecutar Gemma 4 en Android: guía completa de inicio

Wed, 08 Apr 2026 17:55:53 +0800

Si quieres probar Gemma 4 sin conexión en el teléfono, este artículo te lleva paso a paso desde la instalación hasta las funciones prácticas.

Paso 1: obtener la aplicación

Google AI Edge Gallery actualmente no está publicado en Google Play, así que hay que instalarlo mediante sideload de APK.

En el dispositivo Android, entra en:

Ajustes -> Aplicaciones -> Acceso especial de apps -> Instalar apps desconocidas

Después:

Busca el navegador que usas (por ejemplo Chrome o Firefox) y activa “Permitir desde esta fuente”.
Abre en el navegador del teléfono la página GitHub Releases de Google AI Edge Gallery.

Dirección: https://github.com/google-ai-edge/gallery/releases

Descarga el paquete .apk más reciente.
Cuando termine la descarga, abre el instalador desde la barra de notificaciones o el gestor de archivos y completa la instalación siguiendo las indicaciones.

Con una red normal, este paso suele completarse en unos 2 minutos.

Paso 2: primer inicio y permisos

Al abrir AI Edge Gallery por primera vez, la aplicación solicitará permiso de almacenamiento para guardar los archivos de modelos. Se recomienda permitirlo directamente; de lo contrario, la aplicación no podrá descargar ni cargar modelos.

En la página principal suelen aparecer estas entradas:

Ask Image: tareas de comprensión de imágenes (describir imágenes o responder preguntas relacionadas con ellas)
AI Chat: conversación de texto general
Summarize: pegar texto y generar un resumen
Smart Reply: generar sugerencias de respuesta

La opción más usada por la mayoría de usuarios es AI Chat.

Paso 3: descargar el modelo Gemma 4

Entra en AI Chat.
Haz clic en Get Models cuando aparezca la indicación.
Selecciona una versión de Gemma 4 en la lista de modelos (se mostrará su tamaño).
Elige el modelo según el rendimiento del dispositivo; si tu teléfono tiene 8GB RAM, puedes empezar por Gemma 4 4B.
Pulsa Download y la descarga comenzará en segundo plano.

Nota: cuanto más grande sea el modelo, más tardará la descarga. También puedes descargar varios modelos y cambiarlos después cuando lo necesites. Los modelos descargados se guardan localmente y no hace falta volver a descargarlos.

Paso 4: empezar a conversar

Cuando termine la descarga del modelo:

Pulsa el nombre del modelo para cargarlo (la primera carga suele tardar entre 10 y 30 segundos, según el tamaño del modelo y el rendimiento del dispositivo).
Escribe una pregunta en el cuadro de chat y envíala.
El modelo generará la respuesta localmente; los datos no se subirán a la nube.

Normalmente la primera respuesta será algo más lenta. Es un fenómeno normal de calentamiento del modelo; las respuestas siguientes dentro de la misma conversación suelen ser más rápidas.

Paso 5: probar capacidades visuales (Gemma 4 multimodal)

Si descargaste una versión multimodal de Gemma 4:

Vuelve al menú principal y entra en Ask Image.
Selecciona una imagen o toma una foto directamente.
Escribe la pregunta que quieres hacer, por ejemplo “¿Qué hay en esta imagen?” o “¿Qué texto importante aparece en la imagen?”.
Espera a que el modelo analice la imagen localmente y devuelva el resultado.

Esta función puede usarse sin conexión y el contenido de la imagen tampoco se enviará a servidores externos.