Support PaddlePaddle with compatible API

[SigureMo]

We are PaddlePaddle contributors working on a PyTorch compatibility layer aimed at making it significantly easier for PyTorch ecosystem libraries to run on Paddle. See context: #1563

Summary

• This PR introduces a minimal, opt-in compatibility path so third-party projects such as flashinfer can be used with Paddle with very small changes.
• The approach is intentionally minimal and opt-in to avoid breaking upstream behavior for existing PyTorch users.

Design

• C++ / CUDA layer: provide an adapter that is fully compatible with the PyTorch C API surface (ATen / c10 / torch)¹. This allows third-party libraries that call into PyTorch C++/CUDA APIs to instead invoke Paddle's C++/CUDA implementation via the adapter.
• Python layer: reorganize a small compatibility layer so that Paddle's Python API matches PyTorch's API shape as closely as possible (we avoid reproducing PyTorch-specific internals like TorchVersion). The goal is that Python code can do import paddle as torch and run with minimal or no source changes.
• Import proxy: provide paddle.compat.enable_torch_proxy()² which makes import torch actually load paddle. This removes the need for import paddle as torch in most cases and keeps changes non-invasive.

Usage (example)

• Install (build with compatibility enabled)

  PADDLE_COMPATIBLE_API=1 pip install -v --no-build-isolation .

• Runtime example

  # example.py
  import paddle
  
  paddle.compat.enable_torch_proxy()  # enable proxy before import torch
  
  import flashinfer
  
  # use ops in flashinfer ...

  PADDLE_COMPATIBLE_API=1 python example.py

Why this is opt-in

• We added a simple check for the environment variable PADDLE_COMPATIBLE_API. When set, the compatibility hooks and small source adjustments are enabled. This keeps the default behavior unchanged for regular PyTorch or Paddle users.

Small changes requested in flashinfer

• JIT-related logic: some JIT code in flashinfer assumes PyTorch's directory layout. We do not aim to mirror directory structure 1:1. We request a small refactor to decouple the logic from the exact torch package file layout (make paths configurable or resolve modules by import names).
• setup.py / AOT build: during AOT compilation setup.py currently does import torch. For compatibility builds we need the build to perform paddle.compat.enable_torch_proxy() early (before import torch), or otherwise provide a small hook so the build imports load paddle instead.
• To make these changes backward-compatible, our patch adds an environment-variable driven path (PADDLE_COMPATIBLE_API) inside flashinfer; if present, we enable the compatibility adjustments only in that mode.

Would these minimal, environment-gated changes be acceptable to the flashinfer maintainers?

What we tested

• We tested the flashinfer.fused_moe.cutlass_fused_moe interface. With the compatibility mode enabled and some additional Python-side compatibility work in progress, we successfully ran fp16 unit tests for that interface.
• We plan to incrementally expand test coverage and run more of flashinfer's unit tests in CI as part of further collaboration.

Next steps (proposed)

• If you’re open to collaboration, we can:
  • Open a PR with the smallest possible changes to flashinfer (clearly marked and gated).
  • Add flashinfer tests into PaddlePaddle's CE system (run daily under PADDLE_COMPATIBLE_API=1) and gradually increase coverage.

Thank you for reviewing this PR — we welcome your feedback on the minimal integration approach and are ready to iterate on the branch or make any changes you prefer.

Footnotes

1. https://github.com/PaddlePaddle/Paddle/tree/develop/paddle/phi/api/include/compat ↩

2. https://github.com/PaddlePaddle/Paddle/blob/b38a9503d4f3f7c84af44a6399bb76ee043e7616/python/paddle/compat.py#L110 ↩