Hy3 è un modello MoE solo testo per la programmazione, il ragionamento, il lavoro su contesti lunghi e gli agenti. Per una prima integrazione, usa un endpoint hosted compatibile con OpenAI, invia una normale richiesta Chat Completions e valuta il singolo workflow che automatizzeresti davvero. Non standardizzarlo finché non segue il tuo schema di strumenti e non mantiene i vincoli che contano nei tuoi input lunghi.
I dettagli del provider riportati di seguito sono stati verificati il 14 luglio 2026. DeepInfra documenta il modello come tencent/Hy3 nel suo endpoint Chat Completions compatibile con OpenAI. Anche SiliconFlow elenca Hy3 sotto lo stesso ID del modello. I prezzi, i limiti e gli alias del provider possono cambiare, quindi verifica la pagina live del provider prima del rilascio.
Inizia con una chiamata API Hy3 ospitata
DeepInfra pubblica questa richiesta minima per il suo endpoint Hy3 ospitato. Sostituisci il token con il tuo token del provider; non inserirlo nel codice del browser o in un'app client.
curl "https://api.deepinfra.com/v1/openai/chat/completions" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $DEEPINFRA_TOKEN" \
-d '{
"model": "tencent/Hy3",
"messages": [
{"role": "user", "content": "Restituisci tre controlli di accettazione API."}
]
}'
La risposta utilizza la struttura standard di Chat Completions. Analizza la risposta e i campi di fatturazione in questo modo:
{
"id": "chatcmpl-...",
"object": "chat.completion",
"model": "tencent/Hy3",
"choices": [{
"message": {"role": "assistant", "content": "..."},
"finish_reason": "stop"
}],
"usage": {
"prompt_tokens": 0,
"completion_tokens": 0,
"total_tokens": 0
}
}
Leggi choices[0].message.content per la risposta e usage per il conteggio dei token. Aggiungi "stream": true solo dopo che una richiesta non in streaming funziona; DeepInfra documenta lo streaming come eventi inviati dal server che terminano con [DONE].
Le opzioni dei provider nella tabella sono deliberatamente limitate. Si tratta di percorsi di accesso pubblico verificati, non di una classifica dei prezzi.
Provider | Dettaglio di accesso verificato | Cosa confermare prima della produzione |
|---|---|---|
| Prezzo attuale, limiti dell'account, supporto degli strumenti e termini sui dati | |
API compatibile con OpenAI; model | Endpoint attuale, prezzo, limiti di richiesta e ambito della chiave API | |
Il 14 luglio, la sua pagina elencava | Se l'alias è ancora disponibile, i suoi limiti e il provider instradato |
L'annuncio di rilascio di Tencent del 6 luglio 2026 ha presentato Hy3 come un modello Mixture-of-Experts a peso aperto. Il suo annuncio ufficiale dei prezzi e la scheda del modello lo rendono un candidato per una valutazione ospitata, ma una pagina API non è una prova che sia adatto a un carico di lavoro di produzione.
Cos'è Hy3, e cosa non è
Hy3 è un modello MoE da 295B parametri con 21B parametri attivi per token. La scheda modello ufficiale di Hy3 elenca 192 esperti con routing top-8, un backbone a 80 layer, un layer MTP, una finestra di contesto da 256K token e una licenza Apache 2.0.
Quei numeri descrivono un modello testuale progettato per il ragionamento, il coding, le conversazioni lunghe e gli agenti che utilizzano strumenti. Non fanno di Hy3 un modello per immagini o OCR. Un workflow il cui input principale è una fattura scansionata, uno screenshot, una foto di prodotto o un grafico ha bisogno prima di un modello vision o OCR, e solo dopo di Hy3. Mantenere chiaro questo confine evita un errore architetturale comune: chiedere a un modello testuale capace di recuperare informazioni che non ha mai ricevuto.
Tencent posiziona Hy3 per programmazione, lavoro d’ufficio, modellazione finanziaria, lavoro frontend e sviluppo di videogiochi. Considerali carichi di lavoro candidati, non una classifica universale.
Leggi le affermazioni del benchmark con i loro limiti
L'annuncio di rilascio di Tencent riporta una valutazione in cieco con 270 esperti che hanno svolto attività lavorative in cui Hy3 ha ottenuto 2,67 su 4 e GLM-5.1 ha ottenuto 2,51 su 4. La stessa fonte afferma che l'accuratezza di SWE-Bench Verified di Hy3 è variata di meno di quattro punti percentuali tra i scaffold CodeBuddy, Cline e KiloCode. Questi sono risultati riportati da Tencent, non una garanzia indipendente che Hy3 supererà un rivale specifico nel vostro ambiente.
Artificial Analysis è un altro punto di riferimento per le misurazioni a livello di modello. Leggi i numeri dei benchmark come input per la selezione del modello, non come sostituti dei criteri di accettazione a livello di applicazione.
Scegli la modalità di ragionamento in base al costo del fallimento
Hy3 espone no_think, low e high come livelli di sforzo di ragionamento nei suoi esempi ufficiali di serving. La scelta dovrebbe seguire il costo di una risposta errata, non il prestigio di usare un modello di ragionamento.
Carico di lavoro | Inizia con | Cosa misurare prima di passare a un livello superiore |
|---|---|---|
Classificazione, estrazione da testo pulito o instradamento semplice |
| Etichetta corretta o valori dei campi, latenza e token di output |
Modifiche di codice delimitate, riepiloghi con più regole o una sequenza di uno strumento |
| Tasso di superamento dei test, argomenti validi degli strumenti e modifiche umane |
Debugging su più file, pianificazione con vincoli in conflitto o ragionamento numerico |
| Tasso di completamento delle attività, retry, token totali e tempo di revisione |
Mantieni no-think per il lavoro delimitato
no_think è la modalità predefinita di risposta diretta. È la base di riferimento giusta quando la sorgente è già strutturata, la risposta ha una forma nota e una risposta più lenta non aggiungerebbe ragionamenti utili. Ad esempio, un flusso di lavoro di supporto che sceglie uno stato documentato e chiama una funzione dovrebbe essere testato inizialmente in questa modalità. Aggiungi uno schema JSON rigoroso e rifiuta le risposte che hanno campi extra invece di sperare che una catena di ragionamento più lunga ripari un contratto vago.
Usa un ragionamento basso o alto quando un errore cambia l'azione successiva
Sposta su low quando il modello deve conciliare più regole o apportare una modifica limitata al codice. Riserva high per i casi in cui una decisione intermedia debole provoca un costoso tentativo di nuovo: diagnosticare un guasto in più file, scegliere un ordine delle operazioni o verificare i calcoli prima di una chiamata a uno strumento.
Il compromesso è misurabile. Confronta l’intero task completato: latenza della richiesta, numero di token di output, ritentativi delle tool call, fallimenti dei test e i minuti che un revisore dedica a correggere la risposta. Una modalità che sembra più ponderata ma raddoppia i token senza ridurre il tempo di revisione non è l’impostazione migliore per la produzione.
Esegui una prova API in quattro parti prima di adottare Hy3
Questo test crea evidenze per il tuo sistema piuttosto che un verdetto generico sul modello. Usa attività reali ma non sensibili. Blocca prompt, schemi e criteri di superamento prima di eseguire i modelli, così da non cambiare i parametri dopo aver letto una risposta.
Verifica il percorso della richiesta con una chiamata self-hosted minima
L'esempio seguente segue il pattern di serving ufficiale self-hosted compatibile con OpenAI di Hy3. Utilizza un endpoint locale compatibile con vLLM e il nome del modello configurato da quel server. Gli ID dei modelli ospitati sono specifici del provider; usa la tabella dei provider sopra per gli ID ospitati verificati.
from openai import OpenAI
client = OpenAI(
base_url="http://127.0.0.1:8000/v1",
api_key="EMPTY",
)
response = client.chat.completions.create(
model="hy3",
messages=[
{"role": "user", "content": "Elenca i controlli di accettazione per una chiamata a uno strumento JSON."}
],
temperature=0.9,
top_p=1.0,
extra_body={
"chat_template_kwargs": {"reasoning_effort": "low"}
},
)
print(response.choices[0].message.content)
Fai funzionare questa chiamata banale prima di valutare un agente complesso. Separa un problema di autenticazione, endpoint, template o nome del modello da un problema di qualità del modello. Registra il provider, la revisione del modello se disponibile, la modalità di reasoning, il timestamp, i token di input, i token di output e il tempo trascorso per ogni prova.
Testa l'output strutturato e le chiamate agli strumenti con il tuo schema reale
La chiamata degli strumenti non dovrebbe essere valutata come "il modello ha scelto un'azione plausibile." Invia uno schema esplicito e convalida gli argomenti restituiti nella tua applicazione. Questo è un frammento di richiesta in stile OpenAI; conferma il supporto esatto dei parametri dello strumento con il provider prima di farvi affidamento.
{
"model": "tencent/Hy3",
"messages": [
{"role": "user", "content": "Controlla lo stato dell'incidente INC-1042."}
],
"tools": [
{
"type": "function",
"function": {
"name": "get_incident",
"description": "Cerca un incidente in base al suo identificatore.",
"parameters": {
"type": "object",
"properties": {"incident_id": {"type": "string"}},
"required": ["incident_id"],
"additionalProperties": false
}
}
}
]
}
Per questa richiesta, una decisione corretta dello strumento significa una chiamata get_incident il cui incident_id sia esattamente INC-1042. Il tuo codice deve rifiutare un campo mancante, una stringa argomento JSON malformata o uno strumento inatteso prima di toccare il sistema downstream. Ispeziona cinque cose:
Lo strumento selezionato è consentito per il compito.
Ogni argomento richiesto è presente e ha il tipo corretto.
ID, date e importi provengono dal contesto fornito invece di essere inventati.
Il modello chiede il valore richiesto mancante invece di indovinarlo.
Un errore dello strumento porta a un percorso di correzione o di escalation limitato, non a un ciclo.
Esegui un numero sufficiente di esempi per includere input validi, richieste ambigue, campi mancanti e una risposta dello strumento volutamente fallimentare. Un JSON affidabile nel caso standard è utile; un comportamento affidabile quando il sistema rifiuta un argomento è ciò che impedisce a un agente di creare lavoro per un operatore.
Testare il contesto lungo per la conservazione dei vincoli, non la lunghezza del titolo
Il contesto da 256K di Hy3 è utile solo quando i fatti rilevanti sopravvivono nel formato del prompt. Costruisci un test a partire da un repository rappresentativo, un insieme di policy o una thread della cronologia cliente. Inserisci diversi vincoli specifici in punti שונים? Need Italian. Let's produce accurate translation.
Punteggia il recupero esatto, l’aderenza a ogni vincolo nominato, le affermazioni non supportate e il costo totale della richiesta. Poi ripeti con il tuo livello di recupero di produzione abilitato. Questo rivela se un errore appartiene al modello, al chunking, al ranking del recupero o al codice di assemblaggio del prompt. Passare un unico documento grande incollato non è una prova sufficiente per disattivare i guardrail.
Testare il carico di lavoro che giustificherebbe una migrazione
Scegli un'attività in cui un risultato migliore del modello abbia un chiaro valore aziendale: correggere un test fallito in più file, estrarre obblighi da una lunga policy o completare un'operazione interna in più passaggi con strumenti. Confronta il percorso di produzione attuale e Hy3 con lo stesso timeout e la stessa regola di revisione.
Registra il tasso di attività completate, la latenza p50 e p95, i token di input e di output, il numero di ritentativi degli strumenti e il tempo di correzione del revisore. È anche qui che il feedback misto della community diventa utile. Non decidere in base a un’affermazione che Hy3 sia eccezionale o deludente in astratto. Decidi in base all’attività che pagheresti davvero per automatizzare.
API ospitata o self-hosting?
Usa prima un'API hosted quando stai valutando il modello, il traffico è ancora incerto o il tuo team non gestisce già la capacità GPU necessaria. Accorcia il percorso verso i test sopra e mantiene la disponibilità del provider separata dalla logica della tua applicazione.
Usa l'hosting autonomo solo quando hai un motivo concreto legato a controllo, privacy, volume o latenza e l'infrastruttura per supportarlo. La scheda modello ufficiale raccomanda otto GPU H20-3e o altre GPU con ampia memoria per servire Hy3, con ricette vLLM o SGLang. Questa è la raccomandazione di Tencent per l'erogazione in produzione, non un'affermazione che un laptop consumer fornisca una distribuzione equivalente. Valuta il costo delle prenotazioni delle GPU, degli upgrade, del monitoraggio, del batching e della reperibilità rispetto al conto del servizio ospitato prima di considerare i pesi aperti come infrastruttura gratuita.
Scegli questo percorso | Quando è la scelta migliore | Rischio principale da considerare |
|---|---|---|
Hosted API | Valutazione rapida, domanda variabile, piccolo team di piattaforma | Gli ID del modello del provider, i limiti, la disponibilità e il prezzo possono cambiare |
Self-hosted Hy3 | Forte esigenza di controllo dei dati o volume sostenuto con operatori esperti | Hardware ad alta memoria, complessità di serving, pianificazione della capacità e supporto operativo |
Prezzi e disponibilità possono cambiare più rapidamente dei pesi
Tencent ha pubblicato i prezzi dell’API Hy3 a 1 RMB per milione di token in input, 4 RMB per milione di token in output e 0,25 RMB per milione di token in input memorizzati nella cache il 6 luglio. Usalo come riferimento datato, quindi conferma il prezzo effettivo dell’endpoint prima di procedere. Il piano gratuito di un provider, il credito introduttivo o un alias temporaneo del modello gratuito sono disponibilità per un esperimento, non una promessa permanente del costo unitario.
Per un semplice controllo dei costi, 100 richieste giornaliere contenenti 20K token in input e 1K token in output utilizzano 2M token in input e 0.1M token in output. Al prezzo di riferimento pubblicato da Tencent, questo equivale a 2.4 RMB al giorno, oppure circa 72 RMB per 30 giorni. Se tutti i 2M token in input rientrano nel prezzo per la cache, lo stesso calcolo è di 0.9 RMB al giorno. Questa è una stima basata solo sui token: esclude il ricarico del provider, i limiti del piano gratuito, i retry e qualsiasi contesto aggiunto dalla tua applicazione.
Quando si pianifica il budget per una prova, includere il contesto recuperato, il prompt di sistema, le definizioni degli strumenti, i tentativi di ripetizione e l'output prodotto dall'impostazione di ragionamento scelta. Non scegliere Hy3 quando l'input chiave è visivo, una distribuzione locale leggera è un requisito imprescindibile o l'applicazione non può convalidare gli argomenti degli strumenti e gli effetti collaterali a valle.
Per un agente con molto testo che necessita di una finestra di contesto ampia, ragionamento configurabile e pesi aperti, Hy3 è un modello ragionevole da valutare. Conservalo solo quando riduce il tempo di correzione a un costo totale accettabile.
FAQ
Hy3 è multimodale?
No. Hy3 è un modello di input di testo, output di testo. Usa un modello di visione o OCR quando il compito inizia con immagini, scansioni o screenshot.
Che cos'è la finestra di contesto Hy3?
La scheda del modello di Tencent riporta una finestra di contesto da 256K token. Un limite di contesto lungo non garantisce che i fatti pertinenti vengano recuperati o seguiti, quindi convalidalo con materiale di origine rappresentativo.
Con quale modalità di ragionamento Hy3 dovrei iniziare?
Inizia con no_think per lavori delimitati e sensibili alla latenza. Passa a low o high solo quando il costo del fallimento dell'attività e il miglioramento misurato giustificano i token e il tempo aggiuntivi.
Posso ospitare autonomamente Hy3?
Sì. Tencent fornisce indicazioni per la distribuzione con vLLM e SGLang e raccomanda otto GPU ad alta memoria per l’erogazione. L’hosting autonomo dovrebbe basarsi su una decisione di capacità e operativa, non solo sulla licenza open-weight.
Un'API Hy3 gratuita è un piano tariffario permanente?
No. L'accesso gratuito dipende dal provider e può terminare o cambiare i limiti. Verifica le condizioni attuali del provider e la tariffa a pagamento prima di impegnarti in un flusso di lavoro di produzione.