imageCLI — Roxabi

01

Ce que c'est

Générer des images en local, c'est aucun coût d'API, aucune limite de débit, et un contrôle total sur les prompts et les sorties. Mais câbler HuggingFace Diffusers — quantization, budget VRAM, vérifications préalables, libération mémoire après — c'est le même boilerplate à chaque fois. imageCLI réduit tout ça à une commande. Donne-lui un prompt texte ou un fichier Markdown et obtiens une image ; change de backend avec -e ; traite un dossier entier en lot ; ou importe-la comme bibliothèque Python.

C'est le frère « pixels » de la voix de voiceCLI et des tokens de llmCLI — local d'abord, résident sur GPU, la même forme opérationnelle.

Le contrat durable, c'est le prompt, pas le moteur. Écris-le une fois ; passe de FLUX.2 à SD3.5 d'un seul flag.

02

Une commande, tous les moteurs

Une petite flotte de backends, chacun réglé pour un compromis différent entre vitesse, VRAM et fidélité — et chacun n'est qu'une valeur de -e. Les variantes PuLID ajoutent un verrou d'identité de visage à partir d'une image de référence.

Moteur	Idéal pour	VRAM
`flux2-klein`	Le défaut rapide — FP8 quanto, le chemin le plus rapide.	~8 Go
`flux1-dev`	Qualité maximale, prompts plus longs.	~10 Go
`flux1-schnell`	Le plus rapide, quatre étapes, libre (Apache 2.0).	~10 Go
`pulid-flux1-dev`	Verrou d'identité de visage depuis une image de référence.	~10 Go
`sd35`	Sans CFG, photos réalistes.	~14 Go

Les variantes NVFP4 visent les cartes Blackwell pour un cran de vitesse supplémentaire. La matrice complète — neuf moteurs avec étapes, vitesse et notes de quantization — vit dans le README du repo.

03

D'un prompt à une image

Un prompt — texte brut ou fichier .md avec frontmatter — est dispatché vers le moteur choisi. Le moteur charge son modèle à la demande au premier appel, lance les vérifications VRAM et RAM préalables, génère, sauvegarde l'image, puis libère le GPU. Rien ne reste résident plus longtemps qu'il ne faut.

Dispatch — route le prompt (ou chaque fichier d'un lot) vers son moteur.
Préflight — charge le modèle à la demande, vérifie VRAM/RAM avant de s'engager.
Génération — exécute les étapes de diffusion à la résolution configurée.
Sauvegarde & libération — écrit l'image, relâche la mémoire GPU.

imagecli batch applique le même flux à chaque prompt d'un dossier ; imagecli info vérifie l'installation et la détection GPU avant que tu n'y consacres un téléchargement de modèle.

04

Multi-hôtes via NATS

Le GPU et l'appelant n'ont pas à être la même machine. imageCLI embarque un satellite NATS : le modèle se charge une fois sur un serveur GPU, et une requête depuis n'importe où sur le bus renvoie une image générée — PUT vers un blob store multi-hôtes, pour qu'une machine sans GPU ne touche jamais les poids.

C'est ainsi qu'imageCLI se branche sur roxabi-factory : il s'enregistre comme worker image exposant image.generate, et n'importe quel agent de la factory rend une image en publiant une requête — le transport invisible pour la boucle de raisonnement du modèle.

05

Lance-le

Prérequis : Python 3.12, un GPU CUDA (16 Go recommandés ; 10 Go pour les moteurs fp8), et le gestionnaire de paquets uv. Les grosses deps moteur sont optionnelles : tu n'installes que ce que tu utilises. Les modèles se téléchargent automatiquement à la première utilisation.

uv tool install .                      # installation (index cu128 depuis pyproject)
imagecli info                          # vérifie installation + GPU
imagecli generate "a cat in space"     # génère depuis n'importe où
imagecli generate prompt.md -e flux1-dev
imagecli batch images/prompts_in/      # traite un dossier en lot

Moteurs, dispatcher et satellite NATS sont tous en accès ouvert.

Le repo · github.com/Roxabi/imageCLI →