Sanzig

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.

More like $500k, but that's not an unreasonable price for a medium sized enterprise to pay.

I have an RF engineering background, a nice mmWave vector network analyzer can easily land in that ballpark.

If the business value is there, companies will pay for it.

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.

[1] https://en.wikipedia.org/wiki/2009_satellite_collision

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.

My issue is we likely can't use AWS (non-US, CLOUD Act concerns + export control concerns).

Cheers, thanks for the quick turnaround!

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.

Most likely, Papermark would compel Corgi to disclose the source code during discovery.

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).

Yep, agreed. Main issue in Canada is a notoriously slow and stingy investment ecosystem. Resource-wise we're incredibly well positioned.

Ideally yes, but we know people don't RTFA - there's a reason that initialism dates back to early Slashdot.

The paraphrase is doing a lot of heavy lifting to convert it to ragebait. Had the OP gone with something like "you didn't vibe code it, you plagiarized Papermark's open source project" (may need some editing to fit under the character limit) it would have at least been more true to the original tweet.

The tweet was fine - it was directly addressing Corgi's claim that they had "vibe coded" DataRoom when they had copied and pasted it from Papermark. The problem is the OP chose to perform a contextectomy on the tweet and make it look like it's making a completely different argument.

Yeah, the title that the OP chose is so sufficiently misleading that I think this one will need to be get changed by the mods. Seitz isn't opining on the ethics of vibe coding in his tweet, he's pointing out that Corgi literally just stole Papermark's AGPL codebase and passed it off as vibe coding.

Same issue in Canada - domestic inference capability for the open models is woefully behind.

There's a blanket statement at the bottom of the pricing page, which I would hope also applies to GLM-5.2:

Where are models hosted?

Ollama hosts models and compute resources primarily in the United States. To serve global demand, we may route to Europe and Singapore for additional capacity.

Is my prompt or response data trained on?

Prompt or response data is never logged or trained on.

Who does Ollama partner with to host models?

Ollama collaborates with NVIDIA Cloud Providers (NCPs) to host open models.

When Ollama partners with providers, we require no logging, no training, and zero data retention policies in place.

Take a look at Ollama Cloud: https://ollama.com/pricing

You get access to a whole bunch of bleeding edge open models including GLM-5.2, Kimi K2.7, DeepSeek 4 Pro, etc. Inference is run on US/SG/EU cloud providers with zero data retention policies. The $20/mo tier is very generous, in my experience.

It's always a shock to me how opaque most other models are!

This is (unfortunately) by design. The proprietary models hide their reasoning traces so they can't be used for model distillation. Sometimes even when they do show reasoning, it isn't the model's real trace - IIRC, someone was able to demonstrate that Opus' reasoning is usually a summary made with Haiku behind the scenes.

Oh, I wholeheartedly agree! My "bigger problem" statement can be read as "a bigger problem for the US government."

Agreed that you can export-control the closed source models pretty well (although I think the administration is gravely underestimating the long-term damage that will do to the US economy).

The bigger problem will be if someone (such as a Chinese AI lab) releases a Fable/Mythos-class open weight model. That you can't really export control successfully. Sure, you could class it under EAR or ITAR, but that's just going to make using it difficult for American companies, not everyone else. It would be a stupid protectionist measure that would only hurt the US - so I fully anticipate the admin would try it.

It'll depend on what law they're restricting it under. The obvious play would be to put it on the Commerce Control List so it's covered by the EAR (Export Administration Regulations). If so, compliance is pretty well-understood, just a giant pain in the ass that'll pretty much limit use of these models to companies that already have EAR/ITAR compliance offices.