ZynDwarf-1.1

ZynDwarf-1.1 is a compact general-purpose conversational and programming assistant derived from Liquid AI's LFM2.5-350M and adapted by Zyn Models / itsZyn for local inference and agent-oriented workflows.

The release is intentionally small: approximately 354.5M parameters, with Transformers/Safetensors weights and two GGUF distributions for CPU/local inference:

• ZynDwarf-1.1-f16.gguf - highest-fidelity GGUF release.
• ZynDwarf-1.1-Q4_K_M.gguf - compact 4-bit release for lower-memory devices.

The model is designed for short-to-medium conversational turns, programming assistance, structured responses, planning, and tool-oriented agent loops. It is not intended to replace larger models for knowledge-intensive research, difficult mathematics, long autonomous tasks, or high-stakes decisions.

Important: the model's architecture supports a 128K-token maximum position length, but this release was trained with a 768-token training sequence cap. A 128K context window therefore must not be interpreted as a guarantee of 128K-token quality or practical inference on low-memory hardware.

---

Model at a glance

Property	ZynDwarf-1.1
Base	LiquidAI/LFM2.5-350M
Architecture	LFM2 / Lfm2ForCausalLM
Parameters	~354.5M
Vocabulary	65,536
Architectural context	128,000 tokens
Training sequence cap	768 tokens
LoRA	r=8, alpha=16, dropout=0.05
LoRA targets	q/k/v
Learning rate	1.5e-6
Optimizer steps	376
Epochs	1
Gradient accumulation	4
Training examples encoded	1,503
Tool-oriented examples	308
Multi-turn examples	62
Languages emphasized	Spanish + English
GGUF F16	~676 MiB
GGUF Q4_K_M	~216 MiB

---

What changed for 1.1

ZynDwarf-1.1 is the release line intended to supersede the previous public General Agent publication.

The training target was not to memorize a fixed collection of benchmark questions. Instead, the dataset was constructed around behavioral classes:

1. normal conversation without tools;
2. programming and debugging;
3. Spanish and English interaction;
4. structured output;
5. tool selection and tool-call formatting;
6. multi-turn agent trajectories;
7. recovery after tool failures;
8. planning and task decomposition;
9. cases where using a tool is unnecessary;
10. varied code and configuration tasks.

The training data was capped at 768 tokens per encoded sequence. This is deliberately documented because the model architecture and the training context are different things. Marketing a 128K architecture as if it had been trained on 128K sequences would be a rather impressive way to manufacture a benchmark result from thin air.

---

Agent and tool-use support

ZynDwarf-1.1 includes a chat template with explicit support for tool definitions and assistant tool calls.

The template accepts tool definitions through the standard tools argument and renders assistant calls using the model's native control tokens:

<|tool_call_start|>[ToolName(argument='value')]<|tool_call_end|>

The release therefore supports an agent architecture in which the host application is responsible for:

1. presenting available tools to the model;
2. rendering the conversation with the chat template;
3. detecting a tool call in the assistant output;
4. validating the requested function and arguments;
5. executing the tool outside the model;
6. returning the tool result as a new message;
7. continuing generation;
8. stopping when the model produces a final answer.

Security boundary

The model does not receive permission to execute commands by itself. Tool execution must remain in the host application. Treat model-generated tool names and arguments as untrusted input and validate them before execution.

A safe agent loop is therefore:

user
  ↓
chat template + tool definitions
  ↓
ZynDwarf-1.1
  ↓
tool call OR final answer
  ↓
host validation
  ↓
tool execution
  ↓
tool result
  ↓
ZynDwarf-1.1
  ↓
final answer OR another validated tool call

Important agent limitation

The release's chat template is tool-aware, but tool compatibility is not equivalent to perfect tool-use accuracy. The local regression suite described below found that the standalone CLI test did not reliably emit the requested native tool-call syntax on the two explicit tool-call prompts. This result is published rather than hidden. Integrators should test their exact tool schema and runtime adapter before deploying an autonomous loop.

---

Local evaluation

Test protocol

A private regression suite of 16 prompts was executed against the Q4_K_M release using llama.cpp on the release server.

The suite covers:

• conversation;
• Spanish explanation;
• Python generation;
• Bash generation;
• JSON-only output;
• arithmetic;
• logical reasoning;
• no-tool behavior;
• explicit tool calls;
• tool-failure recovery;
• planning;
• debugging;
• multi-turn recovery;
• English response;
• concise instruction following.

The prompts used for this release are not presented as a public training set and were not used as a recipe for memorizing the test cases.

Result

8 / 16 passed = 50.0% on the current small regression suite.

This is a development regression score, not an industry-standard benchmark and not directly comparable with IFEval, BFCL, MMLU-Pro, GPQA, or other published benchmark numbers.

Category breakdown

Category	Result
Overall	50%
Agent / explicit tool call	0%
Code	50%
No-tool	100%
Reasoning	0%
JSON	0%

The strongest result in this small suite was the no-tool behavior. The largest current weakness is explicit tool-call emission, followed by strict structured-output and reasoning cases. These weaknesses should be treated as release limitations rather than ignored because the model card would look prettier without them.

---

Real CPU throughput test

Measured with llama.cpp llama-bench, 2 CPU threads, 128-token prompt and 128-token generation workload.

Variant	Size	Prompt processing	Generation
F16	676.25 MiB	212.12 tok/s ± 8.48	18.89 tok/s ± 0.91
Q4_K_M	216.41 MiB	272.07 tok/s ± 0.48	34.42 tok/s ± 9.82

The Q4_K_M build is approximately 68% smaller than F16 and was substantially faster in this CPU test. The exact throughput will vary with CPU model, thread count, memory bandwidth, context length, and llama.cpp build.

---

Comparison with other small models

The following comparison deliberately separates upstream published benchmark results from ZynDwarf's own local regression tests. These numbers were not generated using the same hardware or necessarily the same evaluation software, so they should not be treated as a single leaderboard.

IFEval

Liquid AI reports the following published IFEval result for LFM2.5-350M: 76.96. Its model card also reports BFCLv3 44.11 and BFCLv4 21.86. The same table includes Granite 4.0-H-350M and other compact models. urlLiquidAI LFM2.5-350M model cardhttps://huggingface.co/LiquidAI/LFM2.5-350M

SmolLM2's official model card reports 41.0 for SmolLM2-360M-Instruct on IFEval and 31.6 for Qwen2.5-0.5B-Instruct under its evaluation setup. urlSmolLM2-360M official model cardhttps://huggingface.co/HuggingFaceTB/SmolLM2-360M-Instruct

Published IFEval snapshot

Model	Parameters	IFEval	Source
LFM2.5-350M	~0.35B	76.96	Liquid AI
Granite 4.0-H-350M	~0.35B	61.27	Liquid AI comparison table
SmolLM2-360M-Instruct	~0.36B	41.0	Hugging Face / lighteval
Qwen2.5-0.5B-Instruct	~0.5B	31.6	Hugging Face / lighteval

ZynDwarf-1.1 is intentionally not assigned an IFEval score here. The local 16-prompt suite is not IFEval, so inserting 50 beside these numbers would create a false comparison.

---

Broader upstream comparison

Liquid AI's current LFM2.5-350M model card reports the following results under its published benchmark setup:

Model	GPQA Diamond	MMLU-Pro	IFEval	BFCLv3	BFCLv4
LFM2.5-350M	30.64	20.01	76.96	44.11	21.86
LFM2-350M	27.58	19.29	64.96	22.95	12.29
Granite 4.0-H-350M	22.32	13.14	61.27	43.07	13.28
Granite 4.0-350M	25.91	12.84	53.48	39.58	13.73
Gemma 3 1B IT	23.89	14.04	63.49	16.61	7.17

These are upstream numbers from Liquid AI's published comparison table, not independent Zyn Models measurements. urlLiquid AI benchmark tablehttps://huggingface.co/LiquidAI/LFM2.5-350M

SmolLM2's published evaluation is also useful for understanding this size class. Its official card reports 32.8 MMLU (cloze), 43.7 ARC Average, 70.8 PIQA, 7.43 GSM8K 5-shot and 3.66 MT-Bench for SmolLM2-360M-Instruct. urlSmolLM2-360M-Instruct evaluationhttps://huggingface.co/HuggingFaceTB/SmolLM2-360M-Instruct

---

Why the comparison matters

ZynDwarf-1.1 is built on LFM2.5-350M rather than attempting to compete with much larger systems through parameter count. Its practical goal is different:

• small enough for local CPU inference;
• usable from GGUF runtimes;
• usable from Ollama;
• compatible with Transformers;
• capable of Spanish and English interaction;
• oriented toward programming and practical tasks;
• structured around agent/tool-call workflows;
• deployable on constrained hardware.

The upstream LFM2.5-350M results show that the base family is unusually strong for its size on instruction following and function-calling-oriented evaluations. ZynDwarf-1.1 should therefore be evaluated primarily on whether its fine-tuning preserves useful base capabilities while improving the desired local assistant behavior.

---

Training details

The release was produced from a repaired LFM2.5-350M starting point and a general agent dataset.

Dataset

• 1,613 deduplicated sequences in the intended dataset.
• 1,503 sequences successfully encoded under the 768-token training cap.
• 308 examples included real tool-oriented traces.
• 62 examples were multi-turn.
• Examples covered programming, debugging, general conversation, planning, tool use, tool failures, Spanish, English, and no-tool behavior.

LoRA configuration

rank       = 8
alpha      = 16
dropout    = 0.05
targets    = q_proj, k_proj, v_proj
lr         = 1.5e-6
epochs     = 1
grad_accum = 4
max_length = 768

The final adapter used approximately 0.069% of the model parameters as trainable parameters during fine-tuning.

What was deliberately avoided

• No attempt was made to memorize the public benchmark prompts.
• No claim of true logit-level knowledge distillation is made for this release.
• No claim is made that the 128K architectural context was trained end-to-end at 128K.
• No claim is made that the model can autonomously execute tools without a host runtime.

---

Installation: Transformers

from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "itsZyn/ZynDwarf-1.1"

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(model_id)

messages = [
    {"role": "user", "content": "Hola, ¿qué puedes hacer?"}
]

inputs = tokenizer.apply_chat_template(
    messages,
    add_generation_prompt=True,
    return_tensors="pt",
)

outputs = model.generate(
    inputs,
    max_new_tokens=128,
)

print(tokenizer.decode(outputs[0], skip_special_tokens=False))

For agent use, provide the tool schemas through the tools= argument of the tokenizer's chat template and inspect the assistant message for tool_calls / the rendered native tool-call sequence.

---

Installation: GGUF / llama.cpp

F16

./llama-cli \
  -m ZynDwarf-1.1-f16.gguf \
  -c 32768 \
  -t 2 \
  --temp 0.35 \
  --top-k 40 \
  --top-p 0.9 \
  --repeat-penalty 1.05

Q4_K_M

./llama-cli \
  -m ZynDwarf-1.1-Q4_K_M.gguf \
  -c 32768 \
  -t 2 \
  --temp 0.35 \
  --top-k 40 \
  --top-p 0.9 \
  --repeat-penalty 1.05

The 32K runtime example is a practical configuration, not a claim that 32K or 128K contexts will have identical quality to short-context inference.

---

Installation: Ollama

The published Ollama package is:

ollama pull itsZyn/ZynDwarf-1.1:latest

Run it with:

ollama run itsZyn/ZynDwarf-1.1:latest

The model can also be used as the local inference backend for agent frameworks that integrate with Ollama's chat/tool APIs.

---

GGUF files

File	Quantization	Approx. size	Intended use
ZynDwarf-1.1-f16.gguf	F16	676 MiB	quality / reference local build
ZynDwarf-1.1-Q4_K_M.gguf	Q4_K_M	216 MiB	memory-constrained local deployment

Both files are distributed directly in this repository so the Hugging Face model page can expose the F16 and Q4 variants together.

---

Checksums

ZynDwarf-1.1-f16.gguf
ce452090b010d1e199fd7b39b2d65e5fcd8d7c2ceac52c38219f8b53e491c424

ZynDwarf-1.1-Q4_K_M.gguf
04a6ea0100b84a8687162db856f4c0b8042f54ad6b50a93b3c8132afc3499ae2

Always verify downloaded model files when distributing them through mirrors.

---

Intended use

ZynDwarf-1.1 is intended for:

• local personal assistants;
• programming help;
• code generation and debugging;
• Spanish/English conversation;
• lightweight planning;
• structured text generation;
• local agent prototypes;
• tool-calling experiments;
• CPU-oriented deployments;
• Ollama and llama.cpp workflows.

Not intended for

• medical, legal, financial, or other high-stakes decisions;
• unrestricted autonomous execution;
• factual research without verification;
• large-scale coding projects without human review;
• claiming guaranteed correctness;
• treating model output as trusted code or trusted tool arguments.

---

Known limitations

1. Small model capacity. At ~354.5M parameters, ZynDwarf-1.1 cannot match larger models on broad knowledge, difficult reasoning, or long complex projects.
2. Tool calling needs host validation. The model can produce tool-call structures, but the host must validate and execute them.
3. Current explicit tool-call regression is weak. The release regression suite scored 0/2 on direct standalone tool-call prompts. Integrators should test the complete chat-template + runtime pipeline.
4. Structured output is imperfect. The 16-prompt suite found failures on the strict JSON case.
5. Arithmetic/reasoning can fail. The small regression suite exposed an incorrect arithmetic explanation and an incorrect transitive-set conclusion.
6. Context length is not quality length. 128K is the architectural limit; the fine-tuning sequence cap was 768 tokens.
7. Quantization changes behavior. Q4_K_M is smaller and faster, but F16 is the reference GGUF for fidelity.
8. Knowledge can be stale or wrong. Use retrieval or external tools when correctness matters.

---

Evaluation philosophy

Zyn Models publishes failures as well as successes because a benchmark section that contains only flattering numbers is closer to advertising than evaluation.

For this release, three kinds of evidence are kept separate:

A. Local regression tests

These are executed by Zyn Models on the actual release artifact and are useful for tracking regressions between versions.

B. Local performance tests

These measure llama.cpp throughput on the release server. They are useful for deployment planning, not for claiming universal CPU speed.

C. Upstream standardized evaluations

These are reproduced from the original model authors' published model cards. They provide external context but are not relabeled as ZynDwarf measurements.

This separation prevents the common mistake of mixing unrelated evaluation protocols into one decorative leaderboard.

---

Reproducibility

The release artifacts, benchmark outputs, benchmark scripts, and SVG charts are kept together in the release workspace. The local benchmark command used llama.cpp with two CPU threads and a 128-token prompt/generation configuration for throughput testing.

For future ZynDwarf releases, the recommended evaluation process is:

1. run the same regression suite;
2. run the same llama-bench configuration;
3. add independent standardized benchmarks;
4. compare F16 and Q4 separately;
5. publish failures and category-level scores;
6. never reuse private evaluation prompts as training examples.

---

Credits

ZynDwarf-1.1 builds on the work of Liquid AI and the LFM2/LFM2.5 model family.

Model adaptation, evaluation, packaging and release engineering: Zyn Models / itsZyn.

Base model: LiquidAI/LFM2.5-350M.

Upstream references:

• https://huggingface.co/LiquidAI/LFM2.5-350M
• https://huggingface.co/HuggingFaceTB/SmolLM2-360M-Instruct

---

Citation

If you use ZynDwarf-1.1 in a project, cite the model repository and the upstream base model.

@misc{zyndwarf11,
  title  = {ZynDwarf-1.1},
  author = {Zyn Models and itsZyn},
  year   = {2026},
  note   = {Compact LFM2.5-350M based conversational and agent-oriented model}
}

---

Release status

Version: 1.1
Release type: general agent-oriented local model
Primary formats: Transformers/Safetensors, GGUF F16, GGUF Q4_K_M
Status: public release with documented regression limitations