Baidu lança Unlimited OCR 2 com pesos MIT: o que verificar no SR-SWA e na pilha de inferência personalizada
Segundo o MarkTechPost, em 26 de outubro de 2026, a Baidu lançou o Unlimited OCR 2, com 3,34 bilhões de parâmetros e pesos sob licença MIT, que usa SR-SWA para reduzir a atenção a um conjunto de referência fixo e assim processar centenas de páginas por requisição, com 77,1 pontos autodeclarados no MarathonDocBench.
O que mudou
Segundo o MarkTechPost, em 26 de outubro de 2026, a Baidu lançou o Unlimited OCR 2, um modelo de linguagem visual de OCR voltado a documentos muito longos, com pesos publicados no Hugging Face sob licença MIT, código hospedado no GitHub, sucedendo o Unlimited-OCR de junho de 2026. A reportagem afirma que ele tem 3,34 bilhões de parâmetros, sem divulgar o número de parâmetros ativos, e comprimento máximo de posição de 131.072 tokens; os pesos em BF16 ocupam cerca de 6,7 GB, e a Baidu testou em uma única NVIDIA A800-80GB. A arquitetura segue o estilo DeepSeek-OCR: um codificador SAM ViT-B mais CLIP-L alimenta um decodificador de 12 camadas com mistura de especialistas, roteando cada token para 6 de 64 especialistas, além de 2 especialistas compartilhados. A mudança central é o SR-SWA (atenção de janela deslizante com referência esparsa), que comprime a atenção texto-visual em um conjunto de referência de trabalho fixo; a reportagem cita o exemplo do cartão do modelo com escala de 512 tokens, e a configuração combina uma janela local de 128 tokens com seleção top-16 sobre blocos de 32 tokens. A reportagem afirma que isso torna a latência de decodificação por passo e o uso de memória quase constantes conforme o documento cresce, mas a codificação de imagem e o tempo total de execução ainda aumentam com o número de páginas; no modo multipágina, cada página consome 273 tokens de imagem. Nos benchmarks, a reportagem afirma que a Baidu testou no MPDocBench-Parse público (433 documentos, 3.246 páginas) e no MarathonDocBench (centenas de páginas), e afirma não ter encontrado uma versão pública do MarathonDocBench; segundo o gráfico de ranking da Baidu, o Unlimited OCR 2 obtém 84,6 no MPDocBench e 77,1 no MarathonDocBench, com o modelo de comparação chegando a no máximo 33,7 neste último, e o Unlimited-OCR anterior com 0,0 no MarathonDocBench. Todos os números são autodeclarados pela Baidu, e a reportagem afirma que são apresentados apenas em uma imagem de gráfico. Entre os subitens, o mais baixo é a hierarquia de títulos (TEDS), com 48,2 no MarathonDocBench; o item de tabelas cai de 87,8 no MPDocBench para 74,8. Quanto à execução, o cartão do modelo lista o Transformers para testes rápidos (infer processa uma página, infer_multi analisa todas as páginas em uma única requisição), e o servidor usa SGLang com um wheel personalizado da Baidu, e não o SGLang upstream como a reportagem descreve; o carregamento exige trust_remote_code=True, que executa código Python do repositório. A reportagem também menciona que o exemplo da Baidu agenda 10 páginas por janela e reutiliza a cauda de KV da janela anterior, que janelas menores reduzem o pico de memória mas enfraquecem a fusão entre páginas, e que a configuração padrão de bias pode acionar uma alocação de 462 MiB e causar aviso de falta de memória. A reportagem não informa qual licença se aplica ao código do repositório GitHub.
Impacto para desenvolvedores
As implicações para desenvolvedores têm várias camadas, e a maioria ainda precisa ser verificada por conta própria. A primeira é que a forma de estimar memória de vídeo e limite de páginas muda: segundo a reportagem, o SR-SWA faz o custo de decodificação por passo não crescer linearmente com o número de páginas, de modo que, com um orçamento fixo de memória, o principal fator limitante do número de páginas por requisição tende a passar para o custo de codificação de imagem, a ocupação da cauda de KV e o agendamento de janelas, e não mais para o crescimento quadrático da atenção; isso tem relevância prática para processamento em lote offline de alto número de páginas e baixa interação, como livros, declarações e relatórios anuais. Mas a reportagem também deixa claro que o tempo total de execução ainda aumenta com o número de páginas, então o ganho é limitado em cenários online que exigem resposta rápida página a página. A segunda camada é o risco de aprisionamento na pilha de inferência: o caminho de serviço é o SGLang com wheel personalizado da Baidu, e a reportagem usa a expressão “e não o SGLang upstream” para descrever essa diferença, indicando que é um fork do fabricante que precisa de manutenção separada; se as imagens, o congelamento de versões e os processos de rollback da equipe já estão montados em torno de um framework de inferência genérico, a adoção significa mais uma linha de dependência a acompanhar. O cartão do modelo também lista o caminho via Transformers, que pode servir como porta de entrada para validação funcional, mas não é uma solução de serviço em produção. A terceira camada é a distinção entre licença e segurança: os pesos são publicados sob licença MIT, o que é uma autorização permissiva em nível de licença e não deve ser confundido com “apenas pesos abertos”; porém a reportagem só informa a licença dos pesos e não informa a licença do código do repositório GitHub, então a reutilização do código não deve ser tratada diretamente como MIT. Além disso, a MIT cobre o escopo de autorização e não equivale a um endosso de segurança ao código carregado por trust_remote_code=True, que executa código Python do repositório dentro do processo, e em ambientes com exigências de auditoria isso normalmente requer revisão prévia do código e execução isolada. A quarta camada é o critério de avaliação: a reportagem mostra que no MPDocBench as diferenças por subitem entre os modelos são pequenas, por exemplo 94,8 contra 94,3 no item de texto e 89,4 contra 89,2 no de fórmulas, e as diferenças se concentram no MarathonDocBench, com centenas de páginas; portanto a decisão de escolha deve se basear na distribuição de páginas dos próprios documentos, e não na ordenação da pontuação total. Os dois pontos fracos, hierarquia de títulos em 48,2 e tabelas em documentos longos em 74,8, afetam diretamente a qualidade a jusante da árvore de capítulos e da ingestão de tabelas, e precisam ser medidos separadamente em amostras próprias.
Integração e avaliação
As sugestões a seguir são condicionais e não são fatos da reportagem. Decisão um: trocar o SR-SWA por maior vazão em documentos longos. A condição de disparo é que a tarefa única frequentemente alcance centenas de páginas; se os documentos em geral têm menos de dez páginas, as diferenças por subitem no MPDocBench citadas na reportagem são pequenas e não há motivo suficiente para trocar. Um critério executável é dividir o corpus próprio em duas faixas por número de páginas (até vinte páginas e mais de cem páginas), executar infer_multi em cada faixa na mesma máquina com a mesma memória e registrar o pico de memória por requisição, o tempo total e a curva de tempo por página; se na faixa de cem páginas o tempo por página subir claramente com o número de páginas, o gargalo já passou para a codificação de imagem, e nesse caso se deve ajustar o número de páginas por janela em vez de continuar aumentando as páginas por requisição. Decisão dois: começar pela pilha Transformers ou pelo SGLang personalizado. O pré-requisito é se a pilha de serviço de inferência existente da equipe é compatível com o wheel do fabricante; se as imagens e o processo de rollback não conseguem acomodar o SGLang personalizado, comece validando função e precisão com Transformers e adote como critério se o número de páginas processáveis por unidade de tempo em uma única GPU consegue preencher a janela de processamento em lote; se for possível acomodar o wheel personalizado, faça teste de carga sobre os riscos citados na reportagem: parta das 10 páginas do exemplo e reduza gradualmente a janela observando o pico de memória, e verifique se a alocação de 462 MiB acionada pelo bias padrão causa falta de memória, adotando “nenhuma falha por falta de memória” como condição obrigatória de aprovação. Decisão três: definir critérios de aceitação separados para saída estruturada. A reportagem mostra hierarquia de títulos em apenas 48,2 em documentos longos e item de tabelas caindo para 74,8; se o uso a jusante depende da árvore de capítulos ou da ingestão de tabelas, prepare primeiro amostras próprias com anotação de hierarquia de títulos e de tabelas, meça esses dois itens por faixa de páginas e só então decida se adiciona revisão humana ou regras de pós-processamento. Decisão quatro: incluir trust_remote_code=True na verificação prévia de lançamento, executar e revisar o código do repositório primeiro em ambiente isolado, e confirmar com a Baidu os termos de licença do código do repositório antes de decidir entrar em produção. Todas essas decisões devem se basear no erro do conjunto anotado próprio, e não na pontuação total do fabricante.
Limites e pontos a confirmar
Quase todos os números de desempenho da reportagem vêm de autodeclaração da Baidu, e a reportagem afirma que são apresentados apenas em uma imagem de gráfico de ranking, sem detalhes de avaliação reproduzíveis de forma independente; o MarathonDocBench é descrito como um benchmark de centenas de páginas, mas a reportagem afirma explicitamente não ter encontrado uma versão pública, portanto o 77,1 e as comparações com outros modelos não podem ser verificados externamente. O número de parâmetros ativos não foi divulgado, então não é possível estimar a capacidade real de inferência ou a vazão. A reportagem só informa execução em uma única GPU em BF16 e pesos de cerca de 6,7 GB, sem mencionar versões quantizadas, e não é possível julgar pelas informações atuais se é viável implantar em dispositivos com menos memória. Até o momento desta verificação de catálogo, a versão Unlimited OCR 2 não aparece no catálogo de modelos do KimiSeek; o Transformers e o SGLang personalizado mencionados na reportagem referem-se a caminhos de implantação própria do repositório do modelo e de materiais do fabricante, e não indicam que o modelo já esteja disponível no KimiSeek, nem a reportagem menciona qualquer serviço hospedado ou forma de cobrança do fabricante. Se um serviço hospedado surgir depois, sua disponibilidade e preço devem ser consultados na documentação oficial e na página de preços, e os preços podem mudar. As observações da reportagem sobre trust_remote_code=True, sobre o bias padrão poder causar falta de memória e sobre o SGLang personalizado vêm de materiais do fabricante e não foram verificadas por terceiros; a licença do código do repositório GitHub também não é informada. Os nomes dos modelos de comparação e as versões de benchmark citados na reportagem são recentes, e este texto apenas reproduz os dados autodeclarados, sem indicar testes independentes.