[PR #233] [CLOSED] fix: preserve original dtype in Upsample instead of hardcoding bfloat16 #232

New issue

Closed

opened 2026-10-26 21:14:22 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-26 21:14:22 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/deepseek-ai/Janus/pull/233
Author: @Mr-Neutr0n
Created: 2/11/2026
Status: ❌ Closed

Base: main ← Head: fix/upsample-preserve-dtype

📝 Commits (1)

0e8fa03 fix: preserve original dtype in Upsample instead of hardcoding bfloat16

📊 Changes

1 file changed (+2 additions, -1 deletions)

View changed files

📝 janus/models/vq_model.py (+2 -1)

📄 Description

Summary

The Upsample.forward method in janus/models/vq_model.py hardcodes a cast to torch.bfloat16 after interpolation when the input is not float32:

x = F.interpolate(x.to(torch.float), scale_factor=2.0, mode="nearest").to(
    torch.bfloat16
)

This causes a problem when the input tensor is float16 (common on GPUs without native bfloat16 support, e.g. older NVIDIA architectures). The tensor is silently converted from float16 to bfloat16 after interpolation, leading to dtype mismatches with downstream convolution layers that still expect float16 weights.

Fix

Store the original dtype before casting to float32 for interpolation, then cast back to it afterward:

orig_dtype = x.dtype
x = F.interpolate(x.to(torch.float), scale_factor=2.0, mode="nearest").to(
    orig_dtype
)

This preserves whatever dtype the input originally had (float16, bfloat16, etc.) instead of always forcing bfloat16.

Test plan

Verified that the fix correctly preserves float16 input dtype through the upsample operation
Verified that bfloat16 inputs continue to work as before (orig_dtype would be bfloat16, matching the previous behavior)
No functional change for float32 inputs (the else branch is unchanged)

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/deepseek-ai/Janus/pull/233 **Author:** [@Mr-Neutr0n](https://github.com/Mr-Neutr0n) **Created:** 2/11/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/upsample-preserve-dtype` --- ### 📝 Commits (1) - [`0e8fa03`](https://github.com/deepseek-ai/Janus/commit/0e8fa03dc7efd692ff7aad29537f19e6e2a0da8e) fix: preserve original dtype in Upsample instead of hardcoding bfloat16 ### 📊 Changes **1 file changed** (+2 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `janus/models/vq_model.py` (+2 -1) </details> ### 📄 Description ## Summary The `Upsample.forward` method in `janus/models/vq_model.py` hardcodes a cast to `torch.bfloat16` after interpolation when the input is not float32: ```python x = F.interpolate(x.to(torch.float), scale_factor=2.0, mode="nearest").to( torch.bfloat16 ) ``` This causes a problem when the input tensor is `float16` (common on GPUs without native bfloat16 support, e.g. older NVIDIA architectures). The tensor is silently converted from `float16` to `bfloat16` after interpolation, leading to dtype mismatches with downstream convolution layers that still expect `float16` weights. ## Fix Store the original dtype before casting to float32 for interpolation, then cast back to it afterward: ```python orig_dtype = x.dtype x = F.interpolate(x.to(torch.float), scale_factor=2.0, mode="nearest").to( orig_dtype ) ``` This preserves whatever dtype the input originally had (float16, bfloat16, etc.) instead of always forcing bfloat16. ## Test plan - Verified that the fix correctly preserves `float16` input dtype through the upsample operation - Verified that `bfloat16` inputs continue to work as before (orig_dtype would be bfloat16, matching the previous behavior) - No functional change for `float32` inputs (the else branch is unchanged) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-26 21:14:22 +00:00

closed this issue
added the
pull-request
label

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

deepseek-ai/Janus#232

No description provided.

Rows
Columns