In general, trying to split up frame rendering between multiple GPUs runs into issues with latency because either you need to share data between the GPUs (so some reads/writes go to the remote GPU, which takes longer and then there’s cache coherency issues on top of that) or you need to mirror it (so all data transactions between GPU and CPU need to be doubled, bus bandwidth might need to be shared), and there could still be cross-gpu dependencies that require eating those longer latencies.
100 fps means each frame needs to be rendered in 10ms, so even round trips of 1ms can be costly and risk missing the frame deadline (which results in a stutter). The whole idea of multi-gpu is to get even higher frame rates, so the higher they get pushed, the bigger an impact that latency has.
Though maybe raytracing workloads would work well with it. Something that depends more on massive parallelization than anything else and where each ray is independent. But load balancing still isn’t trivial as it will depend on the scene or even the camera and lighting position and the software complexity might not be justified by how small the market would be.
Like, two RX 7900 XTXs as an alternative to one RTX 5090?
For some applications.
For games, in general, I believe no, not in 2026. GPUs did have an era where there was some real deployment of games that could leverage multiple GPUs, but I understand that this hasn’t been supported for quite a while.
Scalable Link Interface (SLI) is the brand name for a now discontinued multi-GPU technology developed by Nvidia for linking two or more video cards together to produce a single output. The technology was invented and developed by 3dfx and later purchased by Nvidia during the acquisition of the company. SLI is a parallel processing algorithm for computer graphics, meant to increase the available processing power.[1]
For AI compute, it depends a lot on what exactly you’re doing.
If you want to do two different things that both require no more than one card, sure. Like, Card A is running Stable Diffusion to generate images and Card B is running Gemma to generate text.
If you want to run a model designed for a larger system that doesn’t fit on a single card’s VRAM…maybe.
If you can fit some of the model’s neural net layers on one card, then you can do the compute on one card, then (slowly) move outputs from one card to another card, then compute more layers there. I know, off the cuff, that KoboldAI, which is for use with text LLMs, can make use of multiple cards (as well as the CPU) in this way. I think that it may (or, at least, did) suffer from the same limitation that I saw in a video that Jeff Gearling did last year where he was experimenting with clustering Framework Desktop systems (each of which can have 128GB of VRAM) to build larger clusters that could run very large LLMs.
He could run ollama on multiple systems, but at least at the time, it wasn’t capable of running batched work on cards concurrently. So you’d run some layers on Framework Desktop A, then ollama would move data over to Framework Desktop B and do more work there while Framework Desktop A was idle. That’s not a fundamental hardware limitation, just a software limitation. It meant that while you could run larger models that would otherwise be practical (e.g. four 128GB Framework Desktop systems could run a neural network that’d normally take half a terabyte of memory to work with), you wouldn’t be making use of all of their compute capability concurrently. What he was getting was more-or-less analogous to the compute power of a single Framework Desktop with 512GB of memory. But…there shouldn’t be a hard limitation. As long as you have a queue of requests to feed hardware that use the same model, I imagine that it should be possible to keep all your cards hot. And that limitation might have already been addressed. I think I remember reading about another LLM engine (vllm?) that can do this…but I’m going out of fuzzy memory; I wasn’t actually aiming to build a cluster myself.
It’s also possible, if you’re really going to commit to a particular hardware layout that uses multiple independent cards, to build a neural network designed for this particular card layout. I’d guess that that probably makes more sense if you’re…oh, say, a Chinese AI company with a lot of funds to build out training infrastructure that isn’t sure that it’s going to be able to get its hands on US hardware that’s really dedicated to AI. Then you train a model that runs a neural network on consumer GPU card A. That neural network has only sparse connections, only a few of them, to a neural network on card B, so it’s cheap in terms of bandwidth to move outputs from card A to Card B. In terms of the quality of what the neural network generates, that won’t perform as well as a system that doesn’t have that requirement to be sparsely-connected, but it’s very possible that that performance limitation may not be very significant — I think that the question of how significant it is probably a very interesting and presently-unresolved question for many countries and businesses involved in the industry, since if you can use consumer hardware in parallel to effectively compete with models running on dedicated AI hardware, that eliminates a lot of the “moat” that might let, say, Nvidia price-discriminate between gaming and AI customers, the US ensure that it has a military or industrial advantage relative to China, or a given AI company limit competition in a given field based on access to hardware.
For non-AI parallel compute tasks, like…I dunno, say, cracking passwords via trying to brute-force reverse a cryptographic hash or something, in most cases a task can probably be parallelized and probably doesn’t care much about VRAM anyway (at least compared to AI compute), probably yes, as long as your software can handle it. I had a buddy who used clusters of machines with parallel compute hardware to do multi-body simulations for astronomy stuff, and I’m sure it would work there, since he was, well, doing it. I wouldn’t expect any fundamental limitation to be coming from the hardware there.
EDIT: A more-prominent concern if we’re talking what someone might immediately care about between the two cards if they’re doing some forms of AI compute is probably whether they’re willing to pay a premium for Nvidia hardware to use Nvidia’s software stack, which is more mature than AMD’s. Like, ROCm is definitely less mature than CUDA, and while I’ve been pretty comfortable using Vulkan on AMD hardware to do AI compute with llama.cpp, some software needs to go through ROCm (e.g. ComfyUI), and my experience there has definitely been less positive (though to be fair, I’m also determined to use it on Debian, whereas AMD presently only officially supports Ubuntu, Fedora, and Arch kernels with the newer versions of ROCm, so…shrugs).
I know nothing on this, could you run two of those in parrallel?
In general, trying to split up frame rendering between multiple GPUs runs into issues with latency because either you need to share data between the GPUs (so some reads/writes go to the remote GPU, which takes longer and then there’s cache coherency issues on top of that) or you need to mirror it (so all data transactions between GPU and CPU need to be doubled, bus bandwidth might need to be shared), and there could still be cross-gpu dependencies that require eating those longer latencies.
100 fps means each frame needs to be rendered in 10ms, so even round trips of 1ms can be costly and risk missing the frame deadline (which results in a stutter). The whole idea of multi-gpu is to get even higher frame rates, so the higher they get pushed, the bigger an impact that latency has.
Though maybe raytracing workloads would work well with it. Something that depends more on massive parallelization than anything else and where each ray is independent. But load balancing still isn’t trivial as it will depend on the scene or even the camera and lighting position and the software complexity might not be justified by how small the market would be.
Like, two RX 7900 XTXs as an alternative to one RTX 5090?
For some applications.
For games, in general, I believe no, not in 2026. GPUs did have an era where there was some real deployment of games that could leverage multiple GPUs, but I understand that this hasn’t been supported for quite a while.
https://en.wikipedia.org/wiki/Scalable_Link_Interface
For AI compute, it depends a lot on what exactly you’re doing.
If you want to do two different things that both require no more than one card, sure. Like, Card A is running Stable Diffusion to generate images and Card B is running Gemma to generate text.
If you want to run a model designed for a larger system that doesn’t fit on a single card’s VRAM…maybe.
If you can fit some of the model’s neural net layers on one card, then you can do the compute on one card, then (slowly) move outputs from one card to another card, then compute more layers there. I know, off the cuff, that KoboldAI, which is for use with text LLMs, can make use of multiple cards (as well as the CPU) in this way. I think that it may (or, at least, did) suffer from the same limitation that I saw in a video that Jeff Gearling did last year where he was experimenting with clustering Framework Desktop systems (each of which can have 128GB of VRAM) to build larger clusters that could run very large LLMs.
https://www.jeffgeerling.com/blog/2025/i-clustered-four-framework-mainboards-test-huge-llms/
He could run ollama on multiple systems, but at least at the time, it wasn’t capable of running batched work on cards concurrently. So you’d run some layers on Framework Desktop A, then ollama would move data over to Framework Desktop B and do more work there while Framework Desktop A was idle. That’s not a fundamental hardware limitation, just a software limitation. It meant that while you could run larger models that would otherwise be practical (e.g. four 128GB Framework Desktop systems could run a neural network that’d normally take half a terabyte of memory to work with), you wouldn’t be making use of all of their compute capability concurrently. What he was getting was more-or-less analogous to the compute power of a single Framework Desktop with 512GB of memory. But…there shouldn’t be a hard limitation. As long as you have a queue of requests to feed hardware that use the same model, I imagine that it should be possible to keep all your cards hot. And that limitation might have already been addressed. I think I remember reading about another LLM engine (vllm?) that can do this…but I’m going out of fuzzy memory; I wasn’t actually aiming to build a cluster myself.
It’s also possible, if you’re really going to commit to a particular hardware layout that uses multiple independent cards, to build a neural network designed for this particular card layout. I’d guess that that probably makes more sense if you’re…oh, say, a Chinese AI company with a lot of funds to build out training infrastructure that isn’t sure that it’s going to be able to get its hands on US hardware that’s really dedicated to AI. Then you train a model that runs a neural network on consumer GPU card A. That neural network has only sparse connections, only a few of them, to a neural network on card B, so it’s cheap in terms of bandwidth to move outputs from card A to Card B. In terms of the quality of what the neural network generates, that won’t perform as well as a system that doesn’t have that requirement to be sparsely-connected, but it’s very possible that that performance limitation may not be very significant — I think that the question of how significant it is probably a very interesting and presently-unresolved question for many countries and businesses involved in the industry, since if you can use consumer hardware in parallel to effectively compete with models running on dedicated AI hardware, that eliminates a lot of the “moat” that might let, say, Nvidia price-discriminate between gaming and AI customers, the US ensure that it has a military or industrial advantage relative to China, or a given AI company limit competition in a given field based on access to hardware.
For non-AI parallel compute tasks, like…I dunno, say, cracking passwords via trying to brute-force reverse a cryptographic hash or something, in most cases a task can probably be parallelized and probably doesn’t care much about VRAM anyway (at least compared to AI compute), probably yes, as long as your software can handle it. I had a buddy who used clusters of machines with parallel compute hardware to do multi-body simulations for astronomy stuff, and I’m sure it would work there, since he was, well, doing it. I wouldn’t expect any fundamental limitation to be coming from the hardware there.
EDIT: A more-prominent concern if we’re talking what someone might immediately care about between the two cards if they’re doing some forms of AI compute is probably whether they’re willing to pay a premium for Nvidia hardware to use Nvidia’s software stack, which is more mature than AMD’s. Like, ROCm is definitely less mature than CUDA, and while I’ve been pretty comfortable using Vulkan on AMD hardware to do AI compute with llama.cpp, some software needs to go through ROCm (e.g. ComfyUI), and my experience there has definitely been less positive (though to be fair, I’m also determined to use it on Debian, whereas AMD presently only officially supports Ubuntu, Fedora, and Arch kernels with the newer versions of ROCm, so…shrugs).