LLM package conflict with kubeflow base image

[swapnilsingh81]

We are attempting to use Kubeflow notebook images as a development environment for a modern GenAI / NL2SQL use case (vLLM, LangChain, FastAPI). However, we are facing hard dependency conflicts with the Kubeflow base images.
Kubeflow components such as KServe, Ray, and MLflow appear to be tightly coupled to older versions of numpy, pandas, and pydantic. Our GenAI stack requires newer versions (numpy ≥2.x, pandas ≥2.x, pydantic ≥2.x), and upgrading these breaks core Kubeflow services.
Conversely, retaining the Kubeflow-compatible versions causes vLLM and LangChain to fail. This results in mutually incompatible dependency requirements within a single notebook environment.
We would like to understand:

• Is there a recommended way to support modern GenAI libraries within Kubeflow notebooks?
• Are there plans to decouple Kubeflow components from strict numpy/pandas/pydantic version constraints?
• Is the expected pattern to use Kubeflow only for execution/serving and not for active development?
  Any guidance or best practices from the community would be appreciated.