Local LLM on KnightLi Blog

Actualización llama.cpp b9196: los binarios precompilados para Windows soportan CUDA 13.1, Vulkan, HIP y SYCL

Mon, 18 May 2026 23:20:00 +0800

La versión reciente de llama.cpp para Windows es más amigable para usuarios de LLM locales. Antes, ejecutar modelos GGUF en Windows solía atascarse por problemas de entorno: versiones de CUDA incompatibles, DLL faltantes, drivers no compatibles, fallos de compilación con CMake, variables de entorno incorrectas o configuración complicada de Vulkan / HIP / SYCL.

Ahora la página oficial de Release ofrece varios paquetes precompilados para Windows. En muchos casos ya no hace falta compilar desde código fuente. Descargas la versión correcta, la descomprimes, colocas el archivo del modelo y puedes arrancar directamente un servicio local de inferencia.

Para qué sirve llama.cpp

llama.cpp es uno de los frameworks más usados para inferencia local con modelos GGUF. Es ligero, multiplataforma, puede usar CPU o GPU, y alrededor de GGUF ya existe un ecosistema amplio de modelos.

Familias de modelos comunes:

Qwen
Llama
DeepSeek
Gemma
Mistral
Mixtral
Hermes

A medida que los modelos cuantizados en GGUF se popularizan, muchos modelos open source publican versiones GGUF aptas para despliegue local. Para usuarios normales, el valor de llama.cpp está en que no necesitas montar un stack de inferencia complejo para correr un servicio de chat usable en tu propia máquina.

Cómo elegir una versión precompilada para Windows

Los usuarios de Windows pueden elegir distintos builds según su hardware:

Windows x64 CPU
Windows x64 CUDA 12.4
Windows x64 CUDA 13.1
Windows x64 Vulkan
Windows x64 HIP Radeon
Windows x64 SYCL
Windows ARM64 CPU

Si usas una GPU NVIDIA, normalmente conviene priorizar la versión CUDA. Tarjetas como RTX 3060, 4060, 4070, 4080 y 4090 encajan mejor con la ruta CUDA.

Si usas una GPU AMD, puedes probar HIP o Vulkan. En la práctica, Vulkan a veces resulta más sencillo que HIP, sobre todo si no quieres montar un entorno ROCm completo.

Si usas gráficos integrados Intel o una GPU Arc, puedes probar SYCL o Vulkan. El rendimiento suele quedar por detrás de NVIDIA CUDA, pero ya basta para probar muchos modelos GGUF pequeños y medianos.

La versión CPU sirve para usuarios sin GPU dedicada o para quienes solo quieren verificar un modelo o correr modelos pequeños. No será rápida, pero es la ruta más simple.

Arrancar un modelo GGUF normal

Supongamos que ya descargaste el paquete precompilado de llama.cpp para Windows y colocaste el modelo en el directorio models. Entra en la carpeta descomprimida de llama.cpp y ejecuta:

`1`	`llama-server.exe -m models\your-model.gguf -ngl 999`

Aquí -m apunta al archivo GGUF, y -ngl 999 intenta cargar la mayor cantidad posible de capas en la GPU. Cuántas se cargan realmente depende de la VRAM, el tamaño del modelo y el formato de cuantización.

Cuando arranque correctamente, abre en el navegador:

`1`	`http://127.0.0.1:8080`

Entrarás en la interfaz web local de chat.

Si la VRAM no alcanza, cambia a un modelo más pequeño o a una cuantización más baja, como archivos GGUF Q4 o Q5. No mires solo el número de parámetros; revisa también el formato de cuantización y la longitud de contexto.

Arrancar un modelo visual multimodal

Los modelos visuales multimodales normalmente necesitan algo más que el archivo principal. También necesitan un archivo de proyección visual mmproj. Al arrancar, especifica ambos:

`1`	`llama-server.exe -m "models\main-model.gguf" --mmproj "models\mmproj-model.gguf" -ngl 999`

Usos comunes:

Reconocimiento OCR
Comprensión de capturas de pantalla
Análisis de capturas de páginas web
Preguntas y respuestas sobre imágenes
Juicio simple de contenido visual

Por ejemplo, modelos como Qwen2-VL / Qwen2.5-VL son útiles para entender capturas en chino, OCR y preguntas sobre imágenes. Asegúrate de que el modelo principal y el archivo mmproj correspondan entre sí; una versión no compatible puede causar fallos de carga o resultados extraños.

Gestionar varios modelos con un script bat

Si tienes varios modelos locales, puedes escribir un .bat sencillo para alternarlos con un menú. Este ejemplo requiere cambiar ruta y nombres de modelos por los tuyos:

@echo off
chcp 65001 >nul
cd /d C:\path\to\llama-b9196-bin-win-cuda-13.1-x64

echo 请选择模型：
echo 1. Gemma
echo 2. Qwen VL 多模态
echo 3. DeepSeek

set /p choice=输入数字：

if "%choice%"=="1" llama-server.exe -m "models\gemma.gguf" -ngl 999
if "%choice%"=="2" llama-server.exe -m "models\qwen-vl.gguf" --mmproj "models\mmproj.gguf" -ngl 999
if "%choice%"=="3" llama-server.exe -m "models\deepseek.gguf" -ngl 999

pause

Guárdalo en UTF-8 y luego cambia la extensión a .bat. Al hacer doble clic, podrás elegir distintos modelos por número.

Tres cosas que mirar al elegir modelos

Primero, el hardware. Cuanta más VRAM tengas, modelos más grandes podrás correr. Si la VRAM es limitada, no fuerces un modelo grande; empieza con 7B, 8B o una cuantización más baja.

Segundo, el uso. Para preguntas diarias, resúmenes y reescritura, un modelo pequeño o una cuantización media suele bastar. Para código, análisis de documentos largos o comprensión multimodal, necesitas modelos más fuertes y más VRAM.

Tercero, licencias y límites de seguridad. En internet hay muchos modelos modificados por la comunidad, con capacidades, restricciones y licencias distintas. Antes de descargar, confirma origen, licencia, escenario de uso y riesgos. No conviene entregar tareas de producción directamente a modelos de origen poco claro.

Problemas comunes

Si al arrancar aparece un error de DLL faltante, primero confirma que el paquete descargado corresponde a tu ruta de GPU. Los usuarios de NVIDIA no deberían descargar por error la versión HIP, y los usuarios de AMD no deberían descargar la versión CUDA.

Si el modelo carga muy lento, puede ser demasiado grande, el disco puede ser lento, o parte de las capas puede estar cayendo a CPU por falta de VRAM.

Si la página web no abre, revisa primero si el servicio arrancó correctamente en la consola y confirma que el puerto sea 8080. Si el puerto está ocupado, consulta los parámetros de llama-server para cambiarlo.

Si un modelo multimodal da resultados raros, revisa primero si el archivo mmproj corresponde al modelo principal, antes de limitarte a cambiar prompts.

Resumen

El valor de estos paquetes precompilados para Windows está en bajar la barrera de entrada a la IA local. Antes muchos usuarios se quedaban atrapados en compilación y dependencias; ahora pueden llegar más rápido a descargar modelos, arrancar un servicio y probar resultados.

Para usuarios de Windows, la ruta puede resumirse así:

NVIDIA: prioriza CUDA.
AMD: prueba primero Vulkan, luego HIP.
Intel: prueba SYCL o Vulkan.
Sin GPU dedicada: usa la versión CPU para modelos pequeños.

Antes de usarlo en serio, confirma origen del modelo, licencia, requisitos de VRAM y resultados reales. La IA local ofrece control, uso offline y baja latencia, pero no significa coste cero: gestión de modelos, recursos de hardware y calidad de salida siguen siendo responsabilidad tuya.

Fuente: https://www.freedidi.com/24211.html

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.

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

NVIDIA lanza Nemotron 3 Nano Omni: un modelo abierto de razonamiento omnimodal para agentes

Fri, 01 May 2026 12:07:15 +0800

NVIDIA lanzó Nemotron 3 Nano Omni, un modelo abierto de razonamiento omnimodal diseñado para flujos de AI Agents. Su foco no es solo responder preguntas de texto, sino poner lenguaje, visión y audio en un mismo marco de razonamiento para trabajar con entradas más cercanas al trabajo real.

Por posicionamiento, Nemotron 3 Nano Omni parece un modelo base preparado para agentes. Puede entender información de pantallas, documentos, imágenes, voz y vídeo, y convertirla en resultados de razonamiento accionables.

Especificaciones del modelo

Nemotron 3 Nano Omni usa arquitectura MoE. NVIDIA lista estos puntos:

Item	Information
Model name	`Nemotron 3 Nano Omni`
Architecture	MoE
Parameter scale	30B total / 3B active
Modalities	Text, image, audio, video
Context length	256K tokens
License	Apache 2.0
Main deployment direction	AI Agents, multimodal reasoning, enterprise agents

Lo más llamativo es 30B-A3B: el modelo tiene unos 30B parámetros totales, pero activa alrededor de 3B por paso de inferencia. Es un equilibrio entre capacidad y coste.

Pero active params en MoE no significa que la VRAM pueda estimarse como si fuera solo un modelo de 3B. Hay que contar pesos de expertos, KV cache, módulos de visión y audio, contexto y sobrecarga del framework.

No resuelve un problema de una sola modalidad

Los LLM tradicionales procesan sobre todo texto. Los multimodales añaden imagen. Nemotron 3 Nano Omni apunta a algo más amplio: entrada omnimodal, con texto, imágenes, audio y vídeo dentro de un razonamiento unificado.

Esto importa para agentes porque las tareas reales suelen incluir:

leer botones, tablas y ventanas en pantalla;
analizar PDFs, capturas, gráficos y webs;
escuchar instrucciones o reuniones;
entender acciones y tiempos en vídeo;
combinar esas señales para decidir el siguiente paso.

Si un modelo solo maneja una modalidad, el agente necesita mucho pegamento entre modelos especializados. Un modelo omnimodal reduce ese coste de integración.

Pensado para operación de ordenador e inteligencia documental

NVIDIA menciona explícitamente tareas de operación de ordenador. Estas requieren entender interfaces:

qué controles aparecen en pantalla;
en qué estado está la ventana actual;
qué botón o menú debe usarse;
qué significan tablas, diálogos y campos de entrada.

Esto es difícil de evitar cuando los agentes entran en despliegues reales. Para operar software de oficina, navegadores, backends empresariales o herramientas de desarrollo, el agente debe entender la interfaz, no solo leer documentación.

La inteligencia documental tiene una lógica parecida. Los materiales empresariales mezclan texto, tablas, imágenes, páginas escaneadas y gráficos. Un modelo omnimodal puede poner todo eso en un mismo contexto para revisión de contratos, análisis de informes, facturas, QA de conocimiento y automatización de procesos.

Audio y vídeo acercan los agentes a escenarios reales

Las entradas de audio y vídeo amplían mucho los usos:

resúmenes de reuniones;
análisis de llamadas de atención al cliente;
comprensión de comandos de voz;
organización de contenido educativo;
análisis de vídeos instructivos;
inspección de seguridad o industrial;
revisión de grabaciones de pantalla;
razonamiento temporal en tareas de varios pasos.

Si estas tareas dependen solo de transcripciones, se pierde información visual y temporal. Un modelo omnimodal puede combinar voz, fotogramas y texto para dar al agente una visión más completa.

Despliegue y ecosistema

NVIDIA sitúa Nemotron 3 Nano Omni dentro de un ecosistema abierto y usa licencia Apache 2.0. Para desarrolladores y empresas, esto reduce la barrera de experimentación, integración y desarrollo secundario.

También está muy ligado al ecosistema de inferencia de NVIDIA. En despliegues empresariales aparecen preguntas como:

si corre de forma eficiente en GPUs NVIDIA;
si soporta contexto largo y entrada multimodal;
si conecta con frameworks de agentes existentes;
si procesa documentos internos, audio/vídeo y capturas de UI;
si puede desplegarse en entornos privados.

NVIDIA afirma que el modelo puede alcanzar hasta 9x el throughput de modelos abiertos omnimodales comparables. El valor real dependerá del hardware, contexto, modalidades y framework, pero la dirección es clara: unir modelos abiertos multimodales con infraestructura de inferencia empresarial.

Casos de uso adecuados

Nemotron 3 Nano Omni encaja mejor en:

agentes que entienden texto, imagen, audio y vídeo al mismo tiempo;
inteligencia documental empresarial y QA de conocimiento;
operación de ordenador basada en capturas o interfaces web;
análisis multimodal de reuniones, atención al cliente y docencia;
comprensión de vídeo, revisión de workflows y razonamiento temporal;
equipos que necesitan licencia abierta y despliegue privado.

No es necesariamente lo mejor para todo usuario. Para chat local, completado de código o QA simple, un modelo de lenguaje de una sola modalidad puede ser más ligero y rápido.

Qué significa para AI Agents

Para que los AI Agents entren realmente en escenarios de trabajo, no basta con escribir texto. Necesitan entender interfaces, voz, documentos y cambios en vídeo, y convertirlo en la siguiente acción.

Ahí es donde Nemotron 3 Nano Omni importa. No es solo hacer el modelo más grande: es unificar muchos tipos de entrada que los agentes encuentran en tareas reales.

Desde este ángulo, el lanzamiento de NVIDIA no es solo “otro modelo multimodal”. Es parte del esfuerzo por conectar modelos abiertos, inferencia GPU, agentes empresariales y despliegue privado. Lo siguiente a observar será su rendimiento en frameworks de agentes, workflows empresariales y despliegues locales.

Referencias:

NVIDIA Technical Blog: NVIDIA Nemotron 3 Nano Omni

Ejecutar Qwen3.6 en local: requisitos de VRAM para modelos cuantizados 27B y 35B-A3B

Fri, 01 May 2026 12:02:00 +0800

Los modelos open-weight de Qwen3.6 más relevantes para despliegue local son:

Qwen3.6-27B: modelo denso de 27B.
Qwen3.6-35B-A3B: modelo MoE de 35B totales / 3B activos.

También existen nombres de producto o API como Qwen3.6-Plus y Qwen3.6-Max. Si un modelo no tiene pesos completos públicos y archivos cuantizados estables, no sirve para una tabla local de VRAM.

Como en la tabla de Gemma 4 de /05/10, hay que separar dos conceptos:

Tamaño del archivo GGUF: cuánto ocupa el archivo de pesos.
Uso real de VRAM: depende de pesos, KV cache, contexto, backend, módulos multimodales y batch.

Qwen3.6 tiene contexto por defecto muy largo. La model card indica soporte nativo de 262,144 tokens y extensión a 1,010,000 tokens. La columna de VRAM mínima solo aplica a contexto corto o medio.

Resumen rápido

VRAM	Buena opción	Evitar
8GB	Pruebas extremas de 2 bits para 27B / 35B-A3B	Q4 y superior
12GB	27B Q2/Q3, 35B-A3B Q2/Q3 con contexto corto	27B Q4 con contexto largo
16GB	27B Q3/Q4, 35B-A3B Q3/IQ4_XS	35B-A3B Q4 con contexto largo
24GB	27B Q4/Q5/Q6, 35B-A3B Q4	35B-A3B Q8, BF16
32GB	27B Q8, 35B-A3B Q5/Q6	BF16
48GB	35B-A3B Q8, 27B con más contexto	35B-A3B BF16
80GB+	27B / 35B-A3B BF16	No hace falta BF16 para chat local común

Con una GPU de 24GB, los puntos principales son Qwen3.6-27B Q4_K_M, Qwen3.6-27B Q5_K_M y Qwen3.6-35B-A3B UD-Q4_K_M.

Tamaños oficiales de pesos

Model	Architecture	Official BF16 Weight Size	Official Context
`Qwen3.6-27B`	27B dense	55.56GB	Native 262K, extendable to 1,010K
`Qwen3.6-35B-A3B`	35B total / 3B active MoE	71.90GB	Native 262K, extendable to 1,010K

Aunque 35B-A3B active unos 3B parámetros por paso, todavía debe cargar los pesos MoE completos. No debe estimarse como un modelo pequeño de 3B.

Tabla de VRAM de Qwen3.6-27B

Qwen3.6-27B es un modelo denso. Su ventaja es comportamiento estable; su coste se parece al de un 27B tradicional.

Quantization	GGUF File Size	Minimum VRAM	Safer VRAM	Best For
`UD-IQ2_XXS`	9.39GB	12GB	16GB	Extreme low-VRAM tests
`UD-IQ2_M`	10.85GB	12GB	16GB	Low-VRAM usability
`UD-Q2_K_XL`	11.85GB	14GB	18GB	Low-bit compromise
`UD-IQ3_XXS`	11.99GB	14GB	18GB	VRAM-saving 3-bit
`Q3_K_S`	12.36GB	16GB	20GB	3-bit entry point
`Q3_K_M`	13.59GB	16GB	20GB	Common 3-bit compromise
`IQ4_XS`	15.44GB	20GB	24GB	Near-Q4, more VRAM efficient
`IQ4_NL`	16.07GB	20GB	24GB	Quality/size balance
`Q4_K_M`	16.82GB	20GB	24GB	Recommended 27B default
`Q5_K_M`	19.51GB	24GB	32GB	Higher-quality quantization
`Q6_K`	22.52GB	28GB	32GB	Quality first
`Q8_0`	28.60GB	32GB	40GB	Near-original precision
`BF16`	53.80GB	64GB	80GB	Research, evaluation, precision comparison

Para chat y código local, Q4_K_M es el punto de partida más fácil de recomendar. Una GPU de 24GB puede correrlo bastante bien, pero para contexto largo conviene reducir tamaño o contexto.

Tabla de VRAM de Qwen3.6-35B-A3B

Qwen3.6-35B-A3B es un MoE de 35B totales y unos 3B activos por paso. Equilibra velocidad y capacidad, especialmente para agentes, herramientas y código.

Quantization	GGUF File Size	Minimum VRAM	Safer VRAM	Best For
`UD-IQ2_XXS`	10.76GB	12GB	16GB	Extreme low-VRAM tests
`UD-IQ2_M`	11.52GB	14GB	16GB	Low-VRAM usability
`UD-Q2_K_XL`	12.29GB	14GB	18GB	Low-bit compromise
`UD-IQ3_XXS`	13.21GB	16GB	20GB	VRAM-saving 3-bit
`UD-Q3_K_S`	15.36GB	18GB	24GB	3-bit entry point
`UD-Q3_K_M`	16.60GB	20GB	24GB	Common 3-bit compromise
`UD-IQ4_XS`	17.73GB	20GB	24GB	Quality/size balance
`UD-IQ4_NL`	18.04GB	20GB	24GB	Near-Q4 recommended option
`UD-Q4_K_M`	22.13GB	24GB	32GB	Recommended 35B-A3B default
`UD-Q5_K_M`	26.46GB	32GB	40GB	Higher-quality quantization
`UD-Q6_K`	29.31GB	32GB	48GB	Quality first
`Q8_0`	36.90GB	48GB	64GB	Near-original precision
`BF16`	69.37GB	80GB	96GB	Research, evaluation, precision comparison

Con 24GB, UD-Q4_K_M es una opción clave, pero no conviene fijar contexto muy alto. Para 128K+ contexto, versiones UD-IQ4_XS, UD-IQ4_NL o 3-bit son más realistas.

27B vs 35B-A3B

Necesidad	Mejor opción
Comportamiento denso estable	`Qwen3.6-27B`
Respuesta más rápida, agentes y herramientas	`Qwen3.6-35B-A3B`
Uso diario en 24GB	`35B-A3B UD-Q4_K_M` o `27B Q4_K_M`
Pruebas en 16GB	Usar 2-bit/3-bit y evitar contexto largo
Prioridad a contexto largo	Cuantización más baja y más margen para KV cache
Calidad con 32GB+	`27B Q5/Q6` o `35B-A3B Q5/Q6`

Si escribes código, usas agentes o herramientas, 35B-A3B merece probarse primero. Si quieres estabilidad de un modelo denso, 27B es más directo.

Por qué el contexto largo consume tanta VRAM

La model card de Qwen3.6 recomienda contexto largo para tareas complejas, e incluso señala que 128K+ puede ayudar al razonamiento. Pero en local, contexto largo significa una KV cache mucho más grande.

El uso real depende de:

KV cache;
si se usa entrada de visión;
si se usa --language-model-only;
batch y concurrencia;
cuantización de KV cache;
diferencias entre llama.cpp, vLLM, SGLang, KTransformers y LM Studio.

No mires solo el tamaño GGUF. Si el archivo ya está cerca del límite de VRAM, puede cargar pero fallar al generar salidas largas.

Cómo elegir

12GB: 27B UD-IQ2_M o 35B-A3B UD-IQ2_M, con contexto corto.
16GB: 27B Q3_K_M o 35B-A3B UD-IQ3_XXS.
24GB: 27B Q4_K_M, 35B-A3B UD-IQ4_NL o 35B-A3B UD-Q4_K_M.
32GB: 27B Q5/Q6 o 35B-A3B Q5/Q6.
48GB+: Q8_0 o más margen para contexto largo.

La mayoría no necesita BF16. El objetivo es equilibrar VRAM, contexto, velocidad y calidad.

Referencias

Ejecutar DeepSeek V4 en local: estimaciones de VRAM para versiones Pro, Flash y Base

Fri, 01 May 2026 11:55:25 +0800

DeepSeek V4 y Gemma 4 no están en la misma categoría para despliegue local. Con Gemma 4 todavía tiene sentido hablar de ejecutar modelos 26B o 31B en GPUs de 24GB o 32GB. DeepSeek V4 es un modelo MoE enorme, y el despliegue local completo entra rápidamente en territorio de estaciones multi-GPU o servidores.

El lanzamiento oficial DeepSeek V4 Preview incluye principalmente dos modelos de inferencia:

DeepSeek-V4-Pro: 1.6T total / 49B active params
DeepSeek-V4-Flash: 284B total / 13B active params

La colección oficial de Hugging Face también incluye dos modelos Base:

DeepSeek-V4-Pro-Base
DeepSeek-V4-Flash-Base

Este artículo solo estima VRAM cuando se cargan los pesos completos. En modelos MoE, active params afecta sobre todo al cómputo por token. No significa que solo esos parámetros deban cargarse.

Resumen rápido

Escala de VRAM	Realista	No esperes
24GB	No puede cargar DeepSeek V4 completo; usa modelos destilados o API	V4-Flash / V4-Pro local completo
48GB	Aún no es adecuado para carga completa	V4-Flash Q4 estable
80GB	Pruebas V4-Flash Q2/Q3 u offload pesado	V4-Pro
128GB	V4-Flash Q4 empieza a ser más realista	V4-Pro Q4
192GB	V4-Flash FP8/Q6 más cómodo; Pro Q2 experimental	V4-Pro Q4
256GB	V4-Flash FP8 cómodo; Pro Q2/Q3 puede probarse	V4-Pro Q5+
512GB	V4-Pro Q4 empieza a discutirse	V4-Pro FP8
1TB+	V4-Pro FP8 y Pro-Base de bajo bit	Despliegue barato en una máquina
2TB+	Clase Pro-Base FP8	Estación común

Si tu objetivo es correr un modelo en un PC personal, DeepSeek V4 no es el objetivo adecuado. Es más realista usar API oficial, esperar cuantizaciones comunitarias maduras, usar modelos destilados o elegir modelos locales de 7B a 70B.

Tamaños oficiales de pesos

Las cifras vienen de model.safetensors.index.json en los repositorios oficiales de Hugging Face.

Model	Parameter Scale	Official Weight Size	Notes
`DeepSeek-V4-Flash`	284B total / 13B active	159.61GB	Inference model, smallest in this group
`DeepSeek-V4-Pro`	1.6T total / 49B active	864.70GB	Inference model, stronger but enormous
`DeepSeek-V4-Flash-Base`	284B total	294.67GB	Base model, closer to full FP8 weight size
`DeepSeek-V4-Pro-Base`	1.6T total	1606.03GB	Base model, about 1.6TB

Incluso el V4-Flash más pequeño se acerca a 160GB de pesos oficiales. No debe tratarse como un 13B solo por tener 13B active params.

Estimación de VRAM para DeepSeek V4 Flash

V4-Flash es la variante más abordable para experimentos locales, pero sigue sin ser un modelo de una sola GPU de consumo.

Version / Quantization	Estimated Weight Size	Minimum VRAM	Safer VRAM	Best For
`FP8 / official weights`	159.61GB	192GB	256GB	Multi-GPU servers, inference service
`Q6`	120GB	160GB	192GB	Quality-first quantization tests
`Q5`	100GB	128GB	160GB	Quality/size balance
`Q4`	80GB	96GB	128GB	More realistic starting point for Flash
`Q3`	60GB	80GB	96GB	Large-VRAM single GPU or multi-GPU tests
`Q2`	40GB	48GB	64GB	Extreme low-bit experiments with clear quality risk

Si aparecen builds maduros de V4-Flash Q4, probablemente seguirán sin ser modelos para 24GB. El punto de partida realista es 96GB a 128GB de VRAM total, o setups con offload que sacrifican velocidad por capacidad.

Estimación de VRAM para DeepSeek V4 Pro

V4-Pro es el modelo de inferencia insignia, con unos 864.70GB de pesos oficiales.

Version / Quantization	Estimated Weight Size	Minimum VRAM	Safer VRAM	Best For
`FP8 / official weights`	864.70GB	1TB	1.2TB+	Multi-node or multi-GPU inference service
`Q6`	648GB	768GB	1TB	High-quality quantized service
`Q5`	540GB	640GB	768GB	Quality/cost balance
`Q4`	432GB	512GB	640GB	Lowest practical quality line for Pro
`Q3`	324GB	384GB	512GB	Low-bit experiments
`Q2`	216GB	256GB	320GB	Extreme experiments with high risk

Para usuarios individuales, V4-Pro se consume mejor por API. Para despliegue local completo, trátalo como modelo de servidor multi-GPU.

Estimación de VRAM para Flash-Base y Pro-Base

Los modelos Base suelen ser para investigación, fine-tuning o entrenamiento continuo, no para chat común.

V4-Flash-Base pesa unos 294.67GB:

Version / Quantization	Estimated Weight Size	Minimum VRAM	Safer VRAM	Best For
`FP8 / official weights`	294.67GB	384GB	512GB	Research, preprocessing, evaluation
`Q6`	221GB	256GB	320GB	High-quality quantization research
`Q5`	184GB	224GB	256GB	Quality/size balance
`Q4`	147GB	192GB	224GB	Lower-cost Base experiments
`Q3`	111GB	128GB	160GB	Low-bit experiments
`Q2`	74GB	96GB	128GB	Extreme experiments

V4-Pro-Base pesa unos 1606.03GB:

Version / Quantization	Estimated Weight Size	Minimum VRAM	Safer VRAM	Best For
`FP8 / official weights`	1606.03GB	2TB	2.4TB+	Large-scale research clusters
`Q6`	1205GB	1.5TB	2TB	High-quality quantization research
`Q5`	1004GB	1.2TB	1.5TB	Research and evaluation
`Q4`	803GB	1TB	1.2TB	Low-bit research
`Q3`	602GB	768GB	1TB	Extreme low-bit research
`Q2`	402GB	512GB	640GB	Extreme experiments

Este tipo de modelo no debe evaluarse con la pregunta “¿lo corre una GPU doméstica?”. Incluso Q4 queda fuera de la comodidad de la mayoría de estaciones.

Por qué active params no basta

MoE activa solo parte de los expertos por token, por eso el cómputo puede ser mucho menor que el total de parámetros. Pero eso no significa que la VRAM solo tenga que cargar los parámetros activos.

El despliegue local completo depende de:

si todos los expertos deben residir en GPU;
si hay carga bajo demanda de expertos;
coste de transferencia CPU-GPU;
latencia de offload a NVMe;
crecimiento de KV cache con contexto largo;
sobrecarga de runtime en contexto muy largo;
coste de comunicación multi-GPU o multinodo.

V4-Pro con 49B active no se despliega como un 49B. V4-Flash con 13B active tampoco debe tratarse como un 13B pequeño.

Cómo elegir

Si eres usuario individual:

no intentes alojar DeepSeek V4 completo;
usa la API oficial cuando necesites sus capacidades;
para despliegue privado, revisa primero tu infraestructura multi-GPU;
con 24GB a 48GB, los modelos cuantizados 7B, 14B, 32B o 70B son más prácticos.

Con 128GB a 256GB de VRAM total, observa implementaciones estables de V4-Flash Q4/Q5. Con 512GB+, V4-Pro Q4 empieza a ser un objetivo de validación de ingeniería.

La pregunta clave no es “qué archivo cuantizado descargo”, sino “si tengo capacidad de inferencia de sistema para este modelo”.

Referencias

Ejecutar Gemma 4 en local: requisitos de VRAM para modelos cuantizados E2B, E4B, 26B y 31B

Fri, 01 May 2026 11:42:34 +0800

Gemma 4 tiene cuatro tamaños principales para despliegue local: E2B, E4B, 26B A4B y 31B. E2B y E4B apuntan a dispositivos ligeros y edge, 26B A4B usa arquitectura MoE, y 31B es el modelo denso más grande.

El error más común al hacer inferencia local es confundir dos números:

Tamaño del archivo GGUF: cuánto ocupa el archivo de pesos.
Uso real de VRAM: depende de pesos, KV cache, sobrecarga del runtime, longitud de contexto y módulos multimodales.

Las tablas siguientes estiman VRAM a partir del tamaño GGUF. La suposición base es inferencia local de texto con llama.cpp, LM Studio, Ollama o runtimes similares, usando contexto corto o medio. Para contexto largo, entrada de imagen/audio o concurrencia, deja más margen.

Resumen rápido

VRAM	Buena opción	Evitar
4GB	Cuantizaciones E2B de bajo bit	E4B y superiores
6GB	E2B Q4/Q5, E4B de bajo bit	26B, 31B
8GB	E2B Q8, E4B Q4/Q5	26B Q4, 31B Q4
12GB	E4B Q8, pruebas 26B/31B de 2-3 bits	26B Q4 con contexto largo
16GB	26B y 31B de bajo bit	31B Q4 con contexto largo
24GB	26B Q4/Q5, 31B Q4	31B Q8, BF16
32GB	26B Q6/Q8, 31B Q5/Q6	BF16
48GB	31B Q8 más cómodo	31B BF16
80GB+	26B/31B BF16	GPU de consumo única

Para algo usable en local, empieza con E4B Q4_K_M o E2B Q4_K_M. Con 24GB de VRAM, 26B A4B Q4_K_M y 31B Q4_K_M empiezan a ser opciones realistas.

Tabla de VRAM de Gemma 4 E2B

E2B es la versión más ligera, adecuada para portátiles, mini PC, móviles y pruebas con poca VRAM.

Quantization	GGUF File Size	Minimum VRAM	Safer VRAM	Best For
`UD-IQ2_M`	2.29GB	4GB	6GB	Extreme low-VRAM tests
`UD-Q2_K_XL`	2.40GB	4GB	6GB	Low-VRAM usability
`Q3_K_M`	2.54GB	4GB	6GB	Lightweight chat and summaries
`IQ4_XS`	2.98GB	6GB	8GB	Balance of quality and size
`Q4_K_M`	3.11GB	6GB	8GB	Recommended E2B default
`Q5_K_M`	3.36GB	6GB	8GB	Slightly steadier than Q4
`Q6_K`	4.50GB	8GB	10GB	Higher-quality small model
`Q8_0`	5.05GB	8GB	10GB	Near-original precision
`BF16`	9.31GB	12GB	16GB	Debugging, comparison, research

Para uso diario, E2B Q4_K_M suele bastar. Con solo 4GB de VRAM, variantes de 2 o 3 bits pueden arrancar, pero la calidad será menos estable.

Tabla de VRAM de Gemma 4 E4B

E4B es el modelo ligero más práctico. Sirve mejor para escritura diaria, resúmenes, ayuda ligera de código y asistentes locales.

Quantization	GGUF File Size	Minimum VRAM	Safer VRAM	Best For
`UD-IQ2_M`	3.53GB	6GB	8GB	Low-VRAM tests
`UD-Q2_K_XL`	3.74GB	6GB	8GB	Low-VRAM usability
`Q3_K_M`	4.06GB	6GB	10GB	Lightweight local assistant
`IQ4_XS`	4.72GB	8GB	12GB	Balance of quality and speed
`Q4_K_M`	4.98GB	8GB	12GB	Recommended E4B default
`Q5_K_M`	5.48GB	8GB	12GB	Steadier everyday use
`Q6_K`	7.07GB	10GB	16GB	Quality first
`Q8_0`	8.19GB	12GB	16GB	Near-original precision
`BF16`	15.05GB	20GB	24GB	Research, evaluation, precision comparison

Con 8GB de VRAM, E4B Q4_K_M es un punto de partida realista. Con 12GB o 16GB, E4B Q8_0 también merece consideración.

Tabla de VRAM de Gemma 4 26B A4B

26B A4B es la versión MoE. Tiene más parámetros totales, pero activa solo parte de los expertos por paso de inferencia. Es más adecuada para preguntas complejas, código, uso de herramientas y agentes.

Quantization	GGUF File Size	Minimum VRAM	Safer VRAM	Best For
`UD-IQ2_M`	9.97GB	14GB	16GB	Extreme 16GB GPU tests
`UD-Q2_K_XL`	10.55GB	14GB	16GB	Running 26B with low VRAM
`UD-Q3_K_M`	12.53GB	16GB	20GB	Better quality while still VRAM-conscious
`UD-IQ4_XS`	13.42GB	16GB	24GB	Balance of quality and size
`UD-Q4_K_M`	16.87GB	20GB	24GB	Recommended 26B default
`UD-Q5_K_M`	21.15GB	24GB	32GB	Higher-quality quantization
`UD-Q6_K`	23.17GB	28GB	32GB	Quality first
`Q8_0`	26.86GB	32GB	40GB	Near-original precision
`BF16`	50.51GB	64GB	80GB	Not realistic for most single consumer GPUs

24GB de VRAM es la línea cómoda para 26B A4B. Una GPU de 16GB puede probar versiones de bajo bit, pero conviene mantener contexto y concurrencia moderados.

Tabla de VRAM de Gemma 4 31B

31B es el modelo denso más grande. Tiene más capacidad general, pero la presión de VRAM es directa.

Quantization	GGUF File Size	Minimum VRAM	Safer VRAM	Best For
`UD-IQ2_XXS`	8.53GB	12GB	16GB	Extreme low-VRAM tests with clear quality loss
`UD-IQ2_M`	10.75GB	14GB	18GB	Low-VRAM tests
`UD-Q2_K_XL`	11.77GB	16GB	20GB	16GB GPU experiments
`Q3_K_S`	13.21GB	16GB	24GB	More VRAM-efficient 3-bit
`Q3_K_M`	14.74GB	20GB	24GB	Common 3-bit compromise
`IQ4_XS`	16.37GB	20GB	24GB	Near-Q4 compromise
`Q4_K_M`	18.32GB	24GB	32GB	Recommended 31B default
`Q5_K_M`	21.66GB	28GB	32GB	Higher-quality quantization
`Q6_K`	25.20GB	32GB	40GB	Quality first
`Q8_0`	32.64GB	40GB	48GB	Near-original precision
`BF16`	61.41GB	80GB	96GB	Server or large-VRAM workstation

Se puede probar 31B de bajo bit en 16GB, pero para uso diario 24GB es mejor. Q4_K_M es el equilibrio; Q5_K_M y superiores tienen más sentido con 32GB+.

Por qué el uso real supera el tamaño del archivo

El tamaño GGUF solo representa los pesos. En ejecución también cuentan:

KV cache: más contexto implica más memoria.
Batch y concurrencia: más tokens o usuarios consumen más VRAM.
Componentes multimodales: imagen, audio o vídeo añaden módulos como mmproj.
Backend: CUDA, Metal, ROCm y split CPU/GPU no consumen igual.
Cuantización de KV cache: q8_0, q4_0 y modos similares ahorran VRAM, con posibles efectos en detalle.

La columna de VRAM mínima debe leerse como umbral para arrancar e inferir con contexto corto. Para 32K, 64K, 128K o 256K, los requisitos suben bastante.

Cómo elegir

4GB a 6GB: E2B Q3_K_M o E2B Q4_K_M.
8GB: E4B Q4_K_M; E2B Q8_0 también va bien.
12GB: E4B Q8_0, o pruebas de bajo bit de 26B/31B.
16GB: 26B A4B UD-Q3_K_M o 31B Q3_K_S, sin esperar contexto largo cómodo.
24GB: 26B A4B UD-Q4_K_M y 31B Q4_K_M.
32GB+: considerar Q5_K_M, Q6_K o más contexto.

La mayoría de usuarios no necesita BF16. El despliegue local consiste en equilibrar VRAM, velocidad, contexto y calidad, no en elegir el archivo más grande.

Referencias

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.

Cómo ajustar llama.cpp con 8GB de VRAM: por qué 32K es más seguro y 64K necesita cuantización de KV Cache

Thu, 23 Apr 2026 12:13:04 +0800

Si 8GB de VRAM bastan para ejecutar LLMs locales con fluidez, especialmente con contextos largos, es una de las preguntas más comunes al usar llama.cpp.

Tres conclusiones clave:

Con 8GB de VRAM, contexto 32K suele ser el equilibrio más seguro
Si realmente quieres 64K, la cuantización de KV Cache suele ser esencial
En inferencia full-GPU, subir a ciegas el número de hilos CPU puede empeorar el rendimiento

1. Qué significan 32K, 64K y KV Cache

32K y 64K se refieren a longitud de contexto, es decir, cuántos tokens puede procesar el modelo a la vez. K significa miles: 32K son unos 32000 tokens, y 64K unos 64000 tokens. Cuanto más largo el contexto, más contenido previo puede ver el modelo.

KV Cache es una caché de resultados intermedios que el modelo mantiene para acelerar la generación autoregresiva. Una vez que el modelo leyó parte del contexto, no necesita recalcular todo desde cero cada vez. Guarda información intermedia y la reutiliza. K y V vienen de Key y Value en Transformers.

Estos términos aparecen juntos porque:

32K y 64K definen cuánto contenido quieres recordar
KV Cache determina cuánta VRAM extra hace falta para mantener esa memoria
cuanto más largo el contexto, más grande suele ser la KV Cache

Cuando la inferencia de contexto largo se ralentiza, el problema raíz suele ser que la caché creció hasta presionar el límite de VRAM.

2. Por qué 32K y 64K se comportan tan distinto

Usando unas 30000 letras chinas de The Three-Body Problem como stress test, la comparación entre 32K y 64K puede verse dramática: con tamaño de documento similar, 64K puede volverse mucho más lento.

La razón no es que el modelo empeore de repente. El problema real es tocar el límite de VRAM.

En 32K, pesos del modelo más caché quizá aún caben en 8GB, así que la mayoría del tráfico se queda en la memoria de la GPU. Al pasar a 64K, la caché crece, el uso total se acerca o supera el techo de VRAM, y parte de los datos se empuja a memoria compartida o del sistema.

En ese punto no colapsa el cómputo bruto, sino el ancho de banda.

Lo que parece “el contexto se duplicó y el rendimiento se hundió” suele ser que la ruta de datos salió de VRAM hacia memoria mucho más lenta.

3. Para 64K, la cuantización de KV Cache importa mucho

Para usuarios de 8GB de VRAM, una conclusión importante es que cuantizar KV Cache importa muchísimo.

Sin cambiar el modelo, cuantizar solo la caché reduce directamente el uso de memoria en contexto largo. Eso permite que parte de los datos que antes salían de VRAM vuelvan a caber. 64K seguirá siendo más pesado que 32K, pero es menos probable que caiga en la zona más lenta.

En simple:

32K es el rango predeterminado más práctico para 8GB
64K no es imposible
pero sin cuantización de caché, puede pasar de usable a difícil de usar

Prioridad habitual:

Revisar si la VRAM ya está cerca del techo
Decidir si activar cuantización de KV Cache
Solo después experimentar con ajustes de throughput

4. Baja utilización GPU no significa que esté inactiva

Este punto rompe la intuición.

Cuando Task Manager muestra 20% o 30% de GPU, mucha gente asume:

los parámetros están mal
el modelo no corre realmente en GPU
la GPU no se usa completa

Pero en inferencia llama.cpp, lo más probable es que el cuello de botella no sea cómputo del core, sino lecturas y escrituras de memoria.

Los cores GPU pueden terminar rápido un lote de cálculo y pasar el resto del tiempo esperando el siguiente lote de pesos o datos cacheados.

Por eso:

la utilización de cores no parece alta
pero la velocidad end-to-end no mejora

No es una GPU perezosa. Es una ruta de datos estrecha.

5. Aumentar parámetros de throughput ayuda solo si la VRAM aguanta

Si los cores GPU no están saturados, aumentar parámetros relacionados con throughput puede hacer que la GPU procese más datos a la vez y use mejor el paralelismo.

Puede mejorar velocidad, pero con una condición: debe quedar margen de VRAM.

Si ya estás en 64K, con una caché grande y VRAM casi agotada, subir esos parámetros puede terminar en:

crash
fallback a memoria compartida mucho más lenta

La secuencia más segura:

proteger primero el límite de VRAM
luego probar optimizaciones de throughput
tras cada cambio, revisar velocidad y estabilidad

6. Más hilos CPU no siempre son mejores

Es una trampa fácil.

Parece natural pensar que más hilos dan más velocidad. Pero si el modelo ya corre casi todo en GPU, forzar más hilos CPU puede empeorar claramente el rendimiento.

En inferencia full-GPU, la CPU es más scheduler y ayudante de preprocesamiento que motor principal. Demasiados hilos aumentan contención, overhead de scheduling y cambios de contexto, interrumpiendo el flujo de datos.

Resultado:

la CPU parece más ocupada
la velocidad general baja

En este setup, valores predeterminados o hilos más bajos suelen ser más fiables que maximizar todo.

7. Enfoque práctico para 8GB de VRAM

1. Trata 32K como objetivo predeterminado

Con una GPU de 8GB, no persigas 64K de inmediato. 32K suele equilibrar mejor velocidad, estabilidad y memoria.

2. Si quieres 64K, resuelve primero la caché

Confirma si KV Cache está cuantizada y si la VRAM ya está al límite.

3. No juzgues todo por utilización GPU

Baja utilización no implica ajustes incorrectos. Puede indicar que el cuello de botella es memoria.

4. Optimiza throughput sin cruzar el límite de VRAM

Estos parámetros pueden ayudar, pero solo con margen suficiente.

5. Sé conservador con hilos CPU

Si el modelo corre principalmente en GPU, más hilos CPU no son automáticamente mejores.

Conclusión

El valor de esta discusión no son solo números de benchmark, sino una verdad fácil de olvidar:

ajustar LLMs locales no consiste en poner cada valor al máximo. Consiste en entender si tu cuello de botella real es cómputo, capacidad de VRAM, ancho de banda de memoria o scheduling de CPU.

Para usuarios de 8GB, la estrategia más segura suele ser proteger primero el límite de VRAM y solo entonces decidir cuánto más empujar.

Si recuerdas una frase:

32K suele ser el rango de trabajo más estable para 8GB de VRAM; 64K es posible, pero solo si ya controlaste KV Cache y uso de VRAM.

Una GPU de 16GB aún puede ejecutar modelos 35B: estrategias de compresión VRAM para modelos MoE en LM Studio

Wed, 22 Apr 2026 21:47:34 +0800

Mucha gente piensa que 16GB de VRAM es el punto donde el despliegue local de LLMs se queda más o menos en modelos 12B a 14B, y que cualquier cosa más grande se vuelve demasiado dolorosa incluso con cuantización. Esa visión es comprensible, pero no es el techo real de una GPU de 16GB.

Si eliges bien el modelo y configuras bien los parámetros, una GPU de 16GB no tiene por qué limitarse a modelos pequeños. Un enfoque representativo es usar modelos MoE dentro de LM Studio con una estrategia sensata de descarga, de modo que modelos de clase 35B sigan funcionando a una velocidad realmente usable.

01 Por qué una GPU de 16GB no necesariamente se limita a 12B-14B

La idea central es simple: el tamaño de VRAM importa, pero la arquitectura del modelo importa igual.

Si intentas meter un modelo dense estándar en una GPU de 16GB, chocarás con el límite rápidamente. Estos modelos suelen involucrar todos los parámetros durante inferencia, así que la presión de VRAM y ancho de banda sube de inmediato.

Pero los modelos MoE son distintos. Su número total de parámetros puede ser grande, mientras solo una parte de los parámetros expertos se activa en cada paso de inferencia. Tomando como ejemplo un modelo de clase 35B: aunque el total de parámetros es alto, el número real que participa en cada paso es mucho menor, así que su requisito real de VRAM no es tan extremo como muchos asumen.

Por eso una GPU de 16GB todavía deja cierto margen de trabajo.

02 Conclusión práctica clave: los modelos MoE 35B pueden correr sorprendentemente rápido

Un caso representativo es un modelo MoE cuantizado como Qwen 3.5 35B A3B. Con una GPU de 16GB y los ajustes correctos en LM Studio, la cuantización Q6 puede superar los 30 tokens/s, y Q4 a veces prueba incluso más alto.

Ese resultado importa no solo porque el modelo “corre”, sino porque la velocidad ya está en un rango claramente usable.

En comparación, modelos grandes de escala similar que no son MoE suelen sufrir overflow de VRAM y caídas bruscas de velocidad en una GPU de 16GB. En otras palabras, el resultado no se determina solo por el número de parámetros. Importa cómo se usan esos parámetros durante inferencia.

03 En LM Studio, la clave no es un solo parámetro

Si quieres que este tipo de modelo corra con fluidez en una GPU de 16GB, el truco real no es suerte. Es ajustar correctamente dos parámetros:

GPU Offload
el ajuste que fuerza parte de las capas expertas a memoria CPU

El primero es fácil de entender. GPU Offload básicamente se empuja lo más alto posible para que el modelo priorice cálculo en GPU.

El segundo es la clave. No es el enfoque tradicional de “tomar prestada memoria del sistema cuando se desborda la VRAM”. En su lugar, coloca proactivamente parte de las capas expertas en memoria CPU para reducir uso de VRAM desde el inicio. Como los modelos MoE no activan todos los expertos en cada paso, mover algunos expertos a memoria no perjudica la velocidad global tanto como muchos esperarían.

Una forma más segura de ajustarlo es empezar en un rango y luego afinar gradualmente según tu máquina:

empezar con valores relacionados entre 20 y 35
luego ajustar según uso de VRAM y presión de memoria

En el fondo, este método usa memoria del sistema para recuperar margen de VRAM.

04 Puede seguir funcionando a 128K de contexto, y contextos menores reducen más la VRAM

Otro punto interesante es que incluso con longitud de contexto en 128K, un modelo MoE de clase 35B puede mantener una velocidad relativamente alta.

Eso dice algo importante: el cuello de botella de una GPU de 16GB no es tan rígido como muchos imaginan. Especialmente en una herramienta local como LM Studio, la pregunta real no suele ser simplemente si corre o no, sino:

si aceptas intercambiar más memoria del sistema por menos uso de VRAM
si aceptas acortar la longitud de contexto
si aceptas distintos compromisos de capacidad entre niveles de cuantización

Si reduces el contexto de 128K a 64K o 32K, la presión de VRAM baja aún más. Eso significa que algunos modelos MoE de clase 35B podrían incluso correr, con dificultad, en GPUs con menos VRAM, aunque velocidad y presión de memoria tendrán que reequilibrarse.

05 El coste: mucha más demanda de RAM y memoria virtual

Este setup no es rendimiento gratis.

Lo que debes vigilar es que, al comprimir más la presión de VRAM, el uso de RAM del sistema sube notablemente, y también la presión de memoria virtual. En otras palabras, no eliminas el coste: lo desplazas desde la GPU hacia RAM y swap en disco.

Si quieres probarlo, revisa primero:

si tu RAM del sistema es suficiente
si tu asignación de memoria virtual es suficiente
si demasiadas apps de fondo ya consumen recursos

Si esas condiciones no están, quizá no obtengas “35B corriendo rápido”, sino una máquina lenta en todo.

06 Una cuantización más agresiva no siempre es mejor

Hay otro compromiso práctico. La cuantización de menos bits suele ahorrar más VRAM, pero eso no la convierte automáticamente en la mejor opción.

La conclusión práctica es que algunos modelos corren más rápido en Q4, pero su capacidad original también puede degradarse más. En comparación, Q6 tiende a equilibrar mejor velocidad y retención de capacidad. Así que la elección correcta depende de qué te importe más:

máxima velocidad y encajar en VRAM
o preservar más capacidad original del modelo

Esas dos prioridades no siempre llevan a la misma cuantización.

07 Qué modelos vale la pena probar

Desde este ángulo, lo mejor no es perseguir ciegamente más parámetros, sino buscar primero modelos que encajen con esta estrategia:

modelos construidos sobre arquitectura MoE
modelos bien soportados en LM Studio y con variantes cuantizadas completas
modelos con ventajas claras en contexto largo o seguimiento de instrucciones

La idea no se detiene en un único modelo MoE 35B. También se extiende a modelos experimentales con memoria de contexto largo más fuerte, mejor seguimiento de instrucciones o variantes cuantizadas más ligeras con gran velocidad.

La lógica es consistente: primero encuentra modelos cuya arquitectura encaje con la estrategia de intercambiar memoria por VRAM, y luego habla de tuning. No empieces solo por número de parámetros.

08 Conclusión breve

Si tienes una GPU de 16GB y asumes que los LLMs locales se detienen en 12B-14B, vale la pena actualizar esa suposición.

Una forma más precisa de decirlo:

una GPU de 16GB no queda automáticamente descartada para modelos más grandes
modelos dense y modelos MoE deben considerarse por separado
GPU Offload y transferencia de capas expertas a memoria CPU en LM Studio pueden cambiar significativamente el uso de VRAM
en la práctica, intercambias mayor presión de memoria por más escala de modelo y mejor velocidad usable

Este enfoque no encaja con todas las máquinas, pero muestra algo importante: en despliegue local de LLMs, la VRAM no es el único límite. La arquitectura del modelo y la configuración de inferencia importan igual.

Cómo usar llama-quantize para modelos GGUF

Sun, 12 Apr 2026 09:42:36 +0800

llama-quantize es la herramienta de cuantización de llama.cpp. Se usa para convertir modelos GGUF de alta precisión en versiones cuantizadas más pequeñas.

Su uso más común es convertir formatos como F32, BF16 o FP16 en versiones como Q4_K_M, Q5_K_M o Q8_0, que son más fáciles de ejecutar localmente. Después de la cuantización, los modelos suelen ser mucho más pequeños y a menudo más rápidos en inferencia, aunque se espera cierta pérdida de calidad.

Flujo básico

Un flujo típico consiste en preparar el modelo original, convertirlo a GGUF y luego ejecutar la cuantización.

# install Python dependencies
python3 -m pip install -r requirements.txt

# convert the model to ggml FP16 format
python3 convert_hf_to_gguf.py ./models/mymodel/

# quantize the model to 4-bits (using Q4_K_M method)
./llama-quantize ./models/mymodel/ggml-model-f16.gguf ./models/mymodel/ggml-model-Q4_K_M.gguf Q4_K_M

Después, puedes ejecutar el modelo cuantizado con llama-cli:

1
2

# start inference on a gguf model
./llama-cli -m ./models/mymodel/ggml-model-Q4_K_M.gguf -cnv -p "You are a helpful assistant"

Opciones comunes

--allow-requantize: permite volver a cuantizar un modelo ya cuantizado, algo que normalmente no es ideal para la calidad
--leave-output-tensor: deja la capa de salida sin cuantizar; aumenta el tamaño, pero a veces ayuda a la calidad
--pure: desactiva la cuantización mixta y usa un tipo de cuantización más uniforme
--imatrix: usa una matriz de importancia para mejorar la calidad de cuantización
--keep-split: conserva el diseño original por fragmentos en lugar de producir un único archivo combinado

Si solo quieres un punto de partida práctico, esto suele bastar:

`1`	`./llama-quantize ./models/mymodel/ggml-model-f16.gguf ./models/mymodel/ggml-model-Q4_K_M.gguf Q4_K_M`

Cómo elegir una cuantización

Puedes pensar en los niveles de cuantización como un compromiso entre tamaño, velocidad y calidad:

Q8_0: más grande, pero normalmente más seguro para la calidad
Q6_K / Q5_K_M: opciones equilibradas habituales
Q4_K_M: valor predeterminado muy común, con buen equilibrio entre tamaño y calidad
Q3 / Q2: útiles cuando el hardware es muy limitado, pero la pérdida de calidad es más visible

El objetivo práctico normalmente no es elegir la cuantización más grande que quepa, sino la que se ejecute de forma fiable en tu hardware manteniendo una calidad aceptable.

Conclusión práctica

empieza con Q4_K_M o Q5_K_M
sube a Q6_K o Q8_0 si la calidad importa más
baja a Q3 o Q2 si la memoria está ajustada
compara versiones con el mismo conjunto de prompts

En resumen, llama-quantize es útil porque hace que los modelos GGUF sean más fáciles de ejecutar en hardware local, no solo porque reduce el tamaño de los archivos.

Cómo obtener modelos GGUF desde Hugging Face con llama.cpp

Sun, 12 Apr 2026 09:31:38 +0800

llama.cpp puede trabajar directamente con modelos GGUF alojados en Hugging Face, así que no siempre necesitas descargar manualmente los archivos del modelo primero.

Si un repositorio de modelo ya ofrece archivos GGUF, puedes usar el argumento -hf en la CLI, por ejemplo:

`1`	`llama-cli -hf ggml-org/gemma-3-1b-it-GGUF`

De forma predeterminada, esto descarga desde Hugging Face.
Si usas otro servicio que expone una API compatible con Hugging Face, puedes cambiar el endpoint de descarga con la variable de entorno MODEL_ENDPOINT.

Un detalle importante es que llama.cpp solo puede usar directamente el formato GGUF.
Si tu modelo está en otro formato, primero necesitas convertirlo con los scripts convert_*.py incluidos en el repositorio.

Hugging Face también ofrece varias herramientas online relacionadas con llama.cpp, entre ellas:

convertir modelos a GGUF
cuantizar pesos para reducir tamaño
convertir adaptadores LoRA
editar metadatos GGUF en el navegador
alojar endpoints de inferencia llama.cpp

Si solo quieres la conclusión práctica, empieza por repositorios que ya ofrezcan GGUF y luego usa llama-cli -hf <user>/<model>. En la mayoría de casos, ese es el camino más simple.

Qué significa `it` en Gemma-4-31B-it

Sat, 11 Apr 2026 20:45:34 +0800

En gemma-4-31B-it, it significa Instruction Tuned.

Para la mayoría de usuarios, esto quiere decir que esa versión está diseñada para chat, preguntas y respuestas, ayuda con código y otras tareas que siguen instrucciones.

Qué significa `it`

Los modelos suelen venir en dos formas comunes:

Base / Pre-trained: más cerca de un predictor bruto del siguiente token
it: ajustado para seguir instrucciones de usuario con más fiabilidad

Si pides algo como “traduce este texto” o “escribe un script en Python”, la versión it suele comportarse más como un asistente.

Qué significa `31B`

31B significa que el modelo tiene alrededor de 31 mil millones de parámetros.

En general:

más parámetros suelen implicar capacidades más fuertes
pero también mayores requisitos de VRAM o RAM

Así que 31B es un modelo relativamente grande y necesita hardware más potente.

Qué significa `Gemma-4`

Gemma-4 identifica la familia y la generación del modelo:

Gemma: la familia de modelos abiertos de Google
4: la cuarta generación de esa familia

Cuál elegir

Si tu objetivo es chat, preguntas y respuestas, traducción o programación, la versión -it suele ser la mejor opción.

La versión base tiene más sentido para investigación de bajo nivel, fine-tuning o flujos de entrenamiento personalizados.

Resumen en una línea

gemma-4-31B-it significa: familia Gemma 4, 31 mil millones de parámetros, ajustado por instrucciones para conversación y ejecución de tareas.

Elegir cuantización GGUF de Llama en Hugging Face: consejos prácticos de Q8 a Q2

Sat, 11 Apr 2026 20:07:29 +0800

Al elegir un modelo Llama GGUF en Hugging Face, puedes pensar en los niveles de cuantización como si fueran resolución: los niveles más bajos usan menos VRAM/RAM, pero la calidad cae gradualmente.

Entiende primero 32, 16 y los niveles Q

32: lo más cercano a la calidad original o sin comprimir, pero con requisitos de hardware extremos.
16: todavía muy cerca de la calidad original, con alrededor de la mitad del tamaño de 32.
Q8: punto de entrada común para modelos cuantizados, escrito normalmente como Q8_0 o Q8.
Q6, Q5, Q4, Q3, Q2: cuanto menor es el número, menor es el uso de recursos y mayor el riesgo de pérdida de calidad.

Qué significa `K_M` / `K_S`

K_M y K_S son variantes de cuantización mixta:

la mayoría de pesos se mantienen en el nivel de cuantización objetivo
algunas partes importantes conservan mayor precisión

Por eso, al mismo nivel, Qx_K_M o Qx_K_S suele ser ligeramente mejor que Qx puro.

Estrategia práctica de selección

Si el hardware lo permite, empieza con Q8.
Si la memoria está justa, baja progresivamente a Q6 / Q5 / Q4.
Intenta no bajar de Q4; Q4_K_M es un límite inferior habitual.
Por debajo de Q4, la degradación de calidad se vuelve cada vez más visible.

Orden de calidad, de mejor a peor

32
16

– Por encima de este punto, la calidad es prácticamente igual, pero los requisitos de hardware son extremos –

Q8
Q6_K_M
Q6_K_S
Q6
Q5_K_M
Q5_K_S
Q5

– Este es el punto dulce típico –

Q4_K_M
Q4_K_S
Q4

– Por debajo de este punto, la pérdida de calidad empieza a verse –

Q3_K_M
Q3_K_S
Q3
Q2_K_M
Q2_K_S
Q2

Si quieres una regla corta: empieza con Q8 o Q6_K_M; baja a Q5 o Q4_K_M solo cuando sea necesario.

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.

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.