Do balancete à resposta,
sem sair da sua GPU

§0 · Achados-chave

Cinco conclusões que decidem o projeto antes da primeira linha de código

O modelo é a peça mais fácil de trocar. O pipeline é o que separa um demo de um sistema em que um contador pode confiar.

1 · O harness pesa mais que o modelo. No FinanceBench — 10.231 perguntas de analistas sobre filings reais — o mesmo GPT-4 Turbo vai de 9% de acurácia sem documento a 85% com a evidência certa no contexto, e pipelines de domínio com re-ranking e metadados chegam a 91%^K7K8K9. A variação de pipeline (76 p.p.) é maior que a variação entre qualquer par de modelos da prateleira ≤32B.

2 · 32B é o ponto ótimo da RTX 5090 — e MoE é o atalho de velocidade. Um denso de 32B roda a ~61 tok/s em Q4_K_M; um MoE Qwen3.6 35B-A3B, com só ~3B ativos por token, chega a ~118 tok/s estimados — rápido o bastante para uso interativo por vários funcionários^K2K3.

3 · Para ler documentos, não use o VLM gigante — use o OCR dedicado de 1B. No OmniDocBench v1.6, PaddleOCR-VL (0,9B) faz 96,34% e MinerU2.5-Pro (1,2B) 95,75%, superando o Qwen3-VL-235B (89,78%) com 200× menos parâmetros^K11. O VLM de 32B entra na etapa seguinte: raciocinar sobre o que foi lido.

4 · Em text-to-SQL, modelos locais especializados de 7B–32B já superam o GPT-4o no benchmark BIRD (71,8% vs 58,5%)^K14K16 — mas em esquemas empresariais reais todos despencam para 0–21%^K17K18. É aí que schema linking, camada semântica e auto-correção com feedback de execução fazem a diferença.

5 · Português muda a escolha do embedding. Fine-tuning de domínio em português jurídico elevou MRR@10 de 0,53 para 0,70 (+32% relativo) contra o BGE-M3 genérico^K20 — o maior ganho unitário de baixo custo do projeto.

§1 · O hardware — RTX 5090 32 GB + GPU de 16 GB · Ryzen 9950X · 128 GB DDR5

Duas GPUs, uma regra: a 5090 fica com o cérebro, a placa de 16 GB herda todos os serviços

A tentação de manter 32B e 27B residentes na mesma placa morre na aritmética: 33 GB de pesos antes do primeiro token de KV cache.

A RTX 5090 é a única GPU consumer com 32 GB de VRAM e 1.792 GB/s de banda — e é a banda, não o compute, que define a velocidade de geração: cada token de um modelo denso lê o conjunto inteiro de pesos uma vez, logo o teto teórico de um modelo de 20 GB é ~90 tok/s antes de overheads^K3. Na prática, a comunidade mede ~61 tok/s em um 32B denso (Q4_K_M) e 185–213 tok/s em modelos 8B via llama.cpp^K2. Para cenário multiusuário, o vLLM entrega ~44% mais throughput que Ollama em GPU e 2–3× mais que llama.cpp quando há 32+ requisições concorrentes, graças a PagedAttention e continuous batching^K6.

O plano "32B + 27B residentes juntos" não fecha. Em NVFP4, os dois somam ~33 GB de pesos — estouram a placa antes de alocar um único token de KV cache^K29. O desenho que fecha a conta é assimétrico: a 5090 hospeda um único cérebro — o Qwen3.8-32B NVFP4, servindo roteamento e redação do QIVIQ, classify/veto do Conciliador, visão pesada a 260 dpi e o open-webui — com 8,6 GB de KV cache FP8 para 8 sessões × 8K tokens e prefix caching ligado (o system prompt e o schema linkado se repetem entre usuários; o prefill caro vira hit de cache)^K29. Troca de modelo: zero — a preocupação original desaparece porque não há segundo modelo grande para alternar.

A GPU de 16 GB herda os três serviços que hoje disputam (e derrubam) a placa principal: PaddleOCR-VL-1.6 para leitura de PDF (12,1 s/página na GPU, contra >15 min em CPU)^K27, Arctic-Text2SQL-R1-14B AWQ (70,04% no BIRD — só 1,8 p.p. abaixo do 32B, por 9 GB em vez de 20)^K14 e o BGE-M3 de embeddings. Total: ~14 GB com folga. Numa placa de ~450 GB/s (5060 Ti/5070 Ti 16 GB), o SQL-14B gera ~45–50 tok/s — sobra, porque SQL é resposta curta, e o OCR de 0,9B mal sente a banda menor. O detalhe que mais se esquece continua sendo o KV cache: quantizá-lo para FP8/Q8 corta o custo pela metade com perda desprezível, e é uma linha de configuração no vLLM^K3.

Motor de inferência: qual usar onde

§2 · Modelos até 32B — testes reais

O que a prateleira de 2026 oferece abaixo de 32B — e quem lidera em cada tarefa

A geração 2026 (Qwen3.5/3.6, Gemma 4) aposentou a de 2025; a escolha prática se resume a três nomes, por tarefa.

Em modelos densos de texto, o Qwen3.6-27B lidera entre os abertos do porte com 77,2% no SWE-bench Verified — superando o MoE de 397B da própria geração anterior — e o Gemma 4 31B traz multimodalidade nativa, 140+ idiomas e licença Apache 2.0^K4. No índice composto da timetoact (verão 2025), o Qwen3-32B marcou 71,1%, emparelhado com Claude 3.7 Sonnet em modo thinking e acima do GPT-4.1 — enquanto o Gemma 3 27B ficou em 45,0%^K5. Para documentos em português, as famílias Qwen e Gemma são as apostas seguras: ambas treinadas em 100+ idiomas, com o português bem coberto — mas a recomendação dos próprios mantenedores é testar com seus dados reais, não confiar em benchmark genérico^K4.

Dois cuidados de leitura de benchmark importam aqui. Primeiro, suites diferentes medem coisas diferentes — um índice composto de chat não prevê acurácia em SQL nem em extração de tabela; por isso este relatório separa os modelos por tarefa em vez de coroar um vencedor único. Segundo, números de fornecedores são autorreportados: tratamos os resultados de Snowflake (Arctic) e Alibaba (XiYan) como sinais fortes, porém marcados, e a comparação justa é sempre dentro da mesma tabela/protocolo (ex.: todos os valores BIRD Dev@M-Schema citados juntos abaixo).

§3 · Leitura multimodal de relatórios contábeis

O teste real de leitura separa duas coisas: ler o documento e raciocinar sobre ele

A maior surpresa de 2026: modelos de OCR dedicados com ~1B de parâmetros leem documentos melhor que VLMs de 235B — e cabem na folga da sua VRAM.

No OmniDocBench v1.6 — referência para parsing de PDF complexo com tabelas, fórmulas e múltiplas colunas — o pódio é inteiramente de modelos dedicados minúsculos: PaddleOCR-VL-1.6 (0,9B) com 96,34%, MinerU2.5-Pro (1,2B) com 95,75% e GLM-OCR (0,9B) com 95,22%, enquanto o Qwen3-VL-235B marca 89,78%^K11. O PaddleOCR-VL ainda é o mais rápido: 1,22 páginas/s com backend vLLM e ~44 GB de VRAM médio em batch — e, para volumes menores, roda em qualquer folga da 5090^K11. Na comparação direta de pipelines open-source de PDF, o Docling (IBM, licença MIT) vence em cobertura de formatos e tem o TableFormer, forte justamente em tabelas financeiras — relevante para balanços e DREs^K10.

O VLM de 32B tem papel diferente: o Qwen3-VL-32B marca 93,3% no DocVQA, 94,0% no ChartQA e 86,9% no OCRBench, com OCR em 32 idiomas e contexto nativo de 256K^K12 — ou seja, ele é o melhor ≤32B para responder perguntas sobre o documento (gráficos, notas explicativas, layout), não para transcrevê-lo em lote. No OCRBench v2 em inglês, modelos abertos pequenos como o GLM-4.6V-Flash (9B) já superam GPT-5 e Gemini 2.5 Pro na tarefa^K13. A arquitetura vencedora é em dois estágios: OCR dedicado converte PDF em Markdown estruturado; o VLM/LLM raciocina sobre o texto. E atenção a um achado do MTEB-BR: limitar embeddings a 512 tokens penaliza documentos longos em ~25% de nDCG — relatórios contábeis longos pedem modelos de contexto longo ou chunking inteligente^K20.

§4 · Orquestrador de queries — de linguagem natural a SQL

Modelos locais especializados já ganham do GPT-4o no BIRD — o problema é o que acontece no seu banco real

O benchmark diz que 7B basta. O Spider 2.0 diz que nada basta. A diferença entre os dois números é exatamente o trabalho de engenharia deste projeto.

Na frente otimista: o Arctic-Text2SQL-R1-32B (Snowflake, Apache 2.0) reporta 71,83% de execution accuracy no BIRD — o benchmark mais respeitado de text-to-SQL, com execução real das queries — e a família XiYanSQL-QwenCoder (Alibaba) marca 67,14% (32B), 65,32% (14B) e 62,13% (7B) na mesma tabela M-Schema onde o GPT-4o-0806 faz 58,47%; os três falam PostgreSQL nativamente^K14K16. O framework LitE-SQL mostra o caminho estrutural: com um retriever vetorial de schema (0,6B) + auto-correção guiada por execução, um modelo de 7B chega a 72,10% — e a ablação atribui +4,76 p.p. só ao schema linking^K15.

Na frente realista: o Spider 2.0 — 632 tarefas de workflows empresariais reais, com bancos de 1.000+ colunas — derruba o melhor agente para 21,3%, e o BEAVER, construído sobre logs privados reais, registra 0–2% para o GPT-4o off-the-shelf^K17K18. A lição para o projeto não é desanimadora — é que o sistema precisa nascer com as técnicas que os líderes usam: schema linking para não afogar o modelo em 1.000 colunas, camada semântica com nomes de negócio ("receita líquida", "cliente ativo") compilada deterministicamente em SQL^K25, self-consistency com votação (o ReFoRCE quase dobra o baseline no Spider 2.0 com isso)^K17 e guardrails que rejeitam — nunca "consertam" — SQL perigoso^K19.

§5 · Análise de relatórios contábeis e financeiros

Onde a análise financeira quebra: cadeias de 3+ passos e convenções que não estão escritas no documento

Metade dos erros em FinQA não são de leitura nem de aritmética — são de conhecimento contábil que o modelo não tem.

O benchmark FinQA disseca o fracasso com precisão cirúrgica: em programas que exigem 3 ou mais passos de raciocínio, a acurácia colapsa para 22,78%; quando o cálculo depende de uma constante de domínio (um milhão = mil milhares; ponto-base = 0,01%), cai para 43,88%; e perguntas que cruzam tabela com texto ficam ~17 p.p. abaixo da média^K21. Cerca de 50% dos erros são lacuna de conhecimento do domínio — o modelo achou os números certos e aplicou a lógica contábil errada^K21. Em 2026, benchmarks ainda mais duros confirmam o padrão: no FinSheet-Bench, o melhor modelo de fronteira cai de 82,4% para 48,6% em planilhas financeiras complexas^K26.

As contramedidas têm evidência forte. RAG agentivo de domínio (retrieval contrastivo financeiro + raciocínio programático PoT + roteamento adaptativo) supera o melhor baseline genérico em +8,98 p.p. no FinQA e +9,32 no ConvFinQA^K22. Raciocínio iterativo (ciclos de observação-decisão) sobre um RAG ajustado leva a acurácia de 37–59% para 85% no FinanceBench^K7. E a lição arquitetural mais importante para contabilidade: tirar a aritmética do LLM — o modelo propõe o plano de cálculo; quem executa é o PostgreSQL ou Python determinístico. LLM não calcula; LLM orquestra quem calcula.

§6 · Os harnesses que mais melhoraram — ranking por evidência

Medido, não opinado: o que cada técnica de harness entregou em pontos percentuais

Se o orçamento de engenharia permitir só três investimentos, são estes: retrieval de domínio, auto-correção com execução e camada semântica.

Antes do ranking, um harness invisível que já está na sua GPU: a quantização. Até Q4_K_M, a perda de raciocínio de um 32B é ~1,5 p.p. no GSM8K (89,1% → 87,9%); abaixo de Q4 a curva despenca (−5 p.p. em Q3, −14 em Q2)^K23. Na 5090 não há motivo para descer de Q4 — o orçamento de VRAM do §1 cabe Q5/Q6 com folga. Para SQL e saída estruturada, prefira Q5_K_M ou superior: tarefas de precisão numérica são as mais sensíveis à quantização^K23.

O segundo harness invisível é o constrained decoding: o XGrammar (backend padrão de vLLM/SGLang desde mar/2026) zera falhas de parse de JSON — que em modelos menores chegam a 3–10% — por menos de 40 µs por token^K18. Duas nuances medidas: ele garante estrutura, não verdade (valores alucinados continuam possíveis); e forçar JSON desde o início suprime a cadeia de raciocínio — o padrão que preserva acurácia é raciocinar livre e restringir só a resposta final^K18. O PydanticAI implementa exatamente esse ciclo: valida a saída contra o schema e devolve o erro de validação ao modelo para nova tentativa (ModelRetry)^K24.

§7 · Arquitetura recomendada — ponta a ponta

LiteLLM na porta, PydanticAI no comando, PostgreSQL como cofre — e o LLM longe da aritmética

Cada caixa do diagrama responde a um modo de falha medido nas seções anteriores.

O fluxo de consulta nasce na pergunta em linguagem natural e passa pelo LiteLLM Router, que dá fallback ordenado, cooldowns, limites de orçamento e balanceamento entre deployments — inclusive entre o servidor vLLM local e um endpoint externo para picos^K24. O PydanticAI orquestra os agentes com saídas tipadas e retry de validação: um agente de roteamento classifica a intenção (consulta ao banco × pergunta sobre documento × híbrida), o agente SQL recebe apenas o sub-schema relevante via retriever, gera o SQL candidato, e o muro de guardrails — parser AST com sqlglot, não regex — exige SELECT único, tabelas na allow-list e LIMIT injetado, executando sob uma role read-only do PostgreSQL^K19. Erros de execução voltam ao modelo como feedback — o loop de auto-correção do §4. Em paralelo, o trilho de documentos converte PDFs em Markdown via OCR dedicado e alimenta o pgvector com embeddings fine-tunados em PT-BR^K20.

A pilha, peça por peça

§8 · Riscos, limites e roadmap

O que pode dar errado — e a ordem certa de construir

O risco número um não é técnico: é um número errado parecendo certo para um contador que confia nele.

Risco 1 — alucinação numérica silenciosa. Constrained decoding garante JSON válido, não valores verdadeiros^K18. Mitigação: a resposta exibe sempre o SQL executado e os valores vêm do banco, nunca da memória do modelo; agregados fora da faixa histórica disparam aviso; e perguntas de alto impacto pedem confirmação humana antes de executar.

Risco 2 — o gap benchmark × produção. Com schemas reais de ERP contábil (centenas de tabelas, nomes crípticos), espere acurácia inicial de 30–60%, não os 71% do BIRD^K17K18. Mitigação: começar por 10–20 relatórios de alto valor mapeados na camada semântica, medir com Pydantic Evals sobre perguntas reais dos funcionários, e alimentar o loop de feedback — toda correção vira exemplo few-shot ou dado de fine-tuning.

Risco 3 — vazamento entre clientes do escritório. Mitigação estrutural: Row-Level Security no PostgreSQL por cliente, allow-list por perfil de funcionário, e logs imutáveis de toda query executada — requisito de auditoria, não opcional^K19.

Roadmap em quatro fases

"O modelo é a peça mais barata do sistema. O que você está construindo de verdade é a camada semântica contábil, o retrieval de domínio e os guardrails — o LLM só opera essas peças."

— Síntese da pesquisa, setembro de 2026

ContextoA mesma conclusão aparece independentemente no FinanceBench (harness vale 76 p.p.), no LitE-SQL (retriever 0,6B ≈ multi-agente de 200B) e no FinQA (50% dos erros são de domínio).Por que importaDireciona o orçamento: engenharia de dados e curadoria contábil primeiro, upgrade de modelo por último.

§9 · Caso real medido — QIVIQ + Conciliador na ARQ5090

A tese do relatório, verificada em produção: os dois sistemas do escritório já implementam os harnesses campeões

Quando a pesquisa encontra um sistema real com medições, a convergência é quase constrangedora.

O Conciliador (produção desde 26/09/2026) opera o padrão "determinístico primeiro, LLM depois, humano decide o resto": regras contábeis resolvem o que podem, o RAG (BGE-M3 + pgvector, namespace por empresa) entra só nas linhas sem regra, e o LLM de texto apenas sugere ou veta — nunca grava sozinho no Questor^K27. O QIVIQ vai na mesma direção pelo lado da consulta: em produção o modelo não escreve SQL, respostas seguem um catálogo validado, Python é a fonte de todos os cálculos e uma auditoria determinística confere valores, unidades, datas e citações antes de qualquer entrega^K28. O catálogo de relatórios é, na prática, a camada semântica do §4 — a contramedida nº 1 contra o abismo benchmark × produção.

O resultado mais eloquente é medido, não projetado: na prova diária de leitura de extratos, o Qwen3-VL-32B local aprovou as 13 leituras certas e barrou as 13 erradas — e, em 40 PDFs inéditos de 9 bancos, o saldo da última página saiu certo em 29/40 no modelo local a 1,6 s por PDF, contra 26/40 do Gemini 2.5 Flash a 2,7 s^K27. O modelo local, com o harness certo (prova aritmética dia a dia), venceu a API de fronteira na tarefa do negócio.

O que o caso muda na recomendação de hardware

O próprio histórico da ARQ5090 documenta o porquê da segunda placa: o vLLM reserva 95% da RTX 5090 (29.728 MiB medidos), o qwen3.6:27b do Ollama não cabe na VRAM restante, e a tentativa de somar o PaddleOCR-VL na mesma GPU causou CUDA OOM na requisição mais pesada (260 dpi + 12.288 tokens de saída) e derrubou a produção por ~2 minutos^K27. A lição registrada pelo projeto — "qualquer modelo novo precisa ser testado contra a requisição mais pesada, não contra um ok" — é exatamente a disciplina de capacidade que o layout dual-GPU do §1 institucionaliza: a 5090 fica intocada com o 32B e seu KV pool; tudo que é serviço migra para a placa de 16 GB^K29.