Mercury 2

Cos'è Mercury 2?

Mercury 2 è un large language model (LLM) focalizzato sul reasoning introdotto da Inception. Il suo scopo principale è fornire prestazioni di reasoning rapide per carichi di lavoro AI di produzione—specialmente dove la latenza si accumula attraverso “loop” iterativi come passaggi agent, pipeline di retrieval e job di estrazione.

A differenza dei modelli autoregressivi che generano un token alla volta da sinistra a destra, Mercury 2 utilizza un approccio diffusion-based per il reasoning in tempo reale. Il modello genera output tramite raffinamento parallelo, producendo più token simultaneamente e convergendo in un numero ridotto di passaggi.

Caratteristiche Principali

• Generazione con raffinamento parallelo diffusion-based: Produce più token contemporaneamente anziché decoding sequenziale, per una latenza end-to-end inferiore nei sistemi interattivi.
• Velocità ottimizzata per produzione: Riportata come 1,009 token/sec su GPU NVIDIA Blackwell, progettata per ridurre i tempi di attesa percepiti sotto carico.
• Reasoning configurabile: Consente di regolare il comportamento di reasoning mantenendo l'equilibrio velocità–qualità previsto.
• Contesto 128K: Supporta input lunghi tramite una finestra di contesto da 128K.
• Uso nativo di tool: Include capacità integrate per invocare tool come parte dei workflow di reasoning.
• Output JSON allineato a schema: Può restituire output strutturati allineati a uno schema, utili per automazioni downstream.

Come Usare Mercury 2

1. Integra Mercury 2 nella tua pipeline LLM dove la latenza è critica (es. loop agent, workflow retrieval-augmented o task di estrazione).
2. Scegli un'impostazione di reasoning adatta alle tue esigenze di qualità e tempo di risposta (il modello supporta reasoning configurabile).
3. Fornisci input entro la finestra di contesto da 128K e, se necessario, richiedi output JSON allineato a schema per un parsing affidabile.
4. Usa chiamate a tool per workflow che richiedono azioni esterne (es. ricerca, lookup database o altri passaggi supportati da tool), specialmente in scenari agent multi-step.

Casi d'Uso

• Workflow di coding e editing: Autocompletamento, suggerimenti per modifiche successive, refactor e agent codice interattivi dove le pause possono interrompere il flusso dello sviluppatore.
• Task con loop agentici: Sistemi che incatenano molte chiamate di inferenza per job (es. decision-making multi-step), dove ridurre la latenza per chiamata consente più passaggi.
• Voce in tempo reale e interazioni: Interfacce vocali e scenari HCI interattivi con budget di latenza ristretti, dove un reasoning più veloce mantiene l'interazione responsive come un discorso.
• Pipeline di ricerca e RAG: Workflow di retrieval multi-hop e summarizzazione dove il reasoning si aggiunge al loop di ricerca senza superare i vincoli di latenza.
• Pulizia di trascrizioni e altri task di trasformazione iterativi: Applicazioni che richiedono trasformazioni e raffinamenti rapidi e consistenti su interfacce user-facing.

FAQ

In che modo Mercury 2 differisce dal decoding tipico degli LLM?
Mercury 2 è descritto come diffusion-based e genera risposte tramite raffinamento parallelo anziché decoding autoregressivo sequenziale token-per-token.

Quali caratteristiche di performance sono indicate per Mercury 2?
La pagina riporta generazione >5x più veloce e 1,009 token/sec su GPU NVIDIA Blackwell, con indicazioni per ottimizzare la reattività percepita dall'utente (inclusa latenza p95 ad alta concorrenza).

Quale lunghezza di contesto supporta Mercury 2?
Elenca un contesto da 128K.

Mercury 2 può produrre output strutturati?
Sì. È descritto come supportante output JSON allineato a schema per risposte strutturate.

Mercury 2 supporta l'uso di tool?
La pagina afferma che ha uso nativo di tool, pensato per integrare tool nei workflow di reasoning.

Alternative

• LLM reasoning autoregressivi: LLM tradizionali token-per-token possono essere più semplici da integrare ma generano sequenzialmente, aumentando la latenza nei loop multi-step.
• Altri approcci diffusion- o non-autoregressivi: Architetture alternative mirate alla generazione parallela possono offrire obiettivi di latenza simili, sebbene dettagli di implementazione e comportamento output differiscano.
• LLM più piccoli ottimizzati per velocità interattiva: Modelli focalizzati su bassa latenza possono sacrificare profondità di reasoning o controllabilità rispetto a un setup come Mercury 2 ottimizzato per reasoning.
• Strategie di orchestrazione agent/RAG che minimizzano le chiamate: Invece di cambiare l'architettura del modello, i team possono ridurre la latenza ristrutturando i workflow (es. meno passaggi di retrieval, caching o batching), sebbene possa limitare il reasoning per task.