Neat, but rather incomplete on the system front.

• You can't add multiple GPUs or specify how many RAM sticks.
• The suggested models don't change much with better hardware because you look at raw TPM. An overabundance of it is not useful, you need to also measure quality, not just quantity.
• Your performance estimate is rather useless for real use-cases, because it doesn't factor in the TTFT (time to first token), which can be disastrously bad on CPU systems for long context use cases.
• There's a bunch of fluff text that doesn't say much beyond the actual calculated numbers. I'd review or remove the slop.

Prompt processing speed, which matters for most uses, is based on FLOPs. (Which you can also fetch for known GPU models) I would suggest doing the following things to make it much more useful:

• Include common Pro tier GPUs as well. Second hand P40, MI50, MI60, MI100, A100, GTX 8000, RTX 6000 (ampere/ada/pro), etc. are all decent choices on various spots on the raw power / value for money curve.
• Allow selecting more than one GPU. An 'add GPU' button would work, or a # of GPUs dropdown. Typically you can get up to 16 cards in one system. Note that you'd get less bandwidth between cards without a PCI-e switch for systems with many cards, even HEDT/server. This is where things can get a little complicated, but you can do an upper estimate: divide PCI-e lanes by card count and round down to 1/2/4/8/16 per card. This'll work for every card except for very expensive pro cards with NVlinks, SXM/OAM boards.
• Allow setting a 'performance margin', which is a software inefficiency penalty to the performance number. Default to 70% of theoretical amount. (That's a good rule of thumb). This is useful for sorting later.
• Allow selecting the CPU model (or custom: number of CPUs/cores/threads/AVX capability or SIMD rate or straight TFLOPs). This determines prompt processing for the part of the model that doesn't fit in VRAM. For extra credit successfully estimate MoE (which is more complex than dense models to do)
• Allow selecting RAM channel count, version, theoretical bandwidth. I.e. 8x2 16GB DDR4-2933 RDIMM per socket (2 sockets, 512GB total, bandwidth = 16x2.933GT/s = 375.424 GB/s).
• When model does not fit in VRAM: Force using 'sequential' calculation, factor in the cost of offloading to CPU.
• Assume 0.5GB of VRAM (can be changed) is in use for the desktop. (Set to zero to turn off for home servers. Note, this assumes Linux, on windows 10 and 11, you actually can only use 81-92%)
• Use a relevant benchmark for each use case, and import its values. E.g. UGI for roleplay, UGI NatInt for chat, UGI writing for creative writing, LiveBench coding for coding/agents, LiveBench Reasoning for RAG usage.
• Set a default 'speed minimum' and 'speed target' for each use case. Allow user to override this target with a text box. For example, for Chat/Roleplay, take the p50 and p95 of human reading speed as the minimum and target. These numbers are 5 tps and 12 tps respectively (using 1 token = 1 'word', because words are typically taken as being only 5 letters in wpm scores for typing/reading). The user should be able to change this minimum and target speed from this default suggestion.
• When rating models / sorting them, combine the speed target and the benchmark into a rating. I would suggest turning the speed into an S-curve with domain of 0 to 1, so that a model that meets the target scores say 0.95, while meeting the minimum receives 0.05, smoothly transitioning. (I can give a formula in a comment if you'd like)
• Allow the user to scroll down further than just the 3 best rated suggestions.
• Automatically pick between Parallel or Sequential if one is strictly better, present both if there is a trade-off. So you compute the output of both Tensor Parallel and Tensor Sequential. To compute parallel you have to check how many 'attention heads' the model has: the number of GPUs has to be a multiple of it. So if you have 7 GPUS and 12 Heads, 6 are used. If you have 16 GPUs for 8 Heads, then 2 groups of 8 are used sequential. If you want to be really fancy also factor in how much network load/latency you have; you may be capped by PCI-e bandwidth.
• When using multiple parallel GPUs with different speeds you use the slowest one. When using multiple sequential speeds add the time you need for a token for each one, then take the reciprocal. (Fill the fastest GPUs first for best results).
• Allow the user to specify the input:output ratio. Default to 20:1 (see data from Openrouter). Better yet: Default to a value that's realistic to the use-case and allow user to override.
• Compute the TPS based on both input and output. That is, compute the time t1 needed to input 20 tokens, plus the bandwidth t2 to output 1 token. Then present 1 / (t1 + t2).
• When "Tools and Agents" is selected, allow user to specify "Number of active agents". Check the compute:bandwidth ratio for output: it may be capped by compute instead of bandwidth with enough agents.
• Add "Creative Writing / Roleplay" as a use-case. It's different enough from Chat as the context tends to be longer, and different from Coding because the speed requirements are lower and quality is more important.
• Allow the 'custom' VRAM and RAM settings to be more specific: User should be able to enter both bandwidth and quantity in a text field, not select a dropdown with very limited options. You can have near limitless variety by combining various GPUs.
• When the user loads a model from Huggingface, display the stats of this model, regardless of fit, and always put the chosen models above the default ones. (That is, sort by this thing first if it's enabled).
• Suggest which hardware component to improve for these selected models. (You can use some heuristics to get a good guess as to what the bottleneck is; such as more VRAM if it doesn't fit yet, or more RAM if the MoE experts don't fit in RAM but the base model does fit in VRAM.)

But you're still not really done if you want this thing to be more than 'I have this hardware, which model should I use?' and also answer "I have this much money... what hardware and model to get the best result?"... you need to factor in price. It's possible to fetch/estimate that as well, you'd have to also know lifespan of the GPU/CPU (5 years?), usage factor (say 4 hours/day means 16%), cost of one KWh, power usage of the GPU, to arrive at an $/token estimate for a certain hardware config.

For example: 'I have a 3090, a 4070ti, and a 5060ti on a threadripper system, how long to I wait for a 500 token reply to my 10K input from my 70B model? <== Type of question to answer. Optimizing can get a little involved.