vector search is one of those workloads where the privacy story gets messy fast, since a lot of the earlier options were either searchable encryption with pretty narrow query models, or teees and other trusted-hardware setups that shift the trust problem instead of removing it. once you get to approximate nearest neighbor style indexes, the real question is how much of the access pattern and scoring pipeline leaks, not just whether the raw vectors stay encrypted. benchmarks matter here because every paper tends to pick a different dataset, recall target, and threat model, so comparing sap vs emvp vs bntm vs tiptoe usually turns into folklore. having cpu and gpu numbers in one place at least makes the tradeoffs less hand-wavy, though i'd still want to see which parts are actually protected in each system and which are just moved out of the adversary's view.

"GPU acceleration pays off for Plaintext and SAP but not for EMVP or BNTM" That’s the detail I’d watch. It’s a good reminder that once the protocol has enough crypto around it, the GPU can stop being the star and turn into a very expensive helper for something else. A lot of teams assume the hardware choice is the main scaling knob, but here the privacy layer changes the shape of the workload enough that the usual accelerator story breaks down.