Seeing as we reconfirmed SLI is not all that much use for this pair of 1080Ti’s in Space Year 2026, what else can we do with them while they’re in there?
Welcome to Esk Computers, I’m Scott and today on the desk of Esk, let’s set up a renderfarm, dabble in the forbidden arts of local AI, and generate more fake frames than is medically advisable.
A few weeks ago we ran through a bunch of SLI testing with games across 20 years, and didn’t find much in the way of compelling use cases. However, before admitting defeat and returning one 1080Ti to its usual home in my server system, I want to see if there’s any other real world use cases where this monstrosity is warranted. I’ve hopefully remembered to link to the full system build video, but in short it’s an i9-9900K system, currently running with 16GB of 3000MHz DDR4 RAM.
One avenue would be to simply treat it as two separate machines. Install something like Proxmox as a base operating system, then create two virtual machines each with one GPU and roughly half the CPU cores, and with a little bit of consideration around latency and input devices, and maybe a bit more RAM, that would essentially give two people their own PC to do whatever they want with in the one box. This might be a good solution for families with more kids than room for individual desktops, but in terms of the sort of offbeat shenanigans we encourage around here, it’s a bit too sensible to get excited about.
Another path that’s a bit too similar to the SLI testing is just treating it as it’s own little render farm. It is quite a bit more practical than SLI in 2026, as while as we established modern games don’t use the second card at all, the likes of 3D modelling and rendering program Blender and the paid Studio version of video production app Davinci Resolve can take advantage of the second card’s compute power for the final output. This makes a lot of sense if that final render is a critical, time consuming apart of your workflow, but for me it isn’t.
Still, as a representative sample, here’s the Blender scenes used as part of their Open Data Benchmark at their default settings. This is the Classroom scene, where with one card it took 1 minute 23 seconds to render, and using two cards brings this down to 41 seconds, 51% faster. For reference, using the i9 9900K alone takes 7 minutes and 12 seconds.
A similar story with the Monster scene, going from 3 minutes 11 seconds down to 1 minute 39 seconds, that’s 48% faster. The CPU alone took 11 minutes and 36 seconds.
Rounding off with the more complex Barbershop scene which went from 7 minutes and 1 second down to 3 minutes and 38 seconds, again 48% faster. I gave up waiting for the CPU to finish, as it was estimating half an hour or so and I think we’ve already proven it’s a lot slower than GPU rendering. Indeed, it’s almost perfect scaling for the output, which is nothing to be sneezed at, but I should also mention that it’s not helping at all with the other aspects of using it. So again, depending on your workflow it could be a great timesaver.
Moving on to a look at local Artificial Intelligence, and I’ve made my opinions on AI and LLM’s clear in the past, and they aren’t particularly positive. However, I recognise not everyone shares that opinion, so I wanted to take a look at this for the video. To be fair, If I was going to get into this sort of stuff as anything more than idle curiosity, a local setup would be my ideal way of doing it. At least this gives us a fighting chance of keeping our data secure. It also lets us choose models like the Swiss governments Apertus model, that’s been trained ethically, by which they mean they didn’t just nick every bit of copyrighted material under the sun.
The 1080Ti’s arguably too old for this sort of thing, and not having the Tensor cores of later models it’s likely hobbling along at a quarter or less of the speed of a 3090, according to CoPilot, and I suppose it should know, right? But let’s see if it’s tolerable, while spending about £300 rather than £1000. And I should add that as you might expect this is the first time I’ve fiddled with any of this, so please excuse any errors coming from my AI, that being Authentic Ignorance.
We can, to a degree at least, use the combined 22GB on the GPUs, rather than the memory pools needing to be duplicated as with gaming where we’re limited to 11GB. This should let us use a few of the bigger, more intensive and supposedly better models without slowing it down by handing part of it off to the main system RAM.
I’m far from an expert on this, but here’s how I’ve tried to test it. I’ve downloaded LM Studio, and from there tested similar prompts with different weights of models that recommend increasing amounts of VRAM on the GPU to handle. These are three different flavours of the Qwen 3 model, namely the 8B, 14B, and 32B parameter models, and also three different taste sensations of Google’s Gemma 4 model in 12B, 26B, and 31B parameter models. I’ve run these with one and two cards, and LM Studio gives me metrics which I’ve averaged for the models across three runs of each model. The tokens per second values and time to first tokens were broadly the same across the runs, so I’m happy presenting averages for those. That’s roughly speaking a measure of how fast the models can write your response.
However, each model’s thinking times were all over the place such that I’ll give that as a range. That’s the time it’s taking to process your prompt and arrive at a plan to respond, and even with pretty similar prompts it’s almost random on how long that takes. There’s probably a cleaner, more repeatable way to test this, but hey, here’s what I’ve found.
LM Studio has the option in its settings to turn off the use of one GPU, but that button doesn’t appear to be hooked up to anything and it kept using two cards, so I’ve made sure of it by pulling the card out.
The Qwen 3.5 9B model comfortably fits in one card’s VRAM, taking up a maximum of 6.3GB in my testing, so I wouldn’t expect much of a difference. That’s more or less the case, with the dual card setup getting an average of 39.5 tokens per second, with one card coming in 12% slower at 34.9 tokens per second. The time to first token average difference is huge in percentage terms, 476%, but that’s between 0.32 seconds with two cards and 1.82 seconds with one. Average thinking times for two cards ranged from 22 to 59 seconds, oddly with one card it was 9 to 114 seconds.
The Qwen 3.6 27B model is a little bigger than can fit in one card’s VRAM, but only barely, at 12.73GB in my tests. I figured this would show a slight edge on the dual card setup. While that’s born out in the data, this model appears to be too demanding for any combination of this hardware. The dual card setup gets 9.5 tokens per second, with one card coming in 72% slower at 2.7 tokens per second. The time to first token average difference is again huge in percentage terms, 407%, between 4.5 seconds with two cards and 23 seconds with one. Average thinking times with two cards ranged from 120 to 192 seconds. With one card it’s not really feasible to run, at 748 to 874 seconds. That’s about quarter of an hour, so way too long to be practical with one card, and there’s a good chance it will fail to answer even after the wait as it hits the prompt’s context memory limit. With two, probably not practical either, unless you’re very patient.
The Qwen 3.6 32B model takes up more VRAM, although a bit less than I expected, at 13.56GB. What I didn’t expect was for this to be easier to run than the 27B parameter model, so clearly I’m missing something. The dual card setup gets an average of 25.5 tokens per second, with one card coming in 45% slower at 13.9 tokens per second. The time to first token average actually favours the one card setup by 22%, at 4.1 seconds with two cards and 3.2 seconds with one. Average thinking times for two cards ranged from 81 to 113 seconds, and with one card it was 149 to 196 seconds.
Now, all of that’s slower than using even the unpaid tiers currently being offered by the usual online suspects, but who knows how long that’s going to remain unpaid? I don’t quite understand why the 27B model is so slow, but even with one antiquated card the 9B model is quite usable, and I’d argue the 32B model with 2 cards is on the cusp of usability. i’m not best placed to judge the quality of output across models, but aside from these not being able to reach out to the internet for the most recent information, at least as I have it set up, they seem to be giving broadly sensible outputs.
The Gemma 4 models generally speaking told the same story, so I’ll spare you the full blow by blow narration but the full info is up on the screen.
The smaller 8Gb 12B model actually ran 8% percent faster on one card than two, and 30 tokens per second is pretty decent performance if slower than the smaller Qwen model.
Again the mid-sized model threw up a more questions than answers. This is the Gemma 4 26B model that took up 12.8GB of VRAM. The two card setup result of 57 tokens per second seems unrealistically fast, certainly compared to the 13 the one card setup gets. I’ve also got no ready explanation as to why it would be over twice as fast as the supposedly easier to run model, apart I guess from this being a Quantization Aware Training version, maybe? At any rate, quite the difference for the two card setup.
I even re-downloaded all of this to check again while writing up the script, but them’s the numbers. Which is good, because the larger 31B model is too slow to be usable on both setups. Oddly, it’s only taking up 12.5GB of VRAM, but while the 55% speed difference between the two setups is good scaling, when that’s going from an unusably slow 5 to an even more unusably slow 2 and a half tokens per second, it’s not worth running. But, cards on the table, I’m just kicking the tyres here. I don’t really know what I’m doing, so apologies in advance if I’m wrong.
So, while of course there’s much better suited hardware out there for doing this kind of thing, the older, cheaper hardware is able to at the very least dip your toes in the water. However, if you have designs on anything more ambitious than fiddling around the edges then you might need to keep saving up for at least a 12GB RTX 3060.
Of course it’s not just text processing that can be achieved locally these days, but I think it’s the only AI use case that shows a speed increase with two GPUs working on one task. The rest can only benefit by treating them as essentially separate machines running different tasks in parallel, which is a level of productivity I can only dream of.
For example, image generator Stable Diffusion is practically speaking limited to being run on one card and therefore 11GB, so while having two cards will I suppose let you run two prompts at once, it’s not making one prompt run faster.
While ComfyUI seems to be the best way to play around with various image and video generation models, the most recent version doesn’t support the Pascal era cards. This is supposedly fixable, with enough hacking around in the python guts of the program to install an older subcomponent version that is compatible, but I gave up after a couple of hours and moved on to this Stable Diffusion Forge Webui app, that also needed a bit more command line messing about than it promised on its webpage
After some of the larger models failed quite spectacularly, I installed the Stable Diffusion 3 Medium model which is a couple of years old at this point, so it’s not really surprising that it took the best part of a minute to produce this rather disappointing 512 pixel square anime puppy image, or the same again for this thumbnail candidate with two rather uncanny valley graphics cards.
Of course that’s a me problem, as they’re only as good as the prompt that goes into them, so I nicked this more detailed architectural prompt from the internet. It took a bit over three minutes to get a better, but still kinda generic result. I’m sure better can be done with this model, or the newer competitors, but as they’re not made better by having two GPUs we’re getting outside the scope of this video.
Moving on to AI transcription, and Whisper is openAI’s tool to transcribe videos to text, and faster-Whisper is a re-write of it that promises to be, well, faster, otherwise its very name itself is a damned lie. This is the “Faster Whisper XXL GUI” tool that saves us from the command line.
I’ve set it loose on some of the videos on this channel, and compared it to my scripts. It’s much more straightforward to get up and running, offering to download any parts not installed, and mostly setting itself up to use the autodetected hardware. It did default to using a compute type not supported by the 1080Ti but changing that to auto fixed that.
I fed it my 14 and a half minute Ubuntu Touch video, and it took 2 minutes 55 seconds to transcribe it. It does a pretty solid job, even with the handicap of my heavily accented, mush mouthed delivery. Quite impressive, but again, only using 1 GPU confirmed, so let’s move on.
We could go the other way of course, and turn text into speech. I currently do this the old fashioned way by writing the words my brain comes up with using my hands and then speaking them with my mouth parts, as is traditional. But you can train a speech model on your voice, and as it happens I have a ton of data we can use for this.
It took maybe three hours or so to train a model of my voice, on about an hour and a quarter, or 1.2 GB of audio data. I suspect this initial training might actually have been possible to do on two cards if I understood Python and the CUDA libraries a bit better, but you’re only doing that the once anyway. The setup process again needed a bunch of googling and fixing to get working, but if a dummy like me I can get there in the end anyone else should be able to.
As to the results, well you are experiencing them right now. It’s not perfect, but I have to admit it’s pretty good. It’s obviously quite easy to think of unethical uses for this impersonation toolbox, but there’s also perfectly good obvious reasons that anyone might want to have a model of their own voice should accidents or life happen.
Right, that’s enough of that. I feel dirty. I will say all of this local AI experimentation is now fairly user friendly and easy to play around with, particularly the LLM stuff, and you won’t necessarily need to get your hands dirty with command lines unless you so desire, which wasn’t the case when I first looked at it I think two years ago now.
Coming back to the world of gaming, there’s a few use cases I can think of that would be technically better, but not by anywhere near enough to be worth it. For example if you’re streaming or recording your games, either for playing remotely away from the desktop, or for posting to Twitch or YouTube, the second card could take on that workload leaving the first free to give 100% of its performance to gaming. However in nigh on any modern card, there’s dedicated hardware for that sort of duty that means it’s barely making a noticeable difference anyway. So, technically a valid use, but hardly worth the bother.
Perhaps more useful is the Lossless Scaling app, which also now incorporates Frame Generation. This was all over tech YouTube a year or so ago, and does what it says on its tin independent of whatever solutions the games have. You shouldn’t need anything like as powerful as a 1080Ti for this, but here we are, let’s see what it can do.
Let’s try the scaling part first. Essentially here we can set up Cyberpunk 2077 at Ultra settings to run on one card at 720p, and the other card is taking that and upscaling it to 4K resolution. Unfortunately this confuses the NVidia screen capture, so I’m recording this the old fashioned way, and as you’re watching this reencoded by YouTube after being reencoded by my video editing package at 1080p I don’t expect you’re getting the full experience.
Doing this trick with lossless scaling means we’re seeing 67 average fps in the benchmark, at sorta kinda 4k from the 720p source material. If you do the same but with a 1080p source, it dropped to 44 average fps.
The native 4K benchmark run can only get 17 fps, so there obviously quite a difference in framerate. However, for a baseline, the same unmolested benchmark runs at 1080p gets 63 and at 720p gets 104 average fps. So technically, we’re losing 36% of the performance at 720p and 30% 1080p with Lossless Scaling turned on. Is the difference in image quality worth it?
Now, admittedly, in terms of image quality I’m not the best person to ask, as my eyesight is so bad I have hospital appointments about it. But, I don’t really see that much benefit from just outputting at 720p and letting the monitor deal with scaling it up to its native 4K. There’s nothing about Lossless Scaling’s techniques that make it immune from the usual problems with ghosting and shimmering, but it’s hard for me to notice them unless they’re egregious. What Lossless Scaling does do is a much better job of making the UI elements legible compared to the slight fuzziness my monitor’s inbuilt scaling gives, although that’s much more noticeable on menus rather than in action.
Trying the other half of the equation, we can add some frame generation into the mix. I ran it upscaled from 720p and inserting 6X fake frames into the output stream, and it is wild. This presents as something like 120 fps, which is a very high average framerate, but all this trickery adds in an insane amount of input lag and makes it feel like you are gaming with a concussion. MSI Afterburner says it’s dropped the actual base framerate to 22 average fps, so no wonder it plays poorly. Lossless Scaling lets you go up to 20X the framerate, if you’re clinically insane, but thankfully this machine can’t handle it, removing that temptation. Maybe we can find a better balance.
For context, here’s the baseline performance at Ultra settings without any upscaling or frame generation during a runabout in Kubuki. At 720p settings we’re getting an average of 75 fps, with 1% lows of 50 and 0.1% lows of 42 fps. This plays really well, if a bit fuzzily. At 1080p settings we’re dropping to an average of 61 fps, with 1% lows of 43 and 0.1% lows of 37 fps, and was how I played through the game a few years ago with few concerns. For reference, at 4K we get an average of 17 fps, with 1% lows of 13.7 and 0.1% lows of 13.2 fps, which I don’t think anyone would want to play at.
But let’s not give up on the 4K dream yet. We’re now rendering at 1080p, with Lossless Scaling upping it to 4K, and running a 2x frame multiplier. We’re getting 33 “real” average fps according to MSI Afterburner, which Lossless Scaling beefs up to a presented 66 average fps after frame generation. 1% lows are 26.5 fps and 0.1% lows are 24.5 fps. It plays reasonably well for the most part, but the 30 to 40 percent drop in the low framerates does make it feel noticeably worse than 1080p native, and I’m not convinced it’s enough of a visual benefit to make up for that.
Of course, the elephant in Lossless Scaling’s room is that most games that need this sort of trickery already have their own solutions for upscaling and framegen integrated into them, and reportedly work well enough that I have to question whether offloading it to a whole extra graphics card is really worth it. Well, let’s answer that question.
Here’s Cyberpunk again on one 1080Ti with its inbuilt XeSS Performance upscaling and frame gen implementations effectively doing the same 1080p to 4K, 2x frame gen trick. In the benchmarks we’re seeing 38.2 average frames per second which I presume is effectively getting doubled, and in gameplay MSI Afterburner is recording 59.1 average fps, with 1% lows of 50.6 and 0.1% lows of 47 fps, which I believe are the doubled values. So that’s about 10% less performance with one card than offloading the duties to a second card, so there is some value in the two card approach Lossless Scaling enables.
Is that enough of a difference to be worth sticking an extra card in your rig? Maybe, if you have a disused card lying around, but surely not enough to go and buy one for this purpose, and certainly not a 1080Ti. However, I’m just not sold on either upscaling or frame gen being useful solutions to the problems of modern gaming. I don’t see these upscaling techniques as being all that much of an improvement over letting your display handle it, and frame generation only works acceptably when there’s a high enough frame rate in the first place to arguably not need further fake frames. Again, a problem better left to displays with variable frame rates.
I expect there’s more use cases for machines with two GPUs in them, but this was all that occurred to me that would be valid in 2026. Of the lot of them, there’s certainly utility in the renderfarm type approach in Blender if you do a lot of that, and while it’s not my cup of tea as a low cost way of getting into local LLM tinkering this is a slow but affordable way to dip your toe in the water without spending thousands.
If there’s any blindingly obvious use case you think I’ve missed please let me know. As always, if you have any questions or want further details please leave a comment down below, and if you enjoyed this videotronic missive then consider subscribing. Until next time, take care of yourself, and each other.