Probamos Coder390 y no lo adoptamos: no supera a nuestro GLM
Un modelo de código comunitario con buenas señales cortas (100/100 en 15 escenarios) que se cae en el banco completo: sus problemas con llamadas de herramientas obligatorias y JSON lo desaconsejan como modelo de trabajo.
Configuración
Eval controlada, sin tocar la producción: contenedor temporal, solo acceso local, pesos con SHA verificado, y nunca fue el modelo de por defecto. Es un GGUF orientado a código de unos 20 GB, así que cabe holgado en una sola Spark, con visión y decodificación especulativa MTP.
Resultado
| prueba | resultado |
|---|---|
| banco corto de 15 escenarios | 100/100 |
| banco completo (84 escenarios) | 83/100 (140/168) |
| decodificación en prosa | 18,7 tok/s |
| llamadas de herramientas | ahí decae: falla con JSON complejo, cadenas largas y planificación |
| nota del nodo residencial (GLM, para comparar) | 90/100 |
Estado
Lo retiramos. Borramos los pesos tras la evaluación (no entró en Gateway ni Mission Control) y conservamos solo los resultados. El veredicto es claro: es un candidato ligero de código razonable, pero no supera a GLM-5.3 TensorFold (90/100) y sus fallos con JSON de esquemas y tool_choice=required lo desaconsejan como agente principal.
Qué significa para ti
Un banco corto puede dar un 100 y aun así no ser adoptable: mete 84 escenarios y ya ves las costuras. Si tu agente encadena herramientas, pruébalo antes con escenarios difíciles y no solo con dos o tres ejemplos.
Medido en nuestras máquinas. Dos ASUS Ascent GX10 (NVIDIA GB10, 128 GB de memoria unificada). En tu equipo las cifras serán otras: lo que se traslada es el método y la lección.