There is a distinct moment when a small language model is pushed beyond simple chat and its output starts to unravel. The 3D scene loses coherence, lighting becomes inconsistent, perspective fails. The model does not lack knowledge of individual elements; it lacks the ability to orchestrate them into a stable whole. An experiment described on a research forum starts from that observation: what if the planning discipline of a larger model could be externalized into a scaffold — a procedural framework that smaller models can reuse?

The hidden scaffolding

The scaffold is not a more refined prompt. It is a set of contracts and constraints derived from a Three.js domain: plan first, define subject, environment, lighting, and camera, then build in layers, preserve silhouette, add identity cues, avoid pure primitive objects, audit the final output. It does not modify model weights nor require fine-tuning. It is injected into the inference context like a rail that forces the model to follow a logical sequence.

Preliminary manual results show asymmetric improvements. The larger model, already competent, improves mainly in polish; the smaller models jump in structure and readability. It is as if the small model knows how to cook but forgets the order of courses: the scaffold hands it the script and the meal becomes presentable.

Why it matters for on-premise deployment

Here a path opens that is relevant for local LLM deployment. Organizations evaluating self-hosted models face a well-known trade-off: massive models demand GPUs with tens of gigabytes of VRAM, high energy consumption, and costly infrastructure. Smaller models run on modest hardware — sometimes a single consumer card — but struggle to maintain structural coherence in complex tasks such as scene generation, code writing, or analytical reporting.

If a scaffold derived from a nearby domain can transfer procedural discipline without additional training, then there is the possibility of boosting quantized or compact models, the very ones that today land on enterprise servers or edge appliances. There is no claim of matching hundred-billion-parameter monsters, but the prospect of achieving organized output with reduced computing resources is tangible. And that directly impacts TCO (Total Cost of Ownership) and data sovereignty: less cloud, more local control.

The next test: separating code from rendering

The experimenter now plans a blind test: an external evaluator will compare only the rendered images, without seeing the source code or knowing which model produced them. The hypothesis is that the scaffold will lift the small models’ scores well above baseline. If the result holds across hundreds of varied prompts, it would no longer be a mere improvement of a single example, but a transfer of a reusable procedure, something akin to a procedural skill.

A wider perspective

The experiment touches a raw nerve in current research. Much of the effort to improve small models goes through fine-tuning or distillation, with costs for dataset preparation and training cycles. An approach that acts only at inference time, without altering the model, is lighter and potentially more flexible. If the concept is validated, we might see the emergence of libraries of domain-specific scaffolds: one for SQL queries, one for Python code generation, one for robotics. Each would externalize the wisdom of a large model into a structure reusable by slimmer ones.

Granted, we are still in early stages. The results are manual, the test is not blind, the sample is limited. But the direction points to a pragmatic path for those working with LLMs on controlled hardware: instead of chasing the most powerful model in the cloud, one could start thinking about layering intelligence, where planning is supplied from outside and the model executes. For AI-RADAR, the signal is clear: inference-time strategies are becoming as critical as the model choice itself. And on-premise, with its constraints, is an ideal terrain to experiment with them.