Skip to content

feat(deepinfra): optional service_tier and an explicit request timeout - #5

Merged
nhat-di merged 2 commits into
mainfrom
deepinfra-provider
Aug 12, 2026
Merged

feat(deepinfra): optional service_tier and an explicit request timeout#5
nhat-di merged 2 commits into
mainfrom
deepinfra-provider

Conversation

@nhat-di

@nhat-di nhat-di commented Aug 12, 2026

Copy link
Copy Markdown

What

Two additions to the DeepInfra provider (src/openbench/model/_providers/deepinfra.py):

  • Optional service tier: DEEPINFRA_SERVICE_TIER env var (e.g. flex to ride spare capacity) is injected into extra_body.service_tier on each request. Env-based so a harness can control it without touching eval code; an explicit extra_body setting always wins.
  • Explicit request timeout: the OpenAI SDK's read timeout defaults to 600s and nothing upstream raises it, so long generations get cut off client-side mid-request. Sets a 3600s read-timeout backstop with a separate 30s connect timeout, so an unreachable endpoint still fails fast. Deliberately not taken from config.timeout, which inspect already spends as the retry budget — the two are different quantities.

Tests

tests/test_deepinfra_provider.py covers both: service-tier injection (set, unset, and explicit-extra_body-wins cases) and the timeout defaulting (applied by default, caller override respected). Full unit suite passes locally on the branch.

Notes

This is the branch the deployed openbench:service-tier-aa2eef860-r1 image is built from. PR #3 (hle_250) is based on this branch and can be retargeted to main once this merges.

🤖 Generated with Claude Code

nhat-di added 2 commits August 7, 2026 18:13
Two changes to the DeepInfra provider, both needed to benchmark models on
DeepInfra's own infrastructure.

**service_tier via DEEPINFRA_SERVICE_TIER.** DeepInfra accepts an optional
service_tier on chat completions; "flex" rides spare capacity, which is what
lets a benchmark harness run without competing with production traffic. Read
from the environment so a harness can set it per-run without touching eval
code, and an explicit extra_body setting still wins.

**An explicit per-request timeout.** The OpenAI SDK defaults to read=600s and
nothing upstream raises it: openai_compatible.py builds AsyncOpenAI without a
timeout, and inspect spends GenerateConfig.timeout on tenacity's
stop_after_delay, which bounds retrying and never reaches the socket. So a
generation legitimately running past ten minutes is cut off client-side.

That was measured, not theoretical: benchmarking a 9B model on mbpp (which
leaves max_tokens unset), 19-24% of requests died at exactly 599-602s while
the API had admitted every one of them in about a second and refused none.
Successful requests in the same window tailed to 479s, so the cut lands
inside the live part of the latency distribution -- and it removes the
*slowest* samples, biasing the score rather than merely shrinking it. A
later attempt to set 1200s instead still produced deaths at 1199s, because
the server's own budget can exceed that before generation even starts.

An hour is a backstop rather than a target; a run that needs it has a problem
worth seeing. Deliberately not taken from config.timeout, which inspect
already spends as the retry budget -- reusing one number for both lets a
single attempt consume the budget and leaves nothing to retry, which is the
original failure. The value is an httpx.Timeout rather than a bare float so
only the wait for tokens gets the long budget: connect stays at 30s, or an
unreachable endpoint would hang for the full hour instead of failing fast.

Also pins inspect-ai to 0.3.142; 0.3.141 was never published to PyPI, so the
declared dependency does not install.

Tests cover the timeout default, the short connect phase, independence from
config.timeout, an explicit override, and all three service-tier paths.
# Conflicts:
#	src/openbench/model/_providers/deepinfra.py
#	tests/test_deepinfra_provider.py
@nhat-di
nhat-di merged commit 9b5f613 into main Aug 12, 2026
9 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