Il 29 settembre 2026 Rysana ha pubblicato il lancio di V2: «un nuovo tipo di AI generale», fino a 10.000× più veloce e 1000× più efficiente delle alternative convenzionali. Il post ufficiale su X ha superato le 60.000 visualizzazioni in poche ore. La domanda utile non è se la frase sia bella. È se sia misurabile.
Rysana è una società privata con sede dichiarata a San Francisco, backing early-stage (PitchBook indica un investitore, Autopilot Fund) e un volto pubblico: John, CEO su @jrysana. L’account aziendale @Rysana e il sito esistono da anni. Non è un dominio registrato ieri. È un laboratorio piccolo che da tempo parla solo di una cosa: inferenza estremamente veloce e output strutturati.
Cosa promette V2 sul sito ufficiale
La pagina di prodotto mostra una famiglia V2 Base, V2 Small, V2 Mini, V2 Nano, più un punto residuo V1 Small. Il grafico «Score (%) vs Speed (tok/sec, log)» colloca Claude, GPT, GLM e Llama in un ammasso intorno a 100 token al secondo, e le stelle Rysana a destra, verso 1–10 milioni tok/s, con score dichiarati tra circa 83 e 99 a seconda della taglia.
Il metodo, scritto in piccolo sotto il chart, è questo:
- oltre 20.000 task «real-world» interni
- nessun chain-of-thought
- velocità = picco end-to-end in token al secondo per request
- checkpoint V2 di luglio 2026
- competitor misurati a metà agosto 2026 sulla «API convenzionale più veloce» disponibile
Oltre al grafico, Rysana elenca capacità da piattaforma completa: input nativamente multimodale (testo, audio, vision, codice, documenti), vincoli su schemi, grammatiche e programmi con «overhead da nanosecondo», controllo del comportamento del modello e non solo del formato, bilanciamento dinamico costo-velocità-sforzo. Accesso: form email, non API pubblica general availability.
Nella FAQ «How is it so fast?» l’azienda scrive che l’architettura è «ordini di grandezza più parameter-efficient di transformer e diffusion», accoppiata a parser, kernel, compiler, sampler, codec, tokenizer e server proprietari. I kernel V2 arriverebbero a 1600 PFLOP/s FP16 effettivi per request. I modelli regolerebbero lo sforzo di calcolo sulla difficoltà del task e potrebbero risolvere in parallelo domande mutuamente esclusive.
Cosa si può già verificare, e cosa no
Verificabile oggi:
- il lancio è reale e datato 29 settembre 2026
- il sito, i termini, il login e la richiesta di accesso esistono
- il CEO ha una storia pubblica coerente dal 2023 sul tema «LLM 10.000x più veloci»
- esiste un toolkit TypeScript storico, Lusat, e un’org GitHub rysana-ai con repo piccoli e in larga parte archiviati (centinaia di star, non decine di migliaia)
- V1 non è mai stata GA: John lo ha scritto in risposta a chi ricordava i teaser precedenti
Non verificabile oggi:
- il 10.000× e il 1000× su un workload riproducibile
- il punteggio sui 20.000 task (insieme, prompt, rubric e split non sono pubblici)
- la parità di intelligenza con Opus 5 / Sonnet 5 / GPT «5.x» usati nel grafico
- i 1600 PFLOP/s per request
- la latenza end-to-end sotto il millisecondo vista da un client esterno, rete inclusa
- volumi da «trilioni di token all’ora»
Il CEO stesso ha messo in prospettiva i numeri. A luglio 2026 ha scritto che «è ancora presto per queste architetture»: la maggior parte delle request non arriva a 1 MHz e molte nemmeno a 100 kHz, mentre i modelli equivalenti starebbero a 100 Hz o sotto. In un altro post ha parlato di un vantaggio più sobrio, 10–50× a parità di capability, nelle loro comparazioni interne. Quella frase è più credibile del 10.000× in homepage, e già basterebbe a essere interessante.
Perché il 10.000× è un numero fragile
«Up to» è il meccanismo classico. Si prende il picco su un task facile, corto, fortemente vincolato (schema JSON, scelta discreta, no ragionamento lungo) e lo si divide per la latenza di un’API frontier usata in modo naive, con overhead di rete, safety layer e decoding standard. Il rapporto esplode. Non dice quasi nulla sulla mediana, sul cold start, sul contesto lungo, sul tool-use multi-step o sulla qualità a parità di token.
Il grafico ufficiale misura i competitor sulle API pubbliche e V2 sul proprio stack. Non è lo stesso hardware, non è lo stesso runtime, non è lo stesso percorso di rete. Confrontare «picco end-to-end nostro» con «API convenzionale loro» è un protocollo scelto da chi vende il protocollo.
C’è anche un precedente interno: per anni Rysana ha descritto Inversion come modello strutturato, non come oracolo generale. I claim storici più solidi riguardavano overhead di schema, function calling e generazione tipizzata, non Arena o AIME. V2 allarga il marketing da «structured LLM veloce» a «general AI». Il salto semantico è grande quanto quello numerico.
Cosa sarebbe sufficiente per togliere il dubbio
Non serve un paper da 40 pagine. Servirebbero quattro cose minime:
- una eval pubblica con prompt e metriche note (o un subset scaricabile dei 20k task)
- accesso a un endpoint misurabile da terzi, anche rate-limited
- una tabella che separi task facili vincolati, generazione libera e agenti multi-turno
- la mediana, non solo il picco, più il costo per milione di token
Finché quelle quattro cose mancano, V2 resta un sistema chiuso con un grafico convincente. La community su X lo ha già detto in modo grezzo: «HF link?», «il video di lancio sembra fatto da un modello», «io V1 me la sono persa». Sono obiezioni di metodo, non di fandom.
Il pezzo serio, se esiste, non è il moltiplicatore. È l’idea che i layer non debbano eseguire tutti i pesi a ogni pass, che lo sforzo debba scalare col problema, e che il vincolo di output possa invertire parte dell’inferenza. Quella linea di lavoro — compiler, grammatiche, kernel custom — è coerente con anni di post tecnici di John. Può essere vera in parte e gonfiata in copertina allo stesso tempo.
Oggi il verdetto onesto è questo: Rysana V2 è un lancio reale con claim non dimostrati in pubblico. Trattarlo come fact sarebbe ingenua. Trattarlo come bufala sarebbe pigro. La misura arriva solo quando qualcuno, fuori dal perimetro dell’azienda, ottiene gli stessi token al secondo sugli stessi task.
Testo: assistito da AI · revisionato da Carlos H. P. Ross
