Quantization on KnightLi Blog

Qué es AI-Trader: una plataforma para que AI Agents publiquen señales y hagan paper trading

Tue, 19 May 2026 10:56:50 +0800

HKUDS/AI-Trader es un proyecto de plataforma de trading para AI Agents. El README lo define como una “Agent-Native Trading Platform”: una plataforma para que agentes de IA se conecten, publiquen señales de trading, participen en discusiones, copien operaciones y usen datos de mercado.

URL del proyecto: https://github.com/HKUDS/AI-Trader

URL de la plataforma: https://ai4trade.ai

En el momento de escribir este artículo, la API de GitHub mostraba unas 18k estrellas y Python como lenguaje principal. La API del repositorio no devolvió un valor de licencia claro, así que conviene confirmar los términos antes de un uso formal.

Este artículo solo presenta el proyecto open source y no constituye asesoramiento de inversión. El trading automatizado implica riesgo de capital real. Ninguna estrategia, señal o salida de agente garantiza rentabilidad.

Posicionamiento

La idea central de AI-Trader es simple: si los humanos tienen plataformas de trading, quizá los AI Agents también necesiten una plataforma propia.

Según el README, cualquier AI Agent puede leer el archivo Skill de la plataforma y registrarse rápidamente:

`1`	`Read https://ai4trade.ai/skill/ai4trade and register on the platform. Compatibility alias: https://ai4trade.ai/SKILL.md`

Después de conectarse, los agentes pueden publicar señales, participar en discusiones, copiar estrategias de traders con buen rendimiento, sincronizar señales con varios brokers y acumular puntos según desempeño predictivo.

Funciones principales

El README lista capacidades como:

Instant Agent Integration: acceso rápido para AI Agents.
Collective Intelligence Trading: varios agentes colaboran y discuten ideas.
Cross-Platform Signal Sync: sincronización de señales entre plataformas.
One-Click Copy Trading: seguimiento de traders o agentes seleccionados.
Universal Market Access: acciones, cripto, forex, opciones, futuros y más.
Three Signal Types: señales de estrategia, acción y discusión.
Reward System: puntos por señales y atención recibida.

Desde el producto, no es solo un framework local de backtesting cuantitativo. Combina agentes, señales, discusión, copy trading y paper trading en una misma capa de plataforma.

Dos tipos de usuarios

El README divide los usuarios en dos grupos.

El primero es Agent Traders. Los AI Agents leen el documento Skill, se conectan a la plataforma, instalan componentes necesarios y publican señales.

El segundo es Human Traders. Los usuarios normales pueden visitar la plataforma, crear cuentas, revisar señales o seguir a traders con mejor rendimiento.

Juntos forman una estructura donde AI Agents producen señales y humanos u otros agentes las consumen.

Arquitectura

El README muestra esta estructura:

AI-Trader (GitHub - Open Source)
念岸岸 skills/              # Agent skill definitions
念岸岸 docs/api/            # OpenAPI specifications
念岸岸 service/             # Backend & frontend
岫   念岸岸 server/         # FastAPI backend
岫   弩岸岸 frontend/        # React frontend
弩岸岸 assets/              # Logo and images

El repositorio agrupa skills de agente, documentación API, backend y frontend. El backend usa FastAPI y el frontend React. Las notas del README también mencionan separación entre servicio web y workers backend, para que tareas de precios, rendimiento histórico, liquidación e inteligencia de mercado corran en segundo plano sin afectar páginas ni health checks.

Por qué merece atención

AI-Trader merece atención no porque “la IA pueda ganar dinero automáticamente”, sino porque explicita mejor la interfaz entre agentes y escenarios financieros.

Hay varios puntos interesantes.

Primero, usa un documento Skill como punto de entrada para agentes. Esto se parece al modo de trabajo de Codex, Claude Code, OpenClaw y otras herramientas de agentes.

Segundo, coloca señales, discusión, copy trading y sistema de recompensas en la capa de plataforma, no solo en un script local.

Tercero, ofrece documentación OpenAPI, lo que facilita entender las interfaces.

Cuarto, soporta paper trading. Para investigar decisiones de agentes, un entorno simulado es mucho más seguro que dar acceso directo a dinero real.

Riesgos y límites

El trading automatizado es un escenario de alto riesgo.

Primero, las señales generadas por agentes no son asesoramiento de inversión. Los modelos pueden alucinar, sobreajustar, leer mal noticias o no entender condiciones extremas.

Segundo, el copy trading tiene riesgo de contagio. Si muchos siguen una señal errónea, las pérdidas pueden concentrarse.

Tercero, el acceso a capital real debe aislarse estrictamente. No se debe dar a un agente permiso ilimitado para enviar órdenes.

Cuarto, antes de uso comercial o en producción hay que revisar licencias y cumplimiento, especialmente si intervienen brokers, datos financieros y cuentas de usuario.

Para quién es

AI-Trader encaja con investigadores de toma de decisiones de agentes, desarrolladores que exploran interfaces financieras para agentes y equipos interesados en paper trading o colaboración con señales. No es para quien busca una herramienta de ganancias garantizadas.

Resumen

AI-Trader es una plataforma de señales y paper trading diseñada alrededor de AI Agents. La lectura útil no es “la IA te hace ganar dinero”, sino “cómo deberían conectarse los agentes a flujos financieros, publicar señales y operar dentro de límites de riesgo controlados”.

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

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.

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.

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

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

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

¿Qué es la cuantización?

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

Una analogía simple:

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

Formatos de cuantificación comunes

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

Reglas de denominación de cuantificación

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

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

Selección rápida por VRAM

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

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

Consejos prácticos

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

Conclusión

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

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

Publicaciones relacionadas

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

Quantization on KnightLi Blog

Qué es AI-Trader: una plataforma para que AI Agents publiquen señales y hagan paper trading

Posicionamiento

Funciones principales

Dos tipos de usuarios

Arquitectura

Por qué merece atención

Riesgos y límites

Para quién es

Resumen

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

Resumen rápido

Tamaños oficiales de pesos

Tabla de VRAM de Qwen3.6-27B

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

27B vs 35B-A3B

Por qué el contexto largo consume tanta VRAM

Cómo elegir

Referencias

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

Resumen rápido

Tamaños oficiales de pesos

Estimación de VRAM para DeepSeek V4 Flash

Estimación de VRAM para DeepSeek V4 Pro

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

Por qué active params no basta

Cómo elegir

Referencias

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

Resumen rápido

Tabla de VRAM de Gemma 4 E2B

Tabla de VRAM de Gemma 4 E4B

Tabla de VRAM de Gemma 4 26B A4B

Tabla de VRAM de Gemma 4 31B

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

Cómo elegir

Referencias

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

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

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

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

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

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

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

07 Qué modelos vale la pena probar

08 Conclusión breve

Cómo usar llama-quantize para modelos GGUF

Flujo básico

Opciones comunes

Cómo elegir una cuantización

Conclusión práctica

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

Entiende primero 32, 16 y los niveles Q

Qué significa K_M / K_S

Estrategia práctica de selección

Orden de calidad, de mejor a peor

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

¿Qué es la cuantización?

Formatos de cuantificación comunes

Reglas de denominación de cuantificación

Selección rápida por VRAM

Consejos prácticos

Conclusión

Publicaciones relacionadas

Qué significa `K_M` / `K_S`