Some of the inference engines can process multiple requests in parallel more efficiently than doing them sequentially. Not sure of the exact mechanism but e.g. llama.cpp's llama-server can do this (you tell it the number of slots to have when starting, then fire HTTP requests at it and it batches them together when it can).
Waiting for the hooman (or tool calls) won't help either, of course.
Disk space is one thing, but the actual download size is higher than some people's data allowances altogether!
It baffles me that a lot of people don't seem to be aware of this
Disagreed; it's not a download you'd expect and it's also at least an order or two of magnitude than you'd expect to find reasonable for browsing a page.
I have a 2GB mobile data plan. If I was using Chrome, then some site triggers the Prompt API, that will cause Chrome to not only wipe out my data plan, but need 2 of my data plans. I don't find this reasonable.
This is exactly a consent problem, because I'm not denying it might be a useful feature, but it should be at the user's own informed choice.
The fact that Chrome developers don't appear to see this might be due to them living in a bubble where they've never had to think about the costs.
Worth noting that NVIDIA confidential computing and similar schemes have been compromised and shouldn't be relied upon if it really matters. See https://tee.fail/ and similar.
A while ago I checked this out and the homepage looked like it had fallen to the 'AI hype' trend, you know like how everything was 'AI-native XYZ for Autonomous Agents' at the time. I'm not seeing that now though.
Am I thinking of someone else or did you reverse on that?
Weird; I clicked through out of curiosity and didn't get any corruption of the sort in the end result.
I also asked it some technical details about how diffusion LLMs could work and it provided grammatically-correct plausible answers in a very short time (I don't know the tech to say if it's correct or not).
Sounds interesting, but if I may: the website is exceedingly sluggish, something like 1-2s interval between re-renders when trying to scroll the page (Firefox Linux). Not seeing any reason to explain this based on the page content but it's not happening with anything else on my system atm
edit: maybe `WARNING: Falling back to CPU-only rendering. Reason: webGLVersion is -1` from the console explains why, although I don't get why the page would need webGL
I was going to use Firecracker in an untrusted code execution project (not AI stuff); any chance you'd be happy to elaborate a bit on how you found it a pain to use? Thanks :)
`WHERE status = 'pending'` is not enough to avoid the performance problem, even if you have an index on `(status)`, because the index will still contain dead tuples until it is vacuumed.
Rough intuition: Postgres doesn't immediately delete rows, it just marks them as invalid after a certain snapshot version/transaction ID (and this mark is in the heap, not the indexes, AFAIK).
Every potential tuple that your index returns, Postgres needs to visit the heap to see if that tuple is alive. UNLESS all the tuples in that heap page are alive, in which case an optimisation called the 'visibility map' allows that check to skipped (relevant for Index-Only Scans, where Postgres can get all the results for your query from the index directly).
The only way to avoid the problem is therefore to either vacuum frequently enough that Postgres doesn't get any dead tuples returned from the index (that it must then visit the heap to check for liveness), or to bake in some condition to your queries that prevents the dead tuples from being returned from the index altogether.
Vacuuming frequently is expensive and conflicts with having long-running transactions, so the latter option is generally the choice to go for when it matters.
[n.b. I feel I should note I am not a Postgres developer and wouldn't call myself an expert, just an enthusiast and dealt with a few problems here and there. So what I say should be taken with a grain or two of salt, though I believe it to be accurate.]
For disk usage, yes this doesn't address anything.
But for read performance (which is IMO what the section in the article was motivated by), it doesn't actually matter to have a bunch of entries corresponding to dead tuples in your index, provided Postgres doesn't need to actually consider the dead tuples as part of your query.
So if you have a monotonically increasing `job_id` and that's indexed, then
so long as you process your jobs in increasing `job_id` order, you can use the index and guarantee you don't have to keep reconsidering the dead tuples corresponding to jobs that already completed (if that makes sense).
[This is because the index is a b-tree, which supports efficient (O(log n) page reads for n entries) seeking on (any prefix of) the columns in the index.]