Nouveau src/ollama-tech-step-poc.ts : même tâche/SYSTEM_PROMPT (exporté
depuis llm-tech-step-poc.ts et réutilisé tel quel) que le moteur
node-llama-cpp, mais via Ollama — une implémentation architecturalement
différente plutôt qu'une redite :
- Ollama tourne comme serveur HTTP local séparé (ollama serve), pas comme
binding natif dans ce process — le paquet npm ollama n'a aucune
dépendance native (rien à compiler à l'install, contrairement à
node-llama-cpp).
- Modèle géré par Ollama lui-même (ollama.pull(), cache dans
~/.ollama/models), pas par ce projet — progression de pull journalisée
palier par palier plutôt que silencieuse.
- Schéma JSON imposé via `format` (JSON Schema standard, `type:
["string","null"]` pour un champ nullable) — plus simple que le détour
`oneOf` qu'exige la grammaire GBNF de node-llama-cpp.
- initialize() échoue avec un message explicite si le serveur Ollama n'est
pas joignable, plutôt que l'erreur fetch brute.
- Caveat documenté en tête de fichier et rappelé avant le récapitulatif :
la colonne RSS du harness ne mesure rien d'utile ici, l'inférence tourne
dans le process ollama serve, pas dans ce script.
OllamaStepAnalyzer.dispose() décharge le modèle du serveur (keep_alive: 0,
best effort). Env vars OLLAMA_TECH_STEP_MODEL/OLLAMA_TECH_STEP_HOST,
scripts pnpm bench:ollama.
Vérifié en conditions réelles (Ollama tournait déjà dans l'environnement) :
pull + inférence structurée + parsing JSON fonctionnels, latence nettement
inférieure à node-llama-cpp sur les mêmes phrases (748-1260 ms vs 3-13 s),
delta RSS confirmé proche de zéro/bruit comme attendu.
README mis à jour (4 moteurs, section Ollama avec tableau comparatif
architectural, limites).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nicolas
f5f30923d0