Publicación de Nanbeige4.3-33B: denso de 33B, contexto 512K, pesos Apache 2.0 y benchmarks autoinformados que chocan con model cards de otros
Según MarkTechPost, el 25 de octubre de 2026, Nanbeige LLM Lab (vinculado a BOSS Zhipin) publicó en Hugging Face bajo licencia Apache 2.0 el modelo denso de 33B Nanbeige4.3-33B y una versión Base para postentrenamiento propio, con contexto de 524.288 tokens. Su tabla autoinformada lidera 17 de 20 benchmarks, pero algunos valores de competidores no coinciden con las model cards oficiales de estos.
Qué ha cambiado
Según el periodista de MarkTechPost Asif Razzaq, el 25 de octubre de 2026, Nanbeige LLM Lab (que el reportaje vincula a la plataforma de empleo BOSS Zhipin) publicó en Hugging Face bajo licencia Apache 2.0 Nanbeige4.3-33B, junto con Nanbeige4.3-33B-Base para postentrenamiento personalizado. El reportaje indica que es un modelo de lenguaje denso de 33B (no MoE) y cita que config.json declara arquitectura estándar LlamaForCausalLM: 52 capas, dimensión oculta 7.168, 56 cabezas de consulta y 8 de clave-valor (atención de consultas agrupadas), dimensión intermedia FFN 22.016, vocabulario de 166.912 tokens, RoPE theta de 120.000.000, hasta 524.288 posiciones (contexto 512K) y modalidad de entrada solo texto; además, la model card lista 1 versión cuantizada de la comunidad. La plantilla de chat expone tres controles: enable_thinking (activado por defecto), preserve_thinking y tools; Nanbeige recomienda activar preserve_thinking en uso de herramientas multiturno y agentes de código, y recomienda el formato XML para llamadas a herramientas. El laboratorio posiciona Nanbeige4.3-33B como modelo "profesor" de la serie y planea destilar capacidades de agente a modelos más pequeños, empezando por Nanbeige4.3-3B. En benchmarks, según la tabla comparativa propia de Nanbeige, el modelo supera a Qwen3.8-27B, Muse-Glimmer-30B y Gemma4-31B en 17 de 20 pruebas: Terminal-Bench 2.1 con 80,9 (Qwen3.8-27B: 73,0), DeepSWE 65,5 frente a 42,5; Terminal-Bench 4.0 con 23,8 (reportado como la puntuación más baja), y SWE-Bench Pro con 60,3, por detrás de 61,7 de Qwen3.8-27B. El reportaje señala que varios valores de competidores en la tabla de Nanbeige contradicen sus model cards oficiales: Meta reporta Muse-Glimmer-30B con 51,2 en SWE-Bench Pro y Gemma4-31B con 36,9, mientras Nanbeige los lista al revés; Google lista Gemma 4 31B con 84,3 en GPQA Diamond y la tabla de Nanbeige muestra 91,3; Meta reporta Muse-Glimmer-30B con 51,7 en Terminal-Bench 2.1 y Nanbeige mide 61,8. El reportaje considera que distintos frameworks pueden explicar parte de las diferencias, pero el par de SWE-Bench Pro parece intercambiado, por lo que esas filas deben tratarse como provisionales hasta que haya reproducción independiente. En despliegue, la model card ofrece recetas para Transformers, SGLang y vLLM, con ejemplo de servidor usando paralelismo tensorial de 4 vías y los parsers de razonamiento y llamadas a herramientas de Qwen3; según cálculos del reportaje basados en config.json, los pesos BF16 requieren unos 66 GB y la caché KV BF16 unos 208 KiB por token, con unos 112 GB para la secuencia completa de 524.288 tokens; hasta la publicación no había ningún proveedor de inferencia de Hugging Face alojando el modelo. Todos los benchmarks son autoinformados por el fabricante o reproducidos por medios; las cifras de pesos y caché KV son estimaciones del reportaje, no divulgaciones oficiales. Esta publicación no realizó pruebas propias ni verificó de forma independiente los archivos de configuración ni de licencia del repositorio.
Impacto para desarrolladores
La restricción más directa para los desarrolladores es la forma de despliegue. La receta oficial descrita es paralelismo tensorial de 4 vías en servidores multi-GPU, no una ruta de estación de trabajo de una sola tarjeta; la estimación de unos 66 GB para pesos BF16 implica que, incluso sin cuantizar, se necesita un entorno multitarjeta o multimáquina para levantar el servicio: en el plan de evaluación primero hay que resolver el hardware y después hablar de calidad del modelo. Esto es análisis condicional: el consumo real de memoria varía con el framework de inferencia, el tamaño de lote y la concurrencia, y debe medirse en la propia máquina. Segundo, el costo real del contexto largo. El reportaje estima unos 208 KiB de caché KV por token en BF16 y unos 112 GB para una secuencia completa de 524.288 tokens, del mismo orden que los propios pesos. Esto significa que 512K se parece más a una capacidad que se activa bajo demanda que a una configuración por defecto: si la proporción de peticiones largas no es alta, bajar el límite de contexto cambia de forma notable el presupuesto de memoria y la concurrencia; si de verdad se quiere agotar la longitud, la caché KV se convierte en el principal costo, y cuantizar los pesos no resuelve esa parte por sí solo, sino que requiere cuantización de KV u otras estrategias de paginación. Tercero, la forma de integración y la adaptación al framework. El reportaje indica formato XML recomendado para llamadas a herramientas y ejemplo de servidor con los parsers de razonamiento y herramientas de Qwen3. Para equipos que ya montaron su bucle de agente con el protocolo de function calling estilo OpenAI, esto suele implicar cambiar la capa de parsing y las plantillas de prompt, no solo la dirección de acceso. Que enable_thinking esté activado por defecto y que preserve_thinking conserve el razonamiento histórico también cambia la composición de tokens por turno y el costo multiturno; si el framework trunca o reordena turnos históricos, conviene confirmar antes el comportamiento real de esos controles. Cuarto, el criterio de evaluación. El reportaje lista conflictos entre la tabla autoinformada de Nanbeige y las model cards oficiales de Meta y Google en varias filas de benchmark, con una fila de SWE-Bench Pro aparentemente intercambiada, por lo que cualquier conclusión comparativa del tipo "cuánto mejor que cierto modelo cercano a 30B" no se sostiene antes de una reproducción independiente. Como referencia queda la información estructural dentro de la misma tabla: Terminal-Bench 2.1 lidera según lo autoinformado, mientras Terminal-Bench 4.0 apenas alcanza 23,8 en puntuación absoluta autoinformada; esa brecha dentro de la misma familia sugiere alta sensibilidad a la tarea y al framework de prueba, y la selección debería basarse en reproducción sobre tareas propias. Quinto, modalidad y licencia. El modelo es de entrada solo texto y no procesa directamente capturas, gráficos o vídeo, por lo que no sustituye flujos que necesiten entrada visual. En licencia conviene distinguir pesos abiertos de términos de licencia: el reportaje indica que los pesos se publican bajo Apache 2.0, más permisivo que solo abrir pesos, pero debe prevalecer el archivo de licencia incluido en el repositorio, y no debe inferirse condiciones de uso comercial y redistribución solo porque los pesos sean descargables. Según la comprobación del catálogo actual de KimiSeek, ni Nanbeige4.3-33B ni Nanbeige4.3-33B-Base figuran en la lista de modelos disponibles; la distribución mencionada en el reportaje se refiere a la descarga de pesos desde Hugging Face y, si se trata de una API alojada, al canal propio del fabricante.
Integración y evaluación
Todo lo siguiente son recomendaciones o análisis condicionales, no conclusiones factuales del reportaje. Decisión uno (elección de pila de inferencia): el reportaje indica que la model card ofrece recetas tanto para SGLang como para vLLM, con ejemplo de servidor en paralelismo tensorial de 4 vías y parsers de razonamiento y llamadas a herramientas de Qwen3. La elección es mantener una sola pila o dos en paralelo. La condición es si dependes de llamadas a herramientas: si el flujo de agente necesita parsing estable de function calling, la vinculación de parsers descrita implica que cambiar de pila puede alterar el comportamiento de parsing, y solo entonces vale la pena el costo de mantener dos; si es solo inferencia de texto, una sola pila es más económica. Un criterio medible: preparar entre 20 y 50 tareas con llamadas a herramientas, contar en cada pila la tasa de errores de formato y de fallos de parsing, y converger a una sola si la diferencia es aceptable. Decisión dos (límite de contexto y presupuesto de memoria): el reportaje estima unos 66 GB de pesos BF16, unos 208 KiB de KV por token y unos 112 GB para la secuencia completa. La elección es el límite de longitud de contexto y el de concurrencia del servicio. La condición depende de la distribución real de contextos: si la gran mayoría de peticiones están por debajo de 32K, bajar el límite muy por debajo de 512K libera mucha memoria para más concurrencia, dejando 512K para pocas tareas largas. Un criterio medible: registrar los percentiles de longitud de contexto en producción o en pruebas de carga y medir el pico de memoria y la latencia P95 del primer token con el límite fijado, confirmando que ambos caben en el margen de hardware; si se exceden, bajar el límite o usar la versión cuantizada de la comunidad (el reportaje indica que la model card lista 1; el impacto en calidad debe medirse por cuenta propia). Decisión tres (prioridad y orden de evaluación): el reportaje señala conflictos entre la tabla autoinformada y las model cards oficiales de otros en SWE-Bench Pro, GPQA Diamond y Terminal-Bench 2.1, y juzga que la fila de SWE-Bench Pro parece intercambiada. La elección es seguir discutiendo rankings públicos o destinar el presupuesto a reproducir en tareas propias. La condición es si tu carga de trabajo está muy ligada a programación con agentes o colaboración ofimática: si lo está, tu repositorio y tus tareas reales valen más que el ranking. Un criterio medible: con el mismo conjunto de scripts, medir tasa de éxito ejecutable o de aprobación en tus tareas y compararla con una línea base de tamaño similar dentro del mismo script; solo las diferencias dentro del mismo framework de prueba sirven para elegir. Decisión cuatro (composición de tokens en agentes multiturno): el reportaje indica que enable_thinking está activado por defecto, que preserve_thinking conserva el razonamiento de turnos previos y que se recomienda activarlo en uso de herramientas multiturno y agentes de código. La elección es conservar el razonamiento histórico por defecto o recortarlo por turnos. La condición es el número de turnos: a más turnos, más amplifica el contenido de razonamiento el contexto y el costo. Un criterio medible: en el mismo lote de tareas multiturno, comparar con y sin conservación la tasa de éxito, el consumo total de tokens y la latencia del primer token; solo si la tasa de éxito no baja de forma clara conviene recortar para controlar costos.
Límites y cuestiones pendientes
Debe quedar claro: según la comprobación del catálogo en línea actual de KimiSeek, ni Nanbeige4.3-33B ni Nanbeige4.3-33B-Base aparecen en la lista de modelos disponibles; esta versión no se ofrece actualmente en KimiSeek, y la distribución y disponibilidad mencionadas en el reportaje se refieren a la descarga de pesos desde Hugging Face y, si se trata de una API alojada, al canal propio del fabricante. El reportaje solo confirma que, en el momento de publicación, ningún proveedor de inferencia de Hugging Face alojaba el modelo; no afirma que ningún otro canal de alojamiento lo haga, por lo que la disponibilidad en otros canales debe verificarse por separado. Esta publicación no verificó de forma independiente el repositorio del modelo, los archivos de configuración ni los archivos de licencia adjuntos; los parámetros de arquitectura, controles y descripción de licencia aquí descritos provienen de la transcripción que hace el reportaje de la model card y config.json. Todas las puntuaciones de benchmark del reportaje son autoinformadas por Nanbeige o reproducidas por medios, sin reproducción independiente de terceros, y el propio reportaje señala que varios valores de competidores contradicen las model cards oficiales de Meta y Google, con una fila de SWE-Bench Pro aparentemente intercambiada; esas filas deben considerarse provisionales hasta una reproducción independiente. Las cifras de unos 66 GB de pesos, unos 208 KiB de caché KV por token, unos 112 GB de caché KV para la secuencia completa y el paralelismo tensorial de 4 vías son estimaciones del reportaje basadas en config.json o transcripciones de la model card, no divulgaciones oficiales ni mediciones de esta publicación; el consumo real de memoria depende del framework de inferencia, el tamaño de lote, la concurrencia y la distribución de contextos, y debe medirse en el hardware propio. Apache 2.0 es la descripción de licencia dada en el reportaje; que los pesos sean descargables no equivale a los términos de licencia, y las condiciones concretas de uso comercial y redistribución deben regirse por el archivo de licencia incluido en el repositorio. El formato XML recomendado para llamadas a herramientas, la combinación de parsers con Qwen3 y que enable_thinking esté activado por defecto provienen de la descripción del reportaje sobre la model card y la plantilla de chat, y el comportamiento real puede cambiar con actualizaciones de versión. El plan de destilación de Nanbeige4.3-3B es una declaración de plan del fabricante, sin pesos ni datos de capacidad públicos, y no debe considerarse una capacidad ya entregada.