[CI] Resettle pooling entrypoints tests.

[noooop]

Purpose

Resettle pooling entrypoints tests by use cases.

cc @DarkLight1337

Test Plan

tests/entrypoints/pooling/

Test Result

pass

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

[DarkLight1337]

I think we should still separate online and offline tests, because the fixtures they use are different.

[gemini-code-assist]

Code Review

This pull request is a pure refactoring of the pooling entrypoint tests. The tests have been reorganized into subdirectories based on their use case, such as basic, classify, embed, and score. This change significantly improves the structure and maintainability of the test suite, making it easier to navigate and locate specific tests. The new organization is logical and well-structured. As the PR only contains file moves and renames with no code modifications, there are no code-level issues to address. The refactoring is a positive change for the project.

[DarkLight1337]

Also, in order to better integrate with our CI refactoring, it is better for the tests to match the code organization in vLLM, so we can automatically detect which tests to run based on matching directories.

[noooop]

Also, in order to better integrate with our CI refactoring, it is better for the tests to match the code organization in vLLM, so we can automatically detect which tests to run based on matching directories.

I plan to gradually refactor the pooling entrypoints to have the same layout as this test.

#28631

What do you think?

---

and examples

#29365

[DarkLight1337]

We have a more extensive plan for this, see #27882 (review)

[noooop]

We have a more extensive plan for this, see #27882 (review)

I think there’s more code that can be reused （e.g. render）between the online and offline versions for the same use case.

Code from the same provider is hardly reusable across different use cases.

---

APIs should be organized by use case, not by provider.

[DarkLight1337]

Renderer should be placed outside both offline and online directories., similar to chat utils. There should be no need for offline code to reference online code, and vice versa.