So they knowingly deployed a configuration with an overflow risk, much like writing code with a buffer overflow exploit.
replyThey assumed that it wasn't like an overflow exploit, despite the fact that's exactly what they'd set up to happen, on the grounds of thinking the equivalent of, "oh this probably uses smart pointers, we'll be fine".
That's how I read it anyway.
Next sentence: "We expected the engine to return an error for any prompt it could not process, and our long-context tests returned successful responses, so we did not believe this to be an issue."
replyWhich is pointing the finger at Sglang, who also weren't responsible for this.
replyAt a minimum someone should have realized during testing that their utilization figures are off by 40%.
A much better title would be "Cloudflare configuration error leaked data between user sessions"
I mean they are responsible for this. It's definitely a bug on their end.
replydeleted
replyDoesn't matter, they could have marketed it as 1 million token window, you would then infer, get to 600k and get an error. You won't be able to finish your work, and you won't get credit for 600k tokens.
replyThey thought it worked up to 1m token window
replywhy would they think that? I'm not a pro, but I know you can't serve more than kv cache pool that you have. If you want to run concurrent requests, you need to have more kv cache pool than your context window. The entire thing is weird, my bet is they were thinking most people will be using about 100k cache, compacting, etc and not nearing 600k ever.
replyBro, I had to read this sentence in the context of the previous one, 3 fcking times.. and it sill does not make any sense to me.
replySounds like they are saying they tested with a long prompt and just tested for a failure, but the test likely would have seen that same KV cache leakage and just interpreted it as success.
replythank you...
replyI read that as you can only do a single prefill up to 681k tokens, separate from cache hit or generation. I think people try pretty hard to avoid a cache miss on sessions that long and rarely do standalone requests that big so the situation triggering this condition is rare. If you run a normal coding session with many turns it would get to 1M ok.
reply