Release 1.8.0
Summary
This release replaces the separate TensorRT and PyTorch backend options with a unified optimized backend built on new custom kernels, improves inference performance and supported sequence lengths, and adds affinity embedding outputs for binding affinity prediction.
Key Features
-
Unified optimized backend: Removed the previous separate TensorRT (
trt) and PyTorch (torch) backend selection. The NIM now uses a single new optimized backend that automatically selects the best execution path for each request. -
Automatic backend selection:
- Fully supports the Boltz2 OSS model
- Short sequences (≤768 residues): TensorRT engines
- Medium and long sequences (>768 residues): PyTorch backend with new optimized kernels
-
New optimized kernel backend includes:
-
Fused Adaptive Layer Norm
-
DualGemm sm80 (two variants)
-
Gated sigmoid sm80
-
FAv2/v3 TriangleAttent/AttentionPairBias
-
Pre-computed masks, with masks left-aligned into new kernels for dual GEMM and attention operations
-
Pre-computed buffers for Pairformer/DiT
-
Performance increased up to 1.7x on H100, and sequence length limits increased across supported GPUs:
Actual maximum supported sequence length may exceed the values shown above, depending on available GPU VRAM.
-
Affinity embedding outputs: Boltz2Affinity now exports embedding vectors as outputs. The new ligand-level request flag
output_affinity_embeddingdefaults tofalseand requirespredict_affinity=trueon the same ligand. When enabled, the ligand’s entry underaffinitiesincludesaffinity_embedding,model_1_affinity_embedding, andmodel_2_affinity_embedding(2D number arrays ornull). Each embedding vector has 384 dimensions.
Removed Configuration
The following environment variables are no longer supported and have been removed:
NIM_BOLTZ_ENABLE_DIFFUSION_TF32NIM_BOLTZ_STRUCTURE_OPTIMIZED_BACKENDNIM_BOLTZ_AFFINITY_OPTIMIZED_BACKEND
Notes
-
For best performance with the unified optimized backend, run a warm-up pass with representative test-case sequences before measuring latency/throughput.
-
The first request in a given sequence-length range can be slower because of JIT compilation and runtime kernel specialization. As a result, you may observe a one-time startup latency when entering a new range (for example, short, medium, or long sequences). After that initial compilation for the range, subsequent requests in the same range should show improved performance.