shad0w

Stop Waiting for Answers Your Local Model Already Knows

Waiting seconds for an answer your local model has already figured out hundreds of times is a familiar frustration.

4 min readMachine Learning

We are watching the wrong bottleneck. For months, the conversation around local AI has centered on model size, quantization, and hardware. shad0w points at something more practical: the model already knows the answer, and you are still waiting for it to say so. This project sits in front of any OpenAI-compatible server, logs responses, and after roughly a thousand examples builds a small table that answers repeats on CPU in microseconds. It only steps in when its cached answer matches the model's judgment 95% of the time on held-out examples. Everything else still goes upstream.

That threshold is what makes this worth your attention. A shadow model that guesses is just a cache with extra steps. A shadow model that knows when to stay silent is a genuine optimization. The project respects the difference between repetition and reasoning, and that discipline is rare in a space where most tooling optimizes for speed at the expense of correctness. The same principle shows up in Smarter resource use: how batching transforms LLM performance, where the win comes from grouping requests intelligently rather than pushing raw throughput. shad0w takes that idea further: do not process the request at all if you already know the outcome.

The practical implications are immediate for anyone running classification workloads locally. If you are using Ollama for tasks like sentiment tagging, intent detection, or content moderation, you are paying seconds per message for questions the model has answered hundreds of times. That is not a model limitation. It is a workflow design flaw. shad0w compiles those repeated answers into a lookup table that runs on CPU in microseconds, which means your interactive tools stop feeling like they are thinking and start feeling like they are responding. The Precision scoring models that skip text generation for faster decisions approach attacks the same latency from the model side, treating decisions as closed-set scoring rather than generation. shad0w attacks it from the infrastructure side. Both recognize that the slowest part of most AI interactions is the ceremony, not the computation.

The Snake demo is the part that makes you pause. The system learned moves from an LLM and now plays at ten moves per second, faster than the model that taught it. That is not a gimmick. It is a demonstration that the distilled behavior of a model can outrun the model itself for narrow, well-defined tasks. The same logic applies to your data pipelines, your support triage, your document classification. You do not need to retrain anything. You need to acknowledge that most of your workload is memory wearing a costume.

The open question is where this breaks. The 95% agreement threshold is conservative, but it will still misfire on edge cases, and the project explicitly invites reports of failure. That is the right attitude, and it is the detail to watch. The tool is Apache-2.0, written in Python, JS, and C, and it works with any OpenAI-compatible server. If you run local models for classification, stop treating latency as a cost of doing business. Start treating it as a bug you can fix.

From Machine Learning

project: https://2796gaurav.github.io/shad0w/

If you use a local model for classification, you know the wait: seconds per message, for questions it has answered hundreds of times. shad0w sits in front of any OpenAI-compatible server (Ollama works out of the box: llm="ollama/llama3.1" or `shad0w proxy --upstream http://localhost:11434/v1`), logs the model's answers, and after ~1,000 of them compiles a small table that answers the repeats on CPU in microseconds. It only answers where it agrees with your model 95%+ of the time on held-out answers; everything else still goes to the model.

Read the original at Machine Learning