Yeah, but then there's the size of KV cache needing to be read through that HBM interface for each token, putting a hard limit on the tok/s based on the memory bandwidth.
On some models a large context can be a notable proportion of the size of the weights themselves.
For example, qwen 3.8 27b uses ~64kb/token for the kv cache - so for a 256k token context that's ~16gb of the kv cache for a ~54gb model (assuming 2 bytes-per-param/f16 for both).
So if the current non-baked-in chip is already memory bandwidth bound, as is often the case for current hardware and models, and the "only KV cache in HBM" chip has the same total memory bandwidth, it can only ever be (54/16)=~3.4x faster for the baked in-silicon model.
EDIT: I guess actually (54+16)/16=~4.3x faster, as the current implementation would need to read that KV cache too :)
Yes, the "Big Scary Numbers" listing CCTV cameras per capita include private cameras, which can outnumber "public" (government, council and police) cameras by orders of magnitude. In the UK these include those owned by businesses and individuals, even things like ring doorbells cameras. There's no real equivalent numbers including that I can find for the USA. In 2024 there were some 16 thousand council operated cameras in London total [0] - well below the ~700k often touted including private cameras.
If you restrict it to just those public cameras, London would barely be in the top 10 of USA cities in public cameras per capita.
Sure, it's not good, but implicit in many comments here is "I'm glad it's not that bad here" (presumably the USA for most commentors), but in reality it is happening "here", has been happening "here" for some time, and in many ways is already much worse "here" already.
While I think many of the UK's actions around this are massive mistake, certainly don't read me as supporting it, at least understand that the big headlines and pointing away from home towards "Orwellian UK" is a misleading distraction.
There's the simple physics of a vtol craft when landing needing to push down a lot of a air very fast just to lift an average human - plus the weight of the craft itself. There's a reason helicopters today don't land on street corners even if there's no rotor clearance issues. And these "personal" VTOLs don't seem any lighter than a helicopter of a similar size - for example the "Air One" is twice the mass of a Robinson R22 - ~400 vs ~970 kg empty.
The idea that they would be common enough to seriously disrupt "personal transport", even restricting to the "premium" market as it's known today is crazy. Imagine a fancy party where every 10 seconds everyone on the red carpet is being blown away by the backwash of someone landing - also disrupting everyone else trying to land there at the same time.
No, but to most people the only exposure they've had to the term "Effective Altruism" (if they've even heard of the it) is morality-washing personal greed that never quite seems to get past the "accumulation" or "self-serving boondoggle" stages.
As a brand it's tainted. You might argue unfairly, but that's never mattered in "public brand perception" before.
No, not even close. The issue is simply exhaust velocity and reaction mass, that leads us into the tyranny of the rocket equation - in that you have to carry that reaction mass with you and accelerate that mass too. Even if you had magic infinite energy - e.g. it's supplied externally by a laser or similar.
Using the theorized maximum of 31km/s exhaust velocity of project orion (much higher than any current high impulse propulsion technologies) you'd need to have thrown out something similar to 10^42 times the probe's mass out the back at that 31km/s velocity.
That means to accelerate a 1kg probe to 1%c you'd need to start with a spacecraft holding a reaction mass equivalent to a few trillion suns worth of mass.
Hardly seems worth it.
It's all about exhaust velocity - increase that and it scales down quickly. Using the theoretical max of 500km/s of VASIMIR for example means it's only 400x the mass of the probe of reaction mass - but that's still theory and max thrust limits means it'll take the order of millions of years to reach that sort of speed.
And why not accelerate using swing-bys on moons and planets? Of course this gets harder the faster you're already moving, but IIUC Voyager 1 has roughly 0.01% c, and this was launched 50 years ago.
It might help a bit, as you mentioned that Voyager is currently going about ~17km/s, so nearly 0.005% c, so it's already nearly 1/200th of the way there to our target of 1% c.
But then you're at a velocity so far beyond the escape velocity of most bodies you'd need to be skirting stars, then black holes to get anything more, and that's where it dives straight into "sci-fi" rather than anything even close to theoretically possible. How far away even if a body like that? Will this "probe" even survive such an encounter?
So even with that sort of slingshot it's well within the "Estimate Rough Error" of my intial numbers. They're "order of magnitude back-of-the-envelope calculations" of spherical spaceships in an already unrealistically biased to make the numbers smaller vacuum (just reaction mass, no thought of any mass of the engine or spacecraft body itself, or containing the reaction mass itself, or anything like that).
I probably should have stated my assumptions - in that "Can we accelerate a probe" I assumed that:
- The "probe" is a significant size - if we define a "probe" as a "Single Ion" then we already do that at CERN and similar pretty regularly - 1kg was my assumption of "Useful Probe Mass"
- "We" - in that "humans" as we know them today, preferably in the realisic age of civilizations as we know them, or even better within the lifetime of a currently living human.
Also there's different levels of "theoretical". VASIMIR has only ever been shown in lab settings, so still "theoretical" as a propulsion technology. something like Project Orion is "theoretical" in that it's never been built, but likely just an engineering effort. IKAROS showed solar sails are "possible", but so many orders of magnitude away from what would be required it'll still be a significant engineering and development effort to even show the same idea at the required scale is possible. Things like lasers as remote energy sources haven't really got off the drawing board. And then at the extreme we have "theoretical" ideas like fusion rockets, which are more "Not show to be /impossible/" rather than anything we could even start at really building today.
And each step along that "further out into theory" path means more risks, and more changes that method is shown to be less useful than really desired.
Is there a short snd simple explanation for how these planetary slingshots work? To me the gravity that increases the vehicle speed on the way to the planet will decrease the speed on the way away. Thanks!
It mostly works because the object you're sling-shotting with is moving relative to the initial origin of the probe - if you can line it up so the object is moving in the direction you want to accelerate in you can get it to "drag" your probe along a bit.
The end result is the probe isn't moving any "faster" leaving the slingshot object than it arrived from that object's point of view, but it may well be faster from the origin reference frame.
The thing is to remember that the bodies you're launching from, and then slingshotting against, are moving very fast relative to each other already. It's like throwing a bouncy-ball against a moving car - when it bounces off it may be moving faster relative to you than when you threw it, but it's actually a lower velocity relative to the moving car's reference frame.
Space sails are super low thrust though, even lower than my VASIMIR example - so will take even longer to reach the desired speed - though they have the advantage of not having to carry the complex and heavy engine I ignored that in the rough estimates anyway.
So by the time they're theoretically close to the desired speed they'll be on the other side of the galaxy at least, even if it took millions of years to get there at the much slower average speed.
You can't use a solar sail for this, but if you use lasers, you can get a few newtons / GW of incident laser power. Sci-fi stuff but if you can make a very very light reflector that can somehow be cooled (microscopic IR dipoles come to mind), and a very very focused and powerful laser, you can go a long way. Not sure what the purpose of moving a thin metalized foil at a fraction of lightspeed would be, though :)
Yeah, many of the theoretical solar sail ideas fall down on what I consider a useful "probe" is, and what it can mass. As mentioned in my other comment, if you define the "probe" to be "a single particle" we /already/ do this all the time in particle accelerators. But it's clearly not a useful "probe" I believe the original thought experiment implied. A few hundred grams of super thin solar sail material is still very much in the "Not A Probe" definition in my mind.
Plus even the best laser dispersion quickly gets significant at the distances required to give the sail the time to accelerate at such a low thrust.
They're really simple - arguably the problem is people try to treat them as a single complex unit rather than just "5 junctions in a row". Trying to think of them as a whole is rather pointless and self defeating, as there's no real advantage to doing so.
Most people have no problems with the idea of a road network loop - such as around a block - but that's exactly the same thing from a driving point of view.
Even then the "reserved" section is a carve out guaranteed chunk to allow stuff that might need contiguous physical memory (display scan out buffers and page tables, for example) and similar.
The GPU can still happily use all the rest of the memory for other use cases - which tend to be the bulk of allocations anyway. Though there might be performance implications - for example "moving" buffer ownership to the GPU would need to evict CPU caches, and often 4k pages and tlb lookups can be a pretty inefficient situation for GPU-style accesses.
That's been pretty standard for any SoC for decades. And "differences" to apple's SoC are more implementation details.
Imgur were found to be in breach of the data collection laws before any "you must check IDs" laws were even discussed in parliament, let alone passed, where the guidance was pretty much "Don't get caught actively selling data you already know is from children". And even the punishment was pretty much writing a document of "we'll try not to do it quite so obviously next time", but they refused to do even that.
The "implied" link between their fines, them rejecting UK connections, and any new laws is very much a PR thing from imgur.
All the breathless online reporting seems to miss just how toothless the law was, and they still failed at following it.
Like I think the new verification laws are an unworkable mess at best, written by people with an idea similar to believing they could "ban one specific species of fish from UK territorial waters" by throwing the odd grenade in, but they're rather unrelated to what imgur actually did.
I remember this being a thing done a while back using linux's MTD/phram drivers - https://wiki.archlinux.org/title/Swap_on_video_RAM - not sure if that's still relevant though as I don't know how it'll interact with DRM and how it handles reserving some of the vram - the suggested limit using xorg.conf is probably pretty obsolete now.
That page also has a fuse filesystem implementation on top of opencl - https://github.com/Overv/vramfs - which may be more compatible.
On some models a large context can be a notable proportion of the size of the weights themselves.
For example, qwen 3.8 27b uses ~64kb/token for the kv cache - so for a 256k token context that's ~16gb of the kv cache for a ~54gb model (assuming 2 bytes-per-param/f16 for both).
So if the current non-baked-in chip is already memory bandwidth bound, as is often the case for current hardware and models, and the "only KV cache in HBM" chip has the same total memory bandwidth, it can only ever be (54/16)=~3.4x faster for the baked in-silicon model.
EDIT: I guess actually (54+16)/16=~4.3x faster, as the current implementation would need to read that KV cache too :)
reply