Concepts fondamentaux
Les briques de base de Parsyn : comment la plateforme, les workers, les datasets, les modeles et les credits s'articulent entre eux.
La plateforme
La plateforme Parsyn est le point central. Elle tourne sur parsyn.progatis.com et gere tout sauf le calcul GPU : gestion des utilisateurs, stockage des datasets, orchestration des jobs, collecte des metriques, facturation et tableau de bord web.
Tout l'etat reside dans la plateforme. Les workers sont sans etat : ils se connectent, recoivent des taches, executent le travail et rendent compte. Cela signifie que vous pouvez ajouter, retirer ou remplacer des workers a tout moment sans perdre de donnees ni de progression.
Workers
Les workers constituent la couche de calcul. Un worker est un processus qui tourne sur une machine GPU, se connecte a la plateforme via WebSocket et execute des taches : training, inference, evaluation ou operations post-training.
Parsyn prend en charge deux types de workers :
Parsyn Workers (manages)
Des machines GPU gerees par l'equipe Parsyn. Vous n'installez rien. Il suffit de selectionner le type de GPU souhaite lors de la creation d'un training job, et la plateforme en attribue un depuis sa flotte.
- Factures en credits par heure (le tarif varie selon le type de GPU : A100, RTX 4090, etc.)
- Disponibles uniquement pour le training (pas pour l'inference)
- Geres, mis a jour et supervises par l'equipe Parsyn
- Soumis a la disponibilite de la flotte
User Workers (amenez votre propre GPU)
Vos propres machines GPU. Vous installez le client parsyn-worker, le configurez avec une cle API, et il se connecte a la plateforme. A partir de la, vous gerez le materiel ; la plateforme gere la charge de travail.
- Aucun cout au-dela de votre propre materiel et de l'electricite
- Compatible avec le training, l'inference et l'evaluation
- Vous controlez la disponibilite, la maintenance et la securite physique
- Configurable en tant que
fine_tuner(training uniquement),prompter(inference uniquement) ouboth
Cycle de vie d'un worker
Lorsqu'un worker se connecte a la plateforme, il :
- S'authentifie avec sa cle API (ou s'enregistre via une cle principale lors de la premiere connexion)
- Execute un benchmark GPU et envoie les informations materielles (modele GPU, VRAM, version CUDA, score de benchmark)
- Passe en etat
idleet attend des taches - Envoie un heartbeat toutes les 30 secondes
- Rapporte les metriques systeme (utilisation GPU, memoire, CPU, RAM) toutes les 5 secondes
Si la plateforme ne recoit pas de heartbeat pendant 90 secondes, le worker est marque comme hors ligne. Les workers se reconnectent automatiquement en cas de deconnexion avec un backoff exponentiel (de 5s a 60s).
Datasets
Un dataset est un fichier stocke dans un stockage compatible S3 avec des metadonnees suivies dans la base de donnees de la plateforme. Formats pris en charge :
| Format | Ideal pour |
|---|---|
| JSONL (recommande) | Instruction tuning, donnees de chat. Un objet JSON par ligne. Prend en charge les structures imbriquees comme les messages de chat. |
| CSV | Paires prompt/completion simples, donnees tabulaires. |
| Parquet | Grands datasets (1 Go+). Compression efficace, chargement rapide. |
Cycle de vie d'un dataset
- Upload : Les fichiers passent par un pipeline d'upload multipart. Les fichiers volumineux sont decoupes en morceaux et reassembles cote serveur. Le fichier est stocke dans S3.
- Validation : La plateforme verifie le format, le schema (champs attendus), l'encodage (UTF-8) et l'integrite des donnees.
- Statistiques : Un job asynchrone calcule les statistiques : nombre d'exemples, distributions des champs, comptage de tokens, detection de doublons. S'execute en arriere-plan via Celery.
- Pret : Le dataset peut desormais etre utilise dans des training jobs. Vous pouvez aussi lancer des operations : split, deduplication, conversion de format ou normalisation du schema.
Modeles
Un modele dans Parsyn provient de l'une de ces deux sources :
- HuggingFace Hub : Fournissez un identifiant de modele (par ex.
meta-llama/Llama-3.1-8B). Le worker le telecharge au moment du training. - Upload personnalise : Importez vos propres fichiers de modele (safetensors, checkpoints PyTorch) vers le stockage de la plateforme.
Etats d'un modele
| Etat | Signification |
|---|---|
registered | Metadonnees creees, pret a servir de base pour le training. |
training | Un training job utilise activement ce modele. |
ready | Training termine, le modele peut etre utilise pour l'inference. |
failed | Le training a echoue. Consultez les logs du job. |
Le fine-tuning cree un nouveau modele qui fait reference au modele de base original. Vous obtenez un historique complet : modele de base, configuration de training, dataset et tous les checkpoints.
Training jobs
Un training job relie un dataset, un modele de base, une configuration de training et des ressources de calcul.
Depuis la page Training, cliquez sur New Training Job pour ouvrir le formulaire de creation. Vous selectionnez un dataset, un modele de base, configurez les hyperparametres (learning rate, batch size, epochs, parametres LoRA, etc.) et choisissez votre mode de selection de worker. Apres avoir cree le job, lancez-le avec le bouton play.
Le cycle de vie :
- Creation : Definissez le job via le formulaire. Statut :
pending. - Demarrage : La plateforme met le job en file d'attente et l'assigne a un worker disponible. Statut :
queued. - Dispatch : Le worker recoit le job via WebSocket, telecharge le dataset et le modele, puis lance le training. Statut :
running. - Progression : Le worker transmet les metriques en continu toutes les quelques secondes. La page de detail du training affiche des graphiques en temps reel : courbe de loss, learning rate, utilisation GPU, debit et temps estime restant.
- Fin : Le worker importe le modele fine-tune vers S3 et signale le succes. Statut :
completed.
Etats d'un job
| Etat | Description |
|---|---|
pending | Cree, pas encore demarre. |
queued | Demarre, en attente qu'un worker le prenne en charge. |
running | Le worker est en train d'entrainer. Les metriques arrivent en continu. |
completed | Termine. Le modele fine-tune est disponible. |
failed | Quelque chose s'est mal passe. Consultez l'erreur dans les details du job. |
cancelled | Arrete par l'utilisateur. Un checkpoint peut etre disponible. |
Modes de selection des workers
Lors de la creation d'un job, vous choisissez comment la plateforme attribue le calcul :
| Mode | Comportement |
|---|---|
auto | La plateforme choisit le meilleur worker disponible en se basant sur les scores de benchmark GPU pour correspondre au job. Inclut a la fois les Parsyn Workers et vos propres workers. |
specific_user_workers | Vous choisissez lequel de vos workers connectes utiliser. |
specific_parsyn_workers | Vous choisissez le type de GPU dans la flotte Parsyn. Facture en credits. |
mixed | Vous selectionnez parmi vos workers et la flotte Parsyn. |
Checkpoints
Pendant le training, des checkpoints sont sauvegardes dans S3 a intervalles reguliers. Chaque checkpoint contient les poids du modele (ou l'adaptateur LoRA), l'etat de l'optimiseur et les metriques. Si le training est interrompu, vous pouvez reprendre depuis le dernier checkpoint.
Credits et facturation
Parsyn utilise un systeme de credits pour l'utilisation des Parsyn Workers. Les credits sont prepayes : vous achetez un pack de credits, et les credits sont deduits au fur et a mesure de votre utilisation des GPU manages.
La page Credits du tableau de bord comporte trois onglets :
- Historique : Chaque transaction de credits (achats, consommation, remboursements, bonus) avec filtres et pagination. Chaque entree affiche le montant, le solde resultant et une description.
- Acheter : Les packs de credits disponibles avec leurs prix. Cliquez sur Acheter pour finaliser le paiement via Stripe.
- Tarifs : Le taux de credits par heure pour chaque type de GPU de la flotte Parsyn.
Votre solde actuel, le total achete et le total consomme sont toujours visibles en haut de la page. L'utilisation de vos propres workers ne consomme pas de credits. Les credits s'appliquent uniquement aux GPU manages par Parsyn.
Communication en temps reel
La plateforme utilise WebSocket pour deux canaux :
- Plateforme vers worker : Envoie des commandes (lancer le training, arreter, charger les poids). Recoit la progression, les metriques, les mises a jour de statut et les erreurs.
- Plateforme vers tableau de bord : Pousse les mises a jour en direct vers l'interface web. Quand un worker rapporte des metriques, la plateforme les diffuse a tous les utilisateurs qui suivent ce job.
Les metriques sont transmises au tableau de bord en temps reel, independamment de la limitation d'ecriture en base de donnees. Les graphiques du tableau de bord se mettent a jour en direct avec les courbes de loss, l'utilisation GPU, le debit et le temps estime restant.
Isolation des donnees
Chaque ressource (datasets, modeles, training jobs, workers) est rattachee a un utilisateur. Le backend applique cette regle au niveau des requetes : chaque requete en base de donnees inclut un filtre user_id. Il est impossible pour un utilisateur d'acceder aux donnees d'un autre utilisateur via l'API.
Les Parsyn Workers sont une infrastructure partagee, mais chaque job s'execute de maniere isolee : un Parsyn Worker est attribue au job d'un seul utilisateur a la fois, et le worker est libere une fois le job termine.
Inference
Une fois un modele fine-tune, vous pouvez le tester via l'interface de chat integree. La plateforme route les requetes d'inference vers l'un de vos workers connectes ayant la capacite prompter ou both. Le worker charge le modele (avec un cache LRU pour basculer rapidement entre modeles), genere les tokens et les retransmet en streaming vers le tableau de bord.
Les fonctionnalites d'inference incluent des parametres ajustables (temperature, top_p, top_k, max tokens), l'historique de conversation, les prompts systeme et la comparaison A/B de modeles.
L'inference necessite vos propres workers. Les Parsyn Workers ne gerent que le training. Vous avez besoin d'au moins un worker connecte de type prompter ou both pour utiliser la fonctionnalite de chat.
Pipelines d'entrainement
Un pipeline automatise une sequence d'etapes qui s'enchainent sans intervention manuelle. Typiquement : entrainer un modele, evaluer le resultat, puis exporter vers un format d'inference. Chaque etape ne demarre que si la precedente a reussi.
Les pipelines sont utiles quand vous voulez reproduire le meme workflow plusieurs fois (par exemple, a chaque nouvelle version de votre dataset) sans avoir a relancer manuellement chaque etape. La plateforme gere l'orchestration et les echecs.
- Etapes disponibles : training job, evaluation, export de modele
- Comportement en cas d'echec : le pipeline s'arrete et signale l'etape en erreur
- Annulation : vous pouvez interrompre un pipeline en cours via
POST /pipelines/{id}/cancel
Equipes et organisations
Les organisations permettent de regrouper plusieurs utilisateurs et de partager des ressources entre eux de facon controlee.
Au sein d'une organisation, vous creez des equipes. Chaque equipe peut avoir des membres avec des roles differents. Les ressources (datasets, modeles, jobs) sont partagees au niveau du projet, qui est rattache a une organisation.
- Un utilisateur peut appartenir a plusieurs organisations
- L'isolation reste effective entre projets : une equipe ne voit pas les ressources d'un autre projet
- Les roles au sein d'une equipe controlent qui peut lire, modifier ou supprimer les ressources partagees
Les organisations sont particulierement utiles pour les equipes de recherche ou les entreprises qui veulent separer les environnements (production, experimentation) tout en centralisant la gestion.
Suites d'evaluation
Une suite d'evaluation est un jeu de prompts structure que vous pouvez executer contre n'importe quel modele pour mesurer ses performances de maniere reproductible.
Contrairement aux evaluations simples (qui calculent une metrique globale comme la perplexity), les suites d'evaluation permettent de comparer les reponses de plusieurs modeles sur exactement les memes entrees, avec un scoring defini a l'avance.
- Runs : chaque execution d'une suite contre un modele produit un run avec ses resultats
- Comparaison : comparez les runs de differents modeles ou de differentes versions du meme modele
- Reproductibilite : la suite est fixe, les prompts ne changent pas entre les runs