• 0 Posts
  • 92 Comments
Joined 1 year ago
cake
Cake day: June 7th, 2025

help-circle

  • I’m not an expert by any means I’m just a dabbler, but my understanding is: In theory, more parameters make richer, wider, and deeper model knowledge possible, and with extensive enough training, those parameters could all be important. That said, there is a lot of megapixel-like inflation and there is no guarantee that any of those parameters are actually useful so in practice, really “advanced” models tend to do a better job of maximizing the usefulness of the limited parameters they do have to run on smaller devices. In general, I tend towards the highest parameter size of a particular model that I can reasonably run. My typical target range is between 8GB up to maybe 20GB, which depending on model might be in the 9b to 30b parameters range, and I might even be erring on the wrong side of this and maybe I’d even be better off with smaller parameter models.

    There’s also a lot of models nowadays that use “active” parameters, so the model itself will have X parameters, but then it will determine which of those parameters are most relevant to the task or query at hand, and prune off all but the most relevant ones, so you might have a 30B model, but as soon as you run it, it turns itself into a specialized 4B model. You still need to load the whole model into some kind of RAM typically so it can decide which parameters are relevant, but once it does, it will run much faster. This is another way you can try to run larger models on more limited hardware. Older “dense” models that don’t use this technique with all parameters always active are still typically preferred for some tasks like coding, but YMMV.

    Either way, it’s still sort of a crapshoot, there’s a lot of randomness and subjectiveness, and very small parameter models often seem to realistically be able to outperform much bigger models when they are “good”, “well-trained” advanced models, and they will typically be much faster, so if you don’t like the response, it’s much easier to just ask again or retry. I tend to trust the community wisdom when it comes to this, although I also think there’s a lot of cargo-culting and herd-following going on, I don’t know enough to do anything too much different from the herd myself, other than be willing to experiment a little. Latest is not always greatest, but in a field as quickly moving as this it often is. Don’t be afraid to try older models, or less popular models. You’ll often be disappointed, but not always.

    Quantization is a form of compression, basically instead of using floating point precision to weigh the “strengths” of the various parameters (default is typically F16 or 16 bits per parameter weight), they get quantized down to smaller groups of bits. Q4 means you’re using 4 bits (essentially ranking each parameter on an integer scale from 0 to 15 instead of a floating point from 0 to 1) and in practice this is usually almost as good. Q8 would be even closer to the original full-size model, but smaller quants like Q2 and Q3 start losing quality. Other quantization-related techniques like i-Matrix (imat) map these values non-linearly and situationally, which is particularly helpful on quantizations Q3 and smaller, which are then called IQ3. The community has adopted Q4 as pretty much the go-to quantization level as the best available compromise between having more parameters being squeezed into less memory without destroying the inherent accuracy of those parameters.


  • For chat usage (which is strictly a more efficient way to generate code on the LLM’s part, although you have to keep carefully guided and compartmentalized otherwise it typically requires a lot more testing and sometimes back-and-forth iteration on your part) 12GB is plenty to run many decent LLMs, you’ll typically want to use a Q4 quantization to make models with larger parameter fit into smaller memory, sometimes an IQ2 or IQ3 if you really want a particular model.

    For agentic usage (where the LLM is trained and optimized to use a harness like this to start requesting tool calls and getting their results and using the results of the tool calls to inform what it’s trying to do) it’s quite a bit more challenging to do on consumer hardware at a tolerable speed. The tools often generate large amounts of output which then take a long time to process, and the models and harnesses are both typically quite a bit stupider about using your limited resources efficiently. If you’re using to commercial “frontier” agentic models like Claude Code you’re going to have a bad time.

    That said, it is absolutely possible to do agentic AI on consumer hardware (just the GPU you have, not 6 of them), as long as you’re reasonably patient, using a harness properly tuned for efficiency. Out-of-the-box, many if not most are designed for remote API usage, even the “open source, local” ones realistically rely on free tier APIs and are inherently wasteful in terms of them not really caring how many tokens you burn in these remote datacenters and they’re expecting to just be able to iterate over and over again until they get it right. You don’t have that luxury when you’re getting slow tokens.

    Is PewDiePie’s any better or more efficient? I don’t know, I haven’t tried it yet. I prefer more minimal harnesses personally, OpenCode is about the most usable I’ve found personally, although I’m starting to experiment with Pi-mono (called Pi, but that’s unsearchable) which seems very promising, and I know quite a few people who have had good successful agent usage with Hermes Agent.

    I’m not going to pretend it’s going to be easy or that you’ll necessarily have very good results. I am pretty lukewarm on AI as a whole, but I am personally deeply invested in making sure I have fully local access to it in as much capacity as is currently technologically possible, as a personal digital sovereignty issue.

    As for hardware, I have a 12GB card myself and you don’t really need to fit everything into VRAM these days. I have an AMD X3D CPU which allows me to offload some of the model to system RAM with pretty decent performance, maybe it’s prohibitive on different architectures or configurations I don’t know but it’s worth a try. glm-4.7-flash:Q4_K_M from ollama is the model I’ve had the most consistent success with and with ollama running it with the context window set to 50,000 (context should also be set to be quantized to Q4_K_M), I end up with almost half of it offloaded to system RAM and it still runs quite fast thanks to the flash attention feature. I’ve worked with gemma4 quite a lot too and it’s definitely really fast but it’s also a bit unstable/weird at times, at least the heretic version hf.co/Stabhappy/gemma-4-26B-A4B-it-heretic-GGUF:Q4_K_M I’m running is. Still, if you really do need to fit everything into a smaller set of RAM you might try the gemma4 E4B models which clock in around 9GB when quantized. Qwen3.6 is I guess supposed to be really good too and should fit nicely on your 12GB card, but I haven’t had much opportunity to play with it yet. Qwen3 and 3.5 felt rather disappointing to me for agentic use but YMMV.

    You’re not completely going to outsource all software and all code you write to AI using a local model, the way companies are doing with those commercial models. But I consider that an advantage, not a flaw. I find it’s much more useful to have it help, suggest and advise, not to completely replace everything I’m doing. Yes, sometimes it’s slow and sometimes it’s wrong, but so are other people when I ask them sometimes. I’m prepared for it, and you should be too. Don’t get complacent.




  • Yes. mine is exposed publicly (with fail2ban) on a VPS with a public IP and a public DNS name and it’s fine. Use a minimal configuration that meets your needs, use secure passwords like you would for any public service and keep it up to date, and stay aware of any potential news that might make you aware of any severe and widespread vulnerabilities in the future (there haven’t been any in Nextcloud so far). It is not nearly as terrifying as people make it out to be to share public services on the public internet. Most decent software is secure-by-default. Yes vulnerabilities and attacks can happen but they are the exception not the rule.



  • Maybe if the model trains could actually bring in your groceries and mow your lawn they’d be comparable. Granted, self-hosted software can’t do those exact things either, but it can do an awful lot of the digital stuff that’s part of our lives now which often takes up just as much time and effort if not more. Model trains are a banger hobby, but homelabbing can easily be more than just a hobby, it’s deeply practical too, and I’d argue it’s actually a necessity for establishing personal digital sovereignty and privacy going forward.




  • Trying to use an immutable docker container to host a program that notoriously self-installs and requires self-updates is, I’m pretty sure, something that comprises one of Dante’s circles of hell.

    Wrong tool for the job. Don’t do this. I consider docker harmful at the best of times, but this is truly something horrible to try to do with it. I’ll never understand why people (not just OP, but also developers like Valve) insist on defying and sabotaging and actively working around the distro’s package manager. Your software is not a special snowflake, it does not need its own magical install method and its own perfectly curated libraries. Just fucking use what’s what the system is already providing and if certain libraries don’t have a stable enough interface and have conflicts between versions so bad that you can’t even have any different major versions you require installed alongside each other concurrently, then start shaming them or replacing them with alternatives, because having a compatible-except-for-bugs-and-edge-cases library interface is not such an unreasonable ask for a modern system and toolchain. And then we can all just peacefully use our distro’s package manager like our lord and savior Debian intended.







  • It’s trivial if your project is trivial. Once you’ve got development/CI/CD workflows, releases, issue management, community interaction, maybe even project management or Github pages (may god have mercy on your soul), it gets a lot less trivial.

    Git itself is a distributed version control system, moving it around is indeed trivial. It’s everything else that Github provides that is far less trivial, and they’ve worked hard on building the vendor lock-in elements for those things lately.


  • I love KDE, but as someone who exclusively uses KDE already I have little visibility into Gnome or any other alternatives really, and I’m a little surprised they aren’t defaulting to Gnome since that seems to be the default choice for many distros. Besides my personal feelings that it’s a bit ugly and very clunky to configure, anyone feel like ranting about the drawbacks of Gnome or other desktop environments so that I can feel educated and continue to justify their and my choice of KDE to myself? :)


  • Email chains and mailing lists are not really a practical way to develop anymore, and it is increasingly anachronistic (as is the idea of tying your identity to an email which is also baked into basic git). This was the only realistic democratic and federated option when git was designed, but it was never the ideal one. Forgejo is trying to build a better, more ideal, also-federated alternative that is really designed for code collaboration from the ground up. Once the design is stabilized, there’s no reason it couldn’t get built into git also. I would love to be able to create a PR with git itself and have it automatically submitted to the origin repository.