The ultra-edge rung of the kubelm tier ladder: a 0.8B-parameter K8sGPT MCP tool-use specialist, trained with QLoRA on Qwen3.5-0.8B and quantized to Q4_K_M for the tightest-hardware CPU-only deployment. The 517 MB GGUF serves in ~0.9 GB RAM and is the fastest per-step model in the family.

This is the smallest deployable in the family. The headline deployable is the 2B kubelm-qwen3.5-2b-v1 (edge+). Pick this model when RAM/latency on the target box rules out the 2B, and judge it within its own resource bracket — not against the tier above it.

TL;DR

On the 35-scenario v0.3 evaluation library, served via llama-server at temperature 0:

metric	Qwen3.5-0.8B (untrained)	kubelm-qwen3.5-0.8b-v1	qwen2.5-7b (ref)	kubelm-qwen3.5-2b-v1 (ref)
`conclusion_rubric_passed`	19 / 35	24 / 35	28 / 35	32 / 35
`reference_calls_passed`	30 / 35	34 / 35	28 / 35	32 / 35
`fabrications` (grounding v2)	7	14	8	3
`schema_passed` (tool-call)	35 / 35	34 / 35	34 / 35	35 / 35
`termination_label == complete`	27 / 35	31 / 35	33 / 35	35 / 35
`narrative_inconsistencies`	0	0	0	0

Honest read. Fine-tuning is a real lift over the untrained base (rubric 19 → 24, completion 27 → 31), and on reference-call accuracy (34 / 35) the 0.8B actually tops both the 7B and the 2B — it picks the right K8sGPT tools. Two weaknesses are real and not hidden: rubric 24 trails the 7B (28) and the 2B (32), and the fabrication count (14) is its softest metric — higher than both references. This is the underfit signature of a 1-epoch schedule (see Training); it is the deliberate trade for keeping the model's reasoning intact at this capacity. Zero tool-name and zero argument hallucinations across all 35 trajectories.

At rubric 24 this is a legitimate ultra-edge tier — it beats its own base and makes correct tool calls — but it is not competitive with the 2B. The gap is model capacity, not training recipe. Full rows: eval/results/summaries/kubelm-0.8b-finetune-2026-05-29.json.

Quickstart (recommended: llama-server)

bash

# Boot the model (Apple Silicon shown; on Linux drop -ngl or set 0)
brew install llama.cpp   # or: build from https://github.com/ggml-org/llama.cpp
huggingface-cli download rbentaarit/kubelm-qwen3.5-0.8b-v1 \
    kubelm-edge.Q4_K_M.gguf --local-dir .

llama-server \
    -m kubelm-edge.Q4_K_M.gguf \
    --host 127.0.0.1 --port 8088 \
    --jinja \
    -c 16384 \
    -ngl 99

Three serving-config notes that are load-bearing:

--jinja uses the model's embedded Qwen 3.5 chat template (including its tool-call rendering). Without it, tool-use will silently break.
-c 16384 matches the model's max_seq_length at training time. Long-trajectory investigations regularly accumulate 9–11 K tokens of conversation history; a smaller context errors with HTTP 400 request exceeds the available context size. The 0.8B loops more than the 2B on its hardest cases — serve with generous context (32768 if RAM allows) for an untrained-base bake-off.
Disable thinking via chat_template_kwargs: {enable_thinking: false} in your /v1/chat/completions payload. The training corpus contains no <think> blocks; serving in thinking mode is a train/serve mismatch and silently degrades quality.

In production, drive this through the K8sGPT MCP server and the kubelm eval harness so the model can call real tools against a real cluster.

Why the ultra-edge tier exists

Per-step CPU latency is dominated by prompt processing, so it scales with accumulated tool-output size, not step count. On a real 2-core x86 Linux node the 0.8B runs pp ~165 / tg ~39 tok/s (≈16–32 s/step) in ~0.9 GB RAM — fast enough, and small enough, to terminate at the root cause on hardware where the 2B would be RAM- or latency-bound. Terminating at the root cause on tight hardware is what makes the model deployable, which is the entire reason this rung exists.

Intended use

Tool-use specialist for K8sGPT MCP investigations on the tightest CPU-only hardware (small Linux boxes, RAM-constrained edge nodes).
Local component of agentic K8s diagnosis pipelines where the destructive-action layer is handled by K8sGPT's operator + Mutation CR policy gates (the model proposes; the operator gates).

Out of scope

Snapshot diagnosis from raw cluster YAML. Trained on multi-step tool-use trajectories, not Q&A pairs over frozen cluster state.
Safety / refusal decisions on destructive operations. That layer is architectural in the K8sGPT ecosystem; the model is trained for reliability properties, not behavioral refusal.
Direct kubectl usage. The tools list is K8sGPT MCP-specific.
General K8s domain knowledge questions outside the K8sGPT MCP tool surface.

Training

Base model: Qwen 3.5 0.8B.
Dataset: rbentaarit/kubelm-seed-v0 v0.2 corpus — 561 records across all 33 scenarios. Identical corpus, recipe, and Qwen 3.5 render-fix as the 2B; the only change is the base model and the schedule.
Method: QLoRA, rank 32 / alpha 64, target modules q_proj k_proj v_proj o_proj gate_proj up_proj down_proj. LoRA adapter included in this repo under adapter/.
Schedule: 1 epoch (the keeper), batch 8 × grad-accum 2, lr 2e-4 cosine, warmup 3%, max_seq_length 16384, seed 42. Train loss bottomed at ~0.20 — underfit by design.
Why 1 epoch. A 2-epoch run overfit (loss 0.016) and collapsed rubric back to the untrained 19 while cleaning fabrications to 3 — a reasoning↔grounding trade. A 1.5-epoch "sweet-spot" run was then tested to see if the trade had a hump between the endpoints: it did not. 1.5ep slid monotonically along the same curve (fabs 14 → 9 but rubric flat at 24 and completion regressed 31 → 25), so it was not released. 1 epoch keeps reasoning (rubric) intact, which is the headline metric for this surface. The remaining lever for a future version is lower LR at 1 epoch, not more epochs.
Hardware: 1× H100 SXM (RunPod). The Qwen 3.5 hybrid linear-attention arch has no working fla/causal-conv1d fast path on current Unsloth+Triton; only H100-class FLOPS are tractable.
Train recipe: training/sft.py with restore_base_chat_template: true (the two Qwen 3.5 chat-template mitigations are documented on the 2B card).

Evaluation

Methodology and eval harness: github.com/rbentaarit/kubelm/eval. Each scenario boots a fresh kind cluster, seeds the failure mode, brings up a real K8sGPT MCP server against it, then runs the model through the trajectory loop and grades the result. Mocked MCP servers are not used at any stage.

Versioning

K8sGPT version pin: 0.4.32. Tool surface and MCP error shapes change between K8sGPT releases; quality numbers above are not guaranteed against other versions.
MCP protocol version: 2025-03-26.

Known issues

ollama cannot load this GGUF (same Qwen 3.5 loader limitation as the 2B). Use llama.cpp's llama-server; the GGUF is valid under llama.cpp.
Fabrication rate (14) is the softest metric. This is the underfit-schedule trade described above. If your application is more sensitive to over-confident grounding than to reasoning depth, the 2B is the better choice.
No native tool-call format other than OpenAI Chat Completions.

License

Apache 2.0. The base model is Qwen 3.5 0.8B (Apache 2.0). The training corpus is CC BY 4.0.

Citation

@misc{kubelm_qwen35_0_8b_v1,
  title  = {kubelm-qwen3.5-0.8b-v1},
  author = {Ramzi Ben Taarit and contributors},
  year   = {2026},
  url    = {https://huggingface.co/rbentaarit/kubelm-qwen3.5-0.8b-v1},
  note   = {QLoRA on Qwen3.5-0.8B; trained against K8sGPT v0.4.32 MCP trajectories}
}

Source code

All training, evaluation, and dataset-construction code: github.com/rbentaarit/kubelm.