Matrix multiplication is the arithmetic floor of a language model, and quantization has been quietly making it a strange one. To fit a model onto a phone, a laptop, or a robot, its weights get squeezed down to very low precision — four bits, two bits, sometimes one — while the activations flowing through it stay at something like FP16. What you are left with is not a normal matrix multiply. It is a mixed-precision one, an operand mismatch that no general-purpose CPU has an instruction for. The standard escape hatch is dequantization: inflate the low-bit weights back up to a width the multiply-accumulate units actually understand, then multiply as usual. It works, and it is faintly absurd — you pay full freight for precision you deliberately discarded, on arithmetic silicon most CPUs do not have much of.

A patent application published July 16, 2026 — US20260203368A1, "METHODS FOR LOOKUP TABLE-BASED MIXED-PRECISION MATRIX MULTIPLICATION," assigned to Microsoft Technology Licensing, LLC and naming Mao Yang, Shijie Cao, Ting Cao, and Lingxiao Ma — describes taking the other exit. If a weight is only one bit wide, the set of products it can possibly participate in is small and finite. So do not compute them. Enumerate them once, write them down, and look them up.

Decompose, precompute, index, aggregate

Independent claim 1 is a method, and it lays the mechanism out in four moves. First, decompose: an n-bit weight matrix is split into a series of n separate one-bit matrices, which turns one n-bit problem into n one-bit problems and means a single mechanism covers every quantization level rather than needing a bespoke kernel per bitwidth. Second, precompute: an m-bit activation matrix is received — the abstract specifies m>n, activations wider than weights — and a lookup table of partial matrix multiplication results is generated from permutations of groups of that activation matrix against the one-bit matrices. The record's worked example in FIG. 4 uses groups of four, which enumerate into a sixteen-entry table; a table read now stands in for a four-element dot product. Third, index: the packed weights stop being operands and become addresses, with g-bit groups of the input weight matrix used directly as table indices. Fourth, aggregate: the retrieved partial results are summed into the final mixed-precision result. Multiply-accumulate becomes lookup-plus-add, and the cost tracks weight bitwidth linearly instead of exploding.

None of that is novel by itself, and the application says as much. Lookup-table approaches to this problem have been tried, and the description is unusually candid about how they went — the passage below is the filing's own account of the prior work, not a claim of scope.

The LUT-based approach has been explored on graphics processing units (GPUs). These methods leverage the GPU's shared memory or cache to store and access the lookup tables. However, despite the theoretical reduction in computational complexity, the practical kernel performance is worse than dequantization-based kernels. The suboptimal kernel performance is attributable to the constraints of the GPU's fixed architecture, which offers either inadequate storage capacity for the lookup tables or insufficiently rapid table access.— METHODS FOR LOOKUP TABLE-BASED MIXED-PRECISION MATRIX MULTIPLICATION, US20260203368A1

Read that carefully, because it is a narrow technical observation about why particular kernels lost to particular alternatives on particular memory hierarchies — not a market position. And it locates where the disclosed inventive weight actually sits. If the theory says lookups should win and the practice says they lose to table access latency, then the problem is not the algorithm. It is where the table lives. Dependent claim 2 is the whole thesis in one clause: "The method of claim 1, wherein the lookup table is stored in a register of a central processing unit." Not DRAM, not cache — registers, the fastest storage on the machine.

Everything else in the description reads as engineering in service of that constraint. Registers are scarce, so the tables have to be small and reused hard: the filing describes a lookup-table-centric data layout with axis reordering and tiling to maximize table reuse, table quantization and mirror consolidation to shrink the tables themselves, and weight interleaving to sidestep the reordering cost that little-endian unpacking would otherwise impose. The lookups are performed with SIMD shuffle instructions that commodity processors already ship — the record names TBL on ARM and PSHUF on x86. The application is also honest about the bill: its FIG. 3 comparison counts 144 8-bit registers for the lookup-table method against 104 for llama.cpp. That register pressure is a cost the described techniques then work to mitigate, not a result. The scoped payoff the description states is deployment of large language models on edge devices using widely available CPUs, without relying on GPUs and without compromising computational efficiency.

The filing does not stop at software. Independent claim 10 recites a computing system, and independent claim 18 goes further into hardware, reciting a CPU with a register and at least one LUT unit built on a bit-serial circuit architecture comprising N×M multiplexing units, tiling a table array in the register and broadcasting grouped binary weights and table entries across those multiplexers. That is claimed subject matter — a description of a circuit, not an inventory of one. The record contains no performance figures of any kind, and it is a published application rather than a granted patent, so what it establishes is the shape of an approach, not its measured merit. Claims narrow; abstracts do not benchmark. One implementation detail is worth flagging precisely because of how easy it would be to over-read. The description discusses T-MAC and llama.cpp directly, noting that "when integrating T-MAC into llama.cpp, there may be a conflict between the llama.cpp threadpool and the TVM threadpool" — the kind of sentence that only appears in a document written by people who have actually run the thing. It is implementation discussion inside a specification. It is not an announcement of a shipped integration, a release, or a roadmap. The inventor names do overlap the published T-MAC authorship out of Microsoft Research Asia, which is an observation about people; the record does not declare the application to be that work's patent, and neither will I.

Three levers, one problem

The hero does not arrive alone. Microsoft has twelve applications in this day's drop, seven of them AI- or ML-related, and three of those read as different levers on the same cost. US20260203368A1 makes inference cheaper by computing less. US20260203643A1, "Inference Acceleration of a Model using an In-Place Mixture-of-Experts," makes it cheaper by activating less: it converts an existing model into a mixture-of-experts in place by locating subnetworks and adding a router that scores on hidden state plus subnetwork saliency, then fine-tuning. And US20260203652A1 makes it cheaper by shipping something smaller, training a student model from a teacher with a contrastive loss blending forward KL on teacher samples and reverse KL on student samples. The MoE and distillation records share four inventors. That throughline is my reading of the day's filings, drawn from their titles and abstracts — not a statement of strategy from anyone. The rest of the cluster fans out from serving into science. US20260203604A1 attacks generative latency from the product side rather than the kernel side, serving a cached item instantly while an AI-generated one is produced asynchronously into a slot that has not rendered yet. US20260203530A1 describes conditioning model responses by injecting linked-entity context into a prompt data structure. And well off to the side, US20260204338A1 describes fragment-based quantum mechanical calculation of protein properties, chopping a polypeptide into overlapping three-amino-acid fragments to make the calculation tractable — a different domain, but recognizably the same instinct as the hero: when the whole problem is intractable, decompose it into pieces small enough to actually finish.