Hacker News

This is an exaggeration. The commitment scheme is related but different (Ligero vs Zook). Matmuls are different (Freivald vs Sumcheck), lookups are different (LogUp vs Grand Product), the packing is different.

What original ideas are in VerInf that are also in this work besides the choice of benchmark?

Not sure if this is sufficient attribution, but TFA at least mentions VerInf:

> VerInf proved Llama 4 Maverick (the same 400B-parameter MoE model we prove) at ≈0.02 tok/s.

Claude being a official contributor here gives me the shivers. This feels like setting up a case for: We have the rights for everything you do with Claude. Or rather what they do with Claude for you.

Sorry to hear. Just asking, why did you choose MIT license over something like GPL? It's not that they couldn't have copied you, but you would be in a different position vis-à-vis them now.

The claude contributeth and the claude taketh away.

> MIT license

Live by the sword, die by the sword...

I wonder if this is partially letting agents.. agent, agentically and not know where ideas come form or how they come together, only whether it works or not.

I’m so tired of hearing stories like this. The biggest most well funded corps in the history of mankind and all they do is steal the shit out of everything. It’s pathetic.

I hope you don’t get that wrong, but maybe your best option is to see it positive. The top comment on a first page post on HN, gives you some publicity. Potentially more than if that would’ve not have happened.

You can also use this and create explanation video on it on Youtube, post on X, Bluesky and other in-detail stuff that only you and very little people are in the position to do.

I’m sure some are interested, and this could lead to a hire, too.

I know it’s always easy to say and I probably have less adversity faced as most people, but I really try to see them as energy enablers. Of the almost infinite options you have in life there is a big chunk of realities that are better than your current ones an adverse event can trigger emotions and therefore energy and push one to do things one wouldn’t have done in comfort.

Thanks for your work!

> It would be very, very, very nice to provide a set of model weights and a proof that they had only been trained on a dataset. To be clear, this is a really hard problem, but it would change fundamentally what levels of trust we could have about a given set of weights.

Is it hard? Seems like it isn't that hard if you use NVIDIA's remote attestation/enclave support instead of trying to do everything with ZKPs which have always been something of a dead end. CC overhead 2%, ZKP 100x+ and gigabyte sized proofs - just for inference. It's never been competitive.

I'm very skeptical anyone would care about this for training though. I mean, if there's someone out there who genuinely really really wants proofs of the dataset used to train model weights, let's talk? But it seems the value is mostly for open weights inference providers. They can prove what weights they're serving and they can prove they can't see people's prompts. It would take a lot of the risk out of using a no-name LLM cloud service.

Unfortunately, after many years of this stuff I have become old and cynical. The stated/revealed preference mismatch is huge. The majority of people say they want privacy in theory but in practice won't trade anything off to get it, and especially not convenience.

I have been addressing this problem head on aggressively; https://github.com/emberian/whatember is the toplevel index. Things like arithmetizing parser/other automata to write semantic predicates (incl graph rewrites!) over training sets, inference requests, etc.

No, that has nothing to do with PoW. PoW is computing something intrinsically useless but very hard just to prove you spent all that time, but trivial to check.

ZkPs are expensive to check and even more so to generate because the problem is intrinsically very compute heavy. The ecosystem would immediately jump into a faster way of doing thing, compute time are seen as a flaw, not a feature.

> Of course, it's unlikely that we'll get open-weight models from OpenAI or Anthropic any time soon

This could be worked around by signing the output now and releasing the model after an embargo period, paired with contract penalties if the output of the released model does not match or the cryptographic scheme is compromised in the meantime. However, such guarantees would be worth little, since they can be just moved to a bad bank that defaults on them.

Is it cheaper to rerun it?

> The verifier runs on the client's CPU. It needs no GPU and only has access to a commitment to the weights. The client downloads the commitment, ~6.5 MB in all, and then one proof per request. Checking a proof takes 17 seconds on 24 threads (and 21 seconds on a single thread), including the offline phase's checks.

As a client that sounds like it might be much cheaper to verify than reprocessing.

Good luck rerunning the computation done on 8xB100 unless you aren't a cloud provider yourself

The main benefits are:

1. it proves your models are running correctly. FP ops tend to deviate in small amounts between hardware providers and tensor ops even more so due to the relatively new and unstable standardisation environment atm. So it proves your HW configuration is delivering outputs correctly. i.e. it's a good test for what is currently a very non-trivial validation environment.

2. it proves your external provider is running the inference they said they are. i.e. it eliminates the concerns of model providers running quantized versions silently behind the scenes since quantization breaks the proof and you need to use a new, updated proof signature for the quantized version.

3. likewise for fine tuned or tampered models. Or outright substitution for another model (ex the accusation by OAI and Anthropic that Kimi and DS and co are periodically forwarding requests to their platforms to harvest responses for knowledge distillation).

All in all it's a nice chain of trust utility if it can evolve out of the toy stage and reach production viability (since rn it's limited to int-only weights and 1k context which is practically useless atm).

For example, there are Chinese resellers that promise to provide access to Claude (which isn't officially available in China) and defraud users by substituting something else. They're obviously sketchy in all sorts of ways, but in theory, this would prevent one kind of fraud.

It might also provide an additional guarantee for users of Open Router and Fireworks.

>Who will find this useful?

It's worth reading past the opening paragraph before asking these kinds of questions:

>When a user sends a request to an AI model, today they have no way of knowing for certain that the model they selected is the one that generated the response. For everyday uses, in which users mostly care about the output and not necessarily which specific model produced it, this is a less pressing concern. But there are several cases where such assurance would be useful. For example, independent evaluators who test AI models before and after release need to know that the model they are evaluating is the model being served. Clients who use a model through a third-party routing service want assurance that the tokens came from the model they paid for. And if a cyberattacker modifies the token stream while pretending to be a given model, a user has no way to detect it from the output alone.

This is from the first paragraph in the Introduction.

Customers care about model output being correct, Anthropic cares about model output being generated by Anthropic model.

This solves for the latter with a bunch of handwaving for the former. The end goal is gonna be FUD for cheaper model routing because that obviously is at odds with their biz model.

Off the top of my head, it is useful when there are content-level proxies between the client and anthropic's API server, of which there are many these days.

I think it would catch that, at least for open weights. From the repo docs [1] it looks like this type of attestation is even supported for open weight models: you commit with the public weights and publish the seed, so anyone can recompute the commitment from the Hugging Face files and check the provider is running the exact checkpoint and quantization they say they are. That's what they did with their Maverick demo. That said, it only works for greedy decoding and short contexts for now, and it's 70-95x the GPU time, so there may be cheaper ways to do this like TEEs.

[1] https://github.com/anthropics/FlashProve/blob/main/docs/what...

Maybe it's possible to tell by looking at the size of that error?

> The integer version is generally expected and empirically tested to be within some small error rate of true floating-point inference generically (even taking into account non-determinism of floating-point computations), though this does not cover adversarially designed prompts.

> I mean it tells you that you're not being stiffed by Anthropic using a cheaper model and that they haven't literally been MiTMd, but that's kind of table stakes.

That's literally the most common gripe I see from Anthropic users and, so far from being "table stakes" there no existing mechanism by which those users could verify it is or isn't happening. If Anthropic can figure this out then most of this "is it just me or is Opus hurr durr today" noise can evaporate.

Anthropic here is solving one of their own problems, how to make sure you don't combine other company's models with their stuff for example, and make it sound as if they did it for you.

It makes the inference more expensive and helps controlling the users.

I think some model providers are implementing "eyes glaze over" where if you ask a boring simple question they route it to a cheap model but charge you for an expensive model, so consumers may want a proof of work certificate to know they're getting what they pay for.

I assume this alludes to their prior work with models running on smart TVs being able to setup inference on additional smart TVs. The idea being that you can't be sure that, having gone through the whole deployment process, your hardware has not been subverted to run a different model. Any level of "robust" code you can imagine to prevent this in the traditional ways could be subverted on the fly by a capable model.

> This moves unobservability layer to the system that collects the proofs.

I'd say it's adding security through a secondary system, rather than displacing security to a secondary system. Security by layers.

This sort of result is about steady progress. It's not practical, yet. This system only allows for 1k context, not even enough for a system prompt. But the authors have contributed several orders of magnitude of speedup on the current state of the art.

until your company gets sued for using Dangerous and Shoddy Foreign models and the boss says you can only use the Trustworthy and Premium Aligned labs' models.

In modern sv-wallstreet corporateness you need to be bashful over any attempt to do good for good’s sake.

I'm blind to the problem being solved here. Can you motivate it? Why do I need more than normal HTTPS on the token API?

So, you got beaten to the punch?

That's two entirely different types of things that are being verified.

Watermarking checks whether a _specific text_ came from a provider.

PI checks that the text (that you already know came from the provider) was produced with _a specific set of weights_.

PI is mainly useful for AI supply-chain security.

Not to the degree needed for actually verifying the things this verifies. You could probably quite easily produce a non-Claude model that generates text that conforms to Claude watermarking.

I think there are two gaps with the watermark:

- it only gives a high probability that the text was outputted from the model, whereas a crytographic proof is computationally infeasible to forge

- it cannot be traced back to the input. You could "wash" the output from one model into another and it would be watermarked by the latter. With the crytographic proof, if you have the input, output, and "commitment", you can verify your exact input was processed by the model (or so the model provider says).

More so that attestation requires the model to be running on secure hardware, which is hard to do across all models that a company like Anthropic serves.

In part because many of the accelerators they use may not support attestation, and even with ones that do, such as NVIDIA Blackwell, support is restricted to a single node (8 GPUs). Vera Rubin supports rack-scale encryption, but that is not broadly deployed yet and will not be the only accelerator they use to serve inference.