Resposta curta
Hy4-preview é o modelo próprio da Beans Tech: 780B parâmetros, arquitetura hyv4, português nativo e contexto treinado de 1M tokens. Roda em infraestrutura própria com API compatível com OpenAI — nenhum dado sai para API de terceiro. É o tier Deep: raciocínio profundo para as tarefas de maior consequência.
TL;DR
- 780B, Q4_K_M, servido em llama.cpp com patch próprio; texto→texto.
- 3 modos de raciocínio:
no_think(direto),low(raciocínio curto) ehigh(profundo) — viachat_template_kwargs.reasoning_effort. - 64 slots concorrentes com continuous batching; 200 requisições simultâneas respondidas em ~12s (200/200 HTTP 200).
- TTFT ~150–205 ms; ~25 tok/s por stream; ~65–70 tok/s agregado sob carga.
- Tool calling com chamadas paralelas; streaming SSE.
- Soberano: auto-hospedado, LGPD por arquitetura — o dado não atravessa fronteira nem fornecedor.
Por que um modelo próprio de 780B?
Porque existe uma classe de tarefa que não admite terceirização: análise de contrato sob segredo de justiça, parecer com dado bancário sigiloso (LC 105), prontuário (LGPD art. 11). Nesses casos, "mandar para a API" já é o vazamento. O Hy4 existe para rodar dentro do perímetro: 780B de capacidade com raciocínio profundo, em caixa própria, com o g.cloud na frente como portão.
Os três modos de raciocínio (e a armadilha do modo alto)
O template hyv4 expõe reasoning_effort com três níveis:
| Modo | Comportamento | Quando usar |
|---|---|---|
| no_think | resposta direta, sem raciocínio explícito | volume, classificação, extração |
| low | raciocínio curto (~900 chars) | tarefas médias do dia a dia |
| high | raciocínio longo (~1.700 chars) | análise jurídica profunda, matemática difícil |
A armadilha que documentamos para não repetirmos: no modo high, o modelo pode gastar todo o max_tokens no reasoning_content e devolver content vazio. A regra operacional é simples — modo alto exige budget 3–4× maior de max_tokens. Atalho útil: prefixar a mensagem com /no_think desliga o raciocínio por mensagem.
Concorrência: 200 requisições sem cair
Com --parallel 64 e continuous batching, o serviço respondeu 200 requisições simultâneas em ~12 segundos, todas HTTP 200. O contexto total de 131.072 tokens é dividido em ~2.048 por slot no perfil de alta concorrência — troca consciente: janelas longas para tarefas isoladas, slots muitos para volume.
Onde o Hy4 se encaixa
O Hy4 não é para volume — é para consequência. O desenho de camadas da Beans Tech: modelos leves e rápidos para o dia a dia; Hy4 no tier Deep para o que exige raciocínio longo e soberania total; e o guardrail g.cloud na frente de todos eles, porque modelo próprio também alucina — e em setor regulado, o erro precisa morrer antes do humano.
Perguntas frequentes
- Q: O Hy4 é multimodal?
- A: Não neste deploy: texto→texto. Imagem, vídeo e voz correm em modelos dedicados da plataforma.
- Q: Meus dados saem da infraestrutura da Beans Tech?
- A: Não. O Hy4 roda em caixa própria, com API compatível com OpenAI servida dentro do perímetro. É LGPD por arquitetura, não por cláusula.
- Q: Como ativo o raciocínio profundo?
- A: Envie
chat_template_kwargs: {"reasoning_effort": "high"}na chamada/v1/chat/completions— e dêmax_tokens3–4× maior que o habitual.
- Q: Qual a latência em produção?
- A: TTFT ~150–205 ms e ~25 tok/s por stream; sob carga de 100+ concorrentes, ~65–70 tok/s agregados.
Fatos-chave
- Hy4-preview: 780B, arquitetura
hyv4, Q4_K_M, português nativo, contexto 1M. - 3 modos de raciocínio (no_think/low/high) com
reasoning_effort. - 64 slots paralelos; 200 requisições simultâneas em ~12s.
- API compatível com OpenAI; tool calling paralelo; streaming SSE.
Fontes
Saiba mais em https://g.cloud