OpenShift AI 3.5 upgrades can duplicate models in GenAI Studio

Red Hat has verified a presentation and inventory problem after upgrading or migrating Red Hat OpenShift AI from 3.4 to 3.5: the same deployed model can appear twice in GenAI Studio’s Playground. The Customer Portal solution, updated Sept. 19, lists OpenShift AI 3.4 and 3.5, GenAI Studio, Playground and deployed models as the affected environment.

The upgrade condition

The trigger Red Hat exposes publicly is the 3.4-to-3.5 upgrade or migration path. The symptom is not two similarly named models in a catalog; it is a duplicate entry for the same model in GenAI Studio → Playground after the transition.

That distinction matters for cleanup. A UI list can aggregate state from more than one backing record, and deleting an entry without first identifying its underlying deployment risks removing the working model rather than only the stale representation.

What users see

The immediate consequence is ambiguity in Playground: users can be offered two choices that appear to represent one deployed model. That can undermine test repeatability and make it unclear which entry maps to the live serving endpoint. Red Hat’s public notice does not say that the model process itself is duplicated, so operators should verify deployment state rather than infer extra compute consumption from the UI alone.

Verify before changing anything

Before the upgrade, export or record the deployed-model inventory, including model name, namespace, serving runtime, endpoint and any stable identifiers exposed by the platform. Take a screenshot or structured record of the Playground list so the post-upgrade comparison has a known baseline.

After upgrading:

1. Compare Playground entries with the pre-upgrade inventory.
2. Map each visible entry to a live deployed-model resource and endpoint.
3. Confirm whether one or two backing deployments actually exist.
4. Run a controlled request against the intended endpoint.
5. Preserve logs and object definitions before attempting cleanup.

Use the supported cleanup path

Red Hat’s resolution is subscriber-only. That makes the safe cleanup boundary clear: do not delete a model deployment, database record or platform custom resource merely to remove a duplicate label from Playground. Follow the current solution’s supported procedure or open a Red Hat support case, especially if the two entries cannot be mapped unambiguously.

The acceptance test is not just that one row disappears. It is that Playground shows one intended entry, the backing deployment remains healthy, the endpoint still serves requests, and no unrelated model record was removed. Treat the duplicate as an identity-reconciliation problem first and a cosmetic problem second.