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.
