SSTO design is honestly a lot of trial and error.
The first issue is getting something that you can take off, go supersonic, decelerate, and land successfully.
The second issue is then getting that same craft to make orbit, and then have enough DV left over to perform your desired transfer burn OR go to the mun/minmus and mine to refuel.
If the result of solving the second issue is changing the design, then the first issue comes back up....
The third issue is getting this unicorn of a craft to complete reentry gracefully, and maintaining control while doing so.
if the result of solving the third issue is changing the design, you loop back to 1 all over again.
Meanwhile you can take whatever payloads you want, split them up, lob them into orbit and rendezvous with them and send a mothership with a mining lander wherever you want with conventional rockets. This craft can then remain in orbit after the initial mission is complete, and serve as a tour bus or w/e you need it for...while also saving a crap ton of time vs an SSTO.
I'm not saying this to discourage you, just imparting that a SSTO from Kerbin to Duna is going to be a lot more involved than knowing the ratio of X engines for Y amount of tonnage.
The year is 2020, but alas the way KSP works hasn't changed fundementally in this regard.
Your GPU is doing very little work when playing KSP; only rendering the limited graphics of the Skybox, lighting and whatever ships are in the scene. The CPU is what is pulling the majority of the load, and for individual vessels with high part counts all of this is battering a single core. Other cores are used to offload ships out of focus, so this reduces the overhead slightly for this one poor core. But that one ship is using one core to perform all the calculations of how each of those 500 parts is interacting with each other.
In shorthand; the bottleneck isn't the GPU here. It's the CPU, and only raw clockspeeds would raise your FPS at this point or a CPU with higher IPC (This may not be possible even if you're running recent HW). The "Fix" is on the user end; you now have your upper limit for partcount and can attempt to avoid using that many in the future.
