Add context window and tool calling requirements for self-hosted models

What does this MR do?

Documents what a self-hosted model endpoint needs for GitLab Duo Agent Platform: a context window the requests fit in, and OpenAI-compatible tool calling. Without tool calling, flows and GitLab Duo Agentic Chat fail with a generic error that does not name the cause.

• The context window text is @mhamda's interim text, which @nlee8 cleared to publish. Three claims differ from it:
  • "Return errors" replaces "might truncate". On a self-managed GitLab 19.5 instance and its vLLM server, every request whose prompt or requested output was longer than --max-model-len returned an error, and vLLM truncated none of them.
  • The error condition is a prompt or requested output longer than --max-model-len, not "a smaller context window". A window of 32,768 tokens, below the Qwen family's budget of 262,144, ran a flow and Agentic Chat.
  • 200,000 is the general model family's max_context_tokens. Other families set their own.
• The tool calling text comes from running the Developer flow and Agentic Chat on that instance, with a small open-weight instruct model registered in the Qwen family, with and without the vLLM flags.

The request path

flowchart LR
  A["GitLab Duo Agent Platform<br/>flow or Agentic Chat"] --> B["AI Gateway"]
  B -->|"tools, tool_choice auto or unset"| C["vLLM"]
  C --> D{"Flags set and parser<br/>matches the model?"}
  D -->|"yes"| E["Tool call returned<br/>and the tool runs"]
  D -->|"flags missing"| F["HTTP 400, a flow shows ModelError<br/>and Agentic Chat shows a banner"]
  D -->|"wrong parser that starts"| G["HTTP 200, call returned<br/>as text, no tool runs"]

Where each sentence comes from

Sentence on the page	Observed on the instance	Source
Flows and Agentic Chat send tool definitions	A flow sends tool_choice auto with its tools. Agentic Chat sends tools and no tool_choice, which vLLM reads as auto.	flow agent, Agentic Chat
Non-Agentic Chat works without tool calling	The request carried no tools.	tools rendered into the prompt text
HTTP 400 without the flags	The flow and Agentic Chat sessions failed on the first request with tools.	vLLM error text
Generic error in the UI	A flow session showed Error: ModelError. Agentic Chat showed an error banner. The AI Gateway log held vLLM's error text.	400 maps to ModelError
A mismatched parser fails silently	With a parser that does not match the model, the flow finished and ran no tool.	Observed only
Prompt or requested output more than --max-model-len returns an error	A prompt longer than the window returned 400 on a direct request. A flow with a 4,096-token window and Agentic Chat with a 16,384-token window returned 400 with vLLM's max_tokens message.	vLLM error text

The vLLM commands in vllm_gpt_oss_120b.md and supported_llm_serving_platforms.md omit these flags.

Measured with vLLM 0.32.0 and one model. Other parsers and other serving platforms were not run.

Related issues

Related to #609224

The issue also asks for a recommended minimum context window, which this MR leaves open.

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.

An AI coding assistant wrote this change. The assistant also checked each claim against the AI Gateway source and a self-managed GitLab 19.5 instance on a test VM, and ran Vale and markdownlint-cli2 on the changed page on a local copy of the repository.