Add CPU pytest CI and NIXL P/D example

[Lanoxia]

Summary

• add a CPU-only pytest workflow that runs mocked/pure-Python regression tests across Python 3.9-3.13
• add a shared local/CI entrypoint at tools/run_cpu_tests.sh
• document the vLLM NIXL prefill/decode smoke test under examples/10_vllm_nixl_pd
• make test_make_cache_key.py independent of real PyTorch/CUDA by mocking torch before importing kvcached

Motivation

The repository currently has lint/type-check CI but does not run the existing pytest coverage in CI. This PR starts with the tests that are intentionally isolated from GPU, vLLM, SGLang, and the C++ extension, so they can run on standard GitHub-hosted runners.

The NIXL P/D example also makes the existing smoke script easier to find and use while the roadmap continues to track P/D disaggregation compatibility work.

Validation

• bash tools/run_cpu_tests.sh -> 56 passed
• bash -n tools/run_cpu_tests.sh
• bash -n tools/run_vllm_nixl_pd_smoke.sh
• git diff --check

Closes #395

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[Lanoxia]

Ready for review.

I started with the CPU-only pytest coverage from #395, then added a small preflight mode for the NIXL P/D smoke harness so reviewers can validate the script/configuration path on a non-GPU machine before running the full CUDA/vLLM test:

CHECK_ONLY=1 bash tools/run_vllm_nixl_pd_smoke.sh

I kept the CI suite intentionally narrow to tests that are already mocked or pure-Python and do not require vLLM, SGLang, CUDA, or the C++ extension. Happy to split the NIXL P/D example/preflight work into a separate PR if that is easier to review.

[shipiyouniao]

Thanks for taking on #395. I think this PR now needs to be split before further review.

The current branch combines several independently reviewable and independently risky changes:

• CPU-only pytest CI
• a NIXL P/D example and smoke harness
• GPU-utilization behavior changes in the serving integrations
• an H20 validation report

Those changes have different validation requirements and owners. Keeping them in one PR makes it difficult to determine what the CI change actually depends on and makes a future revert unnecessarily broad. Could you please keep this PR focused on the CPU test workflow, its runner, and only the minimal test-isolation fixes required by that workflow, and move the other changes into separate PRs? The existing pre-commit failure should also be resolved after the split.

There is also a coverage-maintenance concern with the current fixed three-file list in tools/run_cpu_tests.sh: newly added CPU-safe regression tests will remain silently excluded unless someone remembers to edit the script.

For test classification, I suggest using execution boundaries as the primary mechanism, for example:

• tests/cpu/: no physical accelerator, serving engine, or compiled VMM extension required
• tests/gpu/: requires CUDA/HIP and the compiled extension
• tests/integration/: requires vLLM/SGLang, multiprocess services, or an end-to-end environment

Then the hosted job can run only pytest tests/cpu. If moving files is too disruptive, explicit CPU/GPU/integration manifest files are also workable, provided CI validates that every tests/test_*.py module appears in exactly one manifest.

Pytest markers such as cpu, gpu, integration, and slow are useful secondary metadata and should use --strict-markers, but pytest -m cpu alone is not a complete isolation mechanism: pytest imports modules during collection before marker deselection, so GPU-only modules can still fail on a hosted CPU runner due to CUDA, vLLM, or extension imports.

Once the PR is focused and the classification rule prevents silent omissions, this will provide a useful merge gate for the regression tests being added across the project.