Distribuye tareas de IA en la flota de 0.9B a 375B de K2 Horizon

Elegir el tamaño de un modelo es un equilibrio de costes: más parámetros activos compran capacidad, y cada token paga el cómputo que los activa. Un token con 23B activos realiza aproximadamente 5.75 veces el trabajo de parámetros activos de un token con 4B activos. IFM presentó K2 Horizon el 3 de septiembre de 2026 como una flota de seis modelos que abarca de 0.9B a 375B parámetros, y el checkpoint 375B-A23B debutó con analizadores para razonamiento y llamadas a herramientas diseñados para flujos de trabajo de agentes, operaciones de terminal y razonamiento extendido. Trata la gama como un menú de ruteo, no como un producto único.

Clasifica la carga de trabajo antes de nombrar un checkpoint

Empieza con un ticket de carga de trabajo: longitud de contexto, complejidad de herramientas o agéntica, objetivo de latencia y presupuesto. No pongas el nombre de un modelo en el ticket. El ticket es la unidad de revisión para cambios de ruteo. Recoge ejemplos del tráfico de producción y luego etiqueta cada prompt, llamada a herramienta y salida esperada por longitud de contexto, complejidad de herramientas y sensibilidad a la latencia. Una respuesta lenta puede romper un flujo de trabajo de agentes incluso cuando el contenido es correcto, por lo que el ticket debe especificar una clase de latencia antes de elegir cualquier checkpoint.

Mapea el ticket al checkpoint más pequeño que supere la barra de evaluación. La escala de tamaños es la regla que un ingeniero nuevo puede leer sin preguntar por qué se eligió el modelo grande:

• Tareas cortas con pocas herramientas: nivel 0.9B.
• Trabajo local o on-prem: nivel 36B-A4B.
• Trabajo agéntico de contexto largo: nivel 375B-A23B.

Mantén el mapeo reversible. Si el checkpoint pequeño falla, registra el modo de fallo y promociona solo el trabajo que necesite el checkpoint más grande. La regla de promoción debe nombrar la clase de tarea, no la familia de modelos. Elegir por parámetros totales es el fallo común: un modelo grande en total puede costar menos por token que un modelo denso si solo se ejecuta un número pequeño de parámetros activos.

Precia los tokens por parámetros activos, no por tamaño total

Estima el coste por token a partir de los parámetros activos, la longitud de contexto, el tamaño del lote y tu tarifa por hora de GPU. Pone la fórmula en el ticket: parámetros activos por tokens, dividido por el rendimiento, y luego multiplicado por tu tarifa en dólares. La fórmula es el número que el equipo puede defender en revisión. Separa prefill de decode. Un contexto largo puede hacer que el prefill domine, mientras que prompts cortos y repetidos pueden hacer que el decode domine, por lo que el ticket gana una estimación de prefill y una estimación de decode.

El 375B-A23B es un modelo MoE disperso con 375B parámetros totales, 23B parámetros activos por token y un contexto nativo de 524,288 tokens. El modelo disperso 36B-A4B está orientado a la aloja local y a despliegues en servidores on-premise. La flota K2 Horizon usa ruteo dinámico para asignar el trabajo al modelo con la mejor relación coste-eficacia. La flota utiliza un diseño de mezcla de atención de valor que refuerza el razonamiento sin aumentar el cómputo. No dejes que los parámetros totales fijen el precio. Un modelo disperso puede tener un recuento total grande y un recuento activo pequeño, por lo que el coste por token sigue el recuento activo, mientras que prompts más largos aún pueden aumentar la memoria y el trabajo de prefill.

Demuestra la ruta con evaluaciones de pesos abiertos

Ejecuta evaluaciones reproducibles a partir de pesos abiertos y datos de entrenamiento antes de promocionar un modelo. El paquete de evaluación lista el conjunto de tareas, el checkpoint, el formato del prompt, la puntuación y el coste por token. Guarda la ejecución con el ticket. La gama es un conjunto de modelos totalmente abiertos, con pesos, código, datos de entrenamiento y metodologías disponibles para inspección, reproducción y adaptación. Usa los analizadores de razonamiento y llamadas a herramientas del 375B-A23B en el arnés de evaluación cuando la carga de trabajo sea agéntica.

Guarda los artefactos de evaluación con la regla de ruteo para que un ingeniero nuevo pueda reejecutar la evaluación sin adivinar. Comprueba el formato de la llamada a herramienta antes de puntuar. Si el analizador espera una forma diferente, la evaluación mide el formato, no el razonamiento. La evaluación debe mostrar una tasa de análisis limpio y una puntuación de tarea.

Puntúa al candidato en la carga de trabajo exacta, no en un ranking genérico. La comparación debe mostrar que el checkpoint elegido gana en la tarea, el objetivo de latencia y el objetivo de coste. Si falla, pasa al siguiente checkpoint y reejecuta la evaluación. Instrumenta la decisión de ruteo tras el lanzamiento. El conjunto de métricas en vivo muestra la clase de tarea, el checkpoint, la latencia y el coste por token. Revisa el conjunto de métricas cuando cambie la carga de trabajo. Mantén el conjunto de métricas lo suficientemente pequeño como para leerlo en un incidente.