# PRISMA com modelo aberto hospedado por nós — relatório do teste de 19/09/2026

Todas as horas são UTC. Cada afirmação abaixo aponta para o arquivo desta pasta
que a sustenta. `SHA256SUMS` fecha o conjunto.

## 1. O que foi feito

O PRISMA (o mesmo backend, o mesmo MCP do acervo, o mesmo front React que está em
`prisma.davidariasfinance.com`) respondeu às perguntas de teste usando, no lugar
da API da DeepSeek, o **Qwen3.8-27B-FP8**: pesos abertos (Apache 2.0) baixados
do Hugging Face, servidos por **vLLM 0.29.0** numa GPU **RTX PRO 6000 Blackwell
96 GB** alugada na RunPod (Secure Cloud, datacenter EUR-IS-1, Islândia). O
PRISMA ficou na AWS (Estocolmo) e falou com o modelo por um **túnel SSH aberto
pela AWS**; o vLLM escutava só em `127.0.0.1` dentro do pod, sem porta pública.

No mesmo dia, com as mesmas perguntas, o mesmo código rodou contra a DeepSeek
(braço de referência). A produção (porta 8787) não foi tocada.

## 2. O que isto prova, e o que não prova

**Prova:**

1. **Nenhuma API de modelo de terceiros foi usada no braço Qwen.** O processo do
   backend e o subprocesso do acervo rodaram sob `IPAddressDeny=any` +
   `IPAddressAllow=localhost` (filtro de rede do kernel, por cgroup). De dentro
   desse cgroup, `api.deepseek.com`, `api.openai.com` e `huggingface.co` não
   conectam; `127.0.0.1:8001` (o túnel) responde 200 com o token e 401 sem ele.
   → `aws/resultados/qwen27b-bloqueio.txt`, `qwen27b-unidade.txt`.
   O ambiente do processo não tem nenhuma variável `DEEPSEEK*` nem `OPENAI*`.
   → `qwen27b-ambiente-nomes.txt` (só nomes, nunca valores).
   As 63 idas ao modelo foram todas para `http://127.0.0.1:8001/v1/`.
   → `qwen27b-traco.jsonl`. A única conexão de saída do servidor durante o braço
   foi o SSH para o pod (`[ip]:10666`); as outras linhas são o meu
   próprio SSH de controle, de entrada. → `qwen27b-conexoes.txt`.
2. **Os pesos são os públicos, byte a byte.** Commit
   `017b9c7af6b5689d5dd426a76e0bc077eb5ca20a` de `Qwen/Qwen3.8-27B-FP8`; os 81
   arquivos conferidos contra o Hugging Face (sha256 dos `safetensors`, tamanho
   dos pequenos), 0 divergência. O mesmo para os 144 arquivos do
   `Qwen3.8-Flash-Next-FP8`. → `2026-09-19/fase1/sha256.txt`. Qualquer pessoa
   refaz essa conferência sem depender de nós.
3. **Os números dos dois lados batem.** O traço do PRISMA soma 517.501 tokens de
   entrada e 15.633 de saída em 63 pedidos; o teste de imagem, feito direto no
   vLLM, somou 1.708 + 32 em 1 pedido. Os contadores do próprio vLLM no fim da
   sessão: **519.209** de entrada, **15.665** de saída, **64** pedidos concluídos,
   0 erro. É a mesma conta, até o último token.
   → `pod-fase2-27b/fase2-27b/metrics-fim.prom`, `qwen27b-traco.jsonl`, `qwen27b-imagem.json`.
4. **A máquina.** `nvidia-smi` antes, depois e a cada 5 s durante (267 amostras,
   uso até 100%, memória até 90.383 MiB de 97.887), a linha exata do
   `vllm serve`, o log inteiro do servidor com cada pedido e cada resposta
   (14.842 linhas), versões de tudo. → `pod-fase2-27b/fase2-27b/`.
   Criação e término de cada pod, com id, GPU, datacenter e US$/h, nas respostas
   cruas da API da RunPod. → `2026-09-18/runpod/`, `2026-09-19/runpod/`.

**Não prova**, e ninguém deve ler isto aqui: que rodou dentro da empresa de um
cliente. A GPU é de um datacenter da RunPod. O nome correto é **auto-hospedado
com pesos abertos**: nada na receita depende da RunPod nem da AWS, então ela
roda igual num servidor do cliente ou na conta de nuvem dele. Também é registro
nosso, não auditoria de terceiros; o que terceiros atestam é a fatura da RunPod
(exportável do painel) e os hashes do Hugging Face.

## 3. Resultado

| | DeepSeek (API, `deepseek-chat`) | Qwen3.8-27B-FP8 (nosso, 1× RTX PRO 6000) |
|---|---|---|
| Fumaça (CNPJ do Cloudwalk Bela) | certo, 3,2 s | certo, 3,5 s |
| **Gabarito de 17 casos** (mesmo corretor) | **17/17** | **16/17** |
| — numéricos (PL, subordinação) | 10/10 | 10/10 |
| — extremos (mês de pico) | 4/4 | 4/4 |
| — armadilhas | 2/2 | 2/2 |
| — atribuição (fundo irmão) | 1/1 | 0/1 (ver nota) |
| Tempo mediano por caso | 4,3 s | 8,6 s |
| Bateria de 5 turnos, total | 17,8 s | 87,7 s |
| Tempo até o 1º token (mediana por ida) | 0,80 s | 0,49 s |
| Velocidade de geração (mediana) | ~217 tokens/s | ~45 tokens/s |
| Idas ao modelo (fumaça + bateria + gabarito + front) | 48 | 63 |
| Chamadas de ferramenta malformadas | 0 | 0 |
| Leitura de imagem (página de regulamento → 2 taxas) | não testado | certo, 1,9 s |
| Busca no acervo | só lexical | só lexical |

A barra combinada antes do teste era ≥ 15/17, turno mediano < 30 s e zero
chamada malformada. **O 27B passou.**

**Nota sobre o caso perdido.** A pergunta era o PL do SOLIS CAPITAL CORE, e a
armadilha é citar o número do fundo irmão. O Qwen pegou o fundo certo e o valor
certo, mas escreveu **"R$ 3.424 bi"**, com ponto onde o português usa vírgula
("3,424 bi"). O corretor lê isso como outro número e reprova, com razão: é erro
de notação, não de dado nem de atribuição. Mantive a nota estrita. É o tipo de
coisa que uma linha no prompt de sistema resolve, e vale medir de novo depois.
→ `aws/resultados/qwen27b-nota.txt`, `qwen27b-gabarito.json`.

**Sobre a velocidade.** O Qwen responde mais rápido no primeiro token e gera
~5× mais devagar: um modelo denso de 27B numa placa só é limitado pela banda de
memória. Na bateria a diferença cresce porque ele escreve respostas mais longas e
chama ferramenta em turnos em que a DeepSeek respondeu de memória da conversa
(`fidc_buscar`, `fidc_comparar`, `fidc_indicadores`). Não foi usada decodificação
especulativa (o repositório traz os pesos MTP para isso), que é o primeiro ajuste
a tentar.

**Front.** O React de produção, em Chromium headless, 5 turnos: login em 76 ms,
1º texto entre 1,5 e 6,5 s, turnos de 14,7 a 40,9 s. Os 2 erros de console são o
401 da checagem de sessão antes do login, que a produção também mostra.
→ `2026-09-19/fase2-27b/front/` (capturas por turno + `app-resultado.json`).

## 3b. Segundo modelo: Qwen3.8-Flash-Next-FP8 (rodou, mas em condição apertada)

MoE de 125B com ~6B ativos, 185,6 GB de pesos (licença Qwen Community 1.0, não
Apache). Rodou em **2× RTX PRO 6000 96 GB** (US$ 4,18/h), `--tensor-parallel-size 2`,
pela mesma instância travada e pelo mesmo túnel. Carregou 86,5 GiB por placa em
14 min 22 s e sobrou **2,96 GiB** para cache. Para caber, três concessões que
mudam o resultado e por isso ficam à vista: contexto limitado a **32.768**
tokens, **sem CUDA graphs** (`--enforce-eager`) e no máximo 4 sequências.
→ `aws/resultados/pod-fase3-flash/fase3-flash/` (`comando.txt`, `servidor.log`,
`nvidia-smi-durante.csv` com 932 amostras, pico de 94.587 MiB por placa).

| | Qwen3.8-Flash-Next-FP8 (2× RTX PRO 6000, modo apertado) |
|---|---|
| Fumaça | certo, 8,6 s |
| Gabarito de 17 casos | **14/17**: as 3 perdas são respostas **vazias** por estouro de contexto; os 14 casos respondidos estão todos certos |
| Tempo mediano por caso | 30 s |
| Bateria de 5 turnos | 267 s, com o 1º turno vazio pelo mesmo estouro |
| Velocidade de geração | ~22 tokens/s (sem CUDA graphs; não é o que o modelo entrega) |
| Chamadas de ferramenta por caso (mediana) | 2, com casos de 9 e 11 (DeepSeek e 27B: 1) |
| Leitura de imagem | certo, 3,5 s |
| Bloqueio de rede, túnel, contadores | iguais ao 27B: traço 875.152 + 16.223 tokens em 77 pedidos, mais a imagem (1.708 + 32), contra **876.860 / 16.255 / 78** do vLLM |

**Leitura honesta:** este braço prova que o Flash-Next **roda** no PRISMA por
esta arquitetura e acerta o que consegue responder. Não mede o modelo de forma
justa. Ele abre e lê mais documentos por pergunta que os outros dois, e com o
teto de 32k (imposto pela memória, não pelo modelo, que aceita 262k) cinco
pedidos passaram do limite e o vLLM recusou (`400 maximum context length`).
A velocidade também é a do modo de economia de memória. Para julgar o Flash-Next
é preciso 2×H200 ou 4× RTX PRO 6000 (US$ 8–9/h, em outro datacenter).
→ `flash-nota.txt`, `flash-gabarito.json`, `flash-journal-prisma.txt`, `flash-bloqueio.txt`.

**Conclusão dos dois:** para "roda no seu ambiente", o **27B é o candidato**:
cabe numa placa só, passou na barra (16/17, zero chamada malformada, lê imagem)
e o custo de hospedar é o de uma GPU de 48–96 GB. O que falta nele é velocidade
(decodificação especulativa, ou duas placas) e uma linha de prompt sobre notação
numérica em português.

## 4. O que quebrou no caminho (fica registrado)

- O volume de 220 GB estourou a cota: o Flash-Next tem 185,6 GB, não os ~157 GB
  que eu tinha. Volume aumentado para 260 GB, download retomado.
  → `2026-09-18/fase1-tentativa1/`.
- Primeira subida do 27B morreu no aquecimento: o FlashInfer não reconheceu a
  Blackwell dentro da imagem `runpod/pytorch` ("requires sm75 or higher"), com o
  modelo já carregado. Resolvido com o amostrador nativo do vLLM e
  `TORCH_CUDA_ARCH_LIST=12.0`. Custou US$ 0,31. → `2026-09-19/fase2-27b-tentativa1/`.
- A primeira rodada do braço DeepSeek foi descartada por dois erros meus (o campo
  da resposta inteira não estava sendo gravado; a primeira pergunta do gabarito
  bateu no limite de 6/min). Refeita inteira. → `aws/resultados/descartado-0100/`.
- O pod do 27B marcou FECHADO mas não se apagou sozinho; terminei pela API. No Flash-Next terminei pela API logo após copiar os logs.
- No braço Flash-Next o teste de imagem rodou às 02:22, enquanto o gabarito ainda corria (um laço de espera meu venceu antes da hora); pode ter somado alguns segundos a um caso.

## 5. Custos (RunPod)

Saldo no começo US$ 6,39. Fase 1 (download, 3 pods de US$ 0,24/h): ~US$ 0,25.
27B: tentativa morta US$ 0,31 + sessão boa de ~24 min a US$ 2,09/h ≈ US$ 0,85.
Flash-Next: sessão de ~40 min a US$ 4,18/h ≈ US$ 2,75 (14 min só carregando os pesos do volume de rede).
Saldo no fim US$ 2,29; gasto total do teste ≈ US$ 4,10. Volume de 260 GB: US$ 0,61/dia enquanto existir.