TL;DR J’ai dépensé 3,10 € de Claude Sonnet 4.6 (via OpenRouter) pour générer un corpus de distillation de 293 paires destiné au fine-tune d’un LoRA SOC. Sur ces 293 paires, 94 % étaient du bruit ambient SSH (sessions PAM, sshd auth success) et seulement 3 % du signal d’attaque réel (FIM sur fichiers sensibles). Le piège est subtil : plus l’attaquant qu’on utilise pour générer le corpus est scriptable (SSH-driven), plus il génère lui-même du bruit qui contamine le dataset.
Inférence LLM CPU · N°1
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.
Inférence LLM CPU · N°2
tg/s = MB/s : la formule empirique pour planifier la capacité d’un cluster LLM CPU TL;DR Sur 5 plateformes CPU (x86 AMD, x86 Intel, ARM Ampere Altra), 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) à ±10 % près sur x86 et à ±25 % près si on inclut ARM. Le ratio empirique est ~470 MB par token/s sur x86, et ~650 MB par token/s sur ARM Ampere Altra — l’ARM est moins efficient par MB de BW pour des raisons développées plus loin.
Inférence LLM CPU · N°3
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.
Inférence LLM CPU · N°4
Quatre challengers pour llama.cpp sur CPU : ce qui passe et ce qui casse TL;DR Après les 50 benchs de llama.cpp et ik_llama.cpp du premier article de cette série, une question logique : est-ce qu’un autre moteur CPU pourrait faire mieux que llama.cpp HEAD sur mon Ryzen 5 3600 ? J’ai testé quatre candidats régulièrement cités :
Moteur Promesse Résultat sur Ryzen Zen 2 Verdict vLLM CPU Continuous batching multi-request Échec d’install (3 tentatives) À reprendre via Docker CTranslate2 Mature, INT8 historique -46 % vs 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.
victor_le_nettoyeur
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.
victor_le_nettoyeur
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.
victor_le_nettoyeur
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.
