Skip to content

fix(api): resolve model ids through the models.yaml index - #59

Merged
ronaldtse merged 1 commit into
mainfrom
fix/inference-index-resolution
Aug 28, 2026
Merged

fix(api): resolve model ids through the models.yaml index#59
ronaldtse merged 1 commit into
mainfrom
fix/inference-index-resolution

Conversation

@ronaldtse

Copy link
Copy Markdown
Contributor

Live symptom: POST /v1/infer {"model":"ara-diac-small-1.0-int8"} ->
404 "unknown model" while /v1/models advertises it. The Modal server
resolved ids by hardcoding the -fp32.zip naming convention instead of
the models.yaml contract; variant zips (int8/int4) and
differently-named volume copies (heb-diac-1.1) never matched.

  • New src/api/model_resolution.py: pure resolver (index filename ->
    {id}-{precision}.zip -> {id}-fp32.zip), unit-tested against the real
    models.yaml with the exact live failure cases
  • inference.py uses it; equality-only matching keeps user input out of
    path construction (CWE-22)
  • health now reports zips + model_dirs

Deploy + live verification follows (int8, int4, g2p, fp32 cases).

_zip_path hardcoded "<id>-fp32.zip" — every int8/int4 variant
(ara-diac-small-1.0-int8, tha-g2p-small-1.0-int8/-int4) 404'd as
"unknown model", and heb-diac-1.1 (index filename heb.zip, volume copy
heb-diac-1.1-fp32.zip) missed too. Resolution now goes through the
index contract with precision-convention fallbacks, matched by
equality against the volume listing (no user input in path
construction). Health reports zips + model dirs.
@ronaldtse
ronaldtse merged commit 4322b49 into main Aug 28, 2026
7 of 10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant