Quantization PrismaQuant 4.75bit sur Qwen3.6-35B : +37 % de débit pour 0 % de qualité perdue

Si vous gérez un workload LLM en production, la quantization n'est plus une option exotique : c'est ce qui décide si votre modèle tient sur la VRAM disponible et combien il vous coûte par requête. Sur une H100 80 Go vous pouvez vous permettre Llama 3.3 70B en BF16. Sur une RTX 4090 24 Go ou un DGX Spark, il faut quantizer. La question n'est plus « quantizer ou pas » mais « quel schéma ».

GPTQ a dominé 2023-2024. AWQ a pris le relais pour la qualité préservée en 2024-2025. PrismaQuant arrive en 2025-2026 avec une promesse forte : « la qualité d'AWQ avec le débit de FP8 ». On l'a testé en production sur Qwen3.6-35B-A3B pendant 6 semaines. Verdict : la promesse tient.

Cet article est une deep dive technique pour Tech Leads et architectes ML qui doivent défendre un choix de quantization devant leur équipe ou leur DSI. On va couvrir : les fondamentaux compressed-tensors W4A16 et Marlin kernels accessiblement, les benchmarks réels sur 5 axes (débit, latence, qualité, VRAM, coût), une comparaison structurée vs FP8 / GPTQ / AWQ / GGUF, et le pipeline de quantization complet pour vos propres modèles.

Quantization 101 : pourquoi, comment, quels trade-offs

Un LLM en BF16 stocke chaque paramètre sur 16 bits = 2 octets. Pour Qwen3.6-35B, ça fait 70 GB de weights. Aucune GPU consumer n'a 70 GB de VRAM. Quantizer, c'est représenter ces weights sur moins de bits, en acceptant une approximation contrôlée.

La perte mathématique

Représenter un float sur N bits revient à mapper chaque valeur sur 2^N niveaux discrets. INT4 = 16 niveaux, INT8 = 256 niveaux, BF16 = 65 536 niveaux. La perte est une erreur d'arrondi par valeur. Le truc fondamental : cette erreur N'EST PAS uniforme par couche. Les couches d'attention sont sensibles ; les couches MLP en aval le sont beaucoup moins. Les routers de MoE sont critiques ; les experts sont tolérants.

Le compromis classique

Quantization plus agressive = moins de VRAM + plus de débit (les Marlin kernels INT4 font ~3x plus de FLOPs que les BF16) + perte de qualité. La courbe Pareto est à peu près :

• BF16 : qualité 100 %, VRAM 70 GB, débit baseline
• FP8 : qualité 99,5 %, VRAM 35 GB, débit ~1,4x
• INT8 : qualité 99,2 %, VRAM 35 GB, débit ~1,5x
• INT4 (naïf) : qualité 92-95 %, VRAM 17,5 GB, débit ~2,5x — la perte de qualité commence à se voir dans HumanEval
• INT4 + correction (GPTQ, AWQ, PrismaQuant) : qualité 99-100 %, VRAM ~22 GB (overhead scales/zeros), débit ~2,5x

La valeur de PrismaQuant n'est pas « encore une nouvelle technique INT4 » mais « une technique INT4 qui ne perd pas de qualité et qui exploite les Marlin kernels Blackwell aussi bien que FP8 exploite les Tensor Cores Hopper ». C'est la première fois qu'on a INT4 sans compromis sur 35B+.

PrismaQuant : ce que c'est exactement

PrismaQuant est un « recipe » (recette) du compressor Neural Magic llmcompressor, codé open source sous licence Apache 2.0. Trois ingrédients :

Ingrédient 1 : Mixed precision W4 + W8 outliers

Au lieu de quantizer tous les weights en INT4, PrismaQuant identifie les ~5 % de weights par couche dont la valeur absolue est dans le top décile, et les conserve en INT8. Les 95 % restants sont en INT4. Pourquoi ? Parce que dans la matmul, les outliers contribuent disproportionnellement au résultat (math : un weight de 4,2 contribue 7x plus qu'un weight de 0,6 à un activation identique). Préserver leur précision fait disparaître la majeure partie de l'erreur de quantization.

Ingrédient 2 : Calibration single-pass SmoothQuant-style

GPTQ fait du second-pass : il quantize, calcule l'erreur sur un dataset, et ré-ajuste les weights restants pour compenser. Coûteux (~2 h sur un 70B). PrismaQuant fait une calibration unique inspirée de SmoothQuant : il observe les statistiques d'activation sur 256-512 samples, calcule un facteur de scaling per-channel pour absorber les outliers d'activation dans les weights (ou inversement), puis quantize en un seul passage. ~25-40 min pour Qwen3.6-35B sur une H100 ou GB10.

Ingrédient 3 : Layout compressed-tensors + Marlin kernels

Le format compressed-tensors (Neural Magic, intégré à vLLM 0.20+) stocke les weights INT4 packés 2-par-octet, avec un sidecar de scales FP16 par groupe de 128 weights, et un bitmask 1-par-weight pour identifier les outliers INT8. Le tout est aligné mémoire pour les Marlin kernels qui font une matmul fused dequant + multiply en un seul kernel CUDA, exploitant les Tensor Cores INT4 de Blackwell (SM_100) avec un débit théorique de ~600 TOPS INT4 vs ~150 TOPS BF16 sur GB10.

Compressed-tensors W4A16 + Marlin : sous le capot

W4A16 signifie : Weights INT4,Activations BF16. Les activations (les valeurs qui circulent entre couches pendant l'inférence) restent en BF16 pour préserver la dynamic range. Seuls les weights (paramètres figés du modèle) sont quantizés en INT4. C'est différent de W4A4 (INT4 partout, plus agressif, perte de qualité importante) ou W8A8 (INT8 partout, moins de gain VRAM).

Comment se passe une matmul W4A16 ?

# Pseudo-code Marlin kernel pour Y = X @ W^T
# X est un tenseur d'activation BF16 [batch_size, seq_len, hidden_dim]
# W est un tenseur de weights INT4 packés [out_dim, hidden_dim/2]
# scales est un tenseur FP16 [out_dim, hidden_dim/128]
# outlier_mask est un bitmask 1-bit [out_dim, hidden_dim]
# outlier_values est un tenseur INT8 [n_outliers]

def marlin_matmul_w4a16(X_bf16, W_int4_packed, scales_fp16, outlier_mask, outlier_values):
    # 1. Dequantize les weights tile par tile dans la mémoire shared
    for tile in range(num_tiles):
        # Unpack 2 INT4 par octet -> [128, 128] INT4 dans shared memory
        W_tile_int4 = unpack_int4(W_int4_packed[tile])

        # Substitute les outliers depuis le INT8 sidecar
        W_tile = substitute_outliers(W_tile_int4, outlier_mask[tile], outlier_values)

        # Multiply par les scales pour obtenir les valeurs FP16 reconstruites
        W_tile_fp16 = W_tile.to(fp16) * scales_fp16[tile]  # broadcast

        # Tensor Core matmul: BF16 x FP16 -> FP32 accum -> BF16 output
        Y_tile = tensor_core_matmul(X_bf16_tile, W_tile_fp16)
        accumulate(Y, Y_tile)

    return Y_bf16

# Tout ça dans UN SEUL kernel CUDA, fused.
# Sur GB10 SM_100 : ~600 TOPS INT4 effectif après dequant.
# Vs un kernel BF16 standard: ~150 TOPS BF16. Gain ~4x théorique.
# En pratique, après overhead dequant + sync : ~2,4x mesuré.

Le truc clé : la dequantization se fait dans le kernel matmul, pas en amont. Sur GPU traditionnels, dequantizer = écrire dans la VRAM + relire = bottleneck mémoire. Marlin écrit dans la shared memory du SM, calcule la matmul, et n'écrit en VRAM que le résultat final. C'est ce qui rend INT4 plus rapide que BF16 en débit.

Pourquoi pas W4A8 ou W4A4 ?

W4A8 (activations en INT8) ferait gagner ~10 % de débit en plus mais perdrait 1-2 points de MMLU sur les modèles > 30B. W4A4 perd encore plus (3-5 points MMLU). Le sweet spot W4A16 préserve la qualité au prix d'un kernel un peu plus complexe.

Benchmark 1 : débit (tokens/seconde)

Setup : Qwen3.6-35B-A3B sur DGX Spark GB10, vLLM 0.20.0 (build custom SM_100), batch size 1 (use case agent / chat single user), context fixe 8K input + 1K output, 100 runs par configuration, médiane reportée.

Lecture clé : PrismaQuant tape +37 % vs FP8 compilé (29 vs 21 tok/s). C'est cohérent avec les chiffres Spark Arena publiés par Neural Magic (+34 % à +41 % selon les modèles testés). Le gain vs GPTQ et AWQ est marginal (~7 %) parce que les 3 utilisent les mêmes Marlin kernels en aval — mais PrismaQuant les bat sur la qualité (voir benchmark 2).

Benchmark 2 : qualité

Évaluations standards (lm-eval-harness 0.4.x) + un set custom interne de 200 prompts français domaine-spécifique (juridique, RH, finance).

Lecture clé : PrismaQuant est le seul schéma qui reste dans la marge d'erreur de mesure (±0.3 typique pour MMLU sur 14k items) sur les 4 dimensions. Les autres quantizations INT4 perdent toutes significativement sur HumanEval (le code est sensible aux outliers). FP8 est correct mais perd 0.4-0.5 sur tous les benchs sans aucun gain VRAM vs PrismaQuant.

Benchmark 3 : empreinte VRAM

Mesuré nvidia-smi après chargement modèle + alloc KV cache pour 8K context :

• BF16 : 70 GB weights + 16 GB KV cache = 86 GB — impossible à servir sur Spark 128 GB sans réduire gpu_memory_utilization en dessous de 0.7
• FP8 : 35 GB weights + 16 GB KV (KV reste BF16) = 51 GB
• PrismaQuant W4A16 : 22.9 GB weights + 16 GB KV ≈ 39 GB total — laisse 89 GB libres pour autres modèles via llama-swap
• GGUF Q5_K_M : 26.8 GB weights + 16 GB KV ≈ 43 GB
• GGUF Q4_K_M : 22.1 GB weights + 16 GB KV ≈ 38 GB

PrismaQuant est le plus compact des schémas qui ne perdent pas de qualité. Q4_K_M est légèrement plus compact mais perd 1.4 points de MMLU et 2.5 points de HumanEval — pas acceptable pour notre tier « long-reviewer » qui doit produire du code qualité.

Comparaison structurée vs FP8 / GPTQ / AWQ / GGUF

vs FP8 W8A8

FP8 W8A8 est la quantization « safe » qui préserve les activations en INT8 et les weights en FP8 (1 octet). Bon support hardware sur Hopper et Blackwell. PrismaQuant le bat sur 3 axes : débit (+37 %), VRAM (-30 %), qualité (-0.2 vs -0.4 sur MMLU). FP8 reste pertinent si vous êtes sur Hopper non-supporté Marlin OU si vous voulez un schéma sans calibration.

vs GPTQ INT4 g128

GPTQ a 2 ans de production maturité. Workflow second-pass éprouvé. Mais : qualité 0.6-1.5 points en dessous sur les benchmarks, calibration 4-5x plus lente. PrismaQuant le bat sur tous les axes mesurés. GPTQ reste pertinent uniquement pour les vieux GPU (T4, V100) où Marlin n'est pas dispo.

vs AWQ INT4

AWQ est l'ancêtre direct de PrismaQuant (mêmes équipes Neural Magic et MIT Han Lab à l'origine). PrismaQuant ajoute le mixed precision outliers et améliore la calibration. Différence pratique : ~0.5 point de MMLU en plus, débit identique sur Marlin. AWQ reste pertinent si votre modèle est déjà quantizé en AWQ (réutilisable direct par vLLM, pas de re-quantization à faire).

vs GGUF Q4_K_M / Q5_K_M (llama.cpp)

GGUF est le format de llama.cpp. Avantage : tourne sur CPU pure, sur Mac Metal, sur AMD ROCm sans hassle. Inconvénient : ne peut pas utiliser les Marlin kernels (les Q4_K et Q5_K_M ont leur propre format de bloc), donc débit ~25-30 % en dessous de PrismaQuant sur Blackwell. Choisissez GGUF si vous servez sur Mac/AMD ou si vous voulez du fallback CPU. Sur NVIDIA datacenter, PrismaQuant gagne.

Pipeline de quantization de votre propre modèle

# pip install llmcompressor>=0.4 transformers>=4.45 datasets accelerate
# Tested 2026-05 with Qwen3.6-35B-A3B base, GB10 + 128 GB UMA

from llmcompressor.transformers import oneshot
from llmcompressor.modifiers.quantization import GPTQModifier
from llmcompressor.modifiers.smoothquant import SmoothQuantModifier
from transformers import AutoModelForCausalLM, AutoTokenizer
from datasets import load_dataset

MODEL_ID = "Qwen/Qwen3.6-35B-A3B"
OUTPUT_DIR = "./qwen3-35b-a3b-prismaquant-w4a16"

# 1. Load base model in BF16
model = AutoModelForCausalLM.from_pretrained(
    MODEL_ID,
    device_map="auto",
    torch_dtype="bfloat16",
)
tokenizer = AutoTokenizer.from_pretrained(MODEL_ID)

# 2. Build calibration dataset
# 256 samples is the minimum for stable calibration on 35B
# More samples = better outlier identification but linear time cost
N_SAMPLES = 384

# Mix : WikiText for general language, C4 for diversity, FR custom for domain
ds_wiki = load_dataset("wikitext", "wikitext-2-raw-v1", split="train").shuffle(seed=42).select(range(128))
ds_c4 = load_dataset("allenai/c4", "fr", split="train", streaming=True)
ds_c4 = list(ds_c4.take(128))
# + 128 samples internes domaine-spécifique
ds_custom = load_jsonl("./custom_fr_calibration.jsonl")[:128]

calibration_samples = ds_wiki["text"] + [s["text"] for s in ds_c4] + ds_custom

def tokenize(sample):
    return tokenizer(sample, return_tensors="pt", truncation=True, max_length=2048)

calibration_dataset = [tokenize(s) for s in calibration_samples]

# 3. Define recipe : SmoothQuant + GPTQ-style INT4 with 5% INT8 outliers
recipe = [
    SmoothQuantModifier(smoothing_strength=0.7),  # absorb activation outliers into weights
    GPTQModifier(
        targets="Linear",
        scheme="W4A16",  # weights INT4, activations BF16
        ignore=["lm_head"],  # never quantize the LM head
        actorder=True,
        outlier_percentage=0.05,  # 5% des weights conservés en INT8
        outlier_threshold_method="absmax_per_channel",
        block_size=128,  # Marlin requires 128
    ),
]

# 4. Run one-shot calibration + quantization
# ~25 min on H100, ~38 min on GB10
oneshot(
    model=model,
    dataset=calibration_dataset,
    recipe=recipe,
    output_dir=OUTPUT_DIR,
    save_compressed=True,  # saves in compressed-tensors format
    max_seq_length=2048,
    num_calibration_samples=N_SAMPLES,
)

# 5. Verify output
# Le dossier OUTPUT_DIR contient :
# - config.json (modifié pour pointer sur compressed-tensors)
# - model.safetensors (weights INT4 packés + scales + outlier sidecar)
# - quantization_config.json (recipe utilisée, traçabilité)
# - tokenizer.* (inchangé)

Le modèle output est directement loadable par vLLM avec --quantization compressed-tensors.

Déploiement vLLM

# vllm serve config pour PrismaQuant Qwen3.6-35B
# fichier : ~/.local/share/vllm/qwen35b-prismaquant.yaml

vllm serve ./qwen3-35b-a3b-prismaquant-w4a16 \
  --host 0.0.0.0 \
  --port 8001 \
  --quantization compressed-tensors \
  --dtype bfloat16 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.85 \
  --kv-cache-dtype auto \
  --enable-prefix-caching \
  --max-num-seqs 8 \
  --enable-chunked-prefill \
  --tensor-parallel-size 1 \
  --served-model-name qwen3-long-reviewer

# Premier boot : ~21 min (flashinfer JIT, voir billet 1 de la série)
# Boots suivants : ~90 sec
# Memory used : 22.9 GB weights + ~16 GB KV cache (à 32k context)
# Decode throughput : 29 tok/s @ 8K context, 24 tok/s @ 32K context

Quelques flags clés :

• --quantization compressed-tensors : indique à vLLM de charger les Marlin kernels W4A16
• --enable-prefix-caching : critique pour les agents IA qui répètent souvent le même system prompt
• --enable-chunked-prefill : permet de mélanger prefill (long) et decode (court) dans le même batch, ~15 % de débit en plus en concurrent
• --max-num-seqs 8 : sur GB10 single GPU, au-delà de 8 séquences concurrentes le KV cache devient le goulot. Adaptez selon votre VRAM.

Matrice de décision

Questions fréquentes

Conclusion

PrismaQuant 4.75bit n'est pas un produit miracle. C'est l'assemblage propre de 3 techniques mûres (mixed precision, SmoothQuant calibration, Marlin kernels) dans un pipeline production-ready. Sur Qwen3.6-35B en NVIDIA datacenter, c'est la meilleure option de quantization en mai 2026 : débit FP8 + qualité BF16 + VRAM INT4. Si vous gérez un workload LLM ≥ 30B sur Hopper ou Blackwell, vous devriez l'essayer cette semaine.

Cet article est le 2e d'une série de 3 sur notre adventure GB10. Lire aussi :

• DGX Spark GB10 : retour d'expérience après 3 mois — le contexte production qui rend ces benchmarks crédibles
• Notre setup LLM auto-hébergé : 5 noeuds, 1 routeur, 0 cloud — comment PrismaQuant s'intègre dans une architecture multi-nœuds
• Optimisation des coûts IA en production 2026 — méthodologie économique