FreeBSD pour l’inférence LLM embarquée : un non-sujet TL;DR Sur le même CPU (AMD Ryzen 5 3600, Zen 2), le même tag llama.cpp, le même modèle (Qwen 2.5 3B Q4_K_M), le même nombre de threads — Linux Debian 12 et FreeBSD 14.4 produisent des t/s quasi identiques :
OS tag llama.cpp t=6 pp256 t=6 tg64 Linux Debian 12 b9165 90.6 17.1 FreeBSD 14.4 b9000 90.5 16.7 Différence < 1 % sur le pp, ~2 % sur le tg — dans la marge d’erreur des mesures successives.
Benchmarker llama.cpp sur CPU : ce qu’on apprend en 50 runs Résumé Exécutif Pour les besoins d’un PoC SOC agentique CPU-only, j’ai fait tourner ~50 benchmarks llama-bench sur 4 plateformes différentes (un Ryzen 5 3600 bare-metal, sa contrepartie FreeBSD, un EPYC Milan dedicated chez Hetzner, un Xeon Skylake shared chez Hetzner). Modèle de référence : Qwen 2.5 3B Q4_K_M et son grand frère 7B. Builds comparés : llama.cpp (tag b3813 et b9165) et son fork agressif ik_llama.
tg/s = MB/s : la formule empirique pour planifier la capacité d’un cluster LLM CPU TL;DR Sur 4 plateformes CPU x86 — un Ryzen desktop, une VM, un EPYC dedicated, un Xeon shared — la bande passante mémoire (mesurée par mbw) prédit le throughput de génération LLM (tg64 sur Qwen 3B Q4_K_M) avec une précision de ±25 %. Le ratio empirique est ~490 MB de bande passante par token/s.
Conséquence pratique : sur n’importe quelle machine, 5 secondes de mbw -t 0 -n 5 256 suffisent à estimer le tg/s maximum atteignable, sans installer llama.
opnsense-ai-firewall : embarquer un LLM dans le firewall, et mesurer pourquoi c’est une mauvaise idée en production Résumé Exécutif (Management Summary) La question expérimentale : est-il techniquement possible de faire tourner un assistant LLM à l’intérieur d’une VM OPNsense, capable de comprendre une intent administrateur en langage naturel et de la traduire en appels API REST OPNsense — sans aucun sidecar, sans aucun trafic LLM en clair sur le réseau, sans dépendance à un service externe ?
SOC Agentique — asp-forge · N°1
Cet article ouvre une série de trois consacrée à asp-forge, un lab de Security Operations Center agentique entièrement auto-hébergé, conçu comme banc d’essai pour évaluer l’apport concret des modèles de langage dans le triage d’alertes. Cible : DevSecOps et analystes SOC qui s’interrogent sur l’industrialisation des LLM dans une chaîne de réponse aux incidents, sans dépendre d’un fournisseur cloud.
Le problème : la fatigue d’alertes ne se résout pas par plus d’analystes Tout SOC un peu sérieux remonte plusieurs centaines à plusieurs milliers d’événements par jour depuis ses outils — Wazuh sur les serveurs, T-Pot sur les honeypots exposés, les EDR sur les postes, les WAF en bordure.
SOC Agentique — asp-forge · N°2
Deuxième volet de la série asp-forge. Après les choix structurants posés dans le premier article, on entre dans le cœur du système : comment plusieurs agents LLM collaborent sur une même alerte, et pourquoi cette collaboration est organisée en cascade plutôt qu’en agent unique.
Pourquoi une cascade et pas un seul agent ? L’instinct premier, quand on dispose d’un LLM 3 milliards de paramètres qui raisonne correctement, est de lui confier l’intégralité de la décision : alerte en entrée, verdict en sortie.
SOC Agentique — asp-forge · N°3
Troisième et dernier volet de la série asp-forge. Après l’architecture (article 1) et le pipeline cascade (article 2), il reste la question qui intéresse vraiment l’ingénieur : qu’est-ce qui s’est mal passé, qu’est-ce qui a surpris, et qu’est-ce qu’on garde pour la suite ? Pas de success story édulcorée — on partage les pièges réels.
Bug LoRA dynamique : une discipline de version pinning Premier piège qui a coûté plusieurs jours de débogage.
Suite directe du bilan v3.16. Ce cycle couvre trois corpus successifs (v3.17, v3.18, v3.19) et trois problèmes distincts : améliorer URL_URI qui plafonnait à 80.9%, corriger SCHEDULED_TASK à 0%, et isoler un nouveau label KEY_FINGERPRINT du label FILE_HASH.
Corpus v3.17 — Diagnostic URL_URI Analyse des faux négatifs L’article précédent concluait sur URL_URI à 80.9% avec 66 FN. Le script analyze_fn.py donnait :
Total FN URL_URI : 66 Labels prédits à la place de URL_URI : — 66 (100.
Suite directe du bilan v3.11. Ce cycle a trois étapes : migration de l’architecture tok2vec vers un transformer, diagnostic systématique des faux négatifs par label, puis correction ciblée des causes racines identifiées. Résultat : F1 global 88% → 95,9%.
Contexte v3.12→v3.14 — Entre v3.11 et v3.14, trois cycles d’amélioration ont produit des résultats décevants : ajout de 500 exemples synthétiques EC2 pour HOSTNAME (+2 points de recall), tentatives de rééquilibrage des labels PID et MAC_ADDRESS.
Suite directe du bilan v3.1. L’évaluation par label avait identifié deux labels critiquement faibles : PROCESS_NAME (F1=61.8%) et PROTOCOL (F1=50%). Cause : pas assez de logs exposant ces entités dans le corpus d’entraînement. Ce cycle corrige ça en intégrant deux nouveaux datasets open source.
Nouveaux datasets CTU-13 — Stratosphere IPS Le dataset CTU-13 contient des captures réseau binetflow (CSV) avec des flows légitimes et malveillants étiquetés. Format :
SrcAddr,DstAddr,Proto,Sport,Dport,State,TotPkts,TotBytes,...,Label 147.32.84.59,62.107.124.67,tcp,25857,7726,CON,6,396,...,flow=Background Un script de conversion (extract_ctu13_flows.
AnonyNER est le composant NER du projet Victor — un modèle spaCy entraîné spécifiquement sur des entités sensibles de logs de sécurité. La version 3.1 marque un changement d’échelle significatif : passage de 12 à 30 labels, corpus multiplié par 8, et pour la première fois une évaluation complète par label sur un jeu de test indépendant.
Cet article est un bilan technique, pas un tutoriel. L’objectif est de montrer où en est le modèle, ce qui fonctionne réellement, et ce qui reste à faire pour une utilisation en production.
Avant d’envoyer des logs à un éditeur, de les injecter dans un LLM externe ou de les archiver conformément au RGPD, une question se pose inévitablement : ces fichiers contiennent-ils des informations qui exposent mon infrastructure ?
Les logs de sécurité sont denses en données sensibles — adresses IP internes, noms d’hôtes, identifiants de comptes de service, clés API, adresses MAC. Et contrairement aux bases de données ou aux formulaires, leur format n’est jamais tout à fait uniforme : chaque équipement, chaque version de daemon, chaque intégration produit ses propres variantes.
