> the resulting commitment is good for about 16 million requests, after which the provider has to commit again.
> 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 check
I know they mentioned $ETH in the technical report, but this is exactly the mechanic for a crypto currency Proof-of-Work which is expensive by design.
When they announced it, I was hoping for a 5% overhead validation that the model that served you is really Fable and not Opus.
The quantization bit caught me out, because we saw the boundary crossing from good-context-size to bad is so sharp it feels like longer context requests are sent to quantized models to make more room for more KV-Cache. This would expose those sorts of tricks people can play to have the same GPU do better on short context benchmarks and gracefully degrade on long context.
At work, we did a bit of digging[1] into exactly why BaseTen, Fireworks and Together serve Inkling weights differently, we suspected the issue was a combination of how you do disaggregated prefill (+streaming) and quantization for longer context tasks.
[1] - https://isotopes.ai/blog/everyone-is-selling-the-same-model-...
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.