DEV Community

Mathieu Ledru
Mathieu Ledru

Posted on

⚙️ NoLife Models - Vers une infrastructure locale des runtimes IA avec Symfony

#ai #infrastructure #llm #php

Pendant des années, utiliser un modèle IA voulait dire appeler une API distante.

Le workflow était relativement simple :

  • envoyer un prompt
  • attendre une réponse
  • afficher du texte.

Mais depuis quelques mois, un nouvel écosystème est en train d’émerger autour des modèles locaux.

Un écosystème composé de :

  • catalogues de modèles
  • runtimes locaux
  • systèmes de benchmark
  • exports structurés
  • observabilité
  • gouvernance
  • orchestration.

Et progressivement, l’IA commence à ressembler davantage à une infrastructure logicielle qu’à un simple chatbot.

C’est dans ce contexte qu’est né *NoLife Models- :

Un projet Symfony 8 conçu pour explorer cette nouvelle couche d’infrastructure locale autour des modèles IA.

Le problème : les modèles locaux explosent

Aujourd’hui, il existe une quantité gigantesque de modèles :

  • Qwen
  • Llama
  • Granite
  • Gemma
  • Mistral
  • Phi
  • DeepSeek
  • etc.

Et chacun possède :

  • des tailles différentes
  • des quantizations différentes
  • des capacités différentes
  • des context windows différents
  • des comportements différents.

Le problème n’est donc plus :

“Comment utiliser un modèle ?”

Mais plutôt :

“Quel modèle utiliser, dans quel contexte, sur quel runtime, avec quelles performances ?”

models.dev : vers un catalogue standardisé des modèles

Un projet particulièrement intéressant dans cette évolution est :

L’idée est simple :
transformer les modèles en objets structurés exploitables par des outils.

On ne parle plus seulement d’un “nom de modèle”.

On parle désormais de :

  • modalities
  • reasoning flags
  • pricing
  • capabilities
  • context windows
  • providers
  • compatibilité runtime.

Cela ressemble fortement à ce qu’a représenté Docker Hub pour les containers.

modles : explorer les modèles comme des artefacts logiciels

Autour de cette idée émergent aussi des interfaces d’exploration comme :

Le sujet devient alors :

  • filtrer
  • comparer
  • explorer
  • comprendre les capacités réelles des modèles.

Exactement comme nous avons commencé à le faire avec :

  • containers
  • packages
  • runtimes cloud
  • images OCI.

Docker ecosystem ↔ AI runtime ecosystem

L’analogie avec Docker devient de plus en plus pertinente.

Docker ecosystem AI runtime ecosystem
Docker Hub models.dev
Images GGUF / model weights
dockerd Ollama / Kronk / vLLM
Kubernetes agent orchestration
Observability inference tracing
OCI runtime runtime abstraction layers

Le sujet n’est donc plus seulement :

“faire tourner un LLM”.

Le sujet devient :

“gouverner une infrastructure de modèles.”

Ollama : le runtime HTTP local

Le runtime qui a probablement démocratisé cette approche est :

Ollama expose les modèles comme des services HTTP locaux.

Quelques endpoints suffisent :

/api/tags
/api/generate
/api/chat
Enter fullscreen mode Exit fullscreen mode

Et immédiatement :

  • n’importe quelle application
  • n’importe quel langage
  • n’importe quel orchestrateur

peut commencer à interagir avec des modèles locaux.

Cette simplicité est extrêmement puissante.

NoLife Models

C’est précisément ce constat qui a motivé la création de :

NoLife Models est une application locale construite avec :

  • Symfony 8
  • Symfony UX
  • Twig
  • Live Components
  • Turbo
  • HttpClient

Le projet permet :

  • d’explorer un catalogue de modèles
  • de lister les modèles Ollama installés
  • de comparer plusieurs modèles
  • de lancer des benchmarks
  • d’exporter les résultats.

Une architecture orientée runtime

Le point central du projet est probablement cette abstraction :

interface LocalModelRuntimeInterface
{
    /*- @return list<LocalModel> */
    public function listLocalModels(): array

    public function generate(
        GeneratePromptCommand $command
    ): ModelInferenceResult
}
Enter fullscreen mode Exit fullscreen mode

Cette décision transforme complètement l’architecture.

Le domaine ne dépend plus :

  • d’Ollama
  • d’OpenAI
  • d’un provider particulier.

Le domaine dépend uniquement :

  • d’un contrat d’inférence.

Et cela ouvre immédiatement la voie vers :

  • LM Studio
  • vLLM
  • OpenAI-compatible runtimes
  • embedded runtimes
  • futurs adapters.

Symfony 8 + Hexagonal Architecture

Le projet suit une approche DDD / hexagonale.

UserInterface
    ↓
Application
    ↓
Domain ports
    ↓
Infrastructure adapters
Enter fullscreen mode Exit fullscreen mode

Les responsabilités sont séparées :

Layer Role
Domain contracts + models
Application orchestration
Infrastructure Ollama adapter, exports
UserInterface Symfony UX + controllers

Le runtime devient alors une simple implémentation d’interface.

Comparer des modèles localement

L’un des éléments les plus intéressants du projet est le moteur de comparaison.

Même prompt.
Même runtime surface.
Même configuration.

Mais plusieurs modèles.

Cela permet de comparer :

  • latence
  • temps de chargement
  • vitesse de génération
  • raisonnement
  • qualité des réponses
  • hallucinations
  • OCR
  • vision.

Le plus important :

les benchmarks mathématiques seuls ne suffisent pas.

La qualité reste une lecture humaine.

Benchmarks et reproductibilité

Le projet permet également de lancer des benchmark suites.

L’idée :

  • exécuter plusieurs prompts
  • sur plusieurs modèles
  • avec des paramètres contrôlés
  • et produire des résultats structurés.

Cela rapproche progressivement le projet :

  • d’un système d’évaluation
  • d’un observatoire runtime
  • d’une couche d’observabilité.

Exports et gouvernance

Les exports jouent un rôle très important :

  • JSON
  • CSV
  • Markdown

Parce qu’une inférence sans artifact devient difficile à auditer.

Les exports permettent :

  • de tracer
  • reproduire
  • comparer
  • archiver
  • analyser.

Et c’est précisément à ce moment que l’on quitte le simple “prompt engineering”.

Kronk : une autre direction

Un autre projet particulièrement intéressant est :

Kronk ne doit pas être vu comme :

“un meilleur Ollama”.

La philosophie est différente.

Ollama expose les modèles comme des services HTTP locaux.

Kronk pousse l’inférence directement dans le processus applicatif.

L’inférence devient alors :

  • embarquée
  • programmable
  • intégrée au runtime de l’application.

Avec :

  • GGUF
  • llama.cpp
  • Yzma
  • streaming
  • APIs compatibles OpenAI.

Le modèle cesse progressivement d’être un simple endpoint HTTP.

Il devient :

une dépendance logicielle.

Vers une infrastructure IA locale

Le plus intéressant dans cette évolution,
c’est probablement que l’on voit réapparaître les mêmes patterns que dans le cloud :

  • catalogues
  • runtimes
  • observabilité
  • orchestration
  • policies
  • exports
  • traces
  • gouvernance.

Mais appliqués cette fois :
à l’inférence locale.

Conclusion

NoLife Models n’est pas conçu comme :

  • un chatbot
  • un wrapper OpenAI
  • une simple UI Ollama.

Le projet explore plutôt une question plus large :

À quoi ressemble une infrastructure locale de runtimes IA ?

Avec :

  • catalogues
  • runtimes
  • benchmarks
  • exports
  • observabilité
  • abstractions runtime.

Nous sommes probablement encore au début de cet écosystème.

Mais les primitives commencent déjà à apparaître.

Et cela devient extrêmement intéressant à observer.

Depots github

Sources

🔗 Liens de la semaine

🎶 Music credit

@fifaworldcup A little footwork from New York New Jersey. ⚽ #FIFAWorldCup ♬ sonido original - FIFA World Cup
  • Chinese students welcome President Trump to the Great Hall of the People in Beijing 💐 🎥: @MargoMartin47

Chinese students welcome President Trump to the Great Hall of the People in Beijing 💐

🎥: @MargoMartin47 pic.twitter.com/wChlpVnphh

— Rapid Response 47 (@RapidResponse47) May 14, 2026

Top comments (0)