Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

int8_quantize_kernel truncates toward zero instead of rounding (the ±0.5 offset is cast to int8 before being added)

Open Beginner friendly
#90 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python

Research direction

The bug is in int8_quantize_kernel in wan/triton_kernels.py, around lines 29-31, where the ±0.5 rounding offset is cast to int8 before it is added, so it becomes 0. Read the surrounding kernel to see how x_scale and the store mask are used, then check whether the output is clamped to [-127, 127]. Done means the offset is added in float before the int8 cast, and a small test comparing the kernel output with round-half-away-from-zero matches on sample inputs.

Written by the indexing model from the issue text.

Description

Where: https://github.com/SkyworkAI/Matrix-Game/blob/ad397b34dd78880bad068232227a49f7106af817/Matrix-Game-3/wan/triton_kernels.py#L29-L31

x_scaled = x * x_scale
x_scaled += (0.5 * tl.where(x_scaled >= 0, 1, -1)).to(tl.int8)
tl.store(out_ptr + h_offset, x_scaled, mask=h_offset < HDIM)

What happens: (0.5 * sign).to(tl.int8) evaluates to 0, so nothing is added. The float x_scaled is then stored into the int8 output, which truncates toward zero. The intended rounding (half away from zero) is lost and every activation is biased toward zero.

Suggested fix: add the offset in float before the cast:

x_scaled = x_scaled + 0.5 * tl.where(x_scaled >= 0, 1.0, -1.0)
tl.store(out_ptr + h_offset, x_scaled.to(tl.int8), mask=h_offset < HDIM)

(or use a round-to-nearest intrinsic). Since x_scale = 127 / max|x|, the rounded value stays within [-127, 127].

Measured impact (our replication, Matrix-Game-3.0 distilled, --use_int8 path on the 240 attention q/k/v/o layers, real activations from one rollout):

  • Mean relative output MSE vs BF16: 3.68e-3 with the current kernel vs 6.44e-4 with round-to-nearest (about 5.7x lower).
  • The current kernel's error is a systematic magnitude shrinkage (cosine between error and output between -0.62 and -0.85; about 0 with rounding).
  • Other factors (int32 accumulation, bf16 weight scales, per-token / per-channel granularity) change the error by less than 2%.
  • In our closed-loop rollouts (352x640 and 704x1280) we did not detect visible degradation from the current kernel with our metrics, so this is a precision issue rather than an obvious quality break; fixing it should still reduce error at no cost.

Happy to share the per-layer measurements if useful.

Dominant language
Python
Stars
2.7k
Forks
285
PR merge metrics
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SkyworkAI/Matrix-Game

All issues in SkyworkAI/Matrix-Game

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.