this post was submitted on 08 Apr 2026
804 points (98.7% liked)

196

6001 readers
1775 users here now

Community Rules

You must post before you leave

Be nice. Assume others have good intent (within reason).

Block or ignore posts, comments, and users that irritate you in some way rather than engaging. Report if they are actually breaking community rules.

Use content warnings and/or mark as NSFW when appropriate. Most posts with content warnings likely need to be marked NSFW.

Most 196 posts are memes, shitposts, cute images, or even just recent things that happened, etc. There is no real theme, but try to avoid posts that are very inflammatory, offensive, very low quality, or very "off topic".

Bigotry is not allowed, this includes (but is not limited to): Homophobia, Transphobia, Racism, Sexism, Abelism, Classism, or discrimination based on things like Ethnicity, Nationality, Language, or Religion.

Avoid shilling for corporations, posting advertisements, or promoting exploitation of workers.

Proselytization, support, or defense of authoritarianism is not welcome. This includes but is not limited to: imperialism, nationalism, genocide denial, ethnic or racial supremacy, fascism, Nazism, Marxism-Leninism, Maoism, etc.

Avoid AI generated content.

Avoid misinformation.

Avoid incomprehensible posts.

No threats or personal attacks.

No spam.

Moderator Guidelines

Moderator Guidelines

  • Don’t be mean to users. Be gentle or neutral.
  • Most moderator actions which have a modlog message should include your username.
  • When in doubt about whether or not a user is problematic, send them a DM.
  • Don’t waste time debating/arguing with problematic users.
  • Assume the best, but don’t tolerate sealioning/just asking questions/concern trolling.
  • Ask another mod to take over cases you struggle with, if you get tired, or when things get personal.
  • Ask the other mods for advice when things get complicated.
  • Share everything you do in the mod matrix, both so several mods aren't unknowingly handling the same issues, but also so you can receive feedback on what you intend to do.
  • Don't rush mod actions. If a case doesn't need to be handled right away, consider taking a short break before getting to it. This is to say, cool down and make room for feedback.
  • Don’t perform too much moderation in the comments, except if you want a verdict to be public or to ask people to dial a convo down/stop. Single comment warnings are okay.
  • Send users concise DMs about verdicts about them, such as bans etc, except in cases where it is clear we don’t want them at all, such as obvious transphobes. No need to notify someone they haven’t been banned of course.
  • Explain to a user why their behavior is problematic and how it is distressing others rather than engage with whatever they are saying. Ask them to avoid this in the future and send them packing if they do not comply.
  • First warn users, then temp ban them, then finally perma ban them when they break the rules or act inappropriately. Skip steps if necessary.
  • Use neutral statements like “this statement can be considered transphobic” rather than “you are being transphobic”.
  • No large decisions or actions without community input (polls or meta posts f.ex.).
  • Large internal decisions (such as ousting a mod) might require a vote, needing more than 50% of the votes to pass. Also consider asking the community for feedback.
  • Remember you are a voluntary moderator. You don’t get paid. Take a break when you need one. Perhaps ask another moderator to step in if necessary.

founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] atopi@piefed.blahaj.zone 16 points 22 hours ago (1 children)

the response it gives is not consistent

[–] KindnessIsPunk@lemmy.ca 45 points 22 hours ago (2 children)

Say it with me everyone: LLM's are non-deterninistic by design.

[–] voodooattack@lemmy.world 8 points 17 hours ago (3 children)

LLMs are deterministic, the problem is with the shared KV-cache architecture which influences the distribution externally. E.g the LLM is being influenced by other concurrent sessions.

[–] kersplomp@piefed.blahaj.zone 1 points 2 hours ago* (last edited 2 hours ago) (1 children)

Almost all clients do some random sampling after softmax using temperature. I’m confused why someone who knows about kv caching would not know about temperature. Also shared kv cache while plausible is not standard in open source as of a year or so ago, so i’m curious what you are basing this off of. Did I miss a research paper?

[–] voodooattack@lemmy.world 1 points 1 hour ago

Almost all clients do some random sampling after softmax using temperature. I’m confused why someone who knows about kv caching would not know about temperature.

I know what temperature is. Modifying the probability distribution is still not randomness. Because even the random sampling is PRNG based.

The issue you’re not spotting is that it’s still deterministic because a binary system cannot source entropy without external assistance or access to qbits, it’s why even OS kernels have to do a warm up at boot and read all accessible analogue signal sources they can reach, and why PRNGs still exist to begin with.

Also shared kv cache while plausible is not standard in open source as of a year or so ago,

Shared KV-cache is an economic necessity for big providers, otherwise 1M context windows wouldn’t be a thing.

so i’m curious what you are basing this off of. Did I miss a research paper?

Empirical testing, 20 years of experience coding and tinkering with simulators, and Chaos Theory basics. The papers are out there, you just gotta cross some domains to see it.

[–] qqq@lemmy.world 9 points 17 hours ago (1 children)

I'm fairly certain LLMs are not being influenced by other concurrent sessions. Can you share why you think otherwise? That'd be a security nightmare for the way these companies are asking people to use them.

[–] voodooattack@lemmy.world 6 points 16 hours ago (1 children)

Any shared cache of this type makes behaviour non-deterministic. The KV-Cache is what does prompt caching, look at each word of this message, now imagine what the LLM does to give you a new response each time. Let’s say this whole paragraph as the first message from you and you just pressed send.

Because the LLM is supposedly stateless, now the LLM is reading all this text from the beginning, and in non-cached inference, it has to repeat it, like token by token, which is useless computation because it already responded to all this previously. Then when it sees the last token, the system starts collecting the real response, token by token, each gets fed back to the model as input and it chugs along until it either outputs a special token stating that it’s done responding or the system stops it due to a timeout or reaching a tool call limit or something. Now you got the response from the LLM, and when you send the next message, this all has to happen all over again.

Now imagine if Claude or Gemini had to do that with their 1 million token context window. It would not be computationally viable.

So the solution is the KV-Cache. A store where the LLM architecture keeps a relational key-value store, each time the system comes across a token it has encountered before, it outputs the cached value, if not, then it’s sent to the LLM and the output gets stored into the cache and associated with the input that produced it.

So now comes the issue: allocating a dedicated region for the KV-cache per user on VRAM is a big deal. Again try to imagine Gemini/Claude with their 1M context windows. It’s economically unviable.

So what do ML science buffs come up with? A shared KV-Cache architecture. All users share the same cache on any particular node. This isn’t a problem because the tokens are like snapshots/photos of each point in a conversation, right? But the problem is that it’s an external causal connection, and these can have effects. Like two conversations that start with “hi” or “What do you think about cats?” Could in theory influence one another. If the first user to use the cluster after boot asks “Am I pretty?”, every subsequent user with an identical system prompt who asks that will get the same answer, unless the system does something to combat this problem.

Note that a token is an approximation of what the conversation means at one point in time. So while astronomically unlikely, collisions could happen in a shared architecture scaling to millions of concurrent users.

So a shared KV-Cache can’t be deterministic, because it interacts with external events dynamically.

[–] qqq@lemmy.world 4 points 16 hours ago* (last edited 16 hours ago) (1 children)

Hm this tracks to me. I've wondered for a bit how they deal with caching, since yes there is a huge potential for wasted compute here, but I haven't had the time to look into it yet. Do you have a good source to read a bit more about the design decisions or is this just a hypothetical design you came up with and all of that architecture detail is "proprietary"?

If the first user to use the cluster after boot asks “Am I pretty?”, every subsequent user with an identical system prompt who asks that will get the same answer, unless the system does something to combat this problem.

This is very interesting to me, because I'd think they were doing something to combat that problem if they're actually doing something multi-tenant here.

Wouldn't the different sessions quickly diverge and the keys would essentially become tied to a session in practice even if they weren't directly?

Thanks for the response it's definitely something I've been trying to understand

Edit here, thinking a bit more,

So the solution is the KV-Cache. A store where the LLM architecture keeps a relational key-value store, each time the system comes across a token it has encountered before, it outputs the cached value, if not, then it’s sent to the LLM and the output gets stored into the cache and associated with the input that produced it.

This seems like an issue, no? Because the tokens are influenced by the tokens around them in the attention blocks. Without them you'd have a problem, so what exactly would be cacheable here?

[–] voodooattack@lemmy.world 4 points 16 hours ago* (last edited 16 hours ago)

Do you have a good source to read a bit more about the design decisions or is this just a hypothetical design you came up with and all of that architecture detail is "proprietary"?

You’re welcome. Here’s an intro with animations: https://huggingface.co/blog/not-lain/kv-caching

And yes. Most of the tech is proprietary. From what I’ve seen, nobody in ML fully understands it tbh. I have some prior experience from my youth from tinkering with small simulators I used to write in the pre-ML era, so I kinda slid into it comfortably when I got hired to work with it.

Wouldn't the different sessions quickly diverge and the keys would essentially become tied to a session in practice even if they weren't directly?

Yeah, but the real problem is scale and collision risk at that scale. Tokens resolution erodes over time as the context gets larger, and can become “samey” pretty easily for standard RLHF’d interactions.

Edit:

This seems like an issue, no? Because the tokens are influenced by the tokens around them in the attention blocks. Without them you'd have a problem, so what exactly would be cacheable here?

This is what they do: (from that page I linked)

Token 1: [K1, V1] ➔ Cache: [K1, V1]
Token 2: [K2, V2] ➔ Cache: [K1, K2], [V1, V2]
...
Token n: [Kn, Vn] ➔ Cache: [K1, K2, ..., Kn], [V1, V2, ..., Vn]

So the key is the token and all that preceded it. It’s a kinda weird way to do it tbh. But I guess it’s necessary because floating point and GPU lossy precision.

[–] boonhet@sopuli.xyz 2 points 12 hours ago (1 children)
[–] voodooattack@lemmy.world 1 points 9 hours ago

I didn’t say they normally aren’t. What I’m saying is that a shared KV-Cache removes that guarantee by introducing an external source of entropy.

[–] SlurpingPus@lemmy.world 4 points 20 hours ago (3 children)

Are they? Making a non-deterministic program is actually not that easy unless one just feeds urandom into it.

[–] qqq@lemmy.world 6 points 18 hours ago* (last edited 18 hours ago) (2 children)

The guts of an LLM are 100% deterministic. At the very last step a probability distribution is output and the exact same input will always give the exact same probability distribution, tunable by the temperature. One item from this distribution is then chosen based on that distribution and fed back in.

Most people on lemmy literally have no idea what LLMs are but if you say something sounding negative about them then you get a billion upvotes.

[–] SlurpingPus@lemmy.world 4 points 18 hours ago* (last edited 18 hours ago) (2 children)

chosen based on that distribution and fed back in

Do I understand it correctly that the LLM's state is changed after execution? That does sorta mean that it's effectively non-deterministic, though probably not as severely as with an RNG plugged in (depending on the algorithm).

[–] SparroHawc@lemmy.zip 5 points 17 hours ago

The only thing that changes is the data that is passed to the LLM, which for each iteration includes the last token that the LLM itself generated. So yes, sort of. The LLM itself doesn't change state; just the data that is fed into it.

It's also non-deterministic insofar as similar inputs will not necessarily give similar outputs. The only way to actually predict its output is to use the exact same input - and then you only get identical token probability lists on the other end. Every LLM chatbot, by default, will then make a random selection based on those probabilities. It can be set to always pick the most probable token, but this can cause problems.

[–] qqq@lemmy.world 5 points 18 hours ago* (last edited 17 hours ago) (1 children)

There must be an RNG to choose the next token based on the probability distribution, that is where non-determinism comes in, [edit: unless the temperature is 0 which would make the entire process deterministic]. The neural networks themselves though are 100% deterministic.

I understand that could be seen as an "akschually" nitpick, but I think it's an important point, as it is at least theoretically possible to understand that underlying determinism.

[–] SlurpingPus@lemmy.world 4 points 17 hours ago (1 children)

Well, technically users' input could serve as the source of randomness, if it's fed into modifying the internal state. Basically, a redditor is trying to interrogate the LLM as to whether Israel is bad, while someone on line 2 is teaching the LLM “I am Cornholio”. We already know how it goes when a chatbot is learning from its users, and generally the effect could vary arbitrarily from a nothingburger to a chaos-theory mess.

[–] qqq@lemmy.world 2 points 17 hours ago

I don't think it's typical to consider user input a source of randomness. Are you talking about in context learning and thinking about what would happen if those contexts get crossed? If so, contexts are unique to a session and do not cross between them for something like ChatGPT/Claude.

[–] KindnessIsPunk@lemmy.ca 2 points 17 hours ago

I was speaking about the user visible behavior, the context that I was replying to.

[–] criss_cross@lemmy.world 4 points 17 hours ago

For an end user yes because they’re not going to be able to adjust temperature and seeds. So you can have different results give the same input of a “prompt”

Under the hood it’s deterministic but end users don’t have anyway of tweaking that unless they set up something like comfyui and run this shit themselves.

[–] anothercatgirl@lemmy.blahaj.zone 6 points 20 hours ago

yes they consume urandom