Ornith-1.0-9B-KubeOps

English · Português (Brasil)

Transformers model · GGUF quantizations

Ornith-1.0-9B-KubeOps 0.2.0 is a Brazilian Portuguese fine-tune of deepreinforce-ai/Ornith-1.0-9B, specialized in evidence-driven Kubernetes incident diagnosis and safe, authorized recovery.

Version 0.2.0 adds a second, fully agentic operational fine-tuning stage. Compared with 0.1.0, it places greater emphasis on deciding whether a change is necessary, identifying the source of truth, executing the smallest authorized and reversible correction, observing the resulting state, and validating the affected service end to end.

The model was trained to:

• discover the actual cluster state before forming a diagnosis;
• distinguish observations, hypotheses, proposed actions, executed actions, and validated results;
• choose explicitly between correcting, waiting for healthy convergence, making no change, or reporting a concrete blocker;
• use kubectl, Helm, GitOps, KEDA, and operator ownership as sources of truth when represented by the incident;
• avoid inventing namespaces, resource names, containers, selectors, command output, or validation results;
• prefer read-only discovery and execute mutations only when authorization and evidence make them appropriate;
• apply the smallest safe and reversible correction instead of making broad changes;
• handle one failed correction with a bounded alternative or rollback path;
• observe the workload after a change and validate the Service, EndpointSlice, route, or application flow separately;
• finish with exactly one clear operational state: resolved, mitigated, partial, no change required, or blocked.

This repository contains the merged Transformers checkpoint. The LoRA adapter has already been merged into the model and does not need to be loaded separately.

Scope

Recommended uses

• troubleshooting Pods, Deployments, StatefulSets, Services, Ingress, and Gateway API resources;
• investigating probes, scheduling, storage, configuration, RBAC, networking, DNS, Helm, autoscaling, GitOps reconciliation, and workload availability;
• generating bounded diagnostic and recovery plans from observed evidence;
• proposing or executing minimal corrections when the host application has explicitly authorized the operation;
• interpreting tool output and validating workload and service recovery;
• building KubeOps assistants whose tool execution is controlled by the host application.

Out-of-scope uses

• autonomous cluster administration without human oversight and explicit authorization;
• unreviewed destructive commands, broad production changes, or credential handling;
• security, compliance, or disaster-recovery decisions without independent validation;
• Docker, Terraform/OpenTofu, and Terragrunt, which were not part of this training dataset;
• guaranteed correctness for unrepresented Kubernetes versions, CRDs, or infrastructure providers.

Transformers usage

This checkpoint uses the Qwen3.5 architecture and requires a recent version of Transformers.

pip install "transformers>=5.8.1" accelerate torch

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

MODEL_ID = "leandroxk/ornith-1.0-9b-kubeops"

tokenizer = AutoTokenizer.from_pretrained(MODEL_ID)
model = AutoModelForCausalLM.from_pretrained(
    MODEL_ID,
    dtype="auto",
    device_map="auto",
)

messages = [
    {
        "role": "system",
        "content": (
            "You are a KubeOps assistant. Ground decisions in observed "
            "evidence. When a correction is explicitly authorized, apply "
            "the smallest safe change and validate the resulting service."
        ),
    },
    {
        "role": "user",
        "content": (
            "The checkout service is unavailable in the production "
            "namespace. Investigate the incident. You may apply the minimum "
            "safe correction after confirming the cause."
        ),
    },
]

inputs = tokenizer.apply_chat_template(
    messages,
    add_generation_prompt=True,
    return_dict=True,
    return_tensors="pt",
).to(model.device)

with torch.inference_mode():
    output = model.generate(
        **inputs,
        max_new_tokens=1024,
        do_sample=True,
        temperature=0.6,
        top_p=0.95,
        top_k=20,
    )

new_tokens = output[0, inputs["input_ids"].shape[-1]:]
print(tokenizer.decode(new_tokens, skip_special_tokens=True))

The model retains Ornith's reasoning behavior and may produce <think> blocks. In public applications, handle this content separately and expose only the final answer to end users.

Tool use

The included chat_template.jinja accepts tools in the Transformers function-calling format. The 0.2.0 training dataset used a generic run_command tool:

tools = [
    {
        "type": "function",
        "function": {
            "name": "run_command",
            "description": (
                "Run a diagnostic or corrective command and return its exit "
                "code, standard output, and standard error."
            ),
            "parameters": {
                "type": "object",
                "properties": {
                    "command": {"type": "string"},
                    "timeout_seconds": {
                        "type": "integer",
                        "minimum": 1,
                        "maximum": 600,
                    },
                },
                "required": ["command", "timeout_seconds"],
                "additionalProperties": False,
            },
        },
    }
]

inputs = tokenizer.apply_chat_template(
    messages,
    tools=tools,
    add_generation_prompt=True,
    return_dict=True,
    return_tensors="pt",
).to(model.device)

Tool calls are serialized as XML <tool_call> blocks. When serving with vLLM, use a compatible parser:

vllm serve leandroxk/ornith-1.0-9b-kubeops \
  --served-model-name ornith-1.0-9b-kubeops \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_xml \
  --reasoning-parser qwen3 \
  --trust-remote-code

The host application is responsible for deciding which commands are allowed, executing them, returning their results to the model, and enforcing authorization. In production, use command allowlists, execution and output limits, redact Secrets, separate read-only and mutating permissions, and require explicit approval before every mutation.

Training data

The model was trained in two successive SFT stages using synthetic, curated data written in Brazilian Portuguese. The first stage combined conventional answers with agentic troubleshooting trajectories. The second stage was fully agentic and expanded operational incident resolution with no-change decisions, zero-replica recovery, failure of the first correction, rollback and alternative actions, and reconciliation through the actual source of truth.

Tool results in these trajectories are synthetic and must not be interpreted as records captured from real clusters. The figures below aggregate both training stages. Topic families are disjoint across stages, and family separation between the combined training and validation splits remains complete.

Item	Value
Total records	888
Topic families	370
Training split	706 records / 295 families
Validation split	182 records / 75 families
Family overlap between splits	0
Conventional answers	315
Agentic trajectories	573
Tool calls	3,018
Language	pt-BR
Schema	agentic_sft_v5.0

Across both stages, the trajectories were generated with xiaomi/mimo-v2.5 and reviewed with deepseek/deepseek-v4-flash, with configured fallback review and sampled adjudication. They use reviewed synthetic fixtures and the structured_synthetic_trajectory_with_critic_review generation method.

Training

Both stages used QLoRA with loss computed only on assistant tokens. Evaluation and checkpoint saving ran at the end of each epoch; the best checkpoint from each stage was loaded and merged before the next model version. Unless stated otherwise, the parameters were shared by both stages.

Parameter	Value
SFT stages	2
Epochs per stage	2
Maximum sequence length, first stage	4,096 tokens
Maximum sequence length, second stage	8,192 tokens
Per-device batch size	1
Gradient accumulation	8
Learning rate	2e-4
Scheduler	linear
Optimizer	AdamW fused
Training precision	BF16
Training-time quantization	4-bit
Gradient checkpointing	enabled
Assistant-only loss	enabled
Evaluation and save strategy	epoch
Seed	42
LoRA rank	16
LoRA alpha	32
LoRA dropout	0.05
LoRA bias	none
LoRA modules	q, k, v, o, gate, up, and down projections

The merged checkpoint is stored in FP16. The architecture declares a 262,144-token context window, but the second supervised fine-tuning stage was limited to 8,192 tokens. This fine-tune has not been specifically evaluated on very long contexts.

Evaluation

The metrics below come from the held-out validation split of the second fine-tuning stage. Families were kept separate across splits so variants of the same topic could not appear in both.

Metric	Epoch 1	Epoch 2 / best
Validation loss	0.5188	0.5150
Mean token accuracy	0.8515	0.8529

These metrics measure fit to the supervised dataset. On their own, they do not demonstrate incident-resolution rate, command safety, or improvement over version 0.1.0 or the base model. No comparative Kubernetes benchmark or human evaluation on real clusters has been completed.

Limitations and safety

• The model may still hallucinate resources, namespaces, labels, containers, symptoms, causes, command output, or successful recovery.
• Tool output may be incomplete, stale, sensitive, or ambiguous.
• Authorization described in a prompt does not replace authorization controls enforced by the host application.
• A plausible suggestion or successful command exit code does not replace post-change workload and service validation.
• Suggested commands may be incompatible with the Kubernetes version, installed CRDs, reconciler, or local policies.
• The model may select the wrong source of truth or propose a live change that a controller later reverts.
• Performance outside Brazilian Portuguese has not been specifically evaluated for this fine-tune.

Before applying a correction:

1. confirm the active context, cluster, target, and impact;
2. validate namespaces and identifiers using observed tool results;
3. identify whether Kubernetes, Helm, GitOps, KEDA, or an operator owns the desired state;
4. begin with read-only evidence and confirm that a change is necessary;
5. review every mutating command, constrain its scope, and prepare a rollback;
6. observe the workload after the change;
7. validate the Service, EndpointSlice, route, or affected application flow separately;
8. treat an unresolved second correction as partial or blocked instead of continuing an unbounded investigation.

Architecture and artifacts

• Base architecture: deepreinforce-ai/Ornith-1.0-9B
• Architecture: Qwen3_5ForCausalLM
• Type: decoder-only causal language model
• Parameter class: 9 billion
• Layers: 32
• Hidden size: 4,096
• Attention heads: 16
• KV heads: 4
• Vocabulary: 248,320 tokens
• Merged weights: FP16
• License: MIT, inherited from the base model

F16, Q8_0, Q6_K, and Q4_K_M GGUF variants are available in the companion leandroxk/ornith-1.0-9b-kubeops-GGUF repository, with Q6_K recommended for its balance of quality and memory use. They are not included in this Transformers repository.

License and attribution

This fine-tune is distributed under the base model's MIT license. See the original Ornith-1.0-9B model card for inherited architecture details, intended uses, and limitations.