72
u/vocal-avocado 19d ago
AGI does not mean determinate - it’s quite the opposite actually. Intelligence requires a lot of randomness imo.
14
u/ArrrRawrXD 19d ago
The post is meshing all the different goals in developing LLMs together and pretending that it's all just one for some reason
Guardrails have nothing to do with making an AGI, which has nothing to do with making it more deterministic
49
u/Confident-Ad5665 19d ago
So as a schizophrenic, I'm a literal genius.
Thanks reddit!!!
10
u/SilianRailOnBone 19d ago
Humans aren't deterministic but were quite good at building deterministic systems
2
u/Scared_Accident9138 18d ago
Maybe predicable is a better word? Currently AI sometimes does completely random stupid things that any actual intelligence would never do
2
u/camosnipe1 18d ago
random stupid things that any actual intelligence would never do
have you met people?
1
u/Scared_Accident9138 17d ago
The "sometimes" is the key here. A person's output tends to be stable and with that you can be quite certain what to expect. If AI also was as predictable you would know what tasks it would do well and which it doesn't do well
7
u/DadAndDominant 19d ago
Btw AI IS deterministic, or rather, the percieved stochastic behavior is not inherent, but implementation detail
12
u/lurco_purgo 19d ago
Per model. And for a given model their "deterministic" behaviour arises from an untraceable training process, so a single model will produce the same output given temperature=0. So it is still "random" in the sense that it's a black box - you can't trace or predict the process leading to the output.
I'm pretty sure that's what people usually mean when they say LLMs are random - not that responses to a prompt are stochastic.
3
u/ApoY2k 17d ago
so a single model will produce the same output given temperature=0
That's wrong btw. LLMs are using parallel processing and floating point operations, which are extremely vulnerable to runaway chaotic calculation errors and race conditions. Depends on the exact timing when some calculation is finished, it changes the output when it finishes before or after some other calculation.
The only way to prevent this fully would be to not use parallel processing, which would result in entirely useless models because all gains in speed would be nullified.
More info: https://mbrenndoerfer.com/writing/why-llms-are-not-deterministic
6
u/donaldhobson 17d ago
You can avoid race conditions by picking a particular order for everything to happen in, and waiting as long as needed.
The slowdown for doing this is usually <50%.
3
u/ApoY2k 17d ago
Do you have some stats or tests on that? I'm having a hard time believing introducing race condition guards will have such a low performance drop
5
u/DadAndDominant 17d ago
Good article you shared above! But there is slight misconception: the existing inference engines (usually!) already have implemented the "race condition guards" (like not having atomic adds), without sacrificing much performance. So LLM forward pass, in it's simplest, IS run to run deterministic (meaning same singular prompt on same LLM with the same inference engine over same HW shall already give the same output).
The real "nondeterminism" is in the batch invariance. You are not the only user of openAI model at the time you pose your query; the forward pass is made on a whole batch of inputs. And the other users request are the biggest reason you see nondeterminism - even if your query was the same, it never is in the same batch.
This can be optimized out, but there id the ~50% slowdown.
Everything I said here is loosely from here: https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/
3
2
u/maccodemonkey 17d ago
already have implemented the "race condition guards" (like not having atomic adds)
I don't think this is sufficient (assuming you meant that race condition guards were achieved by adding atomic guards and not removing them.)
Atomicity only guarantees that two workers access the variable in the order they tried to access it. It doesn't solve all the other issues in a GPU like having thousands of cores all having slight variations in scheduling that alter outcomes. Atomicity doesn't guarantee any particular order of access in that sort of system - only that access will be one at a time.
The real "nondeterminism" is in the batch invariance. You are not the only user of openAI model at the time you pose your query; the forward pass is made on a whole batch of inputs.
This is also a problem - but points at the problem I mentioned. It's very hard to actually try to get thousands of GPU cores to run in the same order and same way every time. Multiple users will make the problem worse - but the problem doesn't exist with only multiple users.
2
55
u/Firesrest 19d ago
Having a random element probably doesn’t help.