docs(routing): document num_retries precedence and why body max_retries is inert - #734
Open
yassin-berriai wants to merge 1 commit into
Open
docs(routing): document num_retries precedence and why body max_retries is inert#734yassin-berriai wants to merge 1 commit into
yassin-berriai wants to merge 1 commit into
Conversation
…es is inert Spell out the four places num_retries can come from and how they rank (header > request body > model_list litellm_params > litellm_settings), and explain that max_retries is the provider SDK knob rather than a second spelling of num_retries, so it has no effect on a routed proxy request. Companion to BerriAI/litellm#35483 (LIT-4772)
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Companion to BerriAI/litellm#35483 (LIT-4772)
A customer tested all 32 combinations of
num_retriesacrosslitellm_settings,model_list, thex-litellm-num-retriesheader and the request body, and had to reverse engineer the ranking from the observed request counts because it is written down nowhere. They also found that a request bodymax_retrieshad stopped doing anything and could not tell whether that was a bug or a deliberate change.This adds a short subsection under Routing -> Retries listing the four places
num_retriescan be set and how they rank, and explaining thatmax_retriesis the provider SDK knob rather than a second spelling ofnum_retries: for a routed call LiteLLM owns retries and pins the provider client tomax_retries: 0, which is what stops a deploymentnum_retries: Nfrom being applied twice and turning one request into(1 + N) ** 2upstream calls. Thex-litellm-num-retriesentry in the request headers reference now says it outranks the other three and links to that subsection.Validated with
npm ci && npm run build; the new anchor resolves and the only reported broken links on the touched pages are pre-existing ones this PR does not introduce.