Azure `:models` parameter is ignored

[astoff]

trafficstars

Please update gptel first -- errors are often fixed by the time they're reported.

• [x] I have updated gptel to the latest commit and tested that the issue still exists

Bug Description

It seems that the :models parameter of gptel-make-azure doesn't have any effect, and the model being called is determined by YOUR_DEPLOYMENT_NAME alone (cf. https://github.com/karthink/gptel?tab=readme-ov-file#azure).

Backend

None

Steps to Reproduce

Try

 (setq
  gptel-backend (gptel-make-azure "Azure-1"
                 :protocol "https"
                 :host "YOUR_RESOURCE_NAME.openai.azure.com"
                 :endpoint "/openai/deployments/YOUR_DEPLOYMENT_NAME/chat/completions?api-version=2023-05-15"
                 :stream t
                 :key #'gptel-api-key
                 :models '(gpt-4o gpt-999)))

The model Azure-1:gpt-999 works and gives the same answers as Azure-1:gpt-4o.

Additional Context

Emacs 30 on Linux

Backtrace

Log Information

[karthink]

I don't know how Azure should be configured, sorry. Is YOUR_DEPLOYMENT_NAME always predictable from the model name, across all Azure deployments? If it is then we can generate the endpoint dynamically from the active gptel-model.

[astoff]

I don't know how Azure should be configured, sorry.

I'm no expert either, I hope my comment helps anyway.

The YOUR_DEPLOYMENT_NAME is not necessarily the model name; rather it's an arbitrary "nickname" you create for a model. In my experience so far you completely determine an Azure model by providing a :host, a DEPLOYMENT_NAME and an api-version date.

The model property in the request body seems to not do anything (the API is OpenAI-compatible, however what the implications are for the model property is unclear to me...).

[karthink]

gptel makes the assumption that there is always an active model, so the backend has to specify a model, even if it's a dummy.

[astoff]

So I guess the conclusion is that the endpoint might depend on the model. Maybe you could make the endpoint slot accept a function taking the model and the backend as argument.

Or else, do something special for Azure: add an api-version slot and a hard-coded rule to compute the endpoint from that and the model/deployment name.