Skip to content

Conversation

@gante
Copy link
Contributor

@gante gante commented Aug 17, 2024

What does this PR do?

Another step towards using Cache everywhere 💪

This PR makes the following [Cache+generate]-related changes:

  1. Don't initialize a cache when use_cache=False (fixes Cache updating when use_cache = False #32843 )
  2. generate tests now explicitly pass use_cache, instead of setting it in model.config 🤢 We were relying on a LOT of side effects, and missing the incorrect case mentioned in Cache updating when use_cache = False #32843
  3. Add sanity-checks on cache-related parameters, in generation_config
  4. Add a deprecation cycle on the default cache return type, so we start returning a Cache instance by default on generate
  5. Isolate all cache initialization logic in generate into a single function, and reorganize the logic by blocks

@HuggingFaceDocBuilderDev

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

@gante gante changed the title Generate: Update cache initialization Generate: Deprecate returning legacy cache by default; Handle use_cache=False Aug 17, 2024
Copy link
Contributor Author

@gante gante Aug 17, 2024

Choose a reason for hiding this comment

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

moved up to this documentation section (Parameters that control the generation strategy used), which makes more sense

Copy link
Contributor Author

Choose a reason for hiding this comment

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

new cache-related docs section in GenerationConfig, moved all cache-related flags here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

(>120 chars/line)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

(moved)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In our docs we often mention that there are two ways to parameterize generate (generation_config or pass arg to generate). I don't think we need to be verbose here.

Also, setting through config is deprecated 😉

Comment on lines +154 to +155
Copy link
Contributor Author

@gante gante Aug 17, 2024

Choose a reason for hiding this comment

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

rewrote this one.

The old description was outdated (legacy cache), and we now know that different models have different caches, so we shouldn't be precise here. The model class docs can be more precise, let's redirect users there.

Copy link
Contributor Author

@gante gante Aug 17, 2024

Choose a reason for hiding this comment

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

(These aliases made sense in the past, not anymore. They are, however, hard to deprecate!)

Copy link
Contributor Author

@gante gante Aug 17, 2024

Choose a reason for hiding this comment

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

New function, moving the cache logic from generate. I've organized the logic in blocks, putting the cases where we DON'T prepare a new cache at the top.

It is doing essentially the same, except for the Quick escape route 2, which is new. Added the warning in Quick escape route 3.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This logic is expanded to handle a deprecation cycle

Copy link
Contributor Author

Choose a reason for hiding this comment

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

changes in this file: pass use_cache to generate, instead of relying on model.config.use_cache=False and its side-effects

added a check to confirm that the cache is None when we pass use_cache=False

@gante gante requested a review from ArthurZucker August 17, 2024 15:26
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.

Cool! Let's make sure slow tests all pass as well here!

Comment on lines +1545 to +1550
Copy link
Collaborator

Choose a reason for hiding this comment

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

let's create an issue and leave it up to the community in the mean time!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@gante gante force-pushed the update_cache_kwargs branch from a442522 to e8492bf Compare August 22, 2024 15:09
@gante gante merged commit a26de15 into huggingface:main Aug 22, 2024
@gante gante deleted the update_cache_kwargs branch August 22, 2024 19:01
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.

Cache updating when use_cache = False

3 participants