Hacker News new | past | comments | ask | show | jobs | submit
Hi HN! I'm one of the Flide team.

We built Flide from scratch to make Jev-like decision model inference up to 9.5x faster than vLLM and SGLang, while keeping exactness.

Here is the source code: https://github.com/OmniJev/Flide

Look forward to hearing your feedback and ideas!

Under what specific circumstances is it actually 9.5x faster?

Are there any circumstances where it is just about as fast as something like vLLM? For instance, single user, single token/decision inference?

How did you achieve the biggest speed up?

Are there any tradeoffs? “While keeping exactness” implies not.

Are there any specifics about how one must structure their context to take full advantage of it?

loading story #50422934
Thanks for the questions! I think tancop's summary has already captured the essence, and I can add some details.

> Under what specific circumstances is it actually 9.5x faster?

The 9.5x is Qwen3.5-0.8B on QuALITY, one long article that has 5.8k tokens and 18 questions on average. The more questions share a context, the bigger the gain.

> Are there any circumstances where it is just about as fast as something like vLLM? For instance, single user, single token/decision inference?

Yes, with a state that has only a single question, it ranges from a near tie with 27B on a long input to more than 3x with a small model on a short input. In this case nothing is shared, so the gain only comes from lower per-request overhead, since Flide runs the whole forward pass as one prerecorded CUDA graph.

> How did you achieve the biggest speed up?

The big speedup comes from cases where one state carries many questions, where we only compute the shared context once. We achieve this by using a mask that keeps the questions from seeing each other, and each question carries the correct position index just as if it came right after the state, so we can get the answers in one pass. The second is the prerecorded CUDA graph.

> Are there any tradeoffs? "While keeping exactness" implies not.

There is no accuracy tradeoff, since each question gets the identical computation as if asked alone. What remains is floating-point rounding that shifts slightly with batch size in every engine, even for a question asked alone, and our results are still the closest to the FP32 results among all the engines.

> Are there any specifics about how one must structure their context to take full advantage of it?

To get the most out of it, you can put everything shared in the state and ask all the questions in one request. And for continuous agentic decisions, use --session-cache-gb to get a further speedup.