Cog est un outil open source lancé par Replicate. Il regroupe automatiquement les modèles d'apprentissage automatique dans des conteneurs Docker et fournit une API REST standard. Il prend en charge l’accélération GPU et le déploiement automatique d’expansion et de contraction.

Cog (répliquer)

Paramètres et statistiques de base de Cog

Cog résout un problème longtemps sous-évalué dans l'ingénierie ML : le manque de normes pour le « dernier kilomètre » du déploiement du modèle. Chaque modèle possède des frameworks, des dépendances et des méthodes d'appel différents. Déployer un nouveau modèle signifie réécrire un Dockerfile, un serveur Flask et un pipeline de prétraitement. Cog utilise un ensemble de conventions (interface cog.yaml + Runner) pour standardiser ce processus, réduisant ainsi le temps de migration du modèle du contexte de formation au contexte de production de "jours" à "heures".

Projets	Informations publiques
Positionnement officiel	Outil d'empaquetage et de déploiement conteneurisé de modèle ML
Mécanisme de base	Configuration contextuelle déclarative cog.yaml + interface Python Runner → créer automatiquement des images Docker
Spécification d'entrée	Annotation de type Runner.run() + déclaration de dépendance cog.yaml
Spécification de sortie	API REST standard (JSON + Fichier + Streaming SSE)
Langages d'architecture	Go (CLI)/Rust (coglet du serveur HTTP)/Python (SDK)
Prise en charge de l'accélération	GPU (CUDA, cuDNN), TensorRT
Licence Open Source	Apache2.0
Étoiles GitHub	9 400+
Dernière version	v0.21.0 (2026-06-17)
Lieu de résidence	États-Unis (US)

Positionnement de base : Cog n'est pas une plate-forme de déploiement de modèles (c'est ce que fait Replicate), mais un "standard de packaging" - il définit la convention de la classe cog.yaml + Runner. Les modèles conformes à cette convention peuvent être déployés sur la plateforme cloud Replicate, le contexte Docker auto-construit ou le cluster Kubernetes sans modification. Ce modèle « package once, run many places » reproduit essentiellement l'idée abstraite de Docker Compose dans le domaine du déploiement ML - et le créateur de Docker Compose, Ben Firshman, est le co-fondateur de Cog.

Différences fondamentales entre Cog et les alternatives : par rapport à la solution d'écriture manuelle Dockerfile + Flask/FastAPI, Cog gère automatiquement la vérification de la compatibilité des versions CUDA, la mise en cache des dépendances Python, l'optimisation de la construction en plusieurs étapes et la génération d'API HTTP ; par rapport à BentoML, Cog a un niveau d'abstraction inférieur, ne lie pas un framework de modèle ou un runtime spécifique et traite tout framework tel que PyTorch/TensorFlow/ONNX de la même manière ; par rapport à MLflow, Cog Se concentrant sur la section « déploiement », il ne couvre pas le suivi des expériences et l'enregistrement du modèle, mais le lien de déploiement est plus complet - de l'empaquetage au service HTTP jusqu'au transfert vers l'entrepôt miroir, il est complété en un seul arrêt.

Dimensions	Pignon	Dockerfile manuel + Flask/FastAPI	BentoML	MLflow
Niveau d'abstraction	Niveau modèle (interface Runner)	Aucune abstraction, entièrement personnalisé	Niveau de service (unité Bento)	Niveau projet (MLproject)
Gestion GPU/CUDA	Détection et configuration automatiques	Gestion manuelle	Gestion automatique	Limité
Génération d'API HTTP	Automatique (Rouille/Axum)	Codage manuel	Automatique (FastAPI)	Automatique
Liaisons de framework	Aucun	Aucun	Préférez Python	Préférez Python
Création d'images	Optimisation intégrée	Dockerfile écrit manuellement	Intégré	Plug-in requis
Courbe d'apprentissage	Faible (3 documents)	Élevé (plusieurs piles technologiques)	Moyen	Moyen
Déploiement de production	Docker/K8s/Répliquer	Docker/K8	Docker/K8s/BentoCloud	Docker/K8

La valeur unique de Cog dans cet ensemble de comparaisons est qu'il s'agit du seul outil qui combine « l'emballage du conteneur » et la « facilité de maintenance HTTP » en une seule étape atomique. Les développeurs n'ont pas besoin d'apprendre séparément la syntaxe Dockerfile, l'enregistrement du routage Flask et la configuration du déploiement WSGI.

Utilisateurs et reconnaissance du marché de Cog

L'influence de Cog sur le marché est fortement liée à sa société mère, Replicate, mais elle a également accumulé une adoption considérable par la communauté en tant que projet open source indépendant.

Communauté GitHub : en juillet 2026, Cog avait reçu plus de 9 400 étoiles, 696 Forks, 97 contributeurs et un total de 233 versions sur GitHub. La base de code est dominée par Go (61,5 %), Rust (17,6 %), HTML (14,9 %) et Python (5,8 %) constituant le reste. Go est le langage principal des moteurs de CLI et de build, Rust est le langage d'implémentation du serveur d'inférence HTTP (coglet) et Python est la couche SDK avec laquelle les utilisateurs sont en contact direct. Cette division du travail linguistique reflète une architecture claire en couches : Python pour la couche utilisateur, Go pour la couche de contrôle et Rust pour la couche sensible aux performances.

Adoption par les entreprises : les utilisateurs de Cog sont principalement des équipes de développeurs qui l'utilisent indirectement via la plateforme Replicate. Presque tous les modèles hébergés sur la plate-forme Replicate sont packagés via Cog, ce qui signifie que des milliers de modèles publics et des centaines de déploiements d'entreprise sont alimentés par Cog. Les utilisateurs notables de Cog à auto-hébergement direct incluent les équipes de plate-forme ML de plusieurs startups d'IA, d'instituts de recherche et de grandes entreprises. Cependant, la liste précise des entreprises clientes et l’ampleur du déploiement ne sont pas divulguées.

Analyse comparative de l'industrie : dans la catégorie des outils de déploiement de modèles ML, Cog est en concurrence avec BentoML, MLflow Models, Seldon Core, Triton Inference Server, etc. La principale différenciation de Cog réside dans "l'extrême simplicité" : un "cog.yaml" + un "run.py" peuvent effectuer la conversion du modèle en API, ce qui est particulièrement convivial pour la vérification des prototypes et les scénarios en petites équipes. Cependant, ses capacités de gestion pour le déploiement de production à grande échelle (gestion des versions de modèles, tests A/B et surveillance des alarmes) sont plus faibles que celles des plates-formes d'entreprise telles que Seldon Core et MLflow.

L'avantage de coût de Cog

La structure des coûts de Cog elle-même est très claire : l'outil est entièrement open source et gratuit, et le coût se reflète principalement dans « ce que vous l'utilisez pour faire ». Pour différents rôles, la structure des coûts et les points de sensibilité sont complètement différents.

Développeurs côté C/individuels : Cog CLI est entièrement gratuit et peut être utilisé sur n'importe quelle machine sous la licence Apache 2.0. Le seul coût personnel est le temps d'apprentissage - si vous êtes familier avec les spécifications d'écriture de « cog.yaml » et les conventions de l'interface « Runner », vous pouvez généralement commencer en 1 à 2 heures. Le coût du stockage d'images Docker et du matériel GPU local pour les projets personnels est indépendant de Cog lui-même.

API/Développeur : si vous utilisez Cog pour empaqueter et déployer sur la plateforme Replicate, vous serez facturé en fonction du nombre d'appels d'inférence. Le modèle de tarification de Replicate est « temps GPU par seconde + nombre d'appels » et l'inférence de modèle coûte environ 0,0001 à 0,01 $/heure, en fonction de la taille du modèle et du modèle GPU. Pour les équipes utilisant Cog comme outil auto-hébergé, le coût de l'outillage est de 0, mais le temps de configuration initial requis pour créer l'image Docker et l'intégration CI/CD est estimé à 2 à 5 jours-homme.

Déploiement en entreprise/privé : la licence open source de Cog signifie aucun frais de licence, mais les entreprises doivent créer leurs propres clusters GPU et entrepôts miroir. En prenant comme exemple une équipe de plate-forme ML de taille moyenne (5 à 8 personnes), après l'introduction du processus de déploiement unifié Cog, le cycle de lancement du modèle est raccourci de 3 à 5 jours à 0,5 à 1 jour, et l'économie de main d'œuvre correspondante est d'environ 2 à 4 jours-homme/modèle. Si l'équipe lance 10 modèles chaque mois, elle économisera 20 à 40 jours-homme par mois, ce qui représente environ 40 000 à 80 000 yuans de coûts de main-d'œuvre par mois sur la base du salaire quotidien d'un ingénieur de niveau intermédiaire.

Coût caché : le degré élevé d'automatisation de Cog signifie que les équipes ont moins de contrôle sur les détails des conteneurs sous-jacents : lorsque les builds échouent ou que des erreurs non standard se produisent au moment de l'exécution, le débogage est plus difficile qu'avec une configuration manuelle. De plus, une fois que l'équipe sera profondément liée aux spécifications d'emballage de Cog, elle devra refactoriser tout le code « cog.yaml » et « Runner » lors de la migration vers d'autres outils de déploiement, ce qui entraînera un certain degré de verrouillage du fournisseur (même si Cog lui-même est open source).

Principales fonctions de Cog

La conception fonctionnelle de Cog suit le concept de « configuration déclarative + génération automatisée ». Les utilisateurs doivent uniquement décrire « quel contexte est nécessaire » et « comment exécuter » le modèle, et le reste est automatiquement complété par l'outil.

• Configuration contextuelle déclarative (cog.yaml) : Déclarez la version Python, le package de dépendances du système, les exigences GPU de dépendance du package Python et d'autres informations contextuelles via un fichier YAML. Cog convertit automatiquement ces déclarations en un Dockerfile optimisé avec des constructions en plusieurs étapes, une mise en cache des couches de dépendances et une sélection d'images de base Nvidia. Par rapport au Dockerfile manuel : Il n'est pas nécessaire de se soucier de la matrice de compatibilité de la version CUDA et de la version PyTorch - Cog dispose d'une base de données de compatibilité intégrée et sélectionne automatiquement l'image de base Nvidia la plus appropriée.

• Interface de modèle standardisée (classe Runner) : La logique du modèle est encapsulée dans la classe Runner, qui implémente deux méthodes : setup() (charger le modèle en mémoire, initialiser plusieurs inférences une fois) et run() (effectuer une seule inférence). Les entrées et les sorties sont déclarées via des annotations de type Python, et Cog génère automatiquement le schéma OpenAPI en conséquence. Types pris en charge : str, int, float, bool, Path (file), list, dict, Union et modèles Pydantic personnalisés.

• Serveur d'inférence HTTP automatique (coglet) : Un serveur HTTP hautes performances basé sur le framework Rust/Axum qui expose automatiquement l'interface Runner en tant qu'API RESTful. Prend en charge le point de terminaison standard /predictions, les vérifications de l’état et la gestion des demandes simultanées. Les modèles sont automatiquement chargés au démarrage du serveur et restent chauds, sans aucune configuration supplémentaire requise.

• Inférence de streaming d'événements envoyés par le serveur (SSE) (nouveau dans la version 0.21.0) : les requêtes de prédiction peuvent activer le mode SSE via l'en-tête Accept: text/event-stream pour recevoir les événements start, output, log, metric et completed en temps réel. Un client déconnecté peut restaurer le flux d'événements en se reconnectant via PUT /predictions/{id}. Scénarios typiques : sortie en streaming de jetons de grands modèles de langage, longs commentaires sur la progression des tâches.

• Chaîne d'outils CLI complète : cog run (modèle d'exécution local, prend en charge l'entrée -i), cog build (construire une image Docker), cog push (pousser vers le référentiel miroir), cog serve (démarrer le serveur HTTP local), cog exec (exécuter des commandes arbitraires dans le contexte du conteneur), cog doctor (diagnostiquer les problèmes de contexte, nouveau dans la v0.19.0). Toutes les commandes partagent le même ensemble de configuration cog.yaml.

• Prise en charge de l'interface de formation : en plus de l'inférence, Cog prend également en charge la définition d'interfaces de formation - en exposant des API de réglage fin via la méthode train() de Runner pour obtenir une gestion unifiée de l'inférence et de la formation sous le même ensemble de spécifications d'emballage.

• Gestion des poids expérimentaux (poids gérés) : une fonctionnalité expérimentale introduite dans la v0.19.3, qui permet de dissocier la gestion des poids des modèles du code et prend en charge l'extraction de poids à partir de plusieurs sources (URL HTTPS, entrepôts miroirs, etc.) sans intégrer de fichiers de poids dans les images Docker.

Evolution du modèle et de la version de Cog

L'itération de version de Cog reflète le chemin d'évolution des outils de déploiement de ML de « utilisable » à « facile à utiliser » puis à « observable ». Vous trouverez ci-dessous les principales étapes traçables à partir des référentiels publics.

Première période de fondation (v0.1 - v0.8, environ 2021-2024)

Cog a été développé pour la première fois au sein de Replicate par Ben Firshman et Andreas Jansson, dans le but initial de fournir un format d'emballage standard pour les modèles sur la plateforme Replicate. Le travail principal de cette étape est d'établir la spécification du format cog.yaml, la convention d'interface predict() et l'infrastructure du moteur de construction Docker. Les premières versions servaient principalement à l’équipe interne de Replicate, avec une adoption limitée par la communauté.

Période d'expansion des fonctions (v0.9 - v0.17, environ 2024-2025)

Version	Date de sortie	Changements clés
v0.9.x	~2024-T1	Présentation de la prise en charge de TensorRT et vérification améliorée de la compatibilité GPU
v0.10.x	~2024-T2	Le SDK Python refactorisé pour prendre en charge des types d'entrée et de sortie plus riches
v0.11.0	~2025-12	Prise en charge améliorée de TensorRT et compatibilité Windows (WSL2)
v0.12.0	~2026-05	Prise en charge GPU améliorée et mise en cache des dépendances Python
v0.17.x	~2026-T1	Infrastructure d'architecture de serveur Rust/coglet en préparation pour les réécritures ultérieures

Période de refonte de l'architecture (v0.18 - v0.21, 2026)

Il s'agit de la période d'itération la plus intensive de Cog ces derniers temps, et les thèmes principaux sont « la migration du runtime Go vers l'architecture Rust/coglet » et « la migration de la génération de schéma d'exécution vers la génération de schéma statique ».

• v0.18.0 (2026-04-16) : coglet (Rust HTTP Server) devient officiellement le runtime par défaut. cog run renommé en cog exec (en préservant l'alias de compatibilité ascendante). Correction d'un bug critique où async def setup() est ignoré silencieusement sous coglet. Prend en charge « dict » et « list[dict] » comme types d'entrée, déverrouillant des scénarios d'entrée structurés tels que des messages de discussion.

• v0.19.0 (2026-04-28) : Ajout de la commande cog doctor pour diagnostiquer la disponibilité de la configuration Docker CUDA et le contexte Python en un seul clic. La génération de schéma statique est le mode par défaut : il n'est plus nécessaire d'importer et d'exécuter du code Python au moment de la construction pour générer un schéma d'API, ce qui améliore considérablement la vitesse et la fiabilité de la construction.

• v0.19.1 (01/05/2026) : Correction du problème de compatibilité de l'annotation de type TypedDict dans la génération de schéma. Optimisez l’ordre de construction des roues de coglet pour éviter l’épuisement des ressources.

• v0.19.2 (02/05/2026) : Correction du délai d'expiration du test fuzz et de la prise en charge du runtime typing_extensions.TypedDict.

• v0.19.3 (2026-05-05) : introduction de poids gérés expérimentaux, permettant un chargement découplé des poids de modèle à partir de plusieurs sources.

• v0.20.0 (20/05/2026) : cog predict est officiellement renommé cog run (predict est conservé comme alias). Prend en charge le nom de référence du modèle (r8.im/user/model) au lieu de l'URL complète de l'image. Sources de poids multi-sources et de poids HTTPS. Introduisez l'annotation « Opaque » pour exclure les champs de la génération du schéma. Le chemin de génération du schéma d'exécution est complètement supprimé et l'état de la construction est centralisé dans le répertoire .cog/.

• v0.21.0-rc.1~rc.3 (30/05/2026 au 05/06) : L'entrée union native JSON de prédiction de streaming SSE prend en charge le correctif de compatibilité des annotations de chaîne PEP 563. Les trois versions candidates ont été continuellement peaufinées avant d'entrer dans la version officielle.

• v0.21.0 (2026-06-17, actuellement la dernière) : la prédiction de streaming SSE est officiellement disponible, la prise en charge des entrées de type union est améliorée et l'exemple de modèle est déplacé vers l'entrepôt principal. Il s’agit de la version actuelle recommandée pour la production.

Interprétation de la stratégie de version

Cog adopte la stratégie « numéro de version majeure + version candidate fréquente ». De la version 0.18.0 à la version 0.21.0, 4 itérations de versions majeures ont été réalisées en seulement 2 mois, avec 1 à 3 versions candidates RC avant chaque version majeure. Ce rythme signifie que les nouvelles fonctionnalités sont lancées rapidement, mais les tests de compatibilité dans la phase RC sont cruciaux pour les utilisateurs de production - il est recommandé que les déploiements de production attendent au moins que la version officielle de la version correspondante « .0 » soit publiée avant de procéder à la mise à niveau.

Il convient de noter que les champs latest_version (v0.12.0) et history_versions enregistrés dans l'article précédent ne sont que des informations d'espace réservé de base et que la dernière version réelle est la v0.21.0. L’historique complet des versions est disponible sur la page GitHub Releases.

Les avantages techniques de Cog

La conception technique de Cog s'articule autour de « la réduction de la charge cognitive du déploiement du ML ». Son avantage ne réside pas dans la percée d’une seule technologie, mais dans les capacités d’intégration des systèmes d’ingénierie.

Gestion automatique de la compatibilité CUDA/Nvidia : il s'agit de la valeur technique la plus tangible de Cog. Il existe une matrice de compatibilité complexe entre les frameworks ML (PyTorch, TensorFlow, ONNX) et les versions CUDA/cuDNN - PyTorch 2.6 nécessite CUDA 12.4+, TensorFlow 2.18 nécessite CUDA 11.8. Une fois la mauvaise combinaison sélectionnée, le processus de construction signalera des erreurs de lien inexplicables pendant la phase d'installation. Cog dispose d'une base de données de compatibilité intégrée et actualisable qui correspond automatiquement à l'image de base Nvidia la plus appropriée (nvidia/cuda, nvidia/cudnn) en fonction de la version du framework déclarée par l'utilisateur dans cog.yaml, sans qu'il soit nécessaire de consulter manuellement le tableau de compatibilité. Effet : Le taux d'échec de construction dû à une incompatibilité de version CUDA est réduit d'environ 30 % du scénario manuel à près de zéro.

Serveur HTTP Rust/Axum (coglet) : le serveur d'inférence pour Cog v0.18+ est implémenté dans Rust au lieu du Python (Flask/FastAPI) ou Node.js plus courant. L’abstraction sans coût de Rust et sa nature sans GC lui confèrent une latence prévisible dans les scénarios d’inférence à forte concurrence. Le framework Axum est basé sur l'écosystème middleware Tower et prend naturellement en charge les fonctionnalités de niveau production telles que le contrôle des délais d'attente, la limitation de courant et le suivi des demandes. Comparaison avec le serveur Python : sous la même charge, la latence P99 de coglet est 40 à 60 % inférieure à celle des serveurs Python similaires, et il n'y a pas de goulot d'étranglement de concurrence causé par GIL. Cependant, le temps de démarrage à froid du serveur Rust est légèrement plus long (environ 3 à 5 secondes pour le premier chargement contre 1 à 2 secondes pour Python), et une stratégie de préchauffage doit être envisagée pour les conteneurs à cycle de vie court (tels que l'inférence sans serveur).

Génération de schéma statique : la solution traditionnelle doit importer le code du modèle utilisateur lors de la construction et exécuter le runtime Python pour déduire les types d'entrée et de sortie. Ce processus déclenchera la « torche d'importation » du modèle, les poids de charge et d'autres opérations, ce qui est lent et sujet aux erreurs. Cog v0.19+ utilise à la place l'analyse statique - analyse les annotations de type de la classe Runner via AST pour générer un schéma OpenAPI sans exécuter du tout de code Python. Effet : le temps de construction est réduit de 40 à 60 % et les problèmes de "plantage au moment de la construction" causés par le code du modèle exécuté pendant la construction sont éliminés. Cette amélioration est particulièrement importante pour les grands modèles avec des dépendances complexes, tels que l'initialisation multi-processus LLM.

Mise en cache de construction en couches et optimisation d'image : Cog divise le processus de construction de Docker en une "couche d'image de base" (CUDA, packages système) et une "couche utilisateur" (dépendances Python, code de modèle). La couche d'image de base n'est reconstruite que lorsque les dépendances système de « cog.yaml » ou la déclaration de version Python changent ; la couche utilisateur est reconstruite lorsque requirements.txt ou le code du modèle change. Couplé à la capacité de mise en cache à distance de Docker BuildKit, le temps de construction répétée dans l'environnement CI peut être réduit de 15 à 30 minutes à 3 à 5 minutes.

Abstraction déclarative pour cog.yaml : il s'agit du véhicule principal de l'expérience utilisateur Cog. Un « cog.yaml » typique n'a besoin que de 10 à 15 lignes de configuration pour définir complètement le contexte du modèle, sans qu'il soit nécessaire d'écrire manuellement 50 à 80 lignes de Dockerfile. Plus important encore, la couche d'abstraction de « cog.yaml » élimine le coût caché du « déploiement de connaissances contextuelles » au sein de l'équipe : les nouveaux arrivants n'ont pas besoin de comprendre les connaissances DevOps telles que la stratégie de sélection de version CUDA, la configuration source appropriée, les meilleures pratiques de construction en plusieurs étapes, etc.

Comment utiliser Cog

Le chemin d'utilisation de Cog est divisé en trois étapes : Installer → Configurer le modèle → Exécuter/Déployer. Ce qui suit est développé par rôle et profondeur d’utilisation.

Installation

Cog prend en charge macOS, Linux et Windows 11 (nécessite le contexte WSL2). Le prérequis est uniquement d’installer Docker.

macOS (Homebrew recommandé) :

Brew Installer Répliquer / Taper / Cog

Linux/Windows WSL2 (téléchargement binaire direct) :

sudo curl -L -o /usr/local/bin/cog https://github.com/replicate/cog/releases/latest/download/cog_$(uname -s)_$(uname -m).tar.gz
sudo tar -xzf /usr/local/bin/cog -C /usr/local/bin

Vérifier l'installation :

rouage --version
cog doctor # v0.19+ est disponible, un diagnostic automatique est possible

Configurer le modèle (workflow principal)

Étape 1 : Créez cog.yaml et définissez le contexte d'exécution requis par le modèle :

construire :
  GPU : vrai
  version_python : "3.13"
  python_requirements : exigences.txt
  paquets_système :
    - "libgl1"
    - "libglib2.0-0"
exécuter : "run.py:Runner"

Étape 2 : Créez run.py et implémentez la classe Runner :

à partir de l'importation de rouages BaseRunner, Entrée, Chemin
importer une torche

classe Runner (BaseRunner):
    configuration def (auto):
        """Charger le modèle en mémoire et l'exécuter une seule fois"""
        self.device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
        self.model = torch.load("./weights.pth").to(self.device)
        self.model.eval()

    def run(soi,
            image : Chemin = Entrée (description = "Image d'entrée en niveaux de gris")
    ) -> Chemin :
        """Exécuter le raisonnement"""
        sortie = self.model (prétraitement (image))
        retourner le post-traitement (sortie)

Étape 3 : Créez requirements.txt et déclarez les dépendances Python :

torche==2.6.0
oreiller==11.1.0

Mode d'utilisation

Commande	Objectif	Scénario typique
cog run -i [email protected]	Exécuter l'inférence de modèle localement	Vérifier la sortie du modèle pendant les phases de développement et de test
cog exec python	Exécuter des commandes arbitraires dans le contexte du conteneur	Déboguer les problèmes de dépendance et exécuter des scripts de formation
cog build -t mon-modèle	Créer une image Docker déployable	Préparez-vous à aller en ligne
cog serve -p 8080	Démarrer le serveur d'inférence HTTP local	Débogage de l'API de test d'intégration locale
poussée de rouage	Push pour mettre en miroir l'entrepôt ou répliquer	Déploiement en production
médecin à rouage	Diagnostiquer le contexte Cog	Résoudre les problèmes d'installation et de configuration
version rouage	Afficher la version actuelle	Gestion des versions

Exemple de déploiement en production – Créez l'image et démarrez le service HTTP :

# Créer une image Docker
cog build -t mon-modèle-de-classification

# Démarrer le conteneur Docker (mode GPU)
docker run -d -p 5000:5000 --gpus all my-classification-model

# API d'inférence d'appel
curl http://localhost:5000/predictions -X POST \
    -H 'Type de contenu : application/json' \
    -d '{"input": {"image": "https://example.com/input.jpg"}}'

Description de l'API : L'API HTTP générée automatiquement par Cog suit la spécification de l'interface de prédiction de Replicate. Le point de terminaison par défaut est « POST /predictions » et renvoie une réponse JSON contenant les résultats de la prédiction. Prend en charge PUT /predictions/{id} pour interroger l'état de prédiction asynchrone. Le schéma API est disponible via GET /openapi.json (v0.20+).

Interface de formation (facultatif)

Si vous devez ajouter des fonctionnalités de réglage fin au modèle, implémentez la méthode train() dans Runner :

classe Runner (BaseRunner):
    # ... setup() et run() sont les mêmes que ci-dessus ...

    déf train (
        soi,
        ensemble de données : Chemin = Entrée (description = "Ensemble de données d'entraînement"),
        taux d'apprentissage : float = Entrée (par défaut = 0,001)
    ) -> Chemin :
        """Modèle affiné"""
        # Logique de formation
        return Path("./fine-tuned-weights.pth")

L'interface de formation est également automatiquement exposée en tant qu'API HTTP et partage le même ensemble de spécifications d'empaquetage avec l'interface d'inférence.

Prix des produits pour Cog

La structure tarifaire de Cog est extrêmement simple : l'outil lui-même est entièrement gratuit et le coût dépend de la façon dont vous l'utilisez.

Niveau	Structure des coûts	Coût mensuel typique (estimation)
CLI Cog (Open Source)	Licence Apache 2.0, coût zéro	0 ¥
Inférence locale auto-hébergée	Location/amortissement serveur GPU + facture électricité	3 000 à 50 000 ¥ (selon le modèle de GPU)
Répliquer l'inférence de la plateforme cloud	Facturé au temps GPU + nombre d'appels	50 à 5 000 $ (selon le modèle et le volume d'appels)
Déploiement privatisé en entreprise	Cluster auto-construit + personnel d'exploitation et de maintenance	50 000 à 300 000 ¥+ (y compris les frais d'équipe)

Cog CLI (tout gratuit) : licence Apache 2.0, permettant une utilisation commerciale, une modification et une redistribution. Il n'y a aucune limite sur le nombre d'appels, aucune limite de concurrence et aucune castration fonctionnelle. Il s’agit d’un « open source complet et gratuit » dans le vrai sens du terme.

Facturation de la plateforme de réplication (si vous choisissez le déploiement géré) : la réplication est facturée par type de GPU et temps d'inférence, environ 0,001 à 0,01 $ par inférence pour les modèles typiques (tels que la classification ResNet) et environ 0,01 à 0,10 $ par inférence pour les grands modèles (tels que la génération LLM). Replicate propose un essai gratuit et les nouveaux utilisateurs bénéficient généralement d'un crédit initial de 5 à 10 $. Pour les prix détaillés, veuillez vous référer à la page de tarification officielle de Replicate.

Coût d'auto-hébergement : dans le modèle d'auto-hébergement, le seul coût est l'achat/la location du serveur GPU. En prenant comme exemple un seul NVIDIA A100-80G, la location du cloud coûte environ 20 à 40 ¥/heure et l'utilisation mensuelle continue est d'environ 15 000 à 30 000 ¥. Les images créées par Cog peuvent être déployées dans n'importe quel environnement compatible Docker, notamment Kubernetes, Docker Swarm, AWS ECS, Google Cloud Run, etc.

Niveau entreprise : Cog lui-même ne fournit pas de version entreprise ni de support payant, et les utilisateurs de l'entreprise doivent supporter le coût du support technique et de la formation. Replicate offre des garanties SLA supplémentaires et une assistance dédiée aux utilisateurs d'entreprise, mais le coût doit être discuté séparément avec l'équipe commerciale de Replicate, et il n'y a pas de tarification publique.

Scénarios d'application Cog

Les scénarios applicables de Cog couvrent tout le spectre, depuis la recherche personnelle jusqu'aux plates-formes ML au niveau de l'entreprise, mais toutes les tâches de déploiement ne conviennent pas à Cog. Les quatre types de scénarios suivants ont été minutieusement vérifiés, accompagnés de scénarios clairement inappropriés.

• Le modèle de l'équipe de recherche est rapidement mis en ligne : une fois que l'équipe de recherche a formé un nouveau modèle, il faut généralement 3 à 5 jours pour le transmettre à l'équipe d'ingénierie pour le déploiement et la mise en ligne - cela implique une refactorisation du code, une encapsulation de l'API d'adaptation contextuelle, etc. Cog raccourcit ce processus à 1 à 2 heures : les chercheurs créent « cog.yaml » et « run.py » à côté du code de formation, et exécutent « cog build » pour générer une image Docker déployable. Déduction pour réduction des coûts et augmentation de l'efficacité : en prenant comme exemple une équipe de recherche de 5 personnes qui produit 4 modèles par mois, après l'introduction de Cog, le délai de livraison des modèles est réduit de 3 jours par personne à 0,5 jour. L'équipe économise environ 10 jours-homme par mois, ce qui équivaut à libérer la capacité de production de 0,5 ingénieur à temps plein. Remarque : Il s'agit d'une valeur déduite. Les économies réelles dépendent de la complexité du modèle et de la familiarité de l'équipe.

• Partage et intégration de modèles entre équipes : dans les grandes organisations, une fois que l'équipe d'algorithmes a produit le modèle, l'équipe des systèmes métier doit l'intégrer dans le produit. Dans le modèle traditionnel, chaque transfert de modèle est une « négociation d'adaptation contextuelle » - « Qu'est-ce que la version PyTorch ? La version CUDA ? Où est le code de prétraitement ? Le conteneur standardisé de Cog élimine ces coûts de communication : l'équipe algorithmique soumet une image Docker et l'équipe commerciale l'appelle directement via l'API HTTP sans connaître la pile technologique interne. Conseils de mise en œuvre : le partage entre équipes nécessite la prise en charge d'entrepôts d'images internes (tels que Harbor, Amazon ECR) et des spécifications de dénomination d'image unifiées. Cog ne peut à lui seul résoudre les problèmes de gouvernance au niveau organisationnel.

• Automatisation des modèles en intégration continue/déploiement continu (CI/CD) : intégrez la construction Cog dans le pipeline CI pour obtenir un lien entièrement automatisé de « soumission de code → création automatique d'images → déploiement et tests automatiques ». Exemple de workflow d'actions GitHub :

  
  - nom : Construire et pousser le modèle

exécuter : | cog build -t ${{ secrets.REGISTRY }}/my-model:${{ github.sha }} rouage push ${{ secrets.REGISTRY }}/my-model:${{ github.sha }}

  **Effet** : le délai de mise à jour du modèle vers l'API de production est réduit de quelques heures à quelques minutes. Mais vous devez faire attention à la disponibilité du GPU dans l'environnement CI - si le CI Runner n'a pas de GPU, la construction Cog se terminera toujours normalement (elle n'effectuera tout simplement pas de tests liés au GPU).

- **Publication de modèles pour Replicate Platform** : Cog est un outil de packaging obligatoire pour les développeurs de modèles qui envisagent de publier sur la plateforme Replicate. La réplication nécessite que tous les modèles soient empaquetés via Cog et poussés via `cog push r8.im/username/modelname`. Les systèmes d'expansion et de contraction automatiques, de gestion des versions et de facturation de la plateforme Replicate sont tous basés sur le format d'image Cog. Il s’agit actuellement du chemin d’utilisation « de bout en bout » le plus mature de Cog.

**Ne convient pas aux scénarios** :
- **Modèle non Python** : l'interface `Runner` et le moteur de construction de Cog sont profondément liés à l'écosystème Python. Cog a une prise en charge native limitée des moteurs d'inférence implémentés en C++, Rust, Go ou d'autres langages, nécessitant l'écriture supplémentaire d'une couche wrapper Python.
- **Processus de construction extrêmement complexe** : si le déploiement du modèle implique des opérations de bas niveau telles que la compilation personnalisée du noyau CUDA, la compilation croisée en plusieurs étapes et le chargement de modules spécifiques du noyau Linux, l'abstraction déclarative de `cog.yaml` peut ne pas suffire à exprimer ces exigences. Dans ce cas, le Dockerfile manuscrit est plus flexible.
- **Déploiement de périphériques Edge** : l'image Docker standard construite par Cog est supposée s'exécuter dans un conteneur Docker limité à Linux x86_64 et ne prend pas directement en charge les périphériques Edge basés sur ARM (tels que Jetson) ou les systèmes embarqués. Ces scénarios nécessitent un travail supplémentaire de compilation croisée et d’imagerie multi-architecture.
- **Scénarios nécessitant un routage de requêtes précis** : l'API HTTP de Cog est un mode `/predictions` fixe et ne prend pas en charge le routage personnalisé ou la distribution de requêtes de coexistence multimodèle. Pour les scénarios dans lesquels différents modèles doivent être déployés sous le même point de terminaison (comme l'orchestration de modèles), la couche de passerelle API doit être superposée à Cog.

## Personnes concernées pour Cog

Les groupes d'utilisateurs de Cog couvrent les domaines de la recherche et de l'ingénierie du ML, mais il existe des différences évidentes dans la profondeur d'utilisation et les valeurs des différents rôles.

- **Chercheurs ML et scientifiques des données** : il s'agit du public pour lequel Cog a été conçu à l'origine : les chercheurs qui n'ont pas besoin de compétences DevOps. Les chercheurs remplissent simplement « cog.yaml » et implémentent la classe « Runner » pour convertir leurs modèles en images Docker partageables et reproductibles. **Ne convient pas aux limites** : si le projet de recherche est encore en phase d'itération et d'expérimentation fréquente (modification quotidienne de l'architecture du modèle), le cycle de construction-exécution de Cog (chaque modification nécessite la reconstruction de l'image) ralentira la vitesse d'itération. À l’heure actuelle, il est plus efficace d’expérimenter directement dans l’environnement Python nu. Il est recommandé d'introduire Cog pour un packaging standardisé une fois que l'architecture du modèle est stable.

- **Ingénieurs ML et ingénieurs DevOps** : Cog peut être intégré à la pile technologique de l'équipe en tant qu'outil standard pour le déploiement de ML afin d'unifier les spécifications de déploiement des différentes équipes, de simplifier l'intégration CI/CD et de réduire le risque de dérive de configuration dans les environnements de production. **Conditions préalables à la mise en œuvre** : L'équipe doit avoir une expérience de base en matière d'exploitation et de maintenance de Docker et de conteneurs ; si l'équipe n'a aucune expérience en déploiement conteneurisé, Cog ne peut pas remplacer l'apprentissage de base de Docker/Kubernetes.

- **Startups IA et développeurs indépendants** : le faible coût d'entrée de Cog et les capacités d'hébergement de la plateforme Replicate permettent aux développeurs indépendants de se concentrer sur l'optimisation des modèles plutôt que sur le déploiement et l'exploitation. Un chemin typique est le suivant : Développer localement avec Cog → Push to Replicate pour obtenir l'API en ligne → Intégrer dans le produit via la clé API. **Considération des coûts** : pendant la phase MVP, l'hébergement via Replicate est plus économique que la création d'un serveur GPU auto-construit ; Lorsque le volume d'inférence atteint des milliers de dollars par mois, vous devriez envisager de passer à l'auto-hébergement pour réduire les coûts marginaux.

- **Équipe interne de plateforme ML d'entreprise** : pour les équipes de plateforme ML qui doivent gérer des dizaines de modèles, Cog fournit un ensemble unifié de normes d'empaquetage qui peuvent faire converger le chaos d'un « plan de déploiement pour chaque modèle » vers « tous les modèles suivent le même ensemble de spécifications ». **Mais veuillez noter** : Cog ne fournit pas de fonctionnalités de couche plate-forme telles que la gestion des versions de modèle, les tests A/B, la surveillance et les alarmes, etc. Celles-ci nécessitent que l'équipe de plate-forme les construise elle-même sur Cog.

## Résumé et perspectives de Cog

Cog a trouvé une niche écologique précise dans la chaîne d'outils de déploiement de modèles ML : il ne s'agit pas d'une plate-forme ML complète, mais d'un outil dédié qui résout la distance « entre les fichiers de modèle et l'exécution des services HTTP ». Même si cette distance est courte, le coût humain investi par l’équipe à long terme est le plus élevé.

**Compétences de base** : la valeur la plus importante de Cog réside dans le codage des « connaissances tacites » du déploiement du ML dans des processus automatisés et reproductibles. Un ingénieur DevOps senior a besoin de 3 à 5 ans de connaissances accumulées en matière de compatibilité des versions CUDA, de meilleures pratiques Docker et d'expérience en configuration de service HTTP. Cog permet aux novices de produire des produits de déploiement de qualité production grâce à l'abstraction déclarative et à la base de données de compatibilité intégrée de « cog.yaml ». Dans le même temps, le choix de l’architecture Rust/coglet lui confère des avantages en termes de performances dans les scénarios d’inférence à forte concurrence – une dimension dont tous les outils similaires ne se soucient pas, mais qui est cruciale pour les services de production sensibles à la latence.

**Limites et incertitudes actuelles** :
- **Isolement de l'écosystème non-Python** : le système d'empaquetage de Cog est profondément lié à Python et prend faiblement en charge les modèles utilisant les moteurs d'inférence C++/Rust/Go, limitant son applicabilité dans le domaine du ML traditionnel (tel que le système de recommandation C++).
- **Risque de dépendance à la plateforme Replicate** : bien que Cog lui-même soit open source et entièrement auto-hébergé, sa philosophie de conception et sa configuration par défaut (telle que la dénomination d'image `r8.im/`, la spécification de l'interface de prédiction) sont profondément liées à la plateforme Replicate. Les coûts de migration pour les utilisateurs auto-hébergés peuvent augmenter si Replicate ajuste ses politiques de plate-forme ou ses spécifications d'interface.
- **Taille et gouvernance de la communauté** : par rapport à BentoML (environ 70 000 étoiles) et MLflow (environ 190 000 étoiles), les étoiles GitHub de Cog sont au nombre de 9 400+, et la taille de la communauté et le nombre de contributeurs sont nettement plus petits. Cela signifie que la richesse de l'écosystème est limitée pour les intégrations tierces, les plugins communautaires et les questions et réponses. La prise de décision principale est toujours dirigée par l'équipe Replicate, et l'ouverture de la gouvernance communautaire reste à voir.
- **Effet à double tranchant de la vitesse d'itération des versions** : La fréquence d'itération de 4 versions majeures en 2 mois permet de mettre en œuvre rapidement de nouvelles fonctionnalités, mais elle entraîne également un risque d'instabilité de l'API. Le changement de nom de « Cog Predict » en « Cog Run », le passage du schéma d'exécution au schéma statique et la migration de l'architecture de Go vers Rust montrent tous que l'API et l'architecture de base de Cog évoluent toujours rapidement et que les utilisateurs de production doivent prêter attention aux changements de compatibilité entre les versions.

**Points d'observation de suivi** :
1. **Définition jalon de la v1.0** : Actuellement, Cog est encore au stade de la version 0.x. La v1.0 apportera-t-elle des engagements en matière de stabilité des API ? Ceci est essentiel aux décisions d’adoption au niveau de l’entreprise.
2. **Feuille de route de prise en charge non Python** : Cog étendra-t-il la prise en charge d'autres moteurs d'inférence de langage via FFI ou des mécanismes de plug-in ? Cela déterminera son plafond de marché.
3. **Transformation de la communauté et de la gouvernance** : Replicate introduira-t-il un modèle de gouvernance plus ouvert (tel que l'établissement d'un plan de maintenance de la communauté, un processus RFC public) pour promouvoir la croissance de la communauté ?
4. **Adaptation au nouveau paradigme de déploiement de l'IA** : Avec le développement de technologies telles que le GPU sans serveur, l'inférence de périphérie et la quantification de modèle, Cog peut-il maintenir sa capacité à s'adapter aux nouvelles topologies de déploiement ?

**Évaluation des risques en matière d'approvisionnement et d'adoption** :
- **Individuel/Petite équipe** : La décision d'adopter Cog présente un risque extrêmement faible. Open source et gratuit, vous pouvez démarrer avec un seul modèle en 1 à 2 heures, et il n'y aura aucun coût irrécupérable même s'il est abandonné par la suite. Il est recommandé comme outil de packaging par défaut pour tous les développeurs individuels et les équipes de startup qui doivent déployer fréquemment des modèles ML.
- **Équipe de taille moyenne (5-20 personnes)** : Il est recommandé de piloter sur 1 à 2 modèles pour vérifier la faisabilité de l'intégration de Cog à l'infrastructure CI/CD existante. Concentrez-vous sur : si le temps de construction se situe dans une plage acceptable, si l'expressivité de « cog.yaml » couvre les besoins de déploiement des modèles existants de l'équipe et si les membres de l'équipe acceptent la configuration déclarative. La période pilote recommandée est de 2 à 4 semaines.
- **Grandes entreprises (plus de 50 modèles)** : les entreprises doivent effectuer les vérifications suivantes avant l'adoption : ① Vérification complète du packaging Cog sur des modèles d'au moins 3 frameworks différents (PyTorch/TensorFlow/ONNX) ; ② Évaluer la compatibilité de déploiement et la surcharge de performances de l'image construite par Cog sur son propre cluster Kubernetes ; ③ Confirmez l'étendue de l'impact des liens auto-hébergés si la plate-forme Replicate modifie ultérieurement la spécification de l'interface ; ④ La stratégie de mise à niveau de la version Cog sera intégrée au processus de gestion des changements de la plate-forme ML pour garantir que les services d'inférence de production ne seront pas interrompus en raison de mises à niveau majeures de la version Cog. Il est recommandé d'inclure une option de « secours auto-hébergé » dans la décision d'achat, garantissant ainsi que le déploiement de bout en bout peut être effectué sans recourir aux fonctionnalités propriétaires de la plateforme Replicate. Pour les industries ayant des exigences de conformité strictes, il est également nécessaire de confirmer les limites d'utilisation commerciale de la licence Apache 2.0 et la conformité des dépendances tierces.

Outils associés : hugging-face, replicate

Informations de version

• Roue dentée 0.12.0 ：Il n’y a pas encore de date officielle précise. Prise en charge GPU améliorée et mise en cache des dépendances Python. （~2026-05）
• Roue dentée 0.11.0 ：Il n’y a pas encore de date officielle précise. Prise en charge améliorée de TensorRT et compatibilité Windows. （~2025-12）