building-inferencesh-apps

Vue d’ensemble

Qu’est-ce que building-inferencesh-apps ?

La skill building-inferencesh-apps est un guide ciblé pour créer et déployer des applications sur la plateforme inference.sh. Elle explique le flux de travail standard d’une app, le rôle du CLI infsh et comment scaffolder et gérer en toute sécurité des applications de type backend écrites en Python ou Node.js.

Cette skill n’est pas un tutoriel générique ; elle est alignée sur les commandes officielles infsh app et sur les attentes du runtime inference.sh. Elle vous aide à éviter des erreurs fréquentes comme la création manuelle de fichiers clés, la mauvaise configuration des ressources de l’app ou le déploiement depuis le mauvais répertoire.

À qui s’adresse cette skill ?

Utilisez building-inferencesh-apps si vous êtes :

• Un développeur backend qui crée des apps de type API à exécuter sur inference.sh
• Un ingénieur Python ou Node.js qui encapsule des modèles ou des APIs externes dans un service hébergé
• Un développeur orienté CLI qui veut un flux de déploiement prévisible et scriptable
• Un utilisateur de la plateforme qui doit comprendre, à un niveau général, les ressources GPU/VRAM, les secrets d’app et les intégrations

Si vous devez comprendre comment une app inference.sh doit être structurée, comment les fichiers inf.yml et inference.py / inference.js sont générés, et comment travailler avec la plateforme de manière sûre, cette skill est un bon point de départ.

Quels problèmes cette skill résout-elle ?

La skill building-inferencesh-apps traite les points de friction fréquents au démarrage avec le développement d’apps sur inference.sh :

• La confusion sur la bonne façon de scaffolder une nouvelle app
• La création manuelle accidentelle de inf.yml, inference.py, inference.js ou package.json qui ne respecte pas les attentes de la plateforme
• L’oubli de faire un cd dans le répertoire de l’app avant d’exécuter des commandes infsh
• La perte des données output_meta en étendant la mauvaise classe de base
• L’absence de logs, qui complique le debug d’apps distantes ou fortement dépendantes d’APIs

En suivant les pratiques résumées dans cette skill, vous obtenez un flux de travail cohérent et reproductible pour construire et déployer des apps inference.sh.

Quand building-inferencesh-apps est-elle adaptée ?

Cette skill est particulièrement adaptée lorsque :

• Vous démarrez une nouvelle app sur inference.sh et souhaitez suivre le workflow de référence
• Vous avez déjà installé le CLI infsh ou prévoyez de l’installer et de tout piloter depuis la ligne de commande
• Vous voulez créer des backends Python ou Node.js, y compris des wrappers autour d’APIs ou de modèles externes

Elle sera moins utile si :

• Vous n’utilisez pas inference.sh comme cible de déploiement
• Vous avez uniquement besoin de code côté client ou de patterns d’interface front-end
• Vous attendez une interface graphique point-and-click plutôt que des workflows pilotés par CLI

Si votre objectif principal est un déploiement backend et API stable et automatisé sur inference.sh, building-inferencesh-apps est bien alignée avec vos besoins.

Comment utiliser la skill

1. Installer le CLI inference.sh

La skill building-inferencesh-apps part du principe que vous utilisez le CLI officiel inference.sh, infsh, pour toutes les opérations liées aux apps.

Installer le CLI

Lancez le script d’installation depuis votre terminal :

curl -fsSL https://cli.inference.sh | sh

Après l’installation, mettez-le à jour vers la dernière version si nécessaire :

infsh update

Gardez le CLI à jour pour que le scaffolding et le comportement de déploiement de vos apps restent conformes aux attentes actuelles de la plateforme.

2. Ajouter la skill building-inferencesh-apps

Installez cette skill dans l’environnement de votre agent afin qu’il puisse s’appuyer sur les règles et recommandations organisées :

npx skills add https://github.com/inferen-sh/skills --skill building-apps

Cela relie votre agent au contenu sdk/building-apps du dépôt inferen-sh/skills, en exposant les règles de construction d’apps comme une capacité réutilisable.

3. Scaffolder les apps avec infsh app init (jamais à la main)

La règle centrale de building-inferencesh-apps est que toutes les apps doivent être scaffoldées avec le CLI. La plateforme s’attend à certains fichiers et à une certaine structure que le CLI génère pour vous.

Règle de scaffolding obligatoire

• Ne créez pas manuellement :
  • inf.yml
  • inference.py
  • inference.js
  • __init__.py
  • package.json
  • Les répertoires d’app
• Ignorez toute documentation locale ou fichier de structure qui recommande un scaffolding manuel (par exemple PROVIDER_STRUCTURE.md).

À la place, utilisez toujours :

infsh app init

Le CLI créera la bonne structure de répertoires et les fichiers de base requis pour une app inference.sh valide, que vous cibliez Python ou Node.js.

4. Travailler depuis le bon répertoire d’app

La skill building-inferencesh-apps insiste sur le fait que le répertoire courant du shell est critique pour chaque commande infsh :

• Faites toujours un cd dans le répertoire de votre app avant d’exécuter des commandes infsh comme init, deploy ou test.
• Le répertoire courant du shell ne persiste pas entre plusieurs appels d’outils, ce qui signifie que toute automatisation ou tout agent utilisant cette skill doit changer de répertoire de manière explicite à chaque fois.

Pattern typique :

cd path/to/your-app
infsh app deploy

Si vous sautez le cd, vous risquez de déployer ou de tester la mauvaise app, ou de voir des erreurs déroutantes parce que inf.yml n’est pas trouvé dans le répertoire courant.

5. Définir correctement les outputs dans les apps Python

Pour les apps Python qui incluent des métadonnées dans leurs outputs, building-inferencesh-apps souligne une règle critique :

• Si votre classe d’output utilise output_meta, elle doit étendre BaseAppOutput.
• Ne pas étendre BaseModel pour ces outputs.

Si vous étendez BaseModel, tous les champs output_meta seront silencieusement supprimés de la réponse. L’utilisation de BaseAppOutput garantit que les données et les métadonnées associées sont conservées et correctement renvoyées par le runtime.

6. Ajouter des logs dans run() pour l’observabilité

La skill recommande d’inclure des logs par défaut dans la méthode run() de votre app :

• Utilisez des appels self.logger.info(...) dans run() pour capturer les événements clés, les temps d’exécution et des résumés de requêtes/réponses.
• C’est particulièrement important pour les apps qui wrapent des APIs, où le travail principal est effectué par des services distants plutôt que par votre propre code.

Exemples de cas où les logs sont utiles :

• Mesurer la latence des appels à des modèles en amont
• Enregistrer quelles endpoints d’API externes ont été sollicitées
• Suivre la taille des requêtes ou des paramètres pertinents pour l’utilisation GPU/VRAM

Des logs réguliers rendent le diagnostic des problèmes de performance beaucoup plus simple et permettent de comprendre comment votre backend inference.sh se comporte en production.

7. Flux typique de développement et de déploiement

Même si l’extrait du dépôt est centré sur des règles, vous pouvez utiliser building-inferencesh-apps comme checklist mentale pour un workflow type :

1. Installer le CLI infsh.
2. Initialiser une nouvelle app avec infsh app init (Python ou Node.js).
3. Changer de répertoire vers le dossier de l’app nouvellement créée avant toute autre commande.
4. Implémenter la logique de votre app dans les fichiers générés, en respectant la règle BaseAppOutput pour les outputs avec output_meta et en ajoutant des logs via self.logger.info(...).
5. Configurer les ressources (comme le GPU/VRAM et les intégrations) en utilisant la configuration générée par le CLI, plutôt qu’en créant inf.yml manuellement.
6. Déployer et tester en utilisant les commandes infsh depuis le répertoire de l’app.

Dès que vous étendez ou automatisez ce flux, appliquez les mêmes règles : reposez-vous sur le CLI pour la structure, faites respecter le bon répertoire de travail, et gardez des patterns d’output et de logging cohérents.

FAQ

building-inferencesh-apps est-elle uniquement pour Python ?

Non. La skill building-inferencesh-apps couvre les applications inference.sh qui peuvent être écrites en Python ou Node.js. Le même CLI (infsh app init) sert au scaffolding dans les deux cas, et les recommandations sur la gestion des répertoires et l’usage du CLI s’appliquent aux deux langages.

Pourquoi ne puis-je pas créer inf.yml ou inference.py manuellement ?

La plateforme inference.sh impose une structure précise, des champs spécifiques et des relations définies entre les fichiers. Créer manuellement inf.yml, inference.py, inference.js, package.json ou les répertoires de l’app peut entraîner des mauvaises configurations difficiles à détecter. La skill building-inferencesh-apps impose l’utilisation de infsh app init, car le CLI génère une structure valide et à jour, conforme aux exigences actuelles de la plateforme.

Que se passe-t-il si j’oublie de faire cd dans le répertoire de l’app ?

Si vous exécutez des commandes infsh depuis le mauvais répertoire, le CLI peut :

• Opérer sur la mauvaise app
• Ne pas trouver inf.yml ou les fichiers clés de l’app
• Produire des erreurs déroutantes ou déployer une autre app que celle attendue

Pour éviter cela, la skill building-inferencesh-apps considère cd path/to/app comme une étape obligatoire avant chaque commande infsh, en particulier dans les workflows scriptés ou pilotés par des agents.

Comment structurer les classes d’output qui utilisent output_meta ?

Pour les apps Python :

• Toute classe d’output qui inclut output_meta doit étendre BaseAppOutput.
• Évitez d’utiliser BaseModel pour ces outputs, car cela supprimera silencieusement output_meta de la réponse.

En respectant cette règle, vous vous assurez que les métadonnées sont conservées et renvoyées correctement par inference.sh.

Pourquoi la skill met-elle autant l’accent sur les logs dans run() ?

Building-inferencesh-apps insiste sur les logs parce que de nombreuses apps inference.sh sont des wrappers d’API ou dépendent fortement de services externes. Sans logs via self.logger.info(...) dans run(), il devient difficile de :

• Diagnostiquer les problèmes de latence et de performance
• Comprendre les erreurs provenant des APIs en amont
• Faire le lien entre requêtes et réponses lors du debug

Ajouter par défaut quelques logs au niveau info vous donne une bonne visibilité sur ce que fait votre backend à chaque requête.

Est-ce que la skill explique en détail les réglages GPU et VRAM ?

La skill est centrée sur le workflow et les règles du développement d’apps sur inference.sh : scaffolding via le CLI, gestion des répertoires, exigences sur les classes d’output et logging. Elle est pensée pour être utilisée lorsque vous réfléchissez aux ressources de l’app comme le GPU, la VRAM, les secrets et les intégrations, mais l’extrait du dépôt se concentre davantage sur les règles que sur des exemples de configuration détaillés. Pour une configuration précise des ressources, combinez les recommandations de workflow de cette skill avec la documentation officielle inference.sh.

Quand ne pas utiliser building-inferencesh-apps ?

Cette skill n’est pas adaptée si :

• Vous ne déployez pas sur inference.sh
• Vous recherchez des frameworks front-end ou UI plutôt que des conseils sur les backends
• Vous préférez créer les fichiers et répertoires manuellement plutôt que de suivre des workflows pilotés par CLI

Dans les autres cas — en particulier pour construire des backends de type API sur inference.sh — building-inferencesh-apps fournit un pattern fiable et centré sur le CLI à suivre.