Hugging Face on KnightLi Blog

Gemma 4 E4B Sin censura versus oficial: lo que realmente cambia

Sat, 18 Apr 2026 10:20:00 +0800

Si ve un modelo como HauhauCS/Gemma-4-E4B-Uncensored-HauhauCS-Aggressive, el punto más importante es este: no es un nuevo modelo base de Google. Es una versión derivada construida sobre el google/gemma-4-E4B-it oficial, pero con un comportamiento de alineación impulsado intencionalmente hacia menos rechazos.

Eso significa que la verdadera diferencia suele ser la política de comportamiento y el estilo de respuesta, no una arquitectura completamente nueva.

Lo que afirma explícitamente el modelo derivado

Según su tarjeta modelo Hugging Face, el comunicado de HauhauCS dice:

está basado en google/gemma-4-E4B-it
“no realiza cambios en los conjuntos de datos ni en las capacidades”
es “simplemente sin negativas”
la variante “Agresiva” está “totalmente desbloqueada y no rechaza indicaciones”

Esas son las afirmaciones del creador, no un punto de referencia independiente. Aún así, te dicen muy claramente el posicionamiento previsto: se trata de un derivado no oficial optimizado para reducir los fallos de seguridad.

Modelo oficial versus derivado “sin censura”

Dimensión	Oficial `google/gemma-4-E4B-it`	`Gemma-4-E4B-Sin censura-HauhauCS-Agresivo`
Fuente	Lanzamiento oficial de Google	Derivado de terceros sobre Hugging Face
Arquitectura básica	Modelo Gemma 4 E4B ajustado por instrucciones	Misma familia base, descrita explícitamente como basada en `google/gemma-4-E4B-it`
Objetivo principal	Asistente útil de uso general con marcos de uso responsable	Reducir las negativas y seguir respondiendo incluso cuando el modelo oficial pueda decaer
Postura de seguridad	Alineado con los documentos de seguridad de la familia Gemma y la política de uso prohibido	Comportamiento de rechazo intencionalmente debilitado
Estilo de respuesta	Es más probable que rechace, redirija o suavice determinadas solicitudes	Es más probable que responda directamente, incluidas las indicaciones que el modelo oficial puede bloquear
Perfil de riesgo	Menor riesgo de uso indebido por defecto, pero aún no está libre de riesgos	Mayor riesgo de uso indebido, mayor probabilidad de resultados inseguros o no conformes
Previsibilidad en productos	Más fácil de justificar en aplicaciones normales y entornos empresariales	Más difícil de justificar en implementaciones públicas, empresariales o sensibles a las políticas
Carga de cumplimiento	Todavía requiere salvaguardias a nivel de aplicación	Requiere salvaguardias posteriores aún más estrictas porque el modelo en sí es menos restrictivo

La diferencia principal es la alineación, no la capacidad bruta

Muchos usuarios tratan erróneamente “sin censura” como si significara “más inteligente”. Ese suele ser el marco equivocado.

Para una derivada como esta, lo que cambia primero es:

con qué frecuencia el modelo se niega
con qué firmeza sigue instrucciones perjudiciales o sensibles a las políticas
cuánto filtrado queda en sus respuestas finales

Qué no cambia automáticamente:

la arquitectura familiar subyacente de Gemma 4
clase de ventana de contexto
clase de apoyo multimodal
techo de razonamiento general

En otras palabras, un derivado sin censura a menudo se describe mejor como un ajuste de comportamiento diferente de la misma familia de modelos, no como un modelo de nivel superior.

Por qué la versión oficial se comporta de manera diferente

Los materiales oficiales de Gemma de Google enmarcan a la familia como creada para el desarrollo responsable de la IA. La tarjeta modelo Gemma destaca el uso indebido, el contenido dañino, la privacidad y los riesgos de sesgo, y la Política de uso prohibido de Gemma de Google prohíbe explícitamente el uso de Gemma o modelos derivados para:

facilitar actividades peligrosas, ilegales o maliciosas
generar contenido dañino o engañoso
anular o eludir los filtros de seguridad

De modo que el modelo oficial no es simplemente “más conservador” por casualidad. Su política circundante y su postura de despliegue prevista son deliberadamente diferentes.

Cuando el modelo oficial es la mejor opción

Utilice la ruta oficial google/gemma-4-E4B-it si le interesa:

implementación de productos
uso empresarial o en equipo
menor exposición legal y política
menos salidas obviamente inseguras
documentación y revisión más sencillas

Para la mayoría de las aplicaciones normales, este es el valor predeterminado más seguro.

Cuando la gente elige el derivado sin censura

Los usuarios suelen elegir un derivado sin censura para:

experimentación privada local
pruebas donde el modelo oficial se niega demasiado pronto
juego de roles o indicaciones creativas abiertas
comparar el comportamiento de alineación entre variantes

Pero esto conlleva una verdadera compensación: usted está transfiriendo más responsabilidad de seguridad del proveedor del modelo a usted mismo.

Conclusión práctica

La diferencia entre un Gemma 4 E4B llamado “jailbreak” y la versión oficial normal es principalmente la siguiente:

la versión oficial está optimizada para su capacidad utilizable con barandillas
el derivado sin censura está optimizado para menos rechazos con barandillas más débiles

Eso no fortalece automáticamente el modelo sin censura. Principalmente lo hace más permisivo.

Si su objetivo es una implementación estable, explicable y de menor riesgo, utilice primero el modelo oficial. Si su objetivo es la experimentación local y comprende las ventajas y desventajas de cumplimiento y seguridad, entonces un derivado sin censura es una variante de comportamiento que vale la pena probar por separado, no un reemplazo “mejor” directo.

Fuentes

Cara de abrazo: HauhauCS/Gemma-4-E4B-Uncensored-HauhauCS-Aggressive
Cara de abrazo: google/gemma-4-E4B-it
Google AI para desarrolladores: Política de uso prohibido de Gemma
Google AI para desarrolladores: tarjeta modelo Gemma

¿Dónde guarda llama-cli -hf los modelos de caras abrazadas de forma predeterminada?

Fri, 17 Apr 2026 14:48:04 +0800

Si usa llama-cli para descargar y ejecutar un modelo directamente desde Hugging Face, por ejemplo:

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

esto utiliza el soporte de descarga de Hugging Face integrado en llama.cpp. Las compilaciones recientes de llama.cpp almacenan modelos descargados con -hf en el directorio de caché estándar de Hugging Face Hub.

Ubicaciones de caché predeterminadas

La ubicación del caché utilizada por llama-cli -hf se controla primero mediante la variable de entorno LLAMA_CACHE. Si LLAMA_CACHE no está configurado, llama.cpp verifica las variables de caché de Hugging Face como HF_HUB_CACHE, HUGGINGFACE_HUB_CACHE y HF_HOME.

Si no se establece ninguna de esas variables, las rutas predeterminadas comunes son:

Sistema	Directorio de caché predeterminado
Linux	`~/.cache/huggingface/hub`
MacOS	`~/.cache/huggingface/hub`
Ventanas	`%PERFIL DE USUARIO%\.cache\huggingface\hub`

En Windows, %USERPROFILE% normalmente se expande a:

`1`	`C:\Users\用户名`

Entonces el directorio de caché predeterminado es aproximadamente:

`1`	`C:\Users\用户名\.cache\huggingface\hub`

Cómo cambiar el directorio de caché llama-cli

Configure LLAMA_CACHE si desea almacenar los modelos descargados en un disco específico o en una carpeta específica. También puedes seguir la convención de Hugging Face y configurar HF_HOME; en ese caso, el directorio de caché del concentrador será $HF_HOME/hub.

Ejemplo de CMD temporal de Windows:

1
2

set LLAMA_CACHE=D:\models\llama-cache
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

Ejemplo de PowerShell temporal:

1
2

$env:LLAMA_CACHE="D:\models\llama-cache"
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

Ejemplo temporal de Linux/macOS:

1
2

export LLAMA_CACHE=/data/models/llama-cache
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

Resumen

llama-cli -hf ... usa la lógica de descarga de llama.cpp, pero las compilaciones recientes utilizan de forma predeterminada el caché de Hugging Face Hub.
Valor predeterminado de Linux/macOS: ~/.cache/huggingface/hub
Valor predeterminado de Windows: %USERPROFILE%\.cache\huggingface\hub
Para cambiar la ubicación, configure LLAMA_CACHE o configure HF_HOME / HF_HUB_CACHE

Cómo reparar el error de verificación del certificado SSL cuando llama-cli se descarga desde Hugging Face en Windows

Fri, 17 Apr 2026 14:20:29 +0800

Si ejecuta este comando en Windows:

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

y veo un error como este:

1
2

get_repo_commit: error: HTTPLIB failed: SSL server verification failed
error: failed to download model from Hugging Face

Por lo general, el problema no es CUDA ni llama.cpp. Más a menudo, el programa no puede acceder correctamente a la cadena de certificados del sistema en el entorno actual, por lo que falla la verificación HTTPS.

Desde el registro, ggml-rpc.dll y ggml-cpu-alderlake.dll se cargaron correctamente, lo que significa que el entorno de ejecución está prácticamente bien. El problema está principalmente en el paso de descarga del modelo.

La solución más sencilla: descargar el modelo manualmente

Si sólo desea que funcione rápidamente, descargar el modelo manualmente suele ser la opción más estable.

Abra la página del repositorio de Hugging Face correspondiente.
Descargue el archivo .gguf requerido desde Archivos y versiones.
Una vez finalizada la descarga, ejecútela con la ruta del archivo local:

`1`	`llama-cli -m C:\Users\knightli\Downloads\gemma-4-e4b-it.gguf`

Esto omite la verificación SSL durante el paso de descarga -hf y es útil cuando solo desea verificar que el modelo se puede ejecutar localmente.

Si aún deseas utilizar la descarga automática `-hf`

Puede especificar manualmente una ruta de archivo de certificado para que el programa pueda encontrar un paquete de CA utilizable en la sesión actual.

cacert.pem se puede obtener de la página de extracto de CA mantenida por el proyecto curl:

Página: https://curl.se/docs/caextract.html
Descarga directa: https://curl.se/ca/cacert.pem

Si lo descarga en un navegador, abra el enlace de descarga directa y guárdelo como cacert.pem. También puedes descargarlo a un directorio fijo con PowerShell:

1
2

New-Item -ItemType Directory -Force C:\certs
Invoke-WebRequest -Uri https://curl.se/ca/cacert.pem -OutFile C:\certs\cacert.pem

Una vez finalizada la descarga, configure estas variables en la línea de comando:

1
2

set SSL_CERT_FILE=C:\certs\cacert.pem
set CURL_CA_BUNDLE=C:\certs\cacert.pem

Luego ejecute el comando original nuevamente:

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

Si el problema realmente proviene de la cadena de certificados, esto generalmente lo soluciona directamente.

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.