Bêta ouverte · réseau en construction

L'IA, mais pas
dans un data-center américain.

Korai est un réseau pair-à-pair d'exécution de modèles open-weight. Quand vous envoyez un prompt, un orchestrateur à Paris le confie au meilleur GPU disponible dans le réseau — un particulier, un labo, une PME — et vous streame la réponse en retour. Ni hyperscaler, ni rétention de contenu, ni boîte noire. Voici, en détail, comment ça fonctionne.

Essayer le chat Prêter son GPU

Le chat est gratuit pendant la bêta (crédit symbolique, sans paiement). Un Tier Pro avec facturation réelle arrive mi-2026.

Pourquoi c'est différent

Un chatGPT n'est pas l'autre.

Les trois grandes familles d'inférence IA aujourd'hui — et où Korai se place.

Critère	SaaS centralisé (OpenAI, Anthropic, Gemini)	API européen souverain (Mistral, Le Chat)	Korai (pair-à-pair open-weight)
Juridiction des données	États-Unis (Cloud Act)	Union Européenne	UE · par hôte, vérifiable
Poids du modèle	Fermés, propriétaires	Open-weight (Mistral) ou fermés	Open-weight obligatoire
Infrastructure	Data-centers hyperscaler	Data-center souverain unique	Réseau distribué de GPUs
Rétention de contenu	30 jours à plusieurs années	Variable selon le contrat	Aucune au niveau orchestrateur
Qui fournit le calcul	L'opérateur, exclusivement	L'opérateur, exclusivement	N'importe qui avec un GPU qui dort
Rémunération des hébergeurs	N/A	N/A	Part des crédits consommés (Tier Pro)

Korai n'est pas un concurrent direct des LLMs fermés sur la qualité brute — on utilise les meilleurs modèles open-weight du moment. Le pari, c'est la topologie: distribuée plutôt que centralisée, auditable plutôt qu'opaque.

Le pipeline

Un prompt, quatre étapes.

Aucune magie. Chaque étape est observable, chronométrée, et le code qui la régit est accessible.

Prêt

Cycle ~1.2s · didactique

› POST /v1/chat/completions

› X-Korai-Region: eu-west

› routed → worker_ac12 (Lyon, FR · RTX 4090)

› stream: data: "…" · 1.2s TTFT

Vous envoyez

Votre prompt part du navigateur en TLS 1.3 vers l'orchestrateur. Si vous êtes connecté, une clé API (hashée côté serveur) authentifie la requête. L'orchestrateur ne journalise pas le contenu du message.

Le routeur choisit

Un composant Go (le modelrouter) regarde votre prompt et le niveau demandé — auto, fast, balanced ou deep — et sélectionne la bonne variante de modèle parmi celles chargées par les workers connectés.

Le matchmaker place

Un second composant (le matchmaker) liste les workers qui servent ce modèle, exclut ceux déjà occupés, et envoie la requête au premier disponible via WebSocket persistant.

Le GPU exécute et stream

Le worker lance l'inférence (llama.cpp sur Linux/CUDA, MLX sur Apple Silicon) et remonte les tokens un par un en SSE. À la fin, sa mémoire est libérée — rien ne persiste.

Le routeur de modèles

4 niveaux. Pas besoin de choisir.

Le routeur évalue la complexité de votre demande et choisit le modèle adapté. Vous pouvez forcer un niveau via le paramètre `model`.

défaut

auto

Automatique

— choisi pour vous

Heuristique basée sur la longueur et les mots-clés du message : démonstration, raisonnement, architecture → deep ; « bonjour » → fast ; tout le reste → balanced.

fast

Rapide

Gemma 4 e4b

Pour les réponses courtes, les recherches factuelles, les one-liners. ~4B paramètres quantifiés 4-bit, tient sur un Mac M1 ou une 3060.

balanced

Équilibré

Gemma 4 26B

Le cheval de bataille : rédaction, analyse, code, la plupart des usages. Demande un GPU ~16 Go (RTX 4080/4090, Mac M-series 32 Go).

deep

Réflexion

Gemma 4 31B thinking

Mode raisonnement étendu pour les preuves, architectures logicielles, problèmes combinatoires. Le modèle « réfléchit » avant de répondre. GPU ≥24 Go recommandé.

Exemple d'appel API

POST /v1/chat/completions

{

"model": "auto", // ou "fast" / "balanced" / "deep"

"messages": [...],

"stream": true

}

Retour SSE standard — compatible avec les SDK OpenAI existants.

Le matchmaker

Comment un GPU est choisi, concrètement.

La politique d'assignation est volontairement simple — on préfère un algorithme qu'on peut expliquer à un algorithme qu'on ne peut pas déboguer.

Étape 1

Filtrage par capacité

Le matchmaker ne considère que les workers qui déclarent servir le modèle demandé. Chaque worker publie son inventaire au moment de la connexion — on route sur du réel, jamais sur une estimation.

Étape 2

Exclusion des occupés

On exclut les workers qui ont déjà un job en cours. C'est du "one job at a time" par GPU physique — pas de batching implicite qui dégraderait la latence d'un voisin.

Étape 3

Sélection FIFO

Dans les candidats restants, on prend le premier de la liste. Pas d'enchère, pas de prix caché, pas de boosting. Les algorithmes plus malins (affinité, moindre charge) viendront quand le réseau le justifiera.

Que se passe-t-il si ça échoue ?

Le worker crashe en cours d'inférence

L'orchestrateur détecte l'absence de tokens via son heartbeat WebSocket. Après le timeout déclaré par le worker (plus 30 s de marge), le job est remis en file et redistribué à un autre GPU.

Aucun worker ne sert ce modèle

La requête reçoit une erreur explicite « no worker advertises X » — on ne bascule PAS silencieusement sur un modèle différent. Vous savez toujours quel modèle a répondu.

Le niveau demandé n'est pas servi

Fall-down sécurisé : deep → balanced → fast. On ne fait jamais l'inverse (envoyer un "bonjour" à un modèle 31B brûlerait du GPU pour rien).

L'orchestrateur redémarre

Les jobs en file sont persistés dans Postgres. Après redémarrage, la première passe du matchmaker reprend là où il s'était arrêté — pas de perte.

Le réseau

Un maillage européen, pas un data-center.

Chaque point représente un profil de worker pouvant rejoindre le réseau. La répartition géographique est illustrative — elle dépend, à chaque instant, des hôtes connectés.

Worker GPU (Linux/CUDA)Worker Mac (Apple Silicon)Rack pro / colocationOrchestrateur· Illustration, points non géo-exacts

NVIDIA / Linux

La configuration la plus courante : RTX 4080/4090/5090, A6000, H100. Runtime llama.cpp compilé avec support CUDA, accélération tensor cores.

Apple Silicon

Mac M1, M2, M3, M4. Runtime MLX exploitant la mémoire unifiée — un Mac 64 Go peut charger Gemma 26B confortablement. Parfait pour un poste du soir.

Rack professionnel

Colocations, PME, labos universitaires. Plusieurs GPUs par nœud, connectivité fibre, hébergement continu. L'épine dorsale pour les modèles les plus exigeants.

Transparence : le réseau est en cours de constitution. Le nombre de workers actifs, leur localisation et leur disponibilité sont consultables en temps réel sur la page État du réseau. Ne nous croyez pas sur parole — lisez les chiffres.

L'architecture

Trois couches, zéro hyperscaler.

On vous doit la vérité technique, pas un diagramme marketing. Voici les pièces, dans leurs vrais langages et leurs vraies versions.

Edge · Paris

Orchestrateur

Daemon Go (~5 000 lignes), base Postgres pour la persistance des jobs, registre in-memory pour les workers connectés. Hébergé sur un VPS Scaleway EU-West. Expose une API REST + WebSocket.

Routage auto/fast/balanced/deep
Aucun contenu de message en base
Clés API stockées hashées (SHA-256)
Redémarre sans perdre la file

Workers

Runtime d'inférence

Binaire Rust unique qui s'auto-connecte à l'orchestrateur au démarrage. Supporte CUDA (Linux) et MLX (macOS). Mise à jour signée, cryptographiquement vérifiée au démarrage.

Modèle open-weight Gemma 4 (d'autres à venir)
WebSocket persistant + heartbeat
Un seul job à la fois, mémoire libérée après
Pas de données persistées sur disque

Client

Interface & SDK

Web : Next.js 16 (ce site). CLI : Korai Kode en Rust, agent type Codex pour le terminal. API REST compatible OpenAI — vos intégrations existantes fonctionnent sans changement.

Chat web (page d'accueil)
Korai Kode — agent CLI pour dev
API /v1/chat/completions
Historique stocké dans votre navigateur

La confidentialité

Minimisation par construction.

Pas une promesse : une propriété du code. Ce qui suit reflète l'état actuel du dépôt — si nous changeons, nous le dirons.

Transite

Ce que l'orchestrateur voit

Les messages (le temps de les router), un identifiant de requête, votre clé API hashée, le nom du modèle choisi, le nombre de tokens facturables. C'est tout.

Conservé

Ce que l'orchestrateur conserve

Métadonnées de facturation uniquement — horodatage, modèle, compteurs de tokens. Aucun prompt, aucune réponse, aucun extrait de contenu.

Transite

Ce que le worker voit

Le prompt complet (il doit bien l'exécuter) et la sortie en train de se générer. Tout reste en RAM du processus d'inférence — jamais sur disque.

Aucun

Ce que le worker conserve

Rien. La mémoire du processus est libérée à la fin du job. Le worker n'a pas de base de données de conversations — c'est une propriété du runtime, pas une promesse.

Transite

Juridiction par défaut

Orchestrateur en France, workers déclarent leur pays à la connexion et sont routables par région. Pour un besoin spécifique, l'en-tête X-Korai-Region contraint au pays choisi.

Conservé

Historique de chat

Sauvegardé dans le localStorage de votre navigateur (clé korai.history.v1). Exportable, effaçable, jamais envoyé sur nos serveurs. Un autre appareil = un autre historique.

L'économie

Qui paie, qui gagne.

Korai n'est pas gratuit par philosophie — c'est gratuit pendant la bêta parce que le modèle économique n'est pas encore déployé. Voici ce qui est prévu.

Aujourd'hui · Bêta

En cours

Crédit symbolique

Comptes gratuits avec une enveloppe de tokens/mois suffisante pour un usage personnel sérieux. Pas de carte bancaire demandée, pas de tarification activée.

Mi-2026 · Tier Pro

Prévu

Facturation à l'usage

Crédits prépayés, prix par million de tokens proche des APIs open-weight du marché. Une part significative est reversée aux hôtes qui ont effectué l'inférence, proportionnellement aux tokens servis.

Après · Coopérative

Vision

Gouvernance partagée

Le statut visé à moyen terme est celui d'une coopérative ou association : les hôtes et utilisateurs contribuent aux décisions de roadmap, les excédents financent l'infrastructure et le développement.

Nous ne prétendons pas déjà payer les hôtes. La tuyauterie de facturation existe mais elle n'est pas activée. Dès qu'elle le sera, le barème sera publié, auditable, et modifiable uniquement par vote.

Questions directes

Ce qu'on nous demande le plus.

Quels modèles sont disponibles ?

À l'heure actuelle : la famille Gemma 4en trois variantes (e4b pour les réponses rapides, 26B pour l'équilibré, 31B thinking pour le raisonnement étendu). Prochains candidats : Mistral Small 3, Qwen 2.5, DeepSeek V3 — ajoutés dès qu'un worker les sert. Les modèles fermés sont exclus par principe.

Est-ce plus lent qu'OpenAI ?

Cela dépend du GPU choisi par le matchmaker. Sur un worker H100 ou RTX 4090, le temps au premier token est comparable aux APIs commerciales sur modèles de taille équivalente. Sur un Mac M1 de 2020, c'est plus lent — mais c'est aussi un Mac de 2020. Le status publie les latences réelles.

Qui sont les hôtes GPU ? Peuvent-ils lire mes conversations ?

Les hôtes sont des personnes ou organisations qui ont installé notre binaire worker. Techniquement, le processus d'inférence manipule votre prompt en RAM — comme n'importe quel service cloud. La différence : le binaire est signé, auditable, et ne journalise rien. Un hôte malveillant aurait besoin de modifier le runtime, ce qui invaliderait sa signature et le déconnecterait du réseau. Pour les usages ultra-sensibles, limitez-vous à vos propres workers via X-Korai-Worker.

Puis-je vérifier qu'un GPU est bien européen ?

Oui : chaque worker déclare son pays à la connexion. Vous pouvez forcer une région avec l'en-tête X-Korai-Region: eu-west. Si aucun worker conforme n'est dispo, la requête échoue proprement plutôt que de basculer hors-UE silencieusement.

Est-ce open-source ?

Les clients (Korai Kode CLI, SDK, dashboard) sont prévus pour être publiés sous licence permissive à la GA. Le binaire worker l'est aussi — c'est nécessaire pour que la signature soit vérifiable. L'orchestrateur reste géré par l'entité Korai pour des raisons de gouvernance réseau, mais son code source est consultable sur demande dans le cadre de la bêta.

Que se passe-t-il si Korai ferme demain ?

Vos conversations sont dans votre navigateur — vous les gardez. Les workers sont des binaires standalone — ils continuent de tourner. Le code orchestrateur sera publié en cas de cessation d'activité (engagement contractuel — voir CGU), ce qui permettra à la communauté de faire tourner son propre orchestrateur si elle le souhaite.

Ça marche avec les SDK OpenAI existants ?

Oui. L'endpoint /v1/chat/completions respecte le schéma OpenAI, y compris le streaming SSE. Changez l'URL de base et la clé — le reste du code n'a pas besoin de bouger. Les tool-calls sont supportés via la même sémantique.

Puis-je déployer mon propre orchestrateur privé ?

C'est prévu pour les entreprises et administrations qui voudraient un réseau Korai fermé sur leur infrastructure — workers internes uniquement, aucun lien avec le réseau public. La procédure (Docker Compose + migration Postgres) sera documentée avec la GA. Si c'est urgent, contactez-nous.

Rejoindre le réseau