---

license: mit

library_name: llama.cpp

tags:

- gguf

- qwen3.5

- qwen3.6

- spanish

- espanol

- chile

- fine-tuned

- lora

- moe

- llama.cpp

base_model: Qwen/Qwen3.6-35B-A3B

pipeline_tag: text-generation

---

Qwen3.6-35B-A3B — Español Neutro/Chileno 🇨🇱 (GGUF Q4_K_M)

Fine-tune de Qwen3.6-35B-A3B (MoE, 35B total / 3B activos) orientado a español neutro con sesgo chileno, cuantizado a Q4_K_M (20 GB) y listo para correr en una RTX 3090 24GB a ~169 tok/s con llama.cpp.

¿Por qué existe este modelo?

Los modelos Qwen, al hablar español, tienden a arrastrar voseo y modismos rioplatenses ("vos", "querés", "che"). Este fine-tune corrige ese sesgo con un dataset de 200k ejemplos:

• 100k ejemplos de C4 filtrados a dominios .cl (español chileno real)
• 100k ejemplos de español neutro
• Filtro anti-rioplatense aplicado: se descartaron 5,249 ejemplos con marcadores de voseo/argentismos (quedaron 49,752 de la muestra de 50k en la fase de curado)

Resultado: español neutro estándar, con vocabulario y registro natural chileno, sin voseo.

Entrenamiento

| Parámetro | Valor |

|---|---|

| Base | Qwen/Qwen3.6-35B-A3B |

| Método | LoRA r=64 (merge incluido en este GGUF) |

| Pasos | 750 (corrida de validación; run completo 3000 planificado) |

| Precisión | bf16 nativo |

| Hardware | A100 SXM4 80GB (Vast.ai) |

| Secuencia | 512 tokens, batch 1 × grad accum 16 |

| Trainer | transformers.Trainer directo (NO SFTTrainer — el modelo MoE híbrido Mamba/SSM + atención rompe el chunked CE de TRL) |

| Detalles | gradient_checkpointing con use_reentrant=True, attn_implementation="sdpa", merge con peft 0.15.1 |

⚠️ Nota técnica importante (parche GGUF)

La conversión convert_hf_to_gguf.py de esta arquitectura genera metadata MTP inconsistente: declara block_count=41 y nextn_predict_layers=1, pero el modelo solo tiene 40 bloques y no exporta tensores nextn.*. Esto hace fallar llama.cpp con:

missing tensor 'blk.39.nextn.eh_proj.weight'

El archivo de este repo lleva aplicado un parche binario que corrige dos campos del header GGUF:

• qwen35moe.block_count: 41 → 40
• qwen35moe.nextn_predict_layers: 1 → 0

Sin este parche, llama.cpp no carga el modelo. Con el parche, carga y sirve perfectamente. (vLLM 0.25.x no es alternativa: removió el loader GGUF y no soporta esta arquitectura híbrida.)

Uso con llama.cpp

llama-server \
  -m model_qwen35b_espanol_Q4_K_M.gguf \
  --alias qwen35b-espanol \
  -c 4096 -ngl 99 \
  --port 8080 --host 0.0.0.0

API compatible con OpenAI en /v1/chat/completions. El modelo usa modo thinking: gasta tokens en razonamiento antes de responder; si el content llega vacío, sube max_tokens (≥ 800).

Rendimiento medido (RTX 3090): ~169 tok/s generación, ~113 tok/s prompt, ~20.6 GB VRAM.

Archivos

| Archivo | Descripción |

|---|---|

| model_qwen35b_espanol_Q4_K_M.gguf | Modelo final cuantizado, parcheado y listo |

El LoRA adapter (64MB), scripts de entrenamiento/merge y configuraciones se publican por separado en jpalmae/qwen35b-espanol-lora.

Limitaciones

• Entrenamiento de validación (750 pasos sobre 3000 planeados) — es una muestra de viabilidad, no el run final
• Contexto entrenado corto (512 tokens); el modelo base soporta 262k pero el fine-tune no exploró longitudes largas
• Arquitectura híbrida Mamba/SSM + MoE: soporte en ecosistema aún inmaduro (ver nota del parche)

Licencia

MIT — úsalo, modifícalo, redistribúyelo libremente.

---

Pipeline completo: dataset C4 .cl + neutro → LoRA en A100 → merge bf16 → GGUF F16 → Q4_K_M → parche header → llama-server en RTX 3090.