DeepSeek Harness : mesurez l’espace des journaux

Une définition mesurable de l’espace des journaux DeepSeek Harness

Le premier piège vient de la confusion entre le volume traité par le modèle et le volume écrit sur le disque. Les jetons servent à mesurer le contexte, la facturation ou la capacité d’inférence ; ils ne décrivent pas automatiquement la taille d’une base SQLite, d’un fichier d’événements, d’une image conservée ou d’un résultat de commande.

Dans l’implémentation publiée sous le nom DeepSeek Harness, la persistance de session est présentée comme appuyée sur SQLite, tandis que le dépôt distingue les sessions, les messages, le budget, les événements et les artefacts. La présence de ces composants signifie qu’une tâche peut produire plusieurs écritures pour une même interaction visible. Consultez le dépôt et sa structure de persistance avant de reprendre un chemin local dans une procédure d’exploitation.

La mesure doit toujours indiquer :

• la version ou le commit exécuté ;
• le type de tâche : question simple, correction de code, compilation, recherche documentaire, OCR, audio ou vidéo ;
• la durée d’observation ;
• le nombre de reprises, de compressions ou d’interruptions ;
• le profil d’outils utilisé ;
• la politique de conservation et de sauvegarde active.

Sans ces informations, une valeur en mégaoctets n’est pas comparable d’un poste à l’autre.

Les événements persistants comme unité de croissance

Une conversation ne contient pas uniquement le texte affiché. Selon le flux d’exécution, les données persistantes peuvent inclure le message utilisateur, les fragments de sortie du modèle, les appels d’outils, les résultats retournés, les validations, les décisions d’approbation, les interruptions et les événements de compression ou de reprise.

Le terme SessionEvent doit donc être traité comme une unité à inspecter, et non comme un synonyme de message. Si la version utilisée expose ce type dans son code ou son schéma, relevez sa taille moyenne, ses champs volumineux et les références vers des fichiers externes. Un événement qui contient uniquement un identifiant de fichier n’a pas le même coût qu’un événement qui recopie le contenu d’un terminal ou un extrait de code.

La méthode la plus fiable consiste à mesurer la différence de taille du répertoire ou de la base avant et après une tâche isolée :

du -sh "$HOME/.config/deepseek-harness" 2>/dev/null
du -sh "$HOME/.local/share/deepseek-harness" 2>/dev/null
du -sh ./artifacts 2>/dev/null

Lorsque le chemin n’est pas connu, partez de la configuration produite par l’installateur et de la commande de découverte de la version active. Le guide opérateur indique notamment des emplacements de configuration sous ~/.config/deepseek-harness/, mais cette information ne doit pas être transformée en affirmation sur l’emplacement exact de tous les journaux. Le guide opérateur distingue bien la configuration, les sessions, les artefacts et les sorties de preuve.

Exemple de relevé :

avant_tache=...
apres_tache=...
apres_reprise=...
delta_tache=...
delta_reprise=...
version=...
type_tache=...

Le champ delta_tache mesure la croissance immédiate. Le champ delta_reprise révèle les éventuelles copies supplémentaires créées lorsque la session est rechargée, indexée ou convertie.

Les résultats d’outils et les artefacts de travail

Les tâches qui exécutent des commandes ou manipulent un dépôt ont généralement une croissance plus difficile à prévoir qu’un échange textuel. Une compilation peut produire des journaux, des index, des paquets temporaires et des fichiers intermédiaires ; une recherche de code peut renvoyer de longs extraits ; une tâche de design peut générer des aperçus, des exports et des versions de travail.

Il faut séparer deux catégories :

1. Le résultat incorporé à la session, qui peut être conservé comme événement, message d’outil ou preuve de contrôle ;
2. L’artefact laissé dans le répertoire de travail, qui appartient au projet même s’il a été créé par l’agent.

Cette distinction est essentielle pour décider si une suppression est sûre. Effacer un cache de compilation reconstruisible n’a pas la même conséquence qu’effacer un fichier généré utilisé pour reprendre une tâche ou vérifier un audit.

Le dépôt documente une séparation entre l’état, les journaux d’exécution, les paquets de revue et les répertoires d’artefacts. Pour les travaux lourds, il décrit aussi des fichiers de preuve, des journaux d’événements, des états de reprise et des sorties par fragment. La documentation des charges lourdes doit être consultée lorsqu’un travail concerne l’OCR, la traduction, un catalogue média ou une production longue.

Pour obtenir une mesure exploitable, préparez un dépôt de test contenant uniquement les fichiers nécessaires, puis exécutez successivement :

df -h .
du -sh . 2>/dev/null

deepseek-harness chat --plain

du -sh . 2>/dev/null
du -sh ./artifacts 2>/dev/null

La comparaison doit être répétée avec un contrôle de sortie : résultat court, résultat détaillé, écriture dans un fichier et export de preuve. Il est déconseillé d’annoncer un pourcentage d’économie avant cette comparaison, car la réduction dépend du nombre de lignes retournées, du format de stockage et des outils appelés.

Les charges de corpus documentées comportent des limites d’admission qui ne sont pas des promesses de consommation habituelle : le dépôt mentionne une taille de lot rendue de 16 MiB, une limite dure de 64 MiB et une lecture JSONL par blocs de 64 KiB. Ces valeurs décrivent des plafonds techniques de cette implémentation, pas l’espace à réserver sur chaque Mac. Voir les limites documentées des charges de corpus.

Les images et les fichiers multimédias

Les images doivent être calculées à part, surtout pour les équipes qui utilisent DeepSeek Harness dans des flux de design, de vidéo, d’OCR ou de catalogage média. Le nombre de pièces jointes ne suffit pas : deux images peuvent avoir des formats, des résolutions, des profils colorimétriques et des niveaux de compression très différents.

Le relevé doit distinguer :

• le fichier original reçu par le Mac ;
• une copie normalisée ou convertie ;
• une miniature ou un aperçu ;
• le contenu transmis au modèle ;
• la référence conservée dans l’événement ;
• la copie recréée après reprise de session ;
• l’export destiné à l’audit.

Les spécifications ACP montrent que les contenus non textuels, notamment les images, l’audio ou les ressources, peuvent être transportés comme blocs de contenu ; elles indiquent également que les résultats d’outils non textuels peuvent rester associés à la charge utile de l’appel. Cela renseigne sur la possibilité de transport, mais ne remplace pas la mesure de la politique locale de conservation. Consultez la documentation ACP sur les événements de contenu.

Utilisez la taille réelle des fichiers :

find "$PWD" -type f \( -iname '*.png' -o -iname '*.jpg' -o -iname '*.jpeg' -o -iname '*.webp' -o -iname '*.heic' \) -print0 |
  xargs -0 stat -f '%z %N' 2>/dev/null

Après l’envoi et après la reprise, comparez la liste des fichiers, leur taille et leur empreinte. Une image qui n’est pas recopiée localement peut néanmoins être référencée dans la session ; à l’inverse, une conversion peut créer une seconde version plus volumineuse que l’original.

Les pièces jointes sensibles doivent aussi être classées selon leur obligation de conservation. Une suppression techniquement possible peut rester interdite par un contrat, une procédure d’audit ou une politique interne. Dans ce cas, le stockage nécessaire doit être inclus dans la capacité réservable, et non traité comme un simple cache.

Les sauvegardes, les instantanés et la reprise

La capacité du Mac ne doit pas être confondue avec la capacité de travail disponible. Si la session active occupe une unité d’espace, une sauvegarde locale, un instantané ou une copie de migration peut demander une réserve supplémentaire, même lorsque le mécanisme utilise la déduplication ou la copie à la demande.

Calculez séparément :

• les données en ligne nécessaires au fonctionnement ;
• la copie de sauvegarde la plus récente ;
• les instantanés conservés ;
• la copie de migration vers un autre Mac ;
• la fenêtre de retour arrière ;
• les fichiers temporaires créés pendant l’export ou la restauration.

Le guide opérateur de DeepSeek Harness recommande l’export de paquets de revue et d’un instantané d’état pour les opérations contrôlées. Cela ne signifie pas qu’un instantané sera automatiquement compatible avec toute version future. Un fichier lisible par SQLite, ou un export JSON correctement copié, peut être consultable sans permettre une reprise directe si le schéma ou le format des événements a changé.

Une vérification de restauration doit donc suivre ce protocole :

# Exporter l’état dans un emplacement séparé
deepseek-harness state --output /tmp/deepseek-harness-state.json --limit 12

# Copier la base ou le répertoire de session selon la version active
# Restaurer dans un environnement de test distinct
# Lister les sessions, puis reprendre une session non critique
deepseek-harness chat --list
deepseek-harness chat --resume SESSION_ID

Ne validez pas une sauvegarde uniquement parce que le fichier existe. La preuve utile est une reprise réussie, avec lecture de l’historique, accès aux références de fichiers et cohérence des artefacts attendus.

La formule de capacité et les seuils de décision

Une formule remplissable vaut mieux qu’une configuration universelle :

capacité_de_travail =
  occupation_initiale
  + (tâches_par_période × croissance_moyenne_par_tâche × périodes_de_conservation)
  + croissance_des_images
  + croissance_des_artefacts
  + réserve_de_restauration

capacité_totale =
  capacité_de_travail
  + (copies_de_sauvegarde × taille_de_la_copie)
  + espace_temporaire_de_migration

Pour éviter une estimation trop optimiste, mesurez séparément une tâche légère, une tâche de développement avec outils et une tâche multimédia. Une longue session ne doit pas être représentée par une simple conversation prolongée si le trafic réel comprend compilation, recherche, génération de fichiers ou images.

Conditions de choix

• Si la croissance par tâche est stable et que les artefacts sont externalisés, conservez le Mac actuel et automatisez un relevé périodique de l’espace libre.
• Si les journaux augmentent mais que les anciens événements sont exportables et vérifiables, choisissez une politique de rotation documentée avant d’ajouter du stockage.
• Si les résultats d’outils et les artefacts doivent rester sur le même volume, ajoutez la taille des fichiers de travail à la formule ; ne la déduisez pas du journal de conversation.
• Si les images sont nécessaires à la reprise ou à l’audit, conservez les originaux et leurs références jusqu’à la fin de la période imposée.
• Si une restauration n’a pas encore été testée, réservez une copie distincte avant toute suppression.
• Si le seuil de nettoyage est atteint mais qu’aucune donnée ne peut être supprimée sans risque, augmentez la capacité du Mac distant plutôt que de forcer une purge.

Réponses opérationnelles aux recherches fréquentes

Emplacement des données

La réponse à la question « où sont enregistrés les journaux ? » dépend de la version, du mode d’installation et du profil d’exécution. Commencez par la configuration active, recherchez les répertoires de sessions et d’artefacts, puis confirmez avec du. Ne copiez pas un chemin trouvé dans une ancienne version sans vérifier le commit exécuté.

Conservation des longues sessions

Une longue session peut rester modeste si elle conserve des références courtes, mais devenir beaucoup plus lourde lorsque les résultats d’outils, les extraits de code et les images sont recopiés. La bonne mesure est le delta observé après la tâche, puis après redémarrage et reprise, jamais le nombre de tours affichés dans l’interface.

Nettoyage prudent

Les caches reconstruisibles, les exports déjà contrôlés et les artefacts temporaires sont les premiers candidats à la suppression. Les événements, les bases de session et les pièces jointes ne doivent être supprimés qu’après export, contrôle d’intégrité et test de reprise.

Tableau de relevé avant location ou extension

Ces cellules doivent être remplies avec les données de l’environnement réellement loué ou exploité. Aucune valeur fixe ne peut remplacer ce relevé, car les formats de persistance, les outils et les pièces jointes changent le résultat.

Comparaison des stratégies de stockage

Pour préparer un essai, la page Mac distant de NodeMini permet d’examiner une solution temporaire sans figer trop tôt une capacité définitive. Les équipes qui doivent comparer une implantation géographique peuvent ensuite confronter la mesure obtenue à une offre de Mac cloud en Virginie, tout en conservant la même procédure de relevé.

La décision entre nettoyage et extension

Le nettoyage est pertinent lorsque trois conditions sont réunies : les fichiers sont identifiés, leur suppression est réversible ou justifiée, et une reprise a déjà été testée sur une copie saine. Il devient risqué lorsque l’équipe supprime une base de session parce qu’elle paraît ancienne, sans savoir si elle contient les références nécessaires à un audit ou à une migration.

L’extension est plus logique lorsque la croissance provient de données qui doivent rester ensemble : journaux d’outils, images originales, artefacts de compilation et copies de récupération. Elle est également préférable lorsque les sessions sont parallèles, car une moyenne par tâche peut masquer un pic d’écriture simultané.

Un Mac local conserve toutefois des avantages pour une charge permanente et parfaitement connue : accès direct aux périphériques, environnement maîtrisé et coût amorti sur une longue durée. En revanche, il impose l’achat initial, la maintenance, la surveillance de l’espace disque et la gestion des sauvegardes. Une machine virtuelle générique ou un serveur Linux peut réduire certains coûts, mais elle ne reproduit pas toujours les dépendances macOS, les outils de design, les flux audio/vidéo ou les vérifications propres à l’écosystème Apple.

Pour une expérimentation, une migration ou une période de charge incertaine, la location d’un Mac NodeMini permet surtout de tester la croissance réelle avant de prendre une décision matérielle durable. Une fois le delta par tâche, la conservation et la copie de restauration connus, l’équipe peut choisir une capacité avec des critères mesurables plutôt qu’avec une estimation fondée sur le nombre de conversations.

Le bon prochain pas consiste à exécuter le modèle de mesure sur une tâche représentative, à archiver le relevé de version et à intégrer les résultats dans le catalogue Mac de NodeMini. Cette démarche permet de distinguer ce qui doit être nettoyé, ce qui doit être sauvegardé et ce qui justifie réellement une extension du stockage.