Each process will spawn its own networking thread which is unique per process (1). The role of the networking thread is to talk to the database, and also execute the future callbacks when they become ready.
I think that the go binding schedules the continuation of asynchronous operations on a different thread than the fdb network thread, but it can still become saturated just by the cost of executing all the callbacks, especially if you are doing a lot small single-key reads concurrently. Maybe changing your algorithm to use more range reads could potentially reduce the callback overhead?
Spawning multiple GO processes will help you get more throughput because you will have multiple network threads running concurrently, utilizing more of your CPU cores.
(1) you can have multiple thread per process when running the multi-version client, but this is only true while you are in the process of upgrading the database to a new version. In normal operation, only one will be really active.