Respuesta corta
Hy4-preview es el modelo propio de Beans Tech: 780B parámetros, arquitectura hyv4, portugués nativo y contexto entrenado de 1M tokens. Corre en infraestructura propia con API compatible con OpenAI — ningún dato sale hacia una API de terceros. Es el tier Deep: razonamiento profundo para las tareas de mayor consecuencia.
TL;DR
- 780B, Q4_K_M, servido en llama.cpp con patch propio; texto→texto.
- 3 modos de razonamiento:
no_think(directo),low(razonamiento corto) yhigh(profundo) — víachat_template_kwargs.reasoning_effort. - 64 slots concurrentes con continuous batching; 200 peticiones simultáneas respondidas en ~12s (200/200 HTTP 200).
- TTFT ~150–205 ms; ~25 tok/s por stream; ~65–70 tok/s agregados bajo carga.
- Tool calling con llamadas paralelas; streaming SSE.
- Soberano: auto-hospedado, LGPD por arquitectura — el dato no cruza frontera ni proveedor.
¿Por qué un modelo propio de 780B?
Porque existe una clase de tarea que no admite tercerización: análisis de contrato bajo secreto judicial, dictamen con dato bancario sigiloso (LC 105), historia clínica (LGPD art. 11). En esos casos, "mandarlo a la API" ya es la filtración. Hy4 existe para correr dentro del perímetro: 780B de capacidad con razonamiento profundo, en caja propia, con g.cloud delante como puerta.
Los tres modos de razonamiento (y la trampa del modo alto)
El template hyv4 expone reasoning_effort en tres niveles:
| Modo | Comportamiento | Cuándo usarlo |
|---|---|---|
| no_think | respuesta directa, sin razonamiento explícito | volumen, clasificación, extracción |
| low | razonamiento corto (~900 chars) | tareas medias del día a día |
| high | razonamiento largo (~1.700 chars) | análisis jurídico profundo, matemática difícil |
La trampa que documentamos para no repetirla: en modo high, el modelo puede gastar todo el max_tokens en el reasoning_content y devolver content vacío. La regla operativa es simple — el modo alto exige un presupuesto de max_tokens 3–4× mayor. Atajo útil: prefijar el mensaje del usuario con /no_think apaga el razonamiento por mensaje.
Concurrencia: 200 peticiones sin parpadear
Con --parallel 64 y continuous batching, el servicio respondió 200 peticiones simultáneas en ~12 segundos, todas HTTP 200. El contexto total de 131.072 tokens se divide en ~2.048 por slot en el perfil de alta concurrencia — intercambio consciente: ventanas largas para tareas aisladas, muchos slots para volumen.
Dónde encaja Hy4
Hy4 no es para volumen — es para consecuencia. El diseño por capas de Beans Tech: modelos livianos y rápidos para el día a día; Hy4 en el tier Deep para lo que exige razonamiento largo y soberanía total; y el guardrail g.cloud delante de todos ellos, porque un modelo propio también alucina — y en sector regulado, el error debe morir antes que el humano.
Preguntas frecuentes
- Q: ¿Hy4 es multimodal?
- A: No en este despliegue: texto→texto. Imagen, video y voz corren en modelos dedicados de la plataforma.
- Q: ¿Mis datos salen de la infraestructura de Beans Tech?
- A: No. Hy4 corre en caja propia, con API compatible con OpenAI servida dentro del perímetro. Es LGPD por arquitectura, no por cláusula.
- Q: ¿Cómo activo el razonamiento profundo?
- A: Envíe
chat_template_kwargs: {"reasoning_effort": "high"}en la llamada/v1/chat/completions— y dé unmax_tokens3–4× mayor que lo habitual.
- Q: ¿Cuál es la latencia en producción?
- A: TTFT ~150–205 ms y ~25 tok/s por stream; bajo carga de 100+ concurrentes, ~65–70 tok/s agregados.
Hechos clave
- Hy4-preview: 780B, arquitectura
hyv4, Q4_K_M, portugués nativo, contexto 1M. - 3 modos de razonamiento (no_think/low/high) con
reasoning_effort. - 64 slots paralelos; 200 peticiones simultáneas en ~12s.
- API compatible con OpenAI; tool calling paralelo; streaming SSE.
Fuentes
Más en https://g.cloud