So, if I'm understanding correctly, this is just for lower bandwidth transfers of full BF16 weights over the wire, not for serving, correct? Have you benchmarked the performance against a SOTA general purpose compression algorithm like zstd?
Also, are all that many people handling the BF16 weights directly? GLM-5.2's reference deployment is FP8, and many vendors are even serving at NVFP4 which seems to offer negligible degradation over the FP8 reference deployments.
You can even go a step further and run the container in a VM, such as with Docker Sandbox or the krun runtime in Podman.
There's also smolvm which is a nice minimal microvm manager based on libkrun: https://github.com/smol-machines/smolvm. I vibe coded a little shell utility for building and running OCI images for the Pi harness using it (easy enough to do manually, but the automation just makes it a couple quick commands rather than digging through documentation): https://github.com/neuroblaze/smol-pi
Not my field, but since they use SQUIDs I suspect most of the volume is taken up by cryo equipment. So, maybe if someone eventually discovers a room temperature superconductor.
Okay buddy, that was a Gish gallop if I've ever seen one.
The risk is real. The math isn't complicated, you could stand up a basic debris simulation in a few hours with numpy from first principles. And we also know it's real because it's actually happened multiple times now: https://en.wikipedia.org/wiki/Satellite_collision
This is a real thing that satellite operators worry about all the time. Conjunction analysis and risk modeling leading to a go/no-go decision is something that real satellite operations centres do daily.
I don't know if an LVT is the answer, but we do need to figure out some way to make operators consider space sustainability efforts, especially if they are launching systems with such density that they make subsequent operation in those shells significantly riskier.
VLEO addresses the risk, sure, but the new Starcloud space datacenter hype machine isn't going VLEO, it's going 600-850 km. Those altitudes are in the years to decades range for deorbit, and SpaceX has filed for 88,000 of them.
Nobody is arguing that space isn't big. The argument is space is big but dynamic, and launching enough stuff up there means that over a sufficiently long time horizon, you will have a collision between uncontrolled objects. This is not a theoretical concern, it has already happened [1].
Collision risk is significantly reduced by having maneuverable spacecraft with good conjunction prediction systems in place. But fundamentally, nothing is perfect and accidents can and do happen - you set a maneuver threshold based on an expected collision probability, but it's an engineering tradeoff: "spend the fuel to maneuver out of the way of everything, no matter how remote, or accept a small collision risk?"
And of course, when you are launching thousands of satellites, you will have a few failures that will become unmaneuverable hazards. Just the way it goes, you can't realistically engineer your way to perfect reliability.
So sorry, I have to reject your claims that it's "utter bullshit." Space debris risk is a well studied field, so much so that satellite insurance companies are starting to fold those calculations into insurance premiums. So yeah, it's real, and it deserves more than a pithy dismissal.
Not at all, it can be handled via international treaty. Frequency allocations for civilian satellites are already handled this way, a UN body (the ITU Radiocommunication bureau in Geneva) acts as a neutral party that handles satellite spectrum coordination between UN member states.
The ITU has no enforcement power, but fundamentally that doesn't really matter much, since enforcement is handled by the member states. Are there attempts by various member states to skirt around the rules or favour their own national interests? Of course, and sometimes these are successful - but nobody just outright ignores the rules, because they know it very quickly leads to a tragedy of the commons.
Administering an orbital LVT is exactly the kind of thing that could slot cleanly into an expanded ITU mandate. Where the money goes would be up for debate, but I think the cleanest solution would be ITU rebates most of it back to the government of the country that applied for the orbital slot provided that they demonstrate it's going into a space sustainability fund.
Is it perfect? No, but it's based on a rickety-but-mostly-works international model and it doesn't require global government conspiracy theories to come to fruition.
Eh... no, not really. At low altitudes (<500 km), sure, but much above 600 km you are starting to look at decades for a passive deorbit depending on solar cycle and ballistic coefficient.
I mean, presumably, the tax would apply per-spacecraft with a price adjustment for orbit lifetime and how busy a particular orbit is, so a small constellation of 5-10 short lived microsatellites wouldn't have a huge entry barrier.
Ooh, I hadn't seen these yet! That looks quite compelling, my only hesitancy would be what the software support looks like. But 1 TB of memory for $110k is really intriguing - I might go bother a sales rep. Thanks!
Anyone done any benchmarks on the NV4FP quant? Seriously considering pitching an 8 x RTX 6000 Pro box at work to run GLM-5.2 in an air gapped environment.
Thanks so much for building smolvm! I liked it so much that I vibe coded a little bash wrapper around it to handle creating ephemeral VMs for Pi: https://github.com/neuroblaze/smol-pi
Consists of two scripts, one to build an OCI image (customizable by editing the Dockerfile that comes with it) and another to handle smolvm invocation. The invocation script mounts the current working directory under /workspace in the VM and the user's ~/.pi directory under /root/pi, and handles any other setup (eg: I have some convenience flags set up to specify a block all/block local/block internet/allow all for network access).
One issue I ran into, it doesn't seem like smolvm cleans up disk images from ephemeral VMs, so my script has to do that itself. Is this a known bug or intended behaviour?
As with most legal hacks, the courts figured this one out long ago :).
If someone is trying to dig into their competitor's trade secrets via discovery, the court offers multiple ways to safeguard against that. The defendant can identify information as a trade secret and ask that it be protected in some way - for example, the documents may be restricted to "Attorneys' Eyes Only", so while the plaintiff's attorneys can review the material, the plaintiffs themselves are barred from reviewing it. Or the judge themselves may get involved in an in-camera session.
Setting aside how shortsighted it is to fire your employees to replace them with AI, Ford also screwed up by firing the wrong employees. LLMs work best in the hands of experienced senior engineers who can work at a high level of abstraction because they already understand all the pieces underneath.
In a sense, using an LLM agent is like providing instructions to a very smart, very quick junior who despite being brilliant has some blind spots and lacks institutional knowledge. That's something that seniors excel at, so by firing your seniors you've fired the people best positioned to make full use of LLMs.
I wonder if Nico will be feeling so cocky when Papermark gets their general counsel involved. The public Twitter shaming was clearly an attempt to resolve this without litigation, but hey, if that's how Nico truly feels, guess he gets to see what's behind door #2 (a massive bill for a legal retainer).
Also, are all that many people handling the BF16 weights directly? GLM-5.2's reference deployment is FP8, and many vendors are even serving at NVFP4 which seems to offer negligible degradation over the FP8 reference deployments.