Baidu abre Unlimited OCR 2: analiza cientos de páginas por solicitud y qué conviene verificar primero de SR-SWA y su pila de inferencia
Según MarkTechPost, el 26 de octubre de 2026 Baidu publicó Unlimited OCR 2, un modelo de 3,34B parámetros con pesos bajo licencia MIT, que usa SR-SWA para reducir la atención a un conjunto de referencia fijo y así procesar cientos de páginas por solicitud; reporta 77,1 puntos en MarathonDocBench.
Qué ha cambiado
Según MarkTechPost, el 26 de octubre de 2026 Baidu publicó Unlimited OCR 2, un modelo de visión-lenguaje para OCR de documentos muy largos, con pesos bajo licencia MIT en Hugging Face y código alojado en GitHub, sucesor de Unlimited-OCR de junio de 2026. El reporte indica 3,34B parámetros, sin revelar los parámetros activados, y una longitud posicional máxima de 131.072 tokens; los pesos BF16 ocupan unos 6,7 GB y Baidu los probó en una sola NVIDIA A800-80GB. La arquitectura sigue el estilo de DeepSeek-OCR: codificadores SAM ViT-B y CLIP-L conectados a un decodificador de mezcla de expertos de 12 capas, que enruta cada token a 6 de 64 expertos más 2 expertos compartidos. El cambio central es SR-SWA (atención de ventana deslizante con referencia dispersa), que comprime la atención texto-visual sobre un conjunto de referencia de trabajo fijo; el ejemplo de la model card citado en el reporte usa 512 tokens, con una ventana local de 128 tokens combinada con una selección top-16 sobre bloques de 32 tokens. El reporte afirma que esto mantiene casi constante la latencia por paso de decodificación y la memoria a medida que crece el documento, aunque la codificación de imagen y el tiempo total sí aumentan con las páginas; en modo multipágina cada página consume 273 tokens de imagen. En cuanto a benchmarks, el reporte dice que Baidu probó en el público MPDocBench-Parse (433 documentos, 3.246 páginas) y en MarathonDocBench (cientos de páginas), y que no encontró una versión pública de este último; según el gráfico de la tabla de Baidu, Unlimited OCR 2 obtiene 84,6 en MPDocBench y 77,1 en MarathonDocBench, frente a un máximo de 33,7 de los modelos comparados en el segundo y 0,0 de Unlimited-OCR en MarathonDocBench. Todas las cifras son autodeclaradas por Baidu y el reporte señala que solo se presentan en una imagen de gráfico. El subpunto más bajo es la jerarquía de títulos (TEDS), con 48,2 en MarathonDocBench; el apartado de tablas baja de 87,8 en MPDocBench a 74,8. Sobre la ejecución, la model card menciona Transformers para pruebas rápidas (infer procesa una página, infer_multi analiza todas las páginas en una sola solicitud); en servidor se usa SGLang con un wheel personalizado de Baidu, no el SGLang upstream que menciona el reporte; la carga requiere trust_remote_code=True, lo que ejecuta código Python del repositorio. El reporte también menciona que el ejemplo de Baidu programa 10 páginas por ventana y reutiliza la cola KV de la ventana anterior, que una ventana menor reduce la memoria máxima pero debilita la fusión entre páginas, y que la configuración de bias por defecto puede provocar una asignación de 462 MiB y advertencias de falta de memoria. El reporte no indica qué licencia usa el código del repositorio de GitHub.
Impacto para desarrolladores
Las implicaciones para los desarrolladores tienen varios niveles y la mayoría aún requiere verificación propia. El primero es que cambia la forma de estimar memoria y límite de páginas: según el reporte, SR-SWA evita que el coste por paso de decodificación crezca linealmente con las páginas, por lo que con un presupuesto de memoria fijo el límite de páginas por solicitud probablemente dependerá más del coste de codificación de imagen, la ocupación de la cola KV y la programación de ventanas que del crecimiento cuadrático de la atención; esto importa para el procesamiento por lotes offline de alta paginación y baja interacción, como libros, declaraciones o informes anuales. Pero el reporte aclara que el tiempo total sigue creciendo con las páginas, así que el beneficio es limitado en escenarios en línea que exigen respuesta rápida página a página. El segundo es el riesgo de dependencia de la pila de inferencia: la ruta de servicio es SGLang con wheel personalizado de Baidu, y el reporte lo describe como distinto del SGLang upstream, lo que indica una bifurcación del fabricante que requiere mantenimiento propio; si los equipos ya tienen imágenes, versiones congeladas y procesos de reversión sobre un framework de inferencia genérico, integrarlo añade una dependencia más a seguir. La model card también incluye la ruta de Transformers, útil como entrada para validar funcionalidad, pero no como solución de servicio en producción. El tercero es distinguir licencia y seguridad: los pesos se publican bajo licencia MIT, una autorización permisiva a nivel de licencia que no debe confundirse con "solo pesos abiertos"; sin embargo, el reporte solo habla de la licencia de los pesos y no del código de GitHub, así que no conviene tratar la reutilización de código como MIT sin más. Además, MIT cubre el alcance de la autorización, no avala la seguridad del código cargado con trust_remote_code=True, que ejecuta Python del repositorio en el proceso; en entornos con requisitos de auditoría suele requerir revisión de código y ejecución aislada. El cuarto es el criterio de evaluación: el reporte muestra que en MPDocBench las diferencias por subpunto entre modelos son pequeñas, por ejemplo 94,8 frente a 94,3 en texto y 89,4 frente a 89,2 en fórmulas, y que la brecha se concentra en MarathonDocBench con cientos de páginas; por tanto la elección debe basarse en la distribución de páginas de los documentos propios, no en el orden del total. Los puntos débiles de jerarquía de títulos (48,2) y tablas en documentos largos (74,8) afectan directamente la calidad posterior del árbol de secciones y de la carga de tablas, y deben medirse por separado con muestras propias.
Integración y evaluación
Las siguientes son recomendaciones condicionales, no hechos del reporte. Decisión uno: si cambiar a SR-SWA por rendimiento en documentos largos. El detonante es que las tareas individuales lleguen a menudo a más de cien páginas; si los documentos suelen tener menos de diez páginas, las diferencias por subpunto en MPDocBench son pequeñas y no hay motivo suficiente para cambiar. Una prueba ejecutable es dividir el corpus propio en dos tramos por páginas (hasta veinte y más de cien) y ejecutar infer_multi en la misma máquina con la misma memoria, registrando memoria máxima por solicitud, tiempo total y curva de tiempo por página; si en el tramo de cien páginas el tiempo por página sube claramente con el número de páginas, el cuello de botella se habrá trasladado a la codificación de imagen y conviene ajustar las páginas por ventana en lugar de seguir aumentando las páginas por solicitud. Decisión dos: empezar con Transformers o con el SGLang personalizado. Depende de si la pila de servicio actual del equipo es compatible con el wheel del fabricante; si las imágenes y los procesos de reversión no aceptan el SGLang personalizado, conviene validar primero funcionalidad y precisión con Transformers y fijar como umbral si las páginas procesables por unidad de tiempo en una sola tarjeta llenan la ventana de procesamiento por lotes; si se acepta el wheel personalizado, hacer pruebas de carga sobre los riesgos que menciona el reporte: partir de las 10 páginas del ejemplo y reducir la ventana gradualmente observando la memoria máxima, y comprobar si la asignación de 462 MiB por el bias por defecto causa falta de memoria, exigiendo como condición dura que no haya fallos por falta de memoria. Decisión tres: fijar criterios de aceptación separados para la salida estructurada. El reporte muestra que la jerarquía de títulos en documentos largos es solo 48,2 y las tablas bajan a 74,8; si el proceso posterior depende del árbol de secciones o de la carga de tablas, conviene preparar muestras propias con anotaciones de jerarquía y tablas, medir estos dos puntos por tramos de páginas y luego decidir si añadir revisión humana o reglas de posprocesamiento. Decisión cuatro: incluir trust_remote_code=True en las comprobaciones previas al despliegue, ejecutar y revisar primero el código del repositorio en un entorno aislado y confirmar con Baidu los términos de licencia del código antes de decidir si pasa a producción. Todos estos juicios deben basarse en el error de un conjunto de datos propio anotado, no en la puntuación total del fabricante.
Límites y cuestiones pendientes
Casi todas las cifras de rendimiento del reporte son autodeclaradas por Baidu y, según el reporte, se presentan solo en una imagen de gráfico de clasificación, sin detalles de evaluación reproducibles de forma independiente; MarathonDocBench se describe como un benchmark de cientos de páginas, pero el reporte afirma explícitamente que no encontró una versión pública, por lo que ni el 77,1 ni las comparaciones con otros modelos pueden verificarse externamente. No se revela el número de parámetros activados, así que no se puede inferir el cómputo real de inferencia ni el rendimiento. El reporte solo indica ejecución en una sola tarjeta en BF16 con pesos de unos 6,7 GB, sin mencionar versiones cuantizadas; no se puede determinar con la información disponible si es desplegable en dispositivos con menos memoria. Hasta el momento de esta comprobación del catálogo, la versión Unlimited OCR 2 no aparece en el catálogo de modelos de KimiSeek; las rutas de Transformers y SGLang personalizado mencionadas son vías de despliegue propio del repositorio del modelo y de materiales del fabricante, y no implican que el modelo esté disponible en KimiSeek; el reporte tampoco menciona servicios alojados por el fabricante ni formas de facturación. Si más adelante aparece un servicio alojado, su disponibilidad y precios deben consultarse en su documentación y página de precios oficiales, y los precios pueden cambiar. Las advertencias del reporte sobre trust_remote_code=True, la posible falta de memoria por el bias por defecto y el SGLang personalizado provienen de materiales del fabricante y no han sido verificadas por terceros; tampoco se explica la licencia del código del repositorio de GitHub. Los nombres de modelos comparados y las versiones de benchmark citados son recientes; este artículo solo reproduce sus datos autodeclarados y no implica pruebas independientes.