2026 : combien d'appels parallèles dans DeepSeek Harness ?

Une construction, un test et une recherche de code lancés ensemble se bloquent, puis le journal ne permet plus de savoir quel outil a laissé le dépôt dans cet état.

La solution la plus rapide n’est pas de régler maxParallelToolCalls selon le nombre de cœurs. Commencez en mode sériel, classez chaque outil selon ses lectures, ses écritures et ses effets externes, puis n’autorisez les appels d’outils parallèles dans DeepSeek Harness qu’après validation de l’isolation, des pics de ressources, de l’annulation et des journaux.

Cette méthode concerne principalement :

• les développeurs d’agents qui veulent raccourcir une étape multi-outils sans introduire de concurrence de résultats ;
• les ingénieurs plateforme qui doivent fixer des limites de ressources dans un environnement partagé ;
• les responsables techniques qui doivent décider s’il faut augmenter la capacité d’un Mac ou attribuer un environnement indépendant à chaque charge.

Les effets de bord déterminent l’éligibilité

Dans DeepSeek Harness, le modèle peut produire plusieurs appels d’outils dans un même échange, mais cette possibilité ne signifie pas que tous les outils peuvent être exécutés simultanément sans risque. La documentation officielle distingue la génération des appels et leur exécution : le modèle propose une fonction, tandis que votre application fournit réellement cette fonction et doit contrôler ses arguments, ses permissions et ses conséquences. (Documentation DeepSeek sur les appels d’outils)

Avant de modifier maxParallelToolCalls, créez une fiche par outil avec quatre catégories concrètes :

• Objets lus : fichiers, répertoires, variables d’environnement, base locale, cache de dépendances, métadonnées Git ou service distant ;
• Objets écrits : fichiers source, fichiers de sortie, répertoire de construction, verrous, journaux, caches, branche ou état de session ;
• Données envoyées : requête HTTP, dépôt distant, système de tickets, stockage objet, service de publication ou périphérique ;
• Conditions d’arrêt : processus enfants, délai maximal, signal d’annulation, nettoyage attendu et état laissé après échec.

Vous pouvez ensuite répartir les outils en quatre familles.

Outils en lecture seule

La recherche dans le dépôt, l’inspection de fichiers, l’analyse statique sans génération de sortie et la consultation de journaux sont les meilleurs candidats pour un premier essai. Cette qualification ne tient toutefois que si l’outil ne crée pas de cache, ne met pas à jour un index et ne dépose pas de rapport dans le répertoire partagé.

Pour un scénario audio ou vidéo, lire plusieurs pistes ou analyser plusieurs fichiers peut être indépendant. En revanche, la génération de formes d’onde, de vignettes, de fichiers proxy ou de rendus temporaires peut écrire dans un emplacement commun. Le nom « analyse » ne suffit donc pas à classer un outil comme sûr.

Outils à écriture indépendante

Une construction, un export ou un test peut être parallélisé lorsque chaque appel possède son propre répertoire de sortie, son propre nom d’artefact et, si nécessaire, son propre cache. Cette indépendance doit être vérifiée dans la configuration réelle, et non déduite du nom de la commande.

Deux commandes appelées test et build peuvent toutes deux modifier un cache, produire un manifeste ou réécrire un fichier généré. Elles ne sont donc pas indépendantes par défaut.

Outils à écriture partagée

Les éditeurs de fichiers, les commandes de migration, les générateurs de code et les tâches Git qui modifient la branche doivent rester derrière une barrière sérielle tant que leur périmètre n’est pas isolé. Un résultat qui arrive dans le bon ordre dans l’historique du modèle ne répare pas une écriture concurrente déjà effectuée sur le disque.

Outils à effet externe

Les appels qui publient un paquet, ouvrent une demande de fusion, envoient un message, déclenchent un déploiement ou modifient un service distant doivent être traités comme non parallélisables par défaut. Même si l’API distante accepte plusieurs requêtes, vous devez démontrer l’idempotence, la déduplication et la correspondance entre chaque appel et son résultat avant toute ouverture.

Attention : l’ordre des résultats présenté au modèle ne prouve pas que les effets externes ont été exécutés dans cet ordre. La documentation de DeepSeek décrit un format de plusieurs appels, mais la politique d’exécution appartient à votre intégration et à votre registre d’outils. (Documentation DeepSeek sur l’exécution des appels)

L’espace de travail impose une barrière

La question centrale n’est pas seulement le nombre d’appels à lancer, mais le nombre d’appels qui peuvent toucher le même état mutable. Pour chaque scénario, vérifiez les éléments suivants :

• le chemin absolu du dépôt ;
• le répertoire de compilation ;
• le dossier des dépendances ou du cache ;
• les fichiers de verrouillage ;
• les fichiers temporaires ;
• la branche Git et les changements non validés ;
• le répertoire d’artefacts ;
• les journaux et identifiants de session.

Un contrôle fiable consiste à prendre un instantané avant et après chaque appel. Comparez au minimum l’état de Git, la liste des fichiers modifiés, les nouveaux artefacts, les verrous créés et la taille des répertoires temporaires. Si deux tâches produisent le même nom de fichier ou modifient la même branche, le scénario ne doit pas être accepté en parallèle.

Pour une construction parallèle, trois architectures sont possibles :

1. Même espace, lecture seule : acceptable uniquement si les outils ne génèrent aucun cache ni fichier auxiliaire.
2. Même dépôt, sorties séparées : possible si les répertoires de construction, les journaux, les caches et les artefacts sont explicitement distincts.
3. Espaces de travail séparés : préférable pour deux tâches qui écrivent, changent de branche, installent des dépendances ou exécutent des scripts non maîtrisés.

Le troisième choix est généralement le plus prévisible pour des tâches de développement, de design, d’audio ou de vidéo, car chaque agent reçoit un chemin de travail, un journal et une destination d’artefacts qui lui appartiennent. Pour étudier une première capacité matérielle, consultez les nœuds Mac disponibles pour les charges de développement, puis reproduisez votre propre dépôt et vos propres scripts au lieu de transposer une mesure externe.

Les ressources fixent la limite réelle

Le nombre de cœurs donne une indication sur la capacité de calcul, mais il ne représente ni la mémoire disponible, ni la pression du système de fichiers, ni le nombre de processus enfants qu’une commande peut créer. Une boucle DeepSeek Harness qui lance simultanément une construction, plusieurs tests, un serveur de langage et des scripts d’analyse additionne leurs consommations.

Mesurez séparément, puis ensemble :

• l’utilisation moyenne et le pic du processeur ;
• la mémoire réellement occupée et la pression mémoire ;
• l’activité d’échange ;
• le nombre de fichiers ouverts ;
• le nombre de processus et de processus enfants ;
• l’espace temporaire consommé ;
• le temps d’accès au dépôt et aux artefacts ;
• le temps d’attente sur les verrous ou les caches.

Ne transformez pas une mesure ponctuelle en limite de production. Une recherche de code peut être légère, alors qu’une compilation de projet audio, vidéo ou de design produit des fichiers intermédiaires volumineux et maintient plusieurs processus actifs. Les limites côté service DeepSeek sont également distinctes de la capacité locale de votre Mac et de la limite du harnais. (Documentation DeepSeek sur les limites et l’utilisation)

Les signaux de réduction du parallélisme sont concrets :

• saturation prolongée au lieu de pointes brèves ;
• échange mémoire fréquent ;
• processus terminés par manque de ressources ;
• répertoire temporaire proche de sa limite ;
• baisse du débit malgré davantage d’appels ;
• temps d’attente dominé par les verrous ou les accès disque.

Dans ces cas, augmenter maxParallelToolCalls ne crée pas de capacité supplémentaire. Réduisez d’abord le nombre d’outils actifs, limitez les constructions simultanées ou déplacez les tâches indépendantes vers des environnements distincts. Pour comparer plusieurs nœuds, utilisez une même charge et un même dépôt sur chaque environnement Mac de VPSMAC, sans mélanger la latence réseau et la saturation locale dans une seule conclusion.

L’annulation mesure la capacité de récupération

Une configuration parallèle n’est pas acceptable si elle accélère le cas nominal mais laisse des processus actifs après une annulation. Testez au moins quatre situations :

1. un outil échoue immédiatement ;
2. un outil échoue après avoir écrit un fichier ;
3. l’utilisateur annule pendant l’exécution ;
4. le délai maximal expire alors qu’un processus enfant travaille encore.

Pour chaque cas, vérifiez trois niveaux d’état :

• l’appel au premier plan retourne-t-il bien une erreur ou un statut d’annulation ?
• les processus enfants reçoivent-ils réellement le signal et terminent-ils ?
• le répertoire de travail reste-t-il exploitable, ou contient-il une écriture partielle, un verrou abandonné ou un artefact trompeur ?

Une annulation correcte doit aussi définir ce qui arrive aux autres appels parallèles. Les arrêter tous est souvent le choix le plus sûr pour une transaction de construction. Les laisser terminer peut être pertinent pour des lectures indépendantes, mais uniquement si leurs sorties ne seront pas confondues avec celles de la tâche annulée.

Les appels en mode réflexion exigent une attention supplémentaire : DeepSeek demande de conserver reasoning_content dans les requêtes suivantes lorsqu’un tour comprend des appels d’outils, faute de quoi l’API peut répondre par une erreur 400. Ce point concerne la continuité du dialogue, mais il rappelle que l’état d’un outil ne se limite pas à son résultat visible. (Documentation DeepSeek sur le mode réflexion)

Les journaux constituent la preuve

Un parallélisme rapide mais impossible à auditer ne doit pas passer en production. Vous devez pouvoir relier chaque résultat à l’appel original, même lorsque plusieurs sorties arrivent dans un ordre différent.

Conservez au minimum :

• un identifiant de tâche ;
• un identifiant d’appel d’outil ;
• le nom exact de l’outil ;
• les chemins ou ressources ciblés ;
• l’heure de début ;
• l’heure de fin ;
• le statut final ;
• l’erreur normalisée, si elle existe ;
• le processus principal et les enfants concernés ;
• les artefacts produits ;
• le résultat de l’opération de nettoyage.

Ne supposez pas que l’ordre d’arrivée est l’ordre logique. Dans une réponse contenant plusieurs appels, chaque résultat doit rester associé à l’appel correspondant. Votre exécuteur doit donc conserver l’identité de chaque appel plutôt que concaténer des sorties dans une simple liste d’arrivée. (Documentation d’encodage DeepSeek-V4)

Un échec de traçabilité apparaît lorsqu’un journal dit seulement « test terminé » sans préciser quel dépôt, quelle branche, quel répertoire de construction et quel appel ont été concernés. Dans ce cas, même un gain de temps mesuré ne justifie pas l’ouverture du parallélisme.

Outil de décision pour choisir le mode

Utilisez la liste suivante après avoir exécuté le même scénario en sériel puis avec un parallélisme limité. Cochez chaque condition uniquement avec une preuve conservée dans le dossier de validation.

Passage au parallélisme limité

• [ ] Les outils concernés sont en lecture seule ou disposent chacun d’un espace d’écriture distinct.
• [ ] Aucun cache, verrou, fichier généré ou répertoire temporaire n’est partagé sans contrôle.
• [ ] Les ressources restent stables pendant toute la tâche.
• [ ] Aucun processus enfant ne reste actif après la fin ou l’annulation.
• [ ] Chaque sortie possède un identifiant d’appel et un artefact attribuable.
• [ ] Le scénario répété produit un état de dépôt cohérent.

Si toutes les cases sont cochées, choisissez un parallélisme limité et augmentez-le progressivement. Si une seule case reste vide, revenez au mode sériel pour l’outil concerné.

Maintien du mode sériel

Choisissez le sériel si :

• un outil modifie un fichier, un cache, une branche ou un répertoire commun ;
• une opération externe n’est pas idempotente ou ne possède pas de déduplication ;
• l’annulation laisse un processus, un verrou ou un fichier partiellement écrit ;
• les résultats ne peuvent pas être reliés sans ambiguïté à leur appel ;
• la saturation rend la durée totale plus longue ou provoque des erreurs.

Séparation des environnements

Envisagez un espace de travail ou un Mac distinct si :

• les outils sont correctement isolés, mais la mémoire, le stockage temporaire ou les processus restent durablement proches de la limite ;
• plusieurs projets ont des dépendances, caches ou branches incompatibles ;
• chaque tâche doit conserver son propre état après une annulation ;
• les artefacts doivent être remis à des équipes ou à des étapes différentes ;
• l’environnement partagé ne permet pas de contrôler les permissions et les verrous.

Cette grille répond à la question du réglage de maxParallelToolCalls sans inventer une valeur universelle : le réglage est accepté uniquement lorsque les conditions d’exécution le justifient.

Le protocole de validation en cinq étapes

1. Figez le contexte. Notez la version de DeepSeek Harness, la configuration de l’agent, le modèle, le dépôt, les extensions, le système d’exploitation et la date du test. Vérifiez les documents d’architecture et de configuration à chaque changement de version. (Dépôt officiel de DeepSeek Harness)

2. Établissez la référence sérielle. Exécutez le scénario sans appels simultanés. Enregistrez la durée, les fichiers modifiés, les artefacts, les erreurs, les processus enfants et l’état final du dépôt.

3. Classez les outils. Pour chaque appel, remplissez les objets lus, écrits et envoyés. Marquez explicitement les caches, verrous et répertoires temporaires, car ils sont souvent absents de la description fonctionnelle de l’outil.

4. Répétez avec une limite restreinte. Activez uniquement les outils sans effet de bord démontré ou les outils dont les sorties sont séparées. Répétez le même scénario et comparez l’état final plutôt que la seule durée.

5. Injectez des arrêts. Interrompez une tâche pendant une lecture, une écriture, une construction et une opération externe simulée. Vérifiez le retour au premier plan, les processus résiduels, les verrous et la possibilité de reprendre proprement.

Le résultat à conserver n’est pas uniquement une durée totale. Il doit comprendre la référence sérielle, la variante parallèle, les différences de fichiers, les mesures de ressources, les tests d’annulation et les journaux associés.

Questions opérationnelles fréquentes

Un réglage prudent pour maxParallelToolCalls

Aucune valeur ne peut être considérée comme stable pour tous les projets, car la limite du harnais, la concurrence du fournisseur et la charge locale répondent à des contraintes différentes. La documentation DeepSeek autorise plusieurs appels de fonctions dans une réponse, mais elle ne transforme pas cette possibilité en garantie d’écriture sûre ni en dimensionnement pour votre Mac. (Annonce officielle sur les appels parallèles)

Le risque de modifier deux fois le même fichier

Deux outils peuvent modifier le même fichier sans porter le même nom et sans être appelés par la même étape apparente. Contrôlez les chemins réels, les fichiers générés et les effets indirects des scripts. Une comparaison avant/après du dépôt reste plus fiable qu’une lecture de la description de l’outil.

La séparation des constructions

Séparez les constructions lorsque leurs sorties, caches, verrous ou dépendances se recouvrent. Deux espaces distincts rendent également l’attribution des artefacts plus claire, ce qui simplifie la reprise après annulation et la comparaison entre branches.

L’extension de capacité ou le retour au sériel

Réduisez le parallélisme lorsque la saturation provoque des erreurs, de l’échange, des processus supprimés ou une durée totale plus longue. Étendez vers un autre Mac seulement lorsque les tâches sont déjà isolées et observables ; sinon, vous risquez de reproduire le conflit sur une machine plus grande.

Le choix du Mac dépend de la preuve obtenue

Si votre environnement actuel repose sur un poste partagé, un seul répertoire de travail et des tâches qui écrivent dans les mêmes caches, il cumule trois défauts : concurrence difficile à contrôler, nettoyage incomplet après annulation et journaux difficiles à attribuer. Une machine plus puissante ne corrige pas ces défauts ; elle peut seulement les rendre plus rapides à reproduire.

À l’inverse, si votre test sériel est fiable, que les outils parallèles sont isolés, que les ressources atteignent réellement une limite et que chaque résultat reste traçable, la location d’un environnement Mac dédié chez VPSMAC devient une option plus cohérente qu’un poste partagé. Vous pouvez alors comparer une charge réelle sur des nœuds Mac M4 dédiés, conserver le sériel pour les écritures communes et réserver les appels d’outils parallèles aux tâches qui ont passé l’acceptation.