Start with the workload
Inference is two very different jobs sharing one model.
A local LLM first reads your prompt, then writes its answer. Those phases touch the same weights, but they ask radically different things from the hardware. Treating them as one workload forces a compromise before inference even begins.
Prefill is the reading phase. Hundreds or thousands of prompt tokens can be processed together, forming large matrix operations. Modern GPUs have specialized INT8 matrix machinery for exactly this kind of wide, regular work. Feeding that machinery the layout it expects can matter more than shaving another fraction of a bit from storage.
Decode is the writing phase. The model usually advances one token at a time, repeatedly walking through its weights. That loop is often constrained by how quickly bytes can move through memory. A compact representation therefore has a different advantage: it reduces traffic on every generated token.
Ordinary quantization chooses one physical representation and asks both phases to live with it. DualView separates the stored identity of the model from the execution view presented to a kernel. The model remains a quality-maximized Q7 representation; the runtime can expose those same weight values as signed INT8 when the prefill kernel benefits from a matrix-native path.
Wide work, many tokens, matrix throughput matters.
Narrow work, repeated weight reads, bandwidth matters.
DualView is not two independently quantized copies and it is not a quality trade at the phase boundary. It is one authoritative compact representation with two hardware-facing views.