O modelo cabe no hardware que o cliente já tem.
Dois modelos abertos na mesma placa de 2018. Um MoE de 20B a 109,13 tok/s — 1,76× o llama.cpp servindo o mesmo arquivo, com prefill e HTTP no relógio. Um 27B denso a 62,55 tok/s em 6,67 GiB. Engine agnóstico de modelo, API compatível com OpenAI.
Pesos abertos de terceiros, sob licença permissiva. MoE medido em 30/08/2026 no /v1/chat/completions. 27B denso medido em 27/08/2026. RTX 2080 Ti, 10.821 MiB. Identificação dos modelos sob NDA.
O gargalo é memória, não processamento.
Um modelo denso de 27 bilhões de parâmetros em fp16 ocupa cerca de 54 GB. Isso exige um acelerador de datacenter de 80 GB. Não porque a placa de consumo seja lenta demais, mas porque o peso não cabe.
Quantização de 4 bits estreita o buraco sem fechar. Nosso formato fecha.
O mesmo modelo, dois formatos
No nosso formato, o 27B denso ocupa 6,67 GiB. No formato aberto equivalente, 7,05 GiB. Cabe com folga numa placa de 11 GB, junto com o cache de contexto. O volume ao lado está em escala: o cubo é o modelo, os arames são as placas.
Escala linear do volume = (7,05/54)^(1/3). Arames: A100 80 GB e RTX 2080 Ti 11 GB, derivados da mesma base.
Medido, não estimado.
Dois modelos, a mesma RTX 2080 Ti de 2018 (10.821 MiB). O MoE é a prova no mesmo arquivo. O 27B denso continua a prova de que o peso cabe.
MoE aberto de 20B · 30/08/2026 · mesmo arquivo
MoE de 20B com cerca de 1B de parâmetros ativos por token, num arquivo de 5,91 GiB. Servido inteiro na GPU, com 131 072 tokens de contexto numa placa de 11 GB.
| Stack | Hardware | tok/s | Método |
|---|
Os dois stacks serviram o mesmo arquivo de pesos. NeuroGrid no /v1/chat/completions, 4 corridas × 256 tokens. Do outro lado, o llama.cpp no benchmark oficial do modelo.
27B denso aberto · 27/08/2026
| Stack | Modelo | Arquivo | Prefill | Decode |
|---|---|---|---|---|
| NeuroGrid engine | 27B | 6,67 GiB | — | 62,55 tok/s |
| llama.cpp | 27B | 7,05 GiB | 604,39 ± 52,09 tok/s | 52,87 ± 0,18 tok/s |
Medições de 27/08/2026 em RTX 2080 Ti (10.821 MiB). Os arquivos de peso diferem entre as duas linhas: cada stack serviu o formato dele.
A gravação da máquina.
90 segundos do modelo denso de 27B respondendo na RTX 2080 Ti. À esquerda, a sessão de chat. À direita, a telemetria lida da própria placa durante a gravação: ocupação, VRAM, potência e temperatura.
Captura de tela real. Os trechos sem atividade foram cortados e cada corte está marcado no vídeo; o relógio exibido é o da gravação original. Telemetria extraída quadro a quadro do nvtop.
O engine é o produto. Onde ele roda é a decisão.
Licença soberana no hardware do cliente. Cloud pela API. Conversão do modelo que ele já tem.
Licença soberana
NeuroGrid no perímetro, no silício que o órgão ou a empresa já comprou. O dado não sai.
SuperSeed Cloud
Inferência por token através de uma API compatível com OpenAI, servida sobre capacidade que nós alugamos. Integração trocando a base URL.
Conversão de modelo
Transformamos o modelo aberto do cliente, incluindo versões com fine-tuning, em uma build comprimida que roda no hardware que ele já tem.
Onde a soberania é requisito contratual.
O engine vale mais onde o dado não pode sair do prédio, e onde o orçamento de hardware não comporta acelerador de datacenter.
Judiciário e órgãos públicos
A Resolução CNJ 615/2025 exige supervisão humana efetiva, rastreabilidade e controle sobre o ambiente de processamento. É o que a arquitetura entrega, sem transferir acervo para serviço externo.
Empresa regulada
Banco, cooperativa e operadora de saúde que precisam de modelo aberto com fine-tuning rodando sob o próprio controle, com residência de dado definida.
Educação
IA rodando localmente na escola ou na rede de ensino, sem depender de conectividade estável nem de custo por token variável.
O que é aberto, e o que não é.
Um investidor ou um engenheiro sério vai perguntar isso primeiro, então respondemos antes.
Aberto, e não é nosso
- Os pesos abertos que usamos nas medições, publicados por terceiros sob licença permissiva.
- Parte da matemática de compressão, que é pesquisa publicada e não reivindicamos.
- O formato de peso aberto usado pelo runtime de referência.
Nosso, e não é público
- Os kernels CUDA de produção. A cobertura de arquitetura é definida em contrato.
- Os kernels Metal e CPU, e o runtime em Go.
- O serving medido dos dois modelos: pesos deles, kernels nossos.
- Mythos: pré-treino nosso, servido pelo mesmo runtime.
O mesmo stack que serve o 27B é o que treina o próximo.
Um modelo no NeuroGrid especializa o seguinte — pesos, runtime e o silício que o cliente já tem. Cada conta vira um domínio, não um chatbot genérico. Quanto mais o engine roda, mais o próximo modelo fica nosso.
O que o stack já faz
- Serve um MoE de 20B e um 27B denso no hardware que o cliente já comprou.
- Kernels de produção em CUDA, Metal e CPU.
- Pré-treino próprio (Mythos) no mesmo runtime.
- API compatível com OpenAI. Agnóstico de modelo.
Para onde isso vai
- Um modelo gera o próximo, no silício do cliente.
- Especialização por domínio: um tribunal, uma ferrovia, um órgão.
- Modelo e runtime na mesma superfície do hardware.
- O cliente não fica preso a um fornecedor de modelo — inclusive a nós.
Cada linha é uma promessa diferente.
Misturar as linhas é o erro que vira processo. A licença soberana é a única onde a afirmação forte é literal.
| SuperSeed Cloud | Licença soberana | |
|---|---|---|
| Quem pode tecnicamente ler o prompt | SuperSeed e o operador do datacenter alugado | Somente o cliente |
| Confiança exigida | No contrato da SuperSeed e no do fornecedor de capacidade | Nenhuma. O dado não sai do perímetro |
| Afirmação verdadeira | Cifrado em trânsito. Não persistimos prompt nem resposta. | Seus dados não saem da sua infraestrutura. Nós não temos como lê-los. |
| Base legal | Operador identificado, DPA assinado | Cliente é o próprio controlador |
Prompts e respostas não são persistidos pela SuperSeed.AI. Todo nó que processa é operador identificado e contratado. Jurisdição é restrição de roteamento, não preferência: um pedido marcado como Brasil não sai do Brasil.
Cada request atendido deixa um recibo que o cliente confere sozinho.
Esta é uma promessa diferente da do engine, e por isso está numa seção própria. O engine faz o modelo caber. Isto responde a outra pergunta: como o cliente confere, sem confiar na nossa palavra, o que serviu cada request que ele pagou.
Um recibo assinado por request
Cada request servido pela SuperSeed Cloud gera um recibo assinado: o que serviu, quantos tokens entraram e saíram, e os hashes do prompt e da resposta. O prompt em claro não entra no recibo: o que é publicado é um hash com sal.
Uma âncora por época de 30 minutos
A cada 30 minutos os recibos da janela viram uma árvore de Merkle e só a raiz vai para a Arbitrum. É uma transação por época, não uma por request: o custo de ancorar não cresce com o tráfego, e uma época sem nenhum recibo é publicada do mesmo jeito, porque um buraco na sequência seria a evidência que falta.
A conferência não passa por nós
O verificador lê a raiz direto do contrato por RPC público e baixa o arquivo da época, recomputa a árvore e recupera as duas assinaturas. Nenhum passo consulta uma API da SuperSeed. Quem guardar o arquivo da época confere o recibo mesmo que o nosso servidor saia do ar: a raiz que decide está no contrato, não conosco.
Contrato SuperSeedLedger 0x518d126F35f7298aF2D888Bd758081488E8C4042, Arbitrum Sepolia (chain 421614). Época de 30 minutos, âncora com espera de finalidade. Os arquivos de época são servidos sem credencial; o recibo individual, com a chave do próprio cliente. Os recibos descritos aqui são os da SuperSeed Cloud.
Uma conversa técnica de uma hora.
Mostramos o MoE a 109,13 tok/s e o 27B a 62,55 tok/s na mesma placa de 2018, ao vivo, e abrimos os números. Se o hardware não convencer, o resto não importa.