1548 RPM should be slow for a small GPU fan, no? My Nvidia 3090 behaves exactly the same, switching the fan on and off as it hovers around 60C or so.

Looks like it’s working fine to me.

Also, take linux GPU monitors with a grain of salt. It’s possible the GPU fan RPM measurement is totally borked, and it basically represents “on” or “off.” Check it with your eyes and ears instead, see if the fan is screaming or not. It shouldn’t be below 76C (as modern GPUs are configured to operate above 80C or so).

I mean, you are right, and way more people should be using openSUSE :P

I will say Arch-derived distros are a good experience if you want to learn how the terminal and other systems work. They’re engineered to be configurable; the documentation is great. But if you just want to use your computer without opening too many hoods, it’s fundamentally not an optimal system.

Another thing is that many people just want their new laptop to work, and for it to game on linux. Sometimes it does not just work. If you start pulling in fixes and packages that are not supported on your distro, you can screw up any distro very quickly (and this includes the AUR, unofficial Fedora repos and such). If the community packages these, stages them, tests them against all official packages, and they work out-of-the-box… that’s one less hazard.

Yeah, it uses only ram swap by default. If you aren’t going over a ton, it shouldn’t matter.

I just have weird workloads that spike memory usage a ton for short times, so I have to go out to my nvme.

Exactly, and you can get mesa git and some other “fix” packages natively with community integration if you find you need them, without veering off track all by yourself.

I skipped nobara for that very reason.

And I was more familiar with Arch anyway.

Actually I had this one!

Something about their swap config makes it very fragile unless you use RAM swap as enabled by default, and I kept having this when I disabled it for reasons. It was much better once I re enabled it, though occasionally I still have severe issues going way, way, over my RAM pool.

I don’t mention that much because swapping to like 64GB on a 32GB system seems like an uncommon use case.

I see people saying CachyOS is finicky, but I’ve had almost no issues in two years of extensive use.

And anything that pops up gets fixed extremely quickly.

What’s better, everything you need for gaming is in the repos by default and pre-tweaked, no need to fuss with it like other distros. This is my nitpick with Fedora or Arch AUR: once you go outside the curated, officially supported packages, you are asking for trouble.

Almost all of Qwen 2.5 is Apache 2.0, SOTA for the size, and frankly obsoletes many bigger API models.

These days, there are amazing “middle sized” models like Qwen 14B, InternLM 20B and Mistral/Codestral 22B that are such a massive step over 7B-9B ones you can kinda run on CPU. And there are even 7Bs that support a really long context now.

IMO its worth reaching for >6GB of VRAM if LLM running is a consideration at all.

deleted by creator

For local LLM hosting, basically you want exllama, llama.cpp (and derivatives) and vllm, and rocm support for all of them is just fine. It’s absolutely worth having a 24GB AMD card over a 16GB Nvidia one, if that’s the choice.

The big sticking point I’m not sure about is flash attention for exllama/vllm, but I believe the triton branch of flash attention works fine with AMD GPUs now.

Basically the only thing that matters for LLM hosting is VRAM capacity. Hence AMD GPUs can be OK for LLM running, especially if a used 3090/P40 isn’t an option for you. It works fine, and the 7900/6700 are like the only sanely priced 24GB/16GB cards out there.

I have a 3090, and it’s still a giant pain with wayland, so much that I use my AMD IGP for display output and Nvidia still somehow breaks things. Hence I just do all my gaming in Windows TBH.

CPU doesn’t matter for llm running, cheap out with a 12600K, 5600, 5700x3d or whatever. And the single-ccd x3d chips are still king for gaming AFAIK.