Instalar KAT-Coder-V2.5-Dev-APEX-MTP en Ollama

por
Tiempo de lectura: 3 minutos

Guía paso a paso basada en la instalación real de KAT-Coder-V2.5-Dev-APEX-MTP en ollama

Antes de instalar nada: evaluar si el modelo merece la pena (https://huggingface.co/gbuzhf/KAT-Coder-V2.5-Dev-APEX-MTP-GGUF)

No todos los repos de HF son iguales. Antes de descargar varios GB, conviene mirar:

Señal buenaSeñal de alarma
Autor reconocido en la comunidad (bartowski, unsloth, etc.) o base model con trayectoriaCuenta nueva, README con banners/emojis tipo marketing
Benchmarks con tamaño de muestra decente y metodología clara«Research preview» + benchmarks con n=15 sin comparación independiente
Checksums SHA256, manifest de build, procedencia de tensores explicadaCero verificación, cero credits claros
Licencia clara (Apache-2.0, etc.)Licencia ambigua o derivados sin trazabilidad
Otros quantizers reconocidos ya han cuantizado el mismo modelo baseEs el único repo que existe para ese modelo

Truco: si un modelo tiene un quant de bartowski (o similar), es una señal fuerte de que el modelo base es legítimo y de interés real — bartowski cuantiza casi todo lo relevante que sale. Buscar bartowski/<nombre-del-modelo-base>-GGUF en HF es una forma rápida de validar un modelo nuevo…

1. Instalación directa desde Ollama (la vía fácil)

Si el repo de HF usa nombres de cuantización estándar (Q4_K_M, IQ3_M, etc.), esto basta:

bash

docker exec -it ollama ollama run hf.co/usuario/repositorio-GGUF:Q4_K_M

Ollama descarga el archivo, detecta metadata y arranca. Fin.

Cuando esto falla

Si el repo usa nombres de cuantización no estándar (por ejemplo I-Compact-v2D-lite, típico de métodos custom como APEX), Ollama devuelve:

Error: pull model manifest: 400: {"error":"The specified tag is not a valid quantization scheme. Please use another tag or \"latest\""}

Esto pasa porque Ollama intenta mapear el tag contra su lista cerrada de schemes conocidos y no reconoce el nombre.

Solución: usar el nombre completo del archivo .gguf como tag, no el nombre corto:

docker exec -it ollama ollama pull hf.co/usuario/repositorio-GGUF:Kwaipilot_KAT-Coder-V2.5-Dev-APEX-MTP-I-Compact-v2D-lite.gguf

Con el filename completo, Ollama lo trata como referencia directa al archivo en vez de intentar interpretar un scheme, y resuelve sin problema.

2. Verificar que se instaló bien

docker exec -it ollama ollama list

Confirma que aparece con el nombre completo:

NAME                                                                     ID              SIZE
hf.co/usuario/repositorio-GGUF:Kwaipilot_KAT-Coder-...I-Compact...gguf   ec643c3fa4c7    17 GB

3. El paso que casi siempre falla: la chat template

Muchos GGUF —sobre todo los que vienen de merges, injertos custom (MTP grafting, etc.) o conversiones manuales— no traen la metadata del chat_template embebida correctamente. Hay que comprobarlo siempre:

bash

docker exec -it ollama ollama show hf.co/usuario/repositorio-GGUF:archivo.gguf --modelfile

Síntoma del problema

Si ves esto:

TEMPLATE {{ .Prompt }}

…significa que Ollama no tiene ninguna plantilla de chat aplicada. El modelo va a recibir los mensajes en crudo, sin tags de sistema/usuario/asistente, sin stop tokens correctos. Puede que «funcione» a medias porque el modelo infiere el formato de su entrenamiento, pero no vas a tener control real sobre turnos ni terminación limpia.

Cómo encontrar el formato correcto

  1. Busca el prompt format en la ficha del modelo original (no del quantizer) o en un quant de un autor reconocido tipo bartowski, que suele documentarlo explícitamente en una sección «Prompt format».
  2. Casos típicos:
    • ChatML (Qwen y derivados): <|im_start|>role\n...contenido...<|im_end|>
    • Algunos modelos razonadores meten un <think> justo tras <|im_start|>assistant para forzar el modo de razonamiento.

4. Arreglar el Modelfile a mano

Crea un Modelfile nuevo apuntando al blob local ya descargado (así no vuelves a bajar nada — el path lo sacas del FROM que te dio el ollama show --modelfile anterior):

bash

cat > Modelfile.miModelo << 'EOF'
FROM /root/.ollama/models/blobs/sha256-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

TEMPLATE """{{ if .System }}<|im_start|>system
{{ .System }}<|im_end|>
{{ end }}{{ if .Prompt }}<|im_start|>user
{{ .Prompt }}<|im_end|>
{{ end }}<|im_start|>assistant
<think>
"""

PARAMETER stop "<|im_start|>"
PARAMETER stop "<|im_end|>"
PARAMETER num_ctx 32768
PARAMETER temperature 0.85
PARAMETER top_p 0.9
EOF

Cópialo al contenedor y créalo con un nombre limpio y corto:

docker cp Modelfile.miModelo ollama:/root/.ollama/Modelfile.miModelo
docker exec -it ollama ollama create nombre-corto -f /root/.ollama/Modelfile.miModelo

Como KAT-Coder es un fine-tune sobre Qwen3.6-35B-A3B, prueba a forzar el renderer/parser nativo de Qwen3 que Ollama ya trae soportado:

docker exec -it ollama sh -c 'cat > /root/.ollama/Modelfile.katcoder-fix2 << EOF
FROM /root/.ollama/models/blobs/sha256-60cc031751043c72546faa2a91ea727b1d522c58ed70d07c2c2f0043cca2930a

RENDERER qwen3.5
PARSER qwen3.5

PARAMETER num_ctx 16384
PARAMETER temperature 0.85
PARAMETER top_p 0.9
EOF'

docker exec -it ollama ollama create kat-coder-fix2 -f /root/.ollama/Modelfile.katcoder-fix2

Verifica que se aplicó:

bash

docker exec -it ollama ollama show nombre-corto --modelfile

5. Probarlo

bash

docker exec -it ollama ollama run nombre-corto --verbose "tu prompt de prueba"

--verbose te da tokens/segundo al final, útil para comparar rendimiento entre modelos.

Cosas a vigilar en la primera prueba:

  • Si el modelo es razonador y esperas bloque <think>...</think>, comprueba que aparece. Si no sale, prueba a quitar el <think> fijo del TEMPLATE — algunos backends esperan que sea el propio modelo quien lo genere, no que venga forzado en el prompt.
  • VRAM en tiempo real con watch -n1 nvidia-smi en otra terminal — si el modelo no cabe entero en VRAM, Ollama hace offload parcial a CPU/RAM y la velocidad de generación cae notablemente.
Post Views: 4

Deja un comentario