Despliegue local de Qwen3.6-35B-A3B jailbreak: GGUF sin censura, llama.cpp y límites de seguridad

Una guía práctica sobre Qwen3.6-35B-A3B Uncensored en GGUF: cuantizaciones, VRAM, parámetros de llama.cpp, mmproj multimodal, API local compatible con OpenAI y límites de seguridad.

Freedidi presentó recientemente un modelo local popular: Qwen3.6-35B-A3B Uncensored HauhauCS Aggressive. El artículo original lo describe como un modelo abierto jailbreak o sin censura, y ofrece archivos GGUF cuantizados, una forma de lanzarlo con llama.cpp e ideas para conectarlo con agentes.

Este tipo de modelo merece atención, pero conviene entenderlo con calma. Lo importante no es solo que tenga menos restricciones. Reúne varias capacidades clave de la IA local:

  • Un modelo de clase 35B con arquitectura MoE.
  • Cuantización GGUF capaz de correr en GPUs de consumo.
  • API local compatible con OpenAI mediante llama.cpp.
  • Entrada multimodal de visión mediante mmproj.
  • Integración con herramientas locales de agentes como Hermes y OpenClaw.

Si te interesan los modelos locales, lo más relevante no es la etiqueta jailbreak. Es la tendencia: los modelos locales pasan de “pueden chatear” a “pueden usar herramientas, entender imágenes y servir como backend de agentes”.

Qué es este modelo

El nombre completo citado en el artículo original es:

1
Qwen3.6-35B-A3B Uncensored HauhauCS Aggressive

El nombre deja varias pistas:

  • Qwen3.6: basado en la familia Qwen.
  • 35B: alrededor de 35B parámetros totales.
  • A3B: cerca de 3B parámetros activos por paso de inferencia, con lógica tipo MoE.
  • Uncensored / Aggressive: menos restricciones de seguridad o un ajuste más agresivo.
  • GGUF: formato cuantizado para herramientas locales como llama.cpp.

Importante: Uncensored no significa más fiable. Normalmente significa menos rechazos, pero también puede generar contenido menos restringido, no verificado o riesgoso. Puede servir para investigación técnica, pero no debería conectarse directamente a servicios públicos, sistemas de producción o tareas desatendidas.

Por qué un modelo 35B puede correr en local

Al ver 35B, muchos piensan en servidores o máquinas multi-GPU. La clave destacada en el artículo es que el modelo usa una arquitectura MoE.

MoE puede entenderse así: el modelo tiene muchos parámetros totales, pero cada paso de inferencia solo activa una parte de los expertos. El artículo dice que se activan unos 3B parámetros por ejecución, así que con cierta cuantización la presión de velocidad y VRAM puede ser mucho menor que en un dense 35B tradicional.

Con GGUF cuantizado, puede ejecutarse en GPUs de consumo. El artículo menciona una versión mínima de unos 11GB, posible de probar con 6GB/8GB de VRAM, aunque recomienda al menos 8GB.

Una expectativa más realista:

  • 6GB VRAM: posible con cuantización baja, pero con expectativas reducidas de contexto y velocidad.
  • 8GB VRAM: mejor para pruebas iniciales con cuantizaciones pequeñas.
  • 16GB VRAM: más cómodo para contexto más largo y más offload a GPU.
  • 24GB VRAM: mejor para cuantizaciones de mayor calidad como Q4_K_M y Q4_K_P.

Que un modelo local sea usable no depende solo de que arranque. Importan longitud de contexto, velocidad, VRAM restante, KV cache, modo multimodal, concurrencia y tipo de tarea.

Cómo entender las cuantizaciones

El artículo recomienda aproximadamente:

  • Q4_K_P: mejor para RTX 4090 u otras máquinas con 24GB de VRAM.
  • Q4_K_M: más estable y de mejor calidad.
  • IQ4_NL: alta compresión intentando conservar calidad.
  • IQ2_M: para usuarios con 6GB/8GB de VRAM.

Es un intercambio entre calidad y recursos:

  • Las cuantizaciones Q4 suelen ser más estables, pero consumen más VRAM.
  • IQ2 / IQ3 ahorran recursos, pero pueden reducir calidad, estabilidad en textos largos y detalle.
  • Si solo quieres probar llamadas de agente y API local, una cuantización baja ayuda a validar el flujo.
  • Si quieres escribir código, analizar imágenes o razonar durante mucho tiempo, conviene elegir más calidad.

No confundas “arranca” con “sirve para uso prolongado”. Son cosas distintas.

Despliegue con llama.cpp

El artículo recomienda llama.cpp porque soporta Windows, Linux, macOS y backends como NVIDIA CUDA, AMD, Intel, Vulkan y CPU.

Un lanzamiento típico se parece a esto:

1
2
3
4
5
6
7
8
9
llama-server.exe ^
  -m "ruta-del-modelo.gguf" ^
  --mmproj "mmproj.gguf" ^
  -ngl 999 ^
  -c 131072 ^
  -n 8192 ^
  --host 127.0.0.1 ^
  --port 8080 ^
  --jinja

Parámetros importantes:

  • -m: ruta del modelo GGUF principal.
  • --mmproj: archivo de proyección multimodal, necesario para visión.
  • -ngl: intenta offload de capas a GPU según VRAM y backend.
  • -c: longitud de contexto; cuanto mayor, más memoria y VRAM.
  • -n: límite de tokens generados por respuesta.
  • --host 127.0.0.1: escuchar solo en local, más seguro que exponerlo.
  • --port 8080: puerto de API local.
  • --jinja: importante para plantillas de chat de modelos Qwen nuevos; sin ello puede haber formato roto, repeticiones o problemas de idioma.

La trampa más común es la longitud de contexto. -c 131072 suena atractivo, pero aumenta mucho el KV cache. En máquinas con poca VRAM, empieza más bajo y sube gradualmente.

Uso multimodal

El artículo menciona que esta versión soporta visión multimodal: imágenes, capturas, OCR, UI compleja y capturas de código.

En llama.cpp, lo multimodal suele requerir el modelo principal y el archivo mmproj correspondiente. Si --mmproj no se carga bien, la carga de imágenes puede no estar disponible o el modelo puede no entender las imágenes.

Casos útiles:

  • Analizar capturas de UI.
  • OCR de texto en imágenes.
  • Leer capturas de código o errores.
  • Dar entrada visual a agentes locales.
  • Procesar imágenes privadas sin subirlas a la nube.

Pero visión no equivale a OCR estricto ni fuente única de verdad. Facturas, contratos, documentos, imágenes médicas y contenido de alto riesgo requieren revisión humana.

API compatible con OpenAI

llama-server de llama.cpp puede exponer una interfaz local similar a OpenAI API. La URL base local citada es:

1
http://127.0.0.1:8080/v1

Esto permite que herramientas con proveedores OpenAI-compatible personalizados envíen solicitudes al modelo local. La API key suele poder ser un valor de relleno, según si el cliente la valida.

Esto es útil porque:

  • No requiere API key en la nube.
  • No hay coste por token.
  • Los datos pueden quedarse en la máquina.
  • Puede conectarse a agentes locales, asistentes de código o frontends de chat.
  • Puede servir como backend local experimental compatible con OpenAI API.

No expongas esta API local directamente a internet. Aunque el modelo esté en local, una API abierta puede ser abusada, consumir recursos o generar contenido no deseado.

Por qué importan Hermes y OpenClaw

El artículo señala que su valor se ve mejor al conectarlo a Hermes u OpenClaw.

La idea es que el modelo por sí solo es el núcleo de inferencia. Las herramientas de agente lo conectan con tareas reales:

  • Escribir código.
  • Llamar herramientas.
  • Leer archivos.
  • Analizar imágenes.
  • Buscar en la web.
  • Ejecutar tareas de varios pasos.
  • Mantener flujos con contexto largo.

Un modelo local usado solo para chatear tiene valor limitado. Si puede funcionar como backend estable de agente, se acerca más a una estación local de IA.

Pero conectar un modelo sin censura a un agente exige más cuidado. Si el agente puede operar archivos, ejecutar comandos, visitar páginas y llamar herramientas, la salida del modelo se convierte en acción real. Cuantas menos restricciones tenga el modelo, más importantes son permisos externos, confirmación humana y logs de auditoría.

Límites de seguridad de modelos sin censura

El principal atractivo de estos modelos suele ser que rechazan menos. Pero menos rechazos implican más riesgo.

Ten en cuenta:

  • Puede producir contenido ilegal, peligroso o engañoso con más facilidad.
  • Puede no recordar límites de seguridad por iniciativa propia.
  • Puede dar consejos demasiado seguros en temas de alto riesgo.
  • Puede ser inducido por prompts a tareas inapropiadas.
  • No es adecuado para exposición pública directa.

Un enfoque más seguro:

  • Probar solo en local o en una LAN controlada.
  • No conectarlo a herramientas con altos privilegios.
  • No permitir ejecución automática de borrado, pago, publicación o envíos masivos.
  • Definir límites de permisos para archivos, comandos, red y navegador.
  • Mantener revisión humana para salidas de alto riesgo.

Cuanto más libre es el modelo, más restricciones externas necesita.

Para quién tiene sentido

Este tipo de modelo encaja con usuarios que:

  • Quieren estudiar despliegue local de LLM.
  • Tienen al menos 8GB de VRAM y aceptan ajustar GGUF y llama.cpp.
  • Quieren conectar modelos locales a clientes OpenAI-compatible.
  • Se interesan por multimodal local, análisis de capturas y backends de agentes.
  • Quieren procesar algunos datos privados sin conexión.

Encaja peor con:

  • Principiantes que no quieren ajustar parámetros.
  • Servicios que necesitan SLA estable de producción.
  • Equipos con altos requisitos de seguridad y cumplimiento.
  • Flujos de negocio que requieren fiabilidad factual estricta.
  • Personas que quieren exponer el modelo directamente a usuarios externos.

Conclusión

Modelos como Qwen3.6-35B-A3B Uncensored HauhauCS Aggressive muestran que la IA local avanza rápido. GPUs de consumo pueden correr modelos más grandes, GGUF reduce la barrera de despliegue, llama.cpp ofrece API compatible con OpenAI, y lo multimodal más herramientas de agente empujan de chat a ejecución de tareas.

Pero no conviene entenderlo solo como un modelo jailbreak. La lectura más útil es que la IA local se está volviendo infraestructura componible. Modelo, motor de inferencia, servidor API, frontend, herramientas de agente y control de permisos determinan juntos la experiencia final.

Si lo pruebas, empieza con pruebas locales de bajo riesgo: elige una cuantización adecuada, reduce contexto, verifica --jinja y --mmproj, y luego conecta el cliente. Cuando sea estable, considera flujos de agente.

Referencias:

记录并分享
Creado con Hugo
Tema Stack diseñado por Jimmy