[OpenVINO] Support Gemma3TextModel for feature-extraction

[mlukasze]

What does this PR do?

Adds a feature-extraction inputs override to Gemma3TextOpenVINOConfig so that Gemma3TextModel-based text-embedding models (e.g. microsoft/harrier-oss-v1-270m) export cleanly to OpenVINO IR.

Without the override the config inherits GemmaOpenVINOConfig.inputs, which injects position_ids into the graph and breaks sentence-transformers-style callers that pass only input_ids + attention_mask.

Mirrors the pattern used for Qwen3OpenVINOConfig added in #1415.

Installation instructions

pip install git+https://github.com/mlukasze/optimum-intel.git@enable/microsoft-harrier-oss-v1-270m
pip install -U openvino openvino-tokenizers nncf
pip install transformers

Exporting cmd-line

optimum-cli export openvino -m microsoft/harrier-oss-v1-270m ov_harrier_270m --task feature-extraction
optimum-cli export openvino -m microsoft/harrier-oss-v1-270m ov_harrier_270m_int8 --task feature-extraction --weight-format int8

Inference script

from transformers import AutoTokenizer
from optimum.intel import OVModelForFeatureExtraction

model_id = "microsoft/harrier-oss-v1-270m"
model_dir = "ov_harrier_270m_int8"

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = OVModelForFeatureExtraction.from_pretrained(model_dir)

sentences = ["OpenVINO accelerates inference.", "Text embeddings with Gemma3."]
inputs = tokenizer(sentences, return_tensors="pt", padding=True)

outputs = model(**inputs)
embeddings = outputs.last_hidden_state[:, 0]  # CLS pooling
print(embeddings.shape)  # torch.Size([2, 1152])

Before submitting

• [N/A] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
• Did you make sure to update the documentation with your changes?
• Did you write any new necessary tests?

[rkazants]

needs proper PR description with code snippets

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

[rkazants]

@mitruska, please check failing test https://github.com/huggingface/optimum-intel/actions/runs/28499616266/job/84473639987?pr=1799

[mlukasze]

Thanks for flagging this, @mitruska — investigated and pushed a fix in 2d0d8d4.

Root cause (two distinct issues, both external to this PR's diff)

build (*modeling*, 4.57.6) — AssertionError: False is not true
tiny-random-gemma3-text stores model.*-prefixed weights (a Gemma3ForCausalLM-style save). On transformers 4.57.6, Gemma3TextModel.base_model_prefix resolves to "" (not "model"), so none of the checkpoint's weights match on load — the reference model silently falls back to random init (transformers logs "newly initialized" for every param). Verified with a determinism test: two independent loads produce different embed_tokens.weight values. Comparing OV output against a randomly-initialized reference is meaningless.

build (*modeling*, latest) — RuntimeError: Float did not match BFloat16
On latest, base_model_prefix correctly resolves to "model" so weights load fine, but AutoModel.from_pretrained now honors the checkpoint's torch_dtype: bfloat16, so the reference runs in bf16 while OV always computes in fp32 (F32_CONFIG). torch.allclose raises on the dtype mismatch before any value comparison. Cast to fp32 manually: max abs diff is 0.0148 — normal bf16 rounding noise.

Neither issue is caused by this PR's diff (only touches Gemma3TextOpenVINOConfig.inputs) — both stem from the tiny checkpoint's structure vs. transformers-version-dependent Gemma3TextModel internals. Real checkpoints like microsoft/harrier-oss-v1-270m are saved unwrapped (architectures: ["Gemma3TextModel"], no prefix) and are unaffected — consistent with the ~0.999 WWB similarity already measured for this model.

Fix

Narrowly scoped to model_arch == "gemma3_text" in test_compare_to_transformers (zero effect on other archs):

• Skip with a clear message when base_model_prefix != "model" (checkpoint weights don't/can't load) — same pattern already used elsewhere in this file (ticket 175062).
• Otherwise, compare in fp32 with atol=2e-2 (vs default 1e-4) to absorb bf16 rounding, mirroring the existing per-arch atol overrides for flaubert/squeezebert.

Verification (local)

• transformers 4.57.6: target test now skips with a clear reason (was: AssertionError)
• transformers latest (5.13.0): target test now passes for real, not just skipped (was: RuntimeError)
• Full OVModelForFeatureExtractionIntegrationTest class, both versions: no regressions for any other architecture
• Confirmed test_compare_to_transformers_4_qwen3_vl_embedding (latest) and the test_quantization.py PIL.UnidentifiedImageError failures are pre-existing/unrelated (reproduced identically with git stash, i.e. present without this change too) — out of scope for this fix

Follow-up (logged, not addressed here to keep this PR minimal)

The durable fix is re-saving tiny-random-gemma3-text as a bare Gemma3TextModel (unprefixed, no baked-in torch_dtype) to match real checkpoints structurally. I don't have push access to optimum-intel-internal-testing, so I've prepared (and verified) a ready-to-run script for a maintainer: happy to share if useful — just let me know.

CI on the new commit is currently action_required (needs a maintainer to approve running workflows on this fork PR) — flagging in case that needs a manual click on your end.