Multiprocessing, ou concurrent.futures, ou subprocess, ou threading, ou asyncio…
Le fait que tout ça, ce soit dans la lib standard (alors qu’en Python, There should be one, and preferably only one, obvious way to do it) devrait te mettre la puce à l’oreille: la réponse est bien plus compliquée que "utilise multiprocessing et pickle" (d’ailleurs pickle est tellement lent que ça aussi, ça se discute).
La première chose à faire, déjà, c’est connaître la nature de ce que tu cherches à "paralléliser", et si j’utilise des guillemets, c’est parce qu’il y a au moins une chance sur deux que ton problème, que tu ne nous as toujours pas exposé (et ça commence à devenir gonflant cette manie de poser des questions dans le vide), ne requière pas de "vraie" parallélisation au niveau de Python.
Quand je lis tous les posts précédents qui parlent du GIL et qui s’y arrêtent, j’ai très envie de compléter ces réponses : non, le GIL n’est pas une frontière insurmontable, et il est parfaitement possible d’exécuter plusieurs threads en parallèle et meubler 500% de CPU dans un seul processus Python (ça m’arrive régulièrement) : tout dépend du code qui tourne dans ces threads. Mais encore, si ton code est susceptible de relâcher le GIL pour bosser, ça ne te dit pas si tu devais utiliser threading, ou concurrent.Futures, ou asyncio avec un ThreadPoolExecutor, parce que là aussi le choix le plus judicieux dépend de la nature de ton problème et de ta façon de concevoir sa solution.
Donc j’en reviens à la question de base que tout le monde t’a posé ou presque : ne fais pas comme d’habitude et décris-nous précisément ce que tu cherches à paralléliser au lieu de t’arrêter sur la première indication au doigt mouillé qui vient, sans quoi on ne peut absolument pas te répondre efficacement et tu risques d’implémenter un truc à la fois trop compliqué et peut-être bien plus lent qu’un code naïf sans parallélisation.