zazaorg/harpy-9b

Harpy 9B

Harpy est un affinage LoRA de teddy19032/Ornith-1.5-9B-heretic (licence MIT), entraîné sur un corpus red team / opsec et sur la discipline d'usage des outils.

• Base : teddy19032/Ornith-1.5-9B-heretic, révision 4b1cf4847e73, licence MIT
• Gabarit : celui d'origine (tools / thinking / completion), contexte déclaré 262 144
• Usage : llama-server --jinja, ollama create -f Modelfile, ou tout moteur llama.cpp récent
• Architecture : qwen35, 32 blocs, 427 tenseurs, aucun tenseur MTP
• Moteur vérifié : llama.cpp build 11382 (04/10/2026) charge et sert ce modèle correctement, sur GPU comme sur CPU. Toute version au moins aussi récente convient.

Versions

Version	Date	Adaptateur	Profil mesuré
v3.1	19/10/2026	identique à v3 (mêmes poids, nom interne corrigé)	aucun réentraînement : seule la métadonnée general.name change
v3	18/10/2026	checkpoints/s6c-final/adaptateur (4434135f…, r=32, α=64)	outils 43-44 / 50, verbosité médiane 469 car.
v2	17/10/2026	checkpoints/s3-step-001232/adaptateur	outils 37-38 / 50, verbosité médiane 427 car.
v1	16/10/2026	idem v2, en-tête défectueux	remplacée le 17/10 — ne pas utiliser

Les chiffres des deux versions actuelles ont été mesurés le 18/10 sur le même serveur, la même batterie et le même gabarit, en trois passes chacune (échantillonnage à 0,6). Ils sont donc comparables entre eux, mais pas aux chiffres publiés lors des sessions antérieures : le protocole de mesure dérive avec la version du moteur (voir « Sur la reproductibilité »).

Récupérer une version précise :

huggingface-cli download zazaorg/harpy-9b --revision v3.1 harpy-Q4_K_M.gguf
huggingface-cli download zazaorg/harpy-9b --revision v3 harpy-Q4_K_M.gguf
huggingface-cli download zazaorg/harpy-9b --revision v2 harpy-Q4_K_M.gguf
huggingface-cli download zazaorg/harpy-9b --revision v3 harpy-Q4_K_M.gguf

Fichiers (v3)

Fichier	SHA-256 (v3.1, par défaut)	SHA-256 (v3, conservée)
harpy-Q4_K_M.gguf	3def58817cf5de1e18377e2e563b879a5014c755ae2fb57ecf10e7875675a6cf	5350cfa1b84dd7dda2b0b551ac5f37718dab0436d691e60d644e353957ff280c
harpy-Q6_K.gguf	af6bfc4b572ebf12906a88d5dd90305b374a6f2fbc9e3a578a1db4a2b66f681c	5911e5a0fe4b6df6f34407a7192027323e29409733500a6efda2642e856a47b6
harpy-Q8_0.gguf	0f88dd07fb71ef41425fc58041dbdc237f2485c89d0c712e2110e4beb6f98a54	352990ca62d109146e779b5441481abaf84135659e93c834a1e56d91662793d8

Les deux jeux de fichiers ne diffèrent que par un champ de métadonnée : les poids sont identiques octet pour octet (vérifié tenseur par tenseur). v3.1 corrige le nom interne, rien d'autre.

Le fichier f16 d'origine (17 920 696 672 o, 682c43b0…) n'est pas publié : les trois quantifications suffisent à l'usage, et il se régénère à partir de l'adaptateur.

Ce que le modèle fait

• Discipline d'outils : il appelle l'outil quand on le lui demande explicitement, n'invente pas d'appel quand la question est purement documentaire, respecte un périmètre d'autorisation déclaré, et ne réclame pas d'accès hors de ce périmètre. Sur la batterie interne de 50 épreuves réparties en cinq familles (action explicite, action implicite, abstention, périmètre, refus), v3 obtient 43 à 44 réussites. Une batterie indépendante, sur une autre machine, obtient 10/10 deux fois de suite sur ses cinq sous-tests d'appel d'outils.
• Contexte long : récupération d'information vérifiée à 22 k et 44 k jetons de prompt, sur deux plateformes différentes.
• Sécurité défensive : refuse les demandes de code opérationnel nuisibles tout en restant utile sur l'analyse défensive et la remédiation.

La longueur des réponses dépend du mode de raisonnement

C'est la constatation la plus importante pour qui déploie ce modèle, et elle corrige une version antérieure de cette fiche.

Le modèle hérite d'un gabarit avec bloc de raisonnement. Selon que ce bloc est activé ou non, la longueur des réponses change d'un facteur 3 à 5 :

Contexte de mesure	Raisonnement désactivé	Raisonnement activé
Batterie interne, 40 questions figées	médiane 469 car.	non mesuré
Batterie indépendante, invites difficiles	médiane ~281 car.	500 à 2 000+ car.
10 questions de connaissance, profils de service	médiane 442 car.	médiane 1 065 car.

Sur ces 10 questions, le rapport entre les deux modes est de 2,41×. Mais la distribution n'est pas un simple décalage : en mode raisonnement, 3 réponses sur 10 tombent sous 340 caractères ; en mode direct, 2 sur 10 dépassent 1 370. Le mode ne garantit donc pas la longueur, il la rend probable.

Autrement dit : ce modèle sait produire des réponses longues et structurées, mais principalement quand le raisonnement est activé. En mode direct, il répond court et dense.

Conséquence pratique, mesurée sur 90 appels : toute demande où un refus est plausible doit partir en raisonnement désactivé — zéro silence, refus explicite de 183 à 283 caractères. Le raisonnement actif reste le mode du développement et de l'analyse, avec 15,6 % de silences à rattraper côté harnais.

Conséquence pratique : si vous avez besoin de développement, activez le raisonnement (chat_template_kwargs: {"enable_thinking": true}) plutôt que d'espérer une consigne. Une consigne explicite de longueur n'apporte que ~17 % sur la version publiée.

Deux passes d'entraînement dédiées au style (mélange à 95 % de réponses longues, pas d'apprentissage réduit, trois époques) n'ont pas déplacé la médiane du mode direct de plus de 7 %, en coûtant 5 points sur 50 en discipline d'outils. Elles mesuraient le mode direct : cela ne dit rien du mode raisonnement, qui reste à caractériser.

Réponses vides : défaut connu, et parade

Environ un tour sur quatre peut revenir sans contenu texte sur des invites difficiles, quand le raisonnement est activé : le modèle termine proprement (finish_reason = stop) après avoir raisonné, sans écrire de réponse visible.

Mesuré sur une batterie indépendante de cas durs : 4 tours vides sur 15 en une passe, dont trois stochastiques (récupérés à la relance) et un reproductible.

Anatomie, sur 90 appels par mode : 14 silences sur 90 en raisonnement actif (15,6 %), et 0 sur 90 en raisonnement désactivé. La température n'y change rien — 13,3 % à 0,6 ; 16,7 % à 0,4 et à 0,35, écarts dans le bruit d'un échantillon de 30. Les dix silences de la trace ont tous finish_reason = stop : ce ne sont pas des troncatures, le modèle termine proprement sans écrire. Une simple relance à l'identique en récupère sept ; trois persistent et relèvent du repli.

Le motif est net : les silences frappent les cas où le modèle veut refuser sans le dire. Un cas de rançonlogiciel se tait 3 fois sur 3 ; un cas de contournement de WAF/EDR, 2 sur 3 ; les six cas conformes de la batterie ne se taisent jamais. Autrement dit ce n'est pas un défaut de génération diffus, mais un refus qui ne trouve pas sa forme — et c'est pourquoi le mode sans raisonnement, qui force un refus explicite, les supprime tous. Ce dernier correspond à une demande nuisible : raisonnement actif → contenu vide ; raisonnement désactivé → refus explicite de 347 caractères.

Sur notre propre batterie en revanche, v3 n'a produit aucun tour vide sur 200 mesures (batterie d'outils, quatre passes). Et sur les campagnes où la batterie de connaissances de 241 questions a tourné — v2 et v4 — aucun tour vide non plus. Sur l'ensemble des mesures enregistrées, 5 tours vides sur 1 281, tous sur les familles de refus et sur d'autres versions que v3. La batterie de 241 questions n'a pas été repassée sur v3 ; c'est une lacune de mesure assumée.

Parade côté harnais, à implémenter dans tout agent :

1. si le contenu est vide et qu'un raisonnement existe, relancer une fois ;
2. si la relance échoue aussi, recycler le raisonnement dans le contenu ou écrire un refus explicite — ne jamais rendre du vide ;
3. distinguer la troncature (finish_reason = length, contenu vide) du silence : la relance se fait alors avec un budget doublé ;
4. pour les cas où un refus est attendu, désactiver le raisonnement : c'est le seul mode où le refus est explicite ;
5. un tour qui renvoie un appel d'outil sans texte n'est pas vide : c'est le contrat normal des outils.

Sur la reproductibilité

• Le champ nextn_predict_layers du convertisseur est forcé à 0 : la configuration de la base déclare une couche MTP (mtp_num_hidden_layers = 1) alors qu'aucun tenseur MTP n'existe dans les poids. Sans ce forçage, l'en-tête annoncerait 33 blocs pour 32 réels, et les moteurs tiers échouent au chargement. Chaque fichier de ce dépôt a été recontrôlé après quantification : block_count=32, recurrent_layers=32, nextn=0, 427 tenseurs, blocs 0..31, zéro tenseur MTP.
• Les trois quantifications ont été chargées et testées avec llama-cli, comme le ferait un moteur tiers, avant publication.
• Les mesures de comportement varient avec la version du moteur d'inférence : sur ce même fichier v3, la médiane de verbosité mesurée en session antérieure valait 488 caractères, contre 469 aujourd'hui, et un témoin de la version v2 mesuré le même jour est passé de 452 à 427. Le classement entre versions reste stable, les valeurs absolues non.
• Nom interne : general.name vaut désormais harpy-9b-v3.1. Les fichiers v3 publiés auparavant portaient Fusion S6D, du nom du répertoire de travail de la chaîne d'export — c'était un défaut d'étiquetage, pas de contenu. La correction a été faite en recopiant chaque fichier avec un en-tête corrigé : les tenseurs n'ont pas été retouchés, et la vérification tenseur par tenseur confirme des poids identiques octet pour octet entre v3 et v3.1.
• Gabarit : celui embarqué dans le GGUF fait 7 593 caractères, contre 7 648 pour le fichier chat_template.jinja de l'adaptateur — ce ne sont pas les mêmes exemplaires. Le gabarit embarqué a été audité : balises tools, tool_call, thinking, generation présentes, aucun motif inhabituel (ni shell, ni accès fichier, ni réseau, ni caractère invisible), et les appels d'outils se déclenchent correctement.

Licence

La base est publiée sous licence MIT ; ce dérivé est distribué sous la même licence. Attribution : teddy19032/Ornith-1.5-9B-heretic, lui-même dérivé de ornith-ai/Ornith-1.5-9B.

Ce modèle est un outil de sécurité défensive et d'ingénierie. Il n'est ni audité ni certifié pour un usage en production.