• 4 Posts
  • 1.8K Comments
Joined 2 years ago
cake
Cake day: March 22nd, 2024

help-circle










  • I wouldn’t use the word “desperate.”

    Scaling is inefficient.

    For training, it takes a ton of work to even get half-decent utilization across a bunch of servers, and it makes any sort of experimentation with architectures immensely more difficult.

    Hence allegations that some GPUs are assigned “busywork” just to meet utilization quotas from the hardware seller.

    For inference, scale isn’t so important. But the demand for tokens is self inflicted: from Meta shoving chatbots in ramdom places in software, and from their architecture being archaic and inefficient.


    In other words, none of this has to be. It’s just the whims of one insecure man, surrounded by sycophantic tech bros, who’s feeling FOMO but doesn’t understand transformers LLMs at all.

    If he had half a brain, he wouldn’t have fired the team that literally founded the open weights LLM space.

    But he’s also too rich to ever feel the consequences of bad decisions now.



  • It’s not democracy though.

    Whatever the ideals of cypto are, however user friendly could be made, in reality, it’s just fundamentally too easy to be abused.

    As-is, it’s one of those “it would work fine if everyone learned it in detail, and grifters would go away” ideas, and that’s not going to happen.

    Democracy is fragile and exploitable too, but it has a track record of working across general populations for reasonable lengths of time.


  • Rarely of course, something is so complicated that it actually takes more time to come up with the right code than do a review. But that is only a rare thing.

    This is definitely a thing though.

    On this very topic, many llama.cpp PRs are good examples. A model trainer may present a PR with poor understanding of the (very complicated, highly specialized, sparsely documented) project. Then a maintainer comes to fix it, but has absolutely no knowledge of certain things the model trainer would know (“Oh, the whole thing NaNs if this one value on layer 23 isn’t FP32!”)

    There has to be a back-and-forth. A whole lot of it.


    That is an exception, yeah.

    But I’m not sure I’d call it “rare.” There are definitely situations where fixing without explaining is ultimately a whole lot of work.



  • I think it will massively correct, like the dotcom bubble for websites. LLMs are a useful utility, but not something that’s going to make economics irrelevant (like people thought about the internet).

    Why? LLMs are tools, text models, not AGI magic lamps, and a couple of con artists are trying to convince the world otherwise. That’s an oversimplification, but the jist of it.

    And I’m no LLM skeptic. I’ve been playing with ML as a hobby for a decade, with local LLMs before ChatGPT was even available, but the market attitude towards all this is absolutely bonkers. It’s worse than crypto.




  • It’s more complex than that. The weights of big models are distributed, and then tokens are processed in parallel for multiple users. The setup varies, but it could be 8 GPUs serving many dozens of users at once, or bigger sets with even more parallelism.


    I think the bigger problem is that Copilot is… shit.

    It’s probably some ancient, inefficient architecture, not something super sparse and hardware efficient like (say) Deepseek V4, or Kimi 2.6, or Gemini Pro.

    And literally every interesting dev team Microsoft has ever acquired (Phi, WizardLM, many more), and any interesting innovation they figured out, has just disappeared into a black hole.

    They don’t have custom hardware, either, like Huawei NPUs or Cerebras WSEs, or Google TPUs. They’ve written some very interesting papers on that, and proceeded to do squat with them.

    Also, it is AWFUL for its size. Tiny models that are basically free run circles around CoPilot.

    What I’m getting at is that CoPilot is probably the most inefficient LLM out there. Like, it’s impressive how bad it is.


  • I use sigma N sampling at 1.0, a slop phrase banlist, and maybe a little rep penalty.

    Beyond that it depends on the usage.

    For scripts or “questioning a document,” it’s as low as can be until it loops. I start with zero temperature. But I don’t really use Gemma for coding, TBH, and it’s not good for longer documents.

    If it’s for a specific language or a very specific script, I sometimes constrain grammar for the language.

    For more “general” writing, like brainstorming or RP or whatever, I start at around 0.7 with minimal DRY sampling and look at the logit percentages in the Mikupad UI. Especially “important” tokens like names or information recall. If the probability of getting correct answers is too low, I turn the temperature down.

    …But honestly, I tend to use big MoEs instead of Gemma for that, too.


    And if none of this makes any sense…

    Yeah. That’s the problem.

    Sampling was supposed to be a temporary stopgap until looping and such was figured out, but the big LLM devs just never addressed it in production. There are all sorts of interesting papers, including one from Google about sampling logits per-layer, but they don’t implement any of them in the API models.