feat[vLLM x v5]: Rename audio_processor to feature_extractor on Granite Speech and Phi-4 Multimodal processors

[harshaljanjani]

What does this PR do?

→ Fixes vllm-project/vllm#39330 (comment)
→ Renames from audio_processor to feature_extractor, every other audio-capable processor in the codebase already uses feature_extractor; these two were the only outliers. Blocker to the vLLM Transformers audio backend PR.
→ BC preserved for the deprecation cycle, adapted precedent from the PretrainedConfig.torch_dtype pattern.
→ Version matrix considerations: Users on older Transformers are unaffected; users on new Transformers hitting the legacy .audio_processor path see one logger.warning_once per session; downstream consumers (including vLLM's own native granite_speech.py / phi4mm.py) have until v5.20 to migrate.
→ Made sure this doesn't cause any regressions in tests/models/granite_speech/ and tests/models/phi4_multimodal/.

cc: @vasqu @eustlb @ebezzam

Code Agent Policy

• I confirm that this is not a pure code agent PR.

Before submitting

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

[github-actions]

[For maintainers] Suggested jobs to run (before merge)

run-slow: granite_speech, phi4_multimodal

[github-actions]

---

CI recap

Dashboard: View test results in Grafana
Latest run: 28497155988:2
Result: success | Jobs: 2 | Tests: 24 | Failures: 0 | Duration: 2m 7s

[vasqu]

Hmm pretty sure we honestly want to switch the other way around at some point but it's a bigger refactor effort, i.e. it takes time. I guess vllm wants to keep consistent naming but you can also nudge to this comment / the discussion resulting for this PR

@eustlb / @ebezzam do you know the current status?

[ebezzam]

FYI here's the PR that @vasqu is referring to: #44394
which will refactor feature extractor to audio processor

not sure what's best, maybe they should be temporarily renamed to feature_extractor as that's the current standard? and the above PR will handle the global library refactor. As I think it will take some time before that PR is merged since it is handling more than just renaming

[vasqu]

Ok, so it will take a while but I honestly believe it's worse to rename because we drop it either way in the future. Would it be possible to accept both in vllm as we will start deprecating the feature extractor sooner than later and there probaly needs to be some period of adopting

[ebezzam]

yep I agree with @vasqu. It would be strange for us to have a deprecation warning for audio_processor, and then in the end bring it back

[harshaljanjani]

Makes sense, thanks for the clarification @vasqu and @ebezzam, closing the PR. Will point to this discussion and keep both args supported on the vLLM side. Separately, I was wondering if I could bump this audio PR if it'd be of value, whenever you have the time; think it may have gone under the radar last week, thank you!

[ebezzam]

@harshaljanjani thanks for pointing out the Canary PR! We have been porting several Nemo models to Transformers recently. I'll try to give some feedback by this/next week.

[harshaljanjani]

Awesome!! Really appreciate it and thanks for your time :)