Ask Ying-Ja Chen if they know about Multi-Process Service to lower the VRAM overhead, potentially having it run on any modern GPU architecture

[keiran-rowell-unsw]

Early indications is that typical query sizes will not fully saturate everything and it's mostly about start-up cost, or idle time if running in GPU-server mode.

Would need to bundle together user request batches to really get the scale.

Mentor shared that the NIMs already use MMSeqs-GPU in the background (including AF2!), but not prior experience with Multi-Process Service so that idea was likely idealistic

[keiran-rowell-unsw]

MPS service demon is being started as root and so affecting all GPUs on the VM, each process might only access CUDA_VISIBLE_DEVICES but switching on the deamon as the root account affects all users.

Closing to focus on contributions that are less disruptive to others

[keiran-rowell-unsw]

When I enable MPS on a particular GPU the mmseqs gpuserver doesn't work out-of-the-box, ignoring for now since I'm would have to learn more MPS config and will unlikely bring more gains:

export CUDA_MPS_PIPE_DIRECTORY="$HOME/.nvidia-mps/pipe"
export CUDA_MPS_LOG_DIRECTORY="$HOME/.nvidia-mps/log"
mkdir -p "$CUDA_MPS_PIPE_DIRECTORY" "$CUDA_MPS_LOG_DIRECTORY"
chmod 700 "$HOME/.nvidia-mps" "$CUDA_MPS_PIPE_DIRECTORY" "$CUDA_MPS_LOG_DIRECTORY"

nvidia-cuda-mps-control -d

export CUDA_VISIBLE_DEVICES=7

gpuserver /mnt/hackathon-team6-2497s/colabfolddbs/colabfolddbs_gpu/uniref30_2302_db

MMseqs Version:         dca44bc6b867b16ab47932178272440eb27612bd
Max results per query   300
Preload mode            0
Prefilter mode          0

CUDA error: no CUDA-capable device is detected : /work/lib/libmarv/src/marv.cu, line 85