[Feature Request] Expose an API to detect compiled model

[vlejeune-dxo]

Describe the feature request

In the doc related to ep_context cache (https://onnxruntime.ai/docs/execution-providers/EP-Context-Design.html) it is written that :

`The EP or its backend SDK should be capable of detecting common failure scenarios (including but not limited to the following). In such cases, the EP should return a status with the INVALID_GRAPH status code:

Detect mismatches between the driver version and the version required by the EP context binary; return an error if they are incompatible.
Detect mismatches between the runtime SDK version and the version used to generated the EP context binary; return an error if they are incompatible.`

However it means one has to create a session to detect such mismatch ; to create a session involves allocating some resources and probably doing some JIT for some EP, which takes time.

We would like to have a separate API that can check if there is a mismatch, without actually creating a session. This could be part of the compilation API.

Describe scenario use case

We use the compilation API at the moment and sometime load models from disk, and sometime we load them from buffer (when we need to hide model weights).

Our use case is the following :

• at application startup, we detect if a model needs to be compiled or not, and if it does we compile it : the goal is to avoid compilation during the usage of the application.
• We currently check if a model needs to be compiled by creating a session, listening for an ort error, and deleting it afterward (if we don't we will fill the memory too quickly)
• The issue is that it takes a dozen seconds to just create sessions for all our models, even if there is nothing to compile (which is the nominal case).

[adrastogi]

@vlejeune-dxo, thanks for filing this request. As background, we introduced some new APIs into the EP ABI which we are working with IHVs to implement which will have their EPs write a custom string into a compiled model's metadata. These strings contain IHV-specific details about how the model was compiled (e.g., perhaps an IHV might write some data about the driver version the model was compiled with, etc.). This data can be used to perform compatibility checking against the underlying device in coordination with the EP. I am not sure how much context you have on this feature, but you can look at #25749 and #25841 for more details. Anyway, the validation logic is wired up in session initialization, and we are currently working to optimize its placement so that it takes place before some of the heavier-weight operations in that code path. And there is an API (GetModelCompatibilityForEpDevices) that an app can call to query the compatibility status of the model (this was implemented in #25841).

To further help with this scenario, we have a proposed API in #27015 which an application can use to retrieve the compatibility information from the model. That data can then be passed to GetModelCompatibilityForEpDevices for validating the compatibility status before e.g., proceeding to session initialization (there are some performance caveats to this approach that we've noted in the PR for #27015- i.e., because the compatibility information is stored in the metadata, it requires parsing the model's protobuf, which would happen again during any later session initialization).

Would love any feedback from you on the direction and whether this seems viable for your purposes.