Le problème
La segmentation ONNX et les bibliothèques natives conservaient de la mémoire entre les tâches, rendant un worker long-running risqué sur un petit serveur.
Retour aux projets
03Dossier de mission projet
Infrastructure de traitement d’image · 2026
Picnexa
Une plateforme stateless de compression, conversion et suppression d'arrière-plan par IA, optimisée pour un serveur ARM limité.
- Rôle
- Développeur full-stack & responsable déploiement
- Statut
- Déployé en production
Aperçu du projet
- Rôle
- Développeur full-stack & responsable déploiement
- Statut
- Déployé en production
- Plateforme
- Frontend web et API ARM
- Déploiement
- Vercel + Docker sur Oracle Cloud
- Périmètre
- Compression, conversion et détourage IA
- Dépôt
- Aucun dépôt public
La solution
Chaque suppression d'arrière-plan s'exécute dans un processus jetable. Le système récupère la mémoire native, tandis que files, limites, validation et stockage temporaire contrôlent la charge.
Système technique
Composants et frontières vérifiés dans le code source et la documentation du projet.
- 01Frontend Next.js
Interface Vercel et uploads directs
- 02Frontière Caddy
HTTPS et CORS exact-origin
- 03API Fastify
Validation, rate limits et file bornée
- 04Worker IA jetable
Un processus ONNX par détourage
- 05Stockage temporaire
Fichiers par requête supprimés après usage
12.53 MPimage IA testée
~1.86 GiBpic du worker
0 Bswap utilisée
Fonctionnalités
Workers IA jetables et isolés
Validation défensive des fichiers et pixels
File bornée et stockage temporaire
Docker, Caddy, HTTPS, métriques et logs structurés
Parcours produit02
Décisions d'ingénierie
La mémoire native n'est pas le heap JS
ONNX et Sharp conservaient des allocations natives entre les tâches, hors contrôle du heap JavaScript.
- Décision
- Exécuter chaque détourage dans un processus enfant jetable, terminé après succès ou timeout.
- Effet technique
- Le système récupère la mémoire native et l’API revient à son niveau d’attente.
Qualité sous contraintes strictes
La segmentation de meilleure qualité est en concurrence avec un OCPU et une mémoire conteneur bornée.
- Décision
- Ajuster ensemble modèle, dimensions, concurrence, file, caches Sharp et limites du conteneur.
- Effet technique
- Une entrée vérifiée de 12,53 MP passe sous la limite de 3 GiB sans swap.
Carte de responsabilité
Développeur full-stack & responsable déploiement
- 01
Architecture de déploiement frontend/API
- 02
Traitement, validation, files et isolation des workers
- 03
Conteneurisation et déploiement ARM
Résultat
Le benchmark a traité une image 3072 × 4080 avec le modèle haute qualité sous une limite conteneur de 3 GiB, sans swap et avec retour de la mémoire au niveau initial.
Arij Maison
Storefront e-commerce premium