Feature: run the minimax_music3 DiT and depth decoder in bf16 under precision=bf16 (DiT 16x to 19x faster per call)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 42/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- machine-learning
Hướng nghiên cứu
Start with the minimax_music3 family implementation and its precision handling, then trace how the DiT, depth decoder, and language-model KV cache are built and used. Reproduce the reported measurements on the specified model and GPUs, and check existing end-to-end quality thresholds before changing precision or attention lengths. Done means bf16 precision speeds up the proposed components while meeting measured quality thresholds, and decode attention processes only filled cache rows.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Request type: Improvement to existing behavior
Problem and use case
families/minimax_music3 requires precision=bf16, but only the language model is built in bf16. The DiT, the RVQ depth decoder, the condition encoder and the vocoder are built in float32 with TF32 off, so their GEMMs run on CUDA cores. For a 20 s song (the minimax-music3-l0 prompt, native runtime, 500 frames) the engine time is dominated by these float32 parts:
| GPU | Engine time per song | Language model | Depth decoder | DiT | Vocoder |
|---|---|---|---|---|---|
| B200 | 49.4 s | 13.44 s | 12.19 s | 23.57 s | 0.23 s |
| B300 | 43.3 s | 12.34 s | 12.22 s | 18.56 s | 0.21 s |
The same graphs built with bf16 blocks (a test-harness build, not offered by the family) are much faster per call:
| Engine | GPU | Default, float32 (ms) | Same graph, bf16 (ms) | Speedup |
|---|---|---|---|---|
| DiT call | B200 / B300 | 98.36 / 77.25 | 5.28 / 4.67 | 18.6x / 16.5x |
| Depth decoder call | B200 / B300 | 1.628 / 1.641 | 0.405 / 0.410 | 4.0x / 4.0x |
A second, separate cost: every language-model decode step attends over the whole static 9216-row KV cache. In a B200 kernel profile of the bf16 step (11.0 ms), the decode attention kernel takes 5.4 ms (36 calls over 9216 rows), the cache concatenation 0.46 ms and the GEMMs about 4.3 ms, so the step is bound by attention over unused cache rows, not by weight reads.
Proposed outcome
- Under
precision=bf16, build the DiT blocks and the depth decoder in bf16 (keeping float32 only where measurement shows it is needed, for example the timestep embedding, stem convolutions or norms), with E2E thresholds set from measured bf16-vs-reference numbers. Optionally the same for the condition encoder and vocoder if quality allows. - Limit the language-model decode attention to the filled cache length instead of all 9216 rows.
Model and target details
MiniMaxAI/MiniMax-Music3 @ fbdf52fbaaca799592917417eb05f1899f1255ec (the minimax-music3-l0 manifest); TensorRT 11.4; B200 / B300. The DiT has 36 blocks (hidden 2048, 60 calls per 8 s window); the depth decoder has 4 layers (hidden 4096, 15 calls per frame, 7515 calls per 20 s song).
Alternatives considered
FP8 for these parts was measured (not merged): it gets most of its gain over the default from running the DiT blocks in bf16 (FP8 DiT call 4.25 ms against 5.28 ms for the bf16 graph, 1.24x), so a plain bf16 build captures most of the benefit with no quantization.
Additional context
Found during an FP8 study of this family (not merged).
- Ngôn ngữ chính
- Python
- Star
- 288
- Fork
- 73
- Merge trung bình
- 1 ngày 3 giờ
- Pull request đã merge (30 ngày)
- 273
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của NVIDIA/TensorRT-Model-Connect
-
Docs: ITrtModule::forward() output-buffer lifetime and dtype contract are undocumentedCó thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
NVIDIA/TensorRT-Model-Connect#1126 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
NVIDIA/TensorRT-Model-Connect#2060 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
NVIDIA/TensorRT-Model-Connect#2054 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 46/100
NVIDIA/TensorRT-Model-Connect#2050 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
NVIDIA/TensorRT-Model-Connect#2049 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của NVIDIA/TensorRT-Model-Connect
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
NVIDIA/auto-ontology#463 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
NousResearch/hermes-agent#151165 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
Maintainer thường phản hồi trong vòng 1 ngày
-
code-health
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
tinaudio/synth-setter#3750 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug] vllm-sr config migrate drops providers.models[].deploymentCó thể đã có người làm @Bevisy đã nhận hôm nay. Đang mởneeds-acceptance wg/developer-experience-ecosystem
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
vllm-project/semantic-router#5996 ·
Maintainer thường phản hồi trong vòng 2 ngày