Skip to content

bad_words_ids no longer slow on mps #39556

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

DWarez
Copy link
Contributor

@DWarez DWarez commented Jul 21, 2025

What does this PR do?

Using the bad_words_ids on mps is slowing down a lot the text generation, this PR tries to address that.

Fixes #39512

Before submitting

  • This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
  • Did you read the contributor guideline,
    Pull Request section?
  • Was this discussed/approved via a Github issue or the forum? Please add a link
    to it if that's the case.
  • Did you make sure to update the documentation with your changes? Here are the
    documentation guidelines, and
    here are tips on formatting docstrings.
  • Did you write any new necessary tests?

Who can review?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

@ArthurZucker

@xenova
Copy link
Contributor

xenova commented Jul 21, 2025

Thanks for identifying the issue and opening a PR! This does speed up things quite a lot, but it's still around 6 times slower than without setting bad_words_ids 🤔

Pretty much the same as just doing:

            eos_token_id_list = eos_token_id.tolist() # convert to python list before
            bad_words_ids = list(
                filter(lambda bad_token_seq: all(bad_token_seq != [i] for i in eos_token_id_list), bad_words_ids)
            )

@xenova
Copy link
Contributor

xenova commented Jul 21, 2025

Though... I guess, since this is just done once (in the init function), 2 seconds vs 36 seconds is still much better!

Copy link
Collaborator

@ArthurZucker ArthurZucker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Already much better, forward pass could then be slow because of torch ops from SequenceBiasLogitsProcessor happy to merge as is, but if you have time nice to investigate in the forward see if we can squeeze more perfs!

bad_words_ids = [
bad_token_seq for bad_token_seq in bad_words_ids
if len(bad_token_seq) != 1 or bad_token_seq[0] not in eos_set
]
# Forbidding a sequence is equivalent to setting its bias to -inf
sequence_bias = {tuple(sequence): float("-inf") for sequence in bad_words_ids}
super().__init__(sequence_bias=sequence_bias)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SequenceBiasLogitsProcessor is where I would look into slow downs!

@DWarez
Copy link
Contributor Author

DWarez commented Jul 22, 2025

Hi @ArthurZucker, the problem was in the _prepare_bias_variables method, in particular here

self.length_1_bias = torch.zeros((vocabulary_size,), dtype=torch.float, device=scores.device)
for sequence_ids, bias in self.sequence_bias.items():
if len(sequence_ids) == 1:
self.length_1_bias[sequence_ids[-1]] = bias

In the last commit I made, I modified it with a vectorized access and it's much faster, almost reaching the perfs when not using the bad_words_ids parameter.

@DWarez DWarez changed the title [Draft] bad_words_ids no longer slow on mps bad_words_ids no longer slow on mps Jul 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

text-generation extremely slow with large bad_words_ids list
3 participants