[zhenshanx-nv]

Background

families/deberta_v2 builds DeBERTa-v2/v3 encoders (microsoft/deberta-v3-base in the manifests, text_to_token_features, batch 1, window 256) in fp32 (default) or fp16 and has no quantized build. No FP8 or NVFP4 checkpoint of a DeBERTa-v2/v3 model exists on the Hub, so FP8 self-quantization of the encoder projections on top of the fp16 engine (build-time per-tensor FP8 weights, ModelOpt-calibrated static activation scales) was built and measured for deberta-v3-base and deberta-v3-large on TensorRT 11.4 and 11.1. FP8 does not pay for this family: at the manifest window FP8 runs at 0.94x to 0.99x of fp16 on B200 and 1.08x to 1.11x on B300, the plan is 21% (base) to 30% (large) smaller, and the token feature error grows from 0.2% to 6% to 7% (MNLI head agreement 99.25% to 99.55%). This change adds a README for the family that records the study, like the yolov10 (#2093), bart (#2004) and timesfm (#2005) studies, so that it does not have to be repeated. The FP8 code is not part of this change. NVFP4 was not tried: the encoder is not bound by weight reads at batch 1.

Exit Criteria

• The README records the recipe, the method, speed and plan size on B200 and B300 (TensorRT 11.4) and B200 (11.1), feature quality and MNLI head agreement against PyTorch fp32, short-input behavior, the kernel breakdown that explains the missing speedup, batch 32, NVFP4, what was not tried and when to revisit.
• No code, test, manifest or bundle change; builds are unchanged.
• Non-goals: shipping FP8 or NVFP4 builds, an FP8 manifest or CI case.

Implementation

• families/deberta_v2/README.md (new): a short family description and the section "FP8 quantization study (not shipped)": summary and decision, recipe, method, results (speed, batch 32, quality, why there is no speedup), NVFP4, what was not tried, when to revisit.

Recipe that was measured (code kept out of the repository):

• FP8 for the six projections of every layer (query_proj, key_proj, value_proj on the hidden rows, attention.output.dense, intermediate.dense, output.dense; 72 in base, 144 in large). Embeddings, the relative position table and its positional products, layer norms, GELU, attention matmuls and softmax stay fp16.
• Weights: per-tensor scale amax / 448 at build time. Activations: static per-tensor scales from ModelOpt FP8_DEFAULT_CFG (max) on the PyTorch model, 800 WikiText-2 and MNLI train texts. fp16 Dequantize.

Why no gain: in the fp16 engine TensorRT runs the attention of every layer as one fused kernel; in the FP8 engine it does so for one layer only, and the other layers run separate matmuls, a softmax and extra transposes, concats and adds (pointwise kernels 14 to 58 in base, 26 to 118 in large). At 128 and 256 tokens the projection GEMMs are small, so this takes the FP8 GEMM gain back. FP8 is faster only at 512 tokens (1.18x to 1.37x) and at batch 32 in an experiment-only graph (1.03x to 1.34x).

Change categories

• Model or runtime behavior
• Public API
• ABI
• Bundle or artifact format
• Dependencies
• Documentation only
• CI or developer tooling

Validation

Commands and Results

python3 -m tools.model_ci validate
python3 -m pytest tools/tests/test_architecture.py tools/tests/test_public_source_hygiene.py -q
python3 tools/pr_metadata.py validate --event <event.json>   # Pull-request metadata is complete.
git diff --check

Documentation only.

Check	Result
python3 -m tools.model_ci validate	pass
pytest tools/tests/test_architecture.py tools/tests/test_public_source_hygiene.py (CPU)	62 passed
Markdown check of the README (table column counts, code fences, section links)	pass
git diff --check	pass
python3 tools/pr_metadata.py validate on this description	pass

The numbers in the README come from the local study and are not re-run by this change (batch 1, window 256, x is fp16 time over FP8 time):

Model	GPU	TensorRT	fp16 ms	FP8 ms	x	plan MiB fp16 to FP8
base	B200	11.4	0.636	0.674	0.94	386.1 to 306.0
base	B300	11.4	0.682	0.633	1.08	387.6 to 306.0
base	B200	11.1	0.646	0.651	0.99	386.1 to 306.5
large	B200	11.4	1.397	1.407	0.99	935.8 to 650.8
large	B300	11.4	1.468	1.325	1.11	938.7 to 652.3
large	B200	11.1	1.450	1.402	1.03	935.7 to 651.0

Quality against PyTorch fp32 (800 held-out texts, window 256, TensorRT 11.4, B200): token feature relative error fp16 0.0021 / 0.0023, FP8 0.070 / 0.060 (base / large); MNLI head agreement on 2000 validation-matched pairs fp16 100% / 100%, FP8 99.25% / 99.40% (B300 large 99.55%), accuracy within +0.35 point. On a one-token input the large FP8 model gave token cosine 0.631 in one B300 build (0.944 to 0.995 in the others). No NaN or Inf in any engine.

Hardware, Environment, and Revisions

• Repository: this commit on top of upstream/main at 683a7316.
• Checkpoints: microsoft/deberta-v3-base at 8ccc9b6f36199bec6961081d44eb72fb3f7353f3 (manifest revision), microsoft/deberta-v3-large at 64a8c8eab3e352a784c658aef62be1662607476f; for the head check only MoritzLaurer/DeBERTa-v3-base-mnli-fever-anli (6f5cf0a2) and MoritzLaurer/DeBERTa-v3-large-mnli-fever-anli-ling-wanli (b3546ea6).
• Data: Salesforce/wikitext wikitext-2-raw-v1 (b08601e0), nyu-mll/glue mnli (bcdcba79); calibration from the train splits, evaluation from WikiText-2 test and MNLI validation-matched.
• Study: B200 and B300, one GPU per job, TensorRT 11.4.0.106 (target) and 11.1.0.106, ModelOpt 0.46.1, PyTorch 2.14, Transformers 5.17. Quality numbers from a run on upstream/main at 683a7316 (the fp16 support, feat(deberta_v2): support fp16 builds #2056); speed, size and kernel numbers from a re-run of the same FP8 code on 236fede5 (the family code did not change between the two). Reference: Transformers DebertaV2Model in float32 (TF32 off).

Not Run / Remaining Gaps

• No code was run for this change; the study cannot be rerun from this repository because the FP8 code was not merged.
• Not measured: FP8 attention matmuls, keeping attention.output.dense or q/k/v in fp16 to keep the attention fusion, per-channel scales, SmoothQuant, percentile or entropy calibration, H100, the native runtime with an FP8 bundle.
• The cause of the lost attention fusion in the FP8 engine was not isolated.
• No problem on main was found during the study.

Contributor Self-Review

• I have completed a self-review of this change.

Notes For Future Readers

• Suggested review order: "Summary and decision", "Why there is no speedup", "When to revisit".
• Revisit FP8 when a TensorRT release keeps the fused attention kernel with FP8 projections around it, when the family supports batch greater than 1 (B300 batch 32: 1.14x to 1.34x), or when a recipe brings the feature error near fp16.

Risk level

• Low
• Medium
• High

Risk rationale: documentation only; one README added, no code, build, bundle or test change.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.

Next included review available in 8 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used all 12 included reviews currently available.

Learn how review limits work.

Review configuration:

Run configuration

• Source mode: Auto
• Repository: NVIDIA/TensorRT-Model-Connect
• Branch: main
• File: .coderabbit.yaml
• Commit: 683a731
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Enterprise
• Run ID: 086412fb-ed59-40c0-9d5c-48a148d8d0b4

Commits

Reviewing files that changed from the base of the PR and between 683a731 and 314ba5e.

Files selected for processing: 1

• families/deberta_v2/README.md