Recent submissions

Comment · 1 month ago
This is incredibly misleading. OpenAI internal systems were pwned, and in all cases, the labs absolutely are responsible for their models.

Yes, vendors are also irresponsible, but this misses the point.

Comment · 1 year ago
“Model Control Plane” - quite early to already re-use a popular acronym
Comment · 1 year ago
Congrats on the launch!
Comment · 2 years ago
+1 it wouldn’t be terribly useful if it were only caching the tokenizer output.
Comment · 2 years ago
Where is the lie in this repo?
Comment · 2 years ago
I think if you actually meet the people you'd realize they're pretty earnest and candid of these things' limitations, though it may not show in tweets and hackernews posts.

This repo, for instance, makes no claims of AGI. It just claims to help bootstrap a starting point for a software project: "it will not attempt to write the logic to fill in the nodes and edges."

Comment · 2 years ago
But indexing *is* training. It's just not using end-to-end gradient descent.
Comment · 2 years ago
Dang they use Transformer-XL from 2019 haha - didn't realize people still used that / XLNet-like architectures
Comment · 2 years ago
It is not.
Comment · 2 years ago
Congrats on the launch!
Comment · 3 years ago
Cool. Important note:

""" One may ask whether the conditionality introduced by the use of CMM does not make FFFs incompatible with the processes and hardware already in place for dense matrix multiplication and deep learning more broadly. In short, the answer is “No, it does not, save for some increased caching complexity." """

It's hard to beat the hardware lottery!

Comment · 3 years ago
It’s only a matter of time
Comment · 3 years ago
Given that GPTZero was an undergrad’s side project it’s not that surprising?
Comment · 3 years ago
Attention is Turing complete
Comment · 3 years ago
For things like BERT where you just want to extract an embedding, the naive way you reach full utilization at inference time is that you :

- run tokenization of inputs on CPU

- sort inputs by length

- batch inputs of similar length and apply padding to make of uniform length

- pass the batches through so a single model can process many inputs in parallel.

For GPT-style decoder models however, this becomes much more challenging because inference requires a forward pass for every token generated. (Stopping criteria also may differ but that’s another tangent).

Every generated token performs attention on every previous token, both the context (or “prompt”) and the previously generated tokens (important for self consistency). this is a quadratic operation in the vanilla case.

Model sizes are large , often spanning multiple machines, and the information for later layers depends on previous ones, meaning inference has to be pipelined.

The naive approach would be to have a single transaction processed exclusively by a single instance of the model. this is expensive! even if each model can be crammed into a single A100 , if you want to run something like Codex or ChatGPT for millions of users with low latency inference, you’d have to have thousands of GPUs preloaded with models, and each transaction would take a highly variable amount of time.

If a model spans multiple machines, you’d achieve a max of 1/n% utilization because each shard has to remain loaded while the others process, and then if you want to do pipeline parallelism like in pipe dream, you’d have to deal with attention caches since you don’t want to have to recompute every previous state each time

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton