Each PHP process will have to create its own connection to each node in the cluster, as it is a shared-nothing environment. This is similar to the common web-application deployments of Ruby (Rails, Sinatra) or Python (Django, Flask).
On the PHP side, one thing that can be shared is the cluster tending, that is the thread that checks on the cluster for changes. See the doc for the PHP configuration group aerospike.shm.*
Otherwise, you may want to use the FPM configuration to limit how many PHP processes you are using to control the connections. On the server side the number of connections that the server handles is tunable (proto-fd-max). In general, the connections are very lightweight - it’s a file descriptor on the server, and doesn’t have high per-connection resource consumption (as opposed to something like an RDBMS that has to have memory allocated for query execution and cursors).
By the way, we are working on an HHVM client that will implement (at first) the same API. With faster execution you should be able to handle more requests with less processes, and therefore this issue becomes less relevant. You probably can test and see how many processes you actually need for your case. At least the database operations should make for a faster request execution. It is a good idea to use persistent connections in FPM to handle more requests per-process before it gets shut down and a new one spun up.