westwaters/pollard-weights

Пограничные модели. Маленькое оборудование. Никаких компромиссов.

*Знайте, что ваше оборудование может работать *, прежде чем ** вы загрузите - затем создайте модель, измеренную в соответствии с ней, и отправьте ее в любое время выполнения.

Pollard Weights - это модели, созданные для памяти целевого устройства, а не для памяти. бит-ширина графика. Внимание, маршрутизаторы и встраивания сохраняют высокую точность; эксперт FFN несут сжатие; горячие слои сохраняют больше битов, когда вы кормите строителя. Измеренный профиль маршрутизации — и вся сборка размером с любую RAM/VRAM Вы указываете на это, за вычетом рабочего резерва.

** Любая цель, любое устройство — нет фиксированного диапазона размеров. Скажи, что цель бюджет ([T0]/[T1]) и подходит **, что ** — телефон или Pi (сотни МБ), 16 ГБ Mac Mini, 24 ГБ 5090, 256 ГБ сервер, 512 ГБ вафельный узел. ** Построить на одном Машина, развернуть на другой ** - большой диск коробка, на которой вы строите, как правило, не где Модель работает, поэтому --ram — это бюджет *цели, а не сборка машины. [3] только тогда, когда они одинаковы. Примеры 16 ГБ, приведенные ниже, представляют собой Демо, а не потолок.

** Одно измеренное распределение, семь выходных полос** — GGUF (llama.cpp/Ollama/LM) Разработчик: Trellis Флагман на ik llama.

Pollard Weights are models built for a target device’s memory, not for a bit-width chart. Attention, routers and embeddings keep high precision; expert FFNs carry the compression; hot layers keep more bits when you feed the builder a measured routing profile — and the whole build is sized to whatever RAM/VRAM you point it at, minus a working reserve.

Any target, any device — there is no fixed size range. Tell it the target’s budget (--ram/--vram) and it fits that — a phone or a Pi (hundreds of MB), a 16GB Mac Mini, a 24GB 5090, a 256GB server, a 512GB wafer node. Build on one machine, deploy to another — the big-disk box you build on is usually not where the model runs, so --ram is the target’s budget, not the build machine’s (--ram auto only when they’re the same). The 16GB examples below are just a common demo, not a ceiling.

One measured allocation, seven output lanes — GGUF (llama.cpp/Ollama/LM Studio; trellis flagship on ik_llama.cpp), MLX (Apple), GPTQ (vLLM/SGLang), MX (NVFP4 / MXFP4 / FP8 / MXFP6 and measured mixes, Blackwell / Vera Rubin), EXL3 (exllamav3), EXLR8 (one trellis encode, every rung a manifest), and DRAFT (a speculative-decoding drafter matched to the quantized target) — pick the runtime, keep the allocation. Every lane ships the whole model (vision / audio towers included), and every lane lands in one repo per model.

How it works

flowchart LR
    HF["FP16 / BF16model"] -->|"optional: smooth · abliterate(pollard-hf-smooth / -abliterate)"| ALLOC
    ALLOC["Pollard measured allocation(sensitivity → KL knapsack)"] --> GGUF["GGUF · llama.cpp"]
    ALLOC --> GPTQ["GPTQ · vLLM / SGLang"]
    ALLOC --> MLX["MLX · Apple Silicon"]
    ALLOC --> EXL3["EXL3 · exllamav3"]
    ALLOC --> MX["MX · NVFP4 / MXFP4 / FP8 / MXFP6Blackwell / Rubin"]
    ALLOC --> EXLR8["EXLR8 · GR8 / reference decode"]
    ALLOC --> DRAFT["DRAFT · speculative drafterllama.cpp / vLLM / SGLang / MLX"]
    GGUF --> V["pollard-verify(real-reconstruction gate)"]
    GPTQ --> V
    MLX --> V
    EXL3 --> V
    MX --> V