Build a troubleshooting planner.
Feed a small incident summary and relevant logs into a planning job. Ask for checks that distinguish likely causes, and require an operator to approve actions that change a running service.
gpt-oss-20b is OpenAI’s open-weight reasoning model. Prepare an AI Fabric worker for planning, analysis and tool calling, with control over reasoning effort and how your application executes each requested action.
€5 in free credits for every new customer.
Plan your deploymentAI Fabric access is opening gradually. GPU configuration is confirmed during onboarding.
Give analytical tasks a clear stopping point: a diagnosis to check, a plan to review or a tool result to explain. Tune reasoning effort against successful task completion.
Feed a small incident summary and relevant logs into a planning job. Ask for checks that distinguish likely causes, and require an operator to approve actions that change a running service.
Run the same set of bounded analytical questions at different effort settings. Track correct answers, response time and truncated outputs to choose a useful default for your users.
Let the model request a database lookup or a diagnostic operation through a named tool. Validate arguments and return the observed result before asking it to decide the next step.
Model capabilities and upstream setup: gpt-oss-20b publisher reference. Reviewed .
Deployment preparation
OpenAI documents a memory footprint within 16 GB for gpt-oss-20b. Reproducing that depends on a compatible runtime; a fallback that expands weights can change memory needs substantially. Validate the engine and GPU combination first.
from transformers import pipeline
runner = pipeline(
"text-generation",
model="openai/gpt-oss-20b",
torch_dtype="auto",
device_map="auto",
)
messages = [
{"role": "system", "content": "Reasoning: low"},
{"role": "user", "content":
"Plan checks for a worker that retries forever."},
]
result = runner(messages, max_new_tokens=1024)
print(result[0]["generated_text"][-1])Upstream-style Python baseline, not a verified 16 GB deployment recipe. Use a compatible Transformers, PyTorch and kernel environment; confirm that weights are not expanded beyond your GPU budget. vLLM runtime and GPU guidance ↗
GPU memory & performanceRTX A4500 and RTX 2000 Ada have different GPU architectures. Confirm that the selected MXFP4 kernel works on the specific card; a parameter count or a published memory figure does not validate the runtime.
In your applicationBudget output tokens for reasoning as well as the final answer. Detect truncation and cap tool iterations so one unresolved task cannot loop indefinitely.
AI Fabric availability & costRTX A4500 (20 GB) and RTX 2000 Ada (16 GB) are the GPU options. Access, runtime settings and billing are confirmed during onboarding. No Blade latency or throughput benchmark is published for this configuration.
Define allowed tools and their schemas in the serving integration. When the model requests a tool, your backend executes it with scoped permissions and sends the result back. Log the executed action separately from the model’s proposed action.
No. The runtime must preserve a supported low-memory representation. Test the exact engine, kernel, context and card during onboarding.
The model can participate in tool workflows, but your application must provide the search implementation, credentials and execution logic. Model weights alone do not supply a search service.
Use tasks with verifiable answers and measure end-to-end completion, including retries and tool calls. Select the lowest effort that reliably meets your acceptance criteria.
Measure the full reasoning task, including generated reasoning tokens, tool calls and retries. Compare effort settings using completed tasks rather than response length alone.
The GPU billing unit and idle policy are confirmed during onboarding. Managed Models API rates do not apply to this deployment.
Checkpoint: openai/gpt-oss-20b. Access requirements and licence: gpt-oss-20b publisher reference.