surogate

Surogate est une boîte à outils sous licence Apache 2.0 qui combine l'entraînement et le service de LLM dans un seul projet, avec des moteurs natifs C++/CUDA conçus pour les GPU NVIDIA. Il cible Linux x86_64 avec Python 3.12 et CUDA 13 (pilote 580+), et est distribué sous forme de wheel, de script d'installation et d'image conteneur. Moteur d'entraînement Le côté entraînement couvre le pré-entraînement et le fine-tuning complet, les adaptateurs LoRA et QLoRA, et les recettes de précision incluant BF16, FP8 hybride et NVFP4 Blackwell. Il prend en charge l'apprentissage par renforcement GRPO avec environnements de récompense, l'entraînement par préférences DPO, et la distillation de connaissances à partir des distributions top-K de l'enseignant. L'exécution multi-GPU et multi-nœuds utilise le parallélisme de données par threads, le sharding ZeRO, le chevauchement de communication et Ray. Le parallélisme par pipeline peut diffuser des poids gelés pour LoRA sur des GPU PCIe sans NVLink. L'entraînement MoE inclut le parallélisme expert et l'équilibrage de charge. Les contrôles mémoire incluent le déchargement CPU pour les poids, les gradients, l'état de l'optimiseur, les activations et les quants, plus la recomputation et l'exécution MLP en tuiles. Les optimiseurs incluent AdamW 8-bit et NorMuon, avec journalisation Weights & Biases, points de contrôle et reprise. Les modèles sont définis via un DSL Python avec différenciation automatique à l'avance. Moteur de service Le côté service est un serveur HTTP natif C++/CUDA exposant des points de terminaison Chat Completions, Completions et Responses compatibles OpenAI, plus Messages compatibles Anthropic. Il prend en charge le streaming, le contenu de raisonnement séparé, les contrôles de réflexion et des analyseurs d'appels de fonction spécifiques aux modèles. Les fonctionnalités de concurrence incluent le batching continu, le traitement de prompts en morceaux, les graphes CUDA, jusqu'à 128 séquences actives par modèle, la mise en cache de préfixes et le décodage spéculatif via MTP ou DFlash. Il charge les GGUF natifs (K-quants, Q8_0, formats hérités et IQ), les points de contrôle Hugging Face safetensors et les exports BF16/FP8/NVFP4. Le cache KV est élastique et peut être partagé entre modèles. Les adaptateurs LoRA runtime peuvent être chargés et sélectionnés par requête. Plusieurs modèles nommés peuvent partager un GPU avec priorités et comportement veille/réveil. Les grands modèles peuvent s'étendre sur plusieurs GPU ou décharger les poids vers le CPU, avec mise en cache d'experts GPU pour les familles MoE. Le support vision et embedding inclut images/vidéo pour les modèles de vision pris en charge et EmbeddingGemma sur GPU ou CPU AVX-512. Les fonctionnalités opérationnelles incluent l'authentification par clé API, les contrôles de santé, les métriques Prometheus, les journaux de requêtes et les statistiques de cache. Couverture des modèles Les exemples d'entraînement couvrent Qwen3 dense et MoE, Qwen3-VL, Qwen3.5/3.6 dense et MoE, Llama 3.1/3.2, MiniCPM5, Spark-X2.5, Gemma 4, Nemotron 3/Cascade 2, GPT-OSS, Laguna et LFM2/LFM2.5. Le service couvre Qwen3, Qwen3.5/3.6/3.8, Qwen3.8 Flash-Next, GLM-5.3-Flash, Llama, Gemma 3/4, LFM2/LFM2.5, MiniCPM5, Spark-X2.5 et EmbeddingGemma 300M. Le README note que les définitions d'entraînement DeepSeek-V4, Flash-Next et GLM-5.3-Flash ont encore des composants différés. Flux de travail Un flux typique est : installer, servir un modèle avec `surogate serve`, entraîner un adaptateur avec une configuration YAML via `surogate sft`, fusionner l'adaptateur dans son modèle de base, éventuellement quantifier en GGUF, puis servir le résultat. Un mode GRPO sur un seul GPU peut co-localiser le service et l'entraînement avec des poids partagés pour les familles LoRA BF16 prises en charge. Notes matérielles Les builds d'entraînement ciblent SM89+ (Ada, Hopper, Blackwell pris en charge). FP8 nécessite SM89+ ; NVFP4 natif nécessite du matériel Blackwell pris en charge. Les builds de service par défaut ciblent SM120a (série RTX 50 et RTX PRO Blackwell), avec un port SM89/Ada qui compile mais a une validation runtime en attente. L'entraînement distribué utilise NCCL ; le déchargement CPU nécessite suffisamment de RAM système. Le README présente des tableaux de benchmarks comparant le débit d'entraînement et de service avec Unsloth, vLLM et llama.cpp sur du matériel et des charges de travail spécifiques ; ce sont les propres mesures du projet et doivent être traitées comme telles.