CyberSecQwen-4B: modelo local para defensa cibernética
CyberSecQwen-4B es un modelo de 4B afinado para tareas de inteligencia de amenazas que busca correr localmente, preservar evidencia y competir con modelos de 8B en métricas CTI. Entrenado en un AMD MI300X con ROCm 7 y vLLM, la receta demuestra portabilidad y ofrece un balance práctico entre rendimiento y desplegabilidad.
CyberSecQwen-4B nace de una pregunta práctica: ¿puede la defensa cibernética usar modelos que corran localmente, preserven evidencia sensible y a la vez rindan como modelos más grandes? La respuesta del equipo fue un sí con condiciones. Aquí te explico por qué importa, cómo lo entrenaron y qué significa para un SOC, un investigador de vulnerabilidades o un equipo de infraestructura crítica.
Por qué los modelos locales importan en ciberdefensa
¿Te imaginas pegar un volcado de credenciales o un binario sospechoso en una API pública? No lo hagas. En defensa, el dato es la falla. Enviar evidencia a un servicio externo puede ser exactamente la filtración que buscas evitar.
Además, el costo por llamada y la realidad de entornos air-gapped son limitantes concretos. Un SOC mediano procesa miles de alertas diarias: externalizar explicaciones de CVE o mapeos a CWE se vuelve caro y, a veces, imposible desde redes aisladas.
Finalmente, los adversarios automatizan: desde generar phishing en docenas de idiomas hasta encadenar herramientas agenticas. Si la defensa va a competir, necesita modelos que puedas ejecutar en tu hardware, sin mandar secretos fuera.
Local no es solo ejecutar en tu máquina. Es poder desplegar en laptops, GPU on-prem y entornos con conexión parcial, sin sacrificar la calidad en las tareas que importan.
Qué es CyberSecQwen-4B y qué demuestra
CyberSecQwen-4B es un fine-tune especializado de 4B parámetros sobre un checkpoint Qwen3-4B-Instruct-2507. La apuesta: un modelo de 4B afinado cuidadosamente puede igualar o superar a modelos de 8B en tareas CTI (Cyber Threat Intelligence) concretas, y además caber en una GPU de consumidor con 12 GB.
Resultados clave en CTI-Bench (n=5, temp 0.3):
| Métrica (CTI-Bench) | CyberSecQwen-4B | Foundation-Sec-Instruct-8B | Δ |
|---|---|---|---|
| CTI-MCQ (2,500 ítems) | 0.5868 ± 0.0029 | 0.4996 | +8.7 pp |
| CTI-RCM (1,000 CVE→CWE ítems) | 0.6664 ± 0.0023 | 0.6850 | −1.9 pp |
| Parámetros | 4 B | 8 B | mitad del tamaño |
En pocas palabras: mantiene 97.3% del accuracy RCM del 8B y supera ampliamente en MCQ. Para un defensor que decide qué desplegar, esa relación rendimiento/uso de recursos es la que cuenta.
Cómo se entrenó (ingredientes técnicos)
La experiencia fue íntegramente en un único AMD Instinct MI300X con 192 GB HBM3 usando ROCm 7 y la pila vLLM. Esa configuración permitió entrenamiento bf16 completo, FlashAttention-2 forward+backward y secuencia de 4096 sin técnicas de cuantización o particionado.
Principales componentes y versiones:
- Hardware: AMD Instinct MI300X 192 GB · gfx942
- ROCm: 7.0
- Docker: vllm/vllm-openai-rocm:latest
- PyTorch: 2.6.0 (ROCm)
- flash-attn: 2.8.3
- vLLM: 0.10.1
Hiperparámetros y detalles de receta:
- Base:
Qwen3-4B-Instruct-2507(afinada sobre checkpoint IT, no sobre pretrain puro) - LoRA r = 64, alpha = 64, dropout = 0.05
- LR = 5e-5 con schedule coseno, warmup ratio 0.03
- Épocas = 10
- Precisión = bf16
- Atención = FlashAttention-2 (forward + backward)
- Max seq len = 4096
- Batch = 4 (sin acumulación)
- Optimizador =
paged_adamw_8bit
El step time se estabilizó alrededor de ~7.85 s/step en MI300X con esta receta. FlashAttention-2 encaja bien por el head_dim de Qwen (128) dentro del shared-memory budget del MI300X.
Corpus, licencias y limpieza de datos
La fine-tune usó dos corpus Apache-2.0 clean:
- Mapeos CVE → CWE 2021 desde MITRE / NVD, deduplicados contra CTI-Bench para evitar contaminación de evaluación.
- Q&A sintético con contexto defensivo, generado por un teacher más potente y liberado bajo Apache-2.0.
Deduplicar el conjunto de entrenamiento con el benchmark fue clave para que los números sean honestos y fuera de distribución.
Portabilidad y verificación de la receta
¿La mejora viene del caso MI300X o de la receta? Para comprobarlo entrenaron una hermana: Gemma4Defense-2B usando exactamente la misma receta y corpus pero con base Gemma-4-E2B-it. Resultados:
| Modelo | CTI-RCM (media ± std) | CTI-MCQ |
|---|---|---|
| CyberSecQwen-4B (Qwen base) | 0.6664 ± 0.0023 | 0.5868 ± 0.0029 |
| Gemma4Defense-2B (Gemma base) | 0.6754 ± 0.0035 | 0.6042 ± 0.0090 |
Conclusión: la receta viaja. El punto está en cómo afinas el checkpoint IT, no solo en la familia del modelo. La elección entre Qwen y Gemma puede venir por licencias o presupuesto de despliegue (2B vs 4B).
Ejemplo de inferencia (rápido)
Uso mínimo para correr en cualquier GPU de 12 GB+:
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch
model_id = "lablab-ai-amd-developer-hackathon/CyberSecQwen-4B"
tok = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(model_id, torch_dtype=torch.bfloat16, device_map="auto")
messages = [
{"role": "system", "content": "You are a defensive cybersecurity assistant. Answer with the canonical CWE-ID first, then 1-3 sentences of justification."},
{"role": "user", "content": "Path traversal in a Java web app where user-controlled input concatenates into a File() path. What's the CWE?"},
]
prompt = tok.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
out = model.generate(**tok(prompt, return_tensors="pt").to(model.device), max_new_tokens=256, temperature=0.3)
print(tok.decode(out[0], skip_special_tokens=True))
Para serving de alto rendimiento, vLLM funciona en MI300X con la imagen vllm/vllm-openai-rocm. Hay comandos y config pinned en el repo si quieres desplegarlo.
Limitaciones y uso responsable
CyberSecQwen-4B está diseñado para tareas defensivas: mapeo CWE, Q&A CTI estructurado y asistencia en triage. No está pensado para generar exploits, automatizar decisiones críticas sin revisión humana, ni dar asesoría legal o médica.
El equipo planea trabajar en robustez a ejemplos adversariales y en evaluaciones continuas a medida que NVD crece. Un especialista solo es tan bueno como su peor entrada; hardening contra prompt-injection es prioridad.
Problemas encontrados y soluciones prácticas
| Problema | Solución |
|---|---|
| FA2 falla en Gemma-4 con head_dim=512 | Caer a sdpa para global-attention; local-attention sigue usando FA2. Resultado: ~1.6x más lento vs Qwen con FA2. |
| Conflicto AITER en serving con CyberPal-2.0-20B | Poner VLLM_ROCM_USE_AITER=0 para esa evaluación particular. |
| bitsandbytes no soportado oficialmente en ROCm | No fue necesario por 192 GB HBM; se usó paged_adamw_8bit como camino de optimizador. |
| Demo en HF Spaces con cuota ZeroGPU | El demo usa HF OAuth para que cada visitante consuma su propia cuota gratuita. |
Qué sigue y cómo puedes participar
Prioridades del equipo:
- Variante 1B para laptops y despliegue en clase consumidor.
- Lanzamiento cuantizado en GGUF (Q4_K_M, Q5_K_M) para edge y móviles.
- Evaluación continua contra nuevas entradas de CVE.
- Pass de hardening adversarial contra prompt-injection.
Si alguno de esos puntos te interesa, abre un issue en el repo del proyecto: eso mueve prioridades.
La lección es clara: la conversación sobre IA y defensa debe cambiar de escala a encaje. No siempre necesitas el modelo más grande, sino el que mejor se adapta a tus restricciones operativas: privacidad, coste y capacidad de ejecución on-prem. Un 4B especialista que iguala a un 8B en las tareas que importan, corre en hardware asequible y no filtra evidencia fuera de tu red, es un aporte práctico para cualquier equipo de seguridad.