ovis_image: fix guidance_scale / max_sequence_length / batched CFG / precomputed embeds + add pipeline test

[HaozheZhang6]

What does this PR do?

Addresses items 3, 4, 5, 6 and 7 from the ovis_image review in #13630.

• Item 3 — OvisImagePipeline.guidance_scale read an uninitialized self._guidance_scale; it's now set in __call__.
• Item 6 — max_sequence_length was validated but never reached the tokenizer; it's now threaded through encode_prompt → _get_ovis_prompt_embeds.
• Item 5 — precomputed prompt_embeds were used as-is; they're now moved to the right device/dtype and repeated for num_images_per_prompt.
• Item 4 — a single default negative_prompt with batched prompts under CFG raised a shape error; the negative prompt is now expanded to the batch size. Also guarded _get_ovis_prompt_embeds against text_encoder=None.
• Item 7 — adds tests/pipelines/ovis_image/test_ovis_image.py (the model had no pipeline test) covering inference, the guidance_scale property, max_sequence_length, num_images_per_prompt, and batched CFG.

Item 2 (joint_attention_kwargs) and notes on the full PipelineTesterMixin are in a comment below.

Before submitting

• Did you use an AI agent (Claude Code, Codex, Cursor, etc.) to help with this PR? If so:
  • Pointed it at .ai/ — read AGENTS.md and review-rules.md.
  • Self-reviewed the diff against .ai/review-rules.md.
• Did you read the contributor guideline?
• Was this discussed via a GitHub issue? Yes — ovis_image model/pipeline review #13630.
• Did you write any new tests? Yes.

Who can review?

@hlky

[hlky]

This looks good so far @HaozheZhang6. As this is a new test, I would look at some of the recent test refactors and adopt those newer patterns to avoid needing a refactor later.

For the ovis_image review, item 1 is already covered by the pattern level PR you made. I would say items 2 and 6 are other easy fixes, while 4 and 5 are also fairly straight forward. If you feel confident I'd suggest attempting those too, then you'll completed the full review.

[HaozheZhang6]

Thanks @hlky! Makes sense — I'll switch the test to the full PipelineTesterMixin using the newer pattern (a realistic tiny Qwen3 text encoder like the DreamLite / NucleusMoE-Image tests, so the standard save/load and dtype/device tests pass out of the box), and take on items 2/4/5/6 so the full review is covered. Will push the updates here.

[HaozheZhang6]

Pushed items 3/4/5/6 + the test. Two things I'd value your steer on:

1. Full PipelineTesterMixin — I started toward it but ovis hits two infra issues: the tiny model produces NaN in the offload / save-load comparison tests (DreamLite avoids this with AutoencoderTiny + a realistic Qwen3-VL), and the tokenizer's chat_template is lost on save/load because the pipeline uses a bare tokenizer (no processor component like DreamLite). Happy to mirror the DreamLite fixture exactly if that's the intended approach.
2. Item 2 (joint_attention_kwargs) — the transformer forward doesn't currently accept attention_kwargs; the blocks already do, so it looks like a matter of threading it through forward → blocks and passing self.joint_attention_kwargs from the pipeline. I'll do that next unless you had a different shape in mind.

[HaozheZhang6]

Done — items 2/4/5/6 are in, and the test is now on the full PipelineTesterMixin (passes locally, plus a couple of ovis-specific checks).

Heads up on one design choice: to get test_encode_prompt_works_in_isolation passing I changed encode_prompt to encode and return both the positive and negative embeds in a single call (the z_image / PixArt convention) instead of calling it twice. The negative path already accepted precomputed embeds — this just returns them so the standard test can pick them up. If you'd rather keep encode_prompt single-prompt, I'll revert that and skip the one test instead.

item 2 is threaded through forward with @apply_lora_scale, matching flux.

[hlky]

@HaozheZhang6 LGTM, nice work.

For test_encode_prompt_works_in_isolation/encode_prompt I think returning both is the right choice, it's established in more popular model/pipelines and required for the test itself. The change for item 2 is also the correct approach and @apply_lora_scale is a thoughtful extra touch.

As a general rule I would say if a pattern is present in a more popular model/pipeline it's usually a good indication that it's the preferred approach.

At this point I think you are ready to request a review from a maintainer for approval, I would expect the tests may have some requested changes because of the recent refactors we mentioned, I haven't followed those changes exactly so I can't be more specific, my suggestion would be to await the review before making any further changes.

[HaozheZhang6]

Thanks @hlky — appreciate you walking me through this one. I'll request a maintainer review and hold off on any further changes until then.

[HaozheZhang6]

@DN6 — per @hlky's suggestion above, would you have a chance to review this for approval? You did the recent Ovis transformer refactor (#13347), so you've probably got the most context here. CI is green and the full PipelineTesterMixin passes.

[github-actions]

Hi @HaozheZhang6, thanks for the PR! It does not appear to link an issue it fixes. If this PR addresses an existing issue, please add a closing keyword (e.g. Fixes #1234) to the PR description so the issue is linked. See the contribution guide for more details. If this PR intentionally does not fix a tracked issue, a maintainer can add the no-issue-needed label to silence this reminder.

[HaozheZhang6]

@DN6 friendly re-ping -- hlky LGTM'd this and pointed to you for the final review given your Ovis transformer refactor (#13347). CI is green and the full PipelineTesterMixin passes. No rush.

[HaozheZhang6]

Thanks @hlky — incorporated the review feedback. @sayakpaul would you have a moment to take a look for approval? Happy to update the tests for the recent refactors once a maintainer flags the specifics.

[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.

[dg845]

nit: since we always need dtype for text_ids below, maybe we can define it once at the top of _prepare_prompt_embeds?

[dg845]

Thanks for the PR! Left some small comments.