January 7, 2026 · Alexander Vukovic

rzfz.ai — local matters

A technical deep dive: unified memory, reasoning models, and ten use cases for development and testing

1. Introduction: The renaissance of local intelligence

We live in an era of digital paradoxes. On the one hand, generative artificial intelligence (GenAI) is bringing a technological leap whose scope is comparable to the invention of the internet. Models are getting bigger, faster and more capable. On the other hand, the regulatory net is tightening. The EU AI Act is no longer a distant bureaucratic specter but binding reality, forcing companies to fundamentally rethink their AI strategies. In the current issue of the SEQIS Quality News 2025-2, titled “AI Act & Local AI – Paths to a Responsible Future,” this tension is clearly sketched out. It is no longer only about what is technically feasible, but about what is legally permitted, ethically defensible and economically sound.

As someone who has accompanied software quality assurance since the early days of the agile movement – from the first tentative steps with test automation through to complex continuous-integration pipelines – I see parallels. Back then it was about breaking up silos between development and operations (DevOps). Today we have to break up the silo between “powerful AI in the cloud” and “secure data on-premise.” The answer to that is not to blindly push data into the cloud and hope for encryption. The answer is: the intelligence has to come to the data.

With rzfz.ai, we at SEQIS have created a platform that embodies exactly this philosophy: “Enabling local AI.” It is a manifesto for digital sovereignty. Why is this so critical right now? Because the technology is finally ready. We no longer have to choose between “dumb and local” or “smart and cloud.” Through the symbiosis of specialized hardware (unified memory architecture) and highly efficient open-source models such as Magistral and Devstral by Mistral AI, we can run enterprise-grade intelligence locally. rzfz.ai is therefore not an “AI” of its own but a local hardware + software platform for running arbitrary open-source AI models.

This article is a technical deep dive, a survey of the possibilities. We will analyze why local hardware is suddenly “sexy” again, how reasoning models revolutionize test analysis, and we will walk through ten concrete, implementable use cases that show how development and testing should work in the year 2026.

2. The technological substructure: hardware and architecture

To understand why local AI today represents a viable alternative to cloud offerings like OpenAI or Anthropic, we have to look under the hood. The traditional PC architecture was thoroughly unsuited to AI workloads. The bottleneck was always the data transfer between the CPU (central processing unit) and the GPU (graphics processing unit) over the PCIe bus.

2.1 Unified memory: the game changer

The rzfz.ai Box relies on an architecture that eliminates this bottleneck: unified memory. In this configuration, CPU and GPU share the same physical memory pool. This has massive implications for the inference of large language models (LLMs):

1. No copy overhead: In conventional systems, the weights of the neural network (the model weights) have to be loaded into the graphics card’s VRAM. If the model is too large for the VRAM (e.g. 24 GB on a consumer RTX 4090), “offloading” has to be done – parts of the model are swapped out to the slow system RAM, which causes performance to collapse dramatically. With unified memory, the GPU accesses the entire memory directly.
2. Capacity for large models: The rzfz.ai Box offers up to 128 GB of unified memory, of which a net 96 GB is usable exclusively for AI models. This makes it possible to run models that far exceed the capacities of classic desktop GPUs. Here we can load quantized versions of models with 70 billion parameters or more, without having to accept performance losses.
3. Energy efficiency: An often underestimated factor, especially with regard to ESG goals (environmental, social, and governance). A high-end server GPU can consume 400 to 700 watts under load. A cluster of them needs its own air conditioning. The rzfz.ai hardware operates in a range of 30 to 300 watts. This is not only good for the electricity bill but also enables use in normal office environments without a dedicated server room.

In the following table, we compare the architectural approaches to illustrate the positioning of the local solution:

Feature	Classic workstation + GPU	Cloud API (e.g. GPT-5)	rzfz.ai Box (local unified memory)
Memory architecture	Separate (RAM + VRAM)	Opaque / distributed	Unified (shared RAM)
Max. model size	Limited by VRAM (e.g. 24 GB)	Very large (black box)	Up to 96 GB (usable)
Latency	Low (local)	High (network-dependent)	Very low (local)
Data protection	High (local)	Risk (third party)	Maximum (local + air-gapped possible)
Energy consumption	High (800W+)	Unknown (external)	Efficient (30–300W)
Type of investment	CAPEX (hardware)	OPEX (pay-per-token)	CAPEX (one-time)

2.2 The software stack: orchestrating the intelligence

Hardware is only as good as the software that drives it. The rzfz.ai Stack is based on a robust Linux substructure (Ubuntu 26.04 LTS) and integrates a suite of open-source tools that work together seamlessly.

• llama.cpp: This is the engine. The project has massively advanced the democratization of LLMs. It enables the highly efficient execution of GGUF-quantized models on Apple Silicon and other unified-memory architectures. Through quantization (e.g. to 4-bit or 8-bit integers), the memory footprint is massively reduced, with negligible loss of quality.
• Workflow automations: The nervous system. While many AI interactions still run through chat windows, the real power lies in automation. By means of various open-source workflow-automation tools, AI models are embedded into complex processes. You can think of it as the “glue” that connects the AI to Jira, Git, databases or email servers – and all of that locally.
• Vector database (PostgreSQL + pgVector): The long-term memory. To implement RAG (retrieval augmented generation) locally, we need a store for semantic embeddings. PostgreSQL runs efficiently on the Box and enables the AI to retrieve the “knowledge” of internal company documents without the model having to be retrained.
• Open WebUI: The interface to the human. A user-friendly surface that feels like ChatGPT but runs entirely locally and offers multi-user support as well as model management.

3. The models: Magistral and Devstral

The hardware provides the arena, but the models are the athletes. In this article we focus on two specific European models by Mistral AI that are particularly relevant for development and testing: Magistral and Devstral. Both represent the latest state of open-weights research and are optimized for local operation.

3.1 Magistral: the analyst with depth (reasoning model)

“Magistral” marks a paradigm shift at Mistral AI. It is the company’s first dedicated reasoning model. Unlike classic LLMs, which are primarily trained to generate statistically probable sequences of words, Magistral was optimized to solve problems through a “chain of thought” (CoT).

What does “reasoning” mean technically? When you ask Magistral a complex question, it does not answer immediately. It first generates an internal monologue (often visible in <think> tags), in which it breaks down the problem, forms hypotheses, tests them, and only then formulates the final result. This process resembles Daniel Kahneman’s “System 2” thinking – slow, logical, calculating.

Performance data and architecture:

• Size: Magistral Small is a 24B (24B = 24 billion) parameter model. That is the “sweet spot” for local inference on our hardware. It is small enough to be fast, but large enough for complex logic.
• Context: It supports a context window of 128k tokens. That means it can hold hundreds of pages of documentation or extensive code files in memory and factor them into its considerations.
• Benchmarks: On the AIME2024 benchmark (mathematics and logic), the Medium variant achieves scores of over 73%, which represents a massive improvement over non-reasoning models.
• Field of application: Software architecture, requirements engineering, logical review of test cases, complex data analysis.

An interesting feature is the speed on simple tasks: through “Flash Answers,” the model can respond extremely quickly to less complex queries, but scales up its compute time as needed for deeper analyses.

3.2 Devstral: the agentic developer (coding model)

While Magistral is the thinker, Devstral is the doer. It was specifically trained and refined for software engineering tasks. It is not simply an autocompletion; it is designed for “agentic workflows.”

The difference from classic code models: earlier models like CodeLlama were good at completing a function. Devstral, by contrast, understands the context of an entire project. It was developed in collaboration with All Hands AI and trained to act like a developer: it can read files, plan changes, edit code and execute shell commands (in a secured sandbox).

Specifications:

• Specialization: It is based on Mistral Small 3.1, with the vision encoder removed in order to focus purely on text and code.
• Performance: On SWE-Bench Verified, the gold standard for automated software engineering, Devstral achieves a score of 46.8%. For comparison: GPT-4o mini is at about 23.6%. That means Devstral autonomously and correctly solves almost half of all real GitHub issues – a value that is sensational for a model of this size (24B).
• Tokenizer: It uses the Tekken tokenizer with a vocabulary of 131k, which is particularly efficient for source code (fewer tokens per line of code = more context in memory).

Together, Magistral and Devstral form an unbeatable team: the one plans and reviews (Magistral), the other executes and implements (Devstral).

4. Ten use cases for development and testing

Theory is good, practice is better. How do we put this power on the road? In what follows, I sketch ten detailed use cases that we use at SEQIS and that can be implemented with the rzfz.ai Box. Each use case leverages the specific strengths of Magistral (reasoning) or Devstral (coding) and the orchestration through workflow automation.

Use case 1: The requirements architect (model: Magistral)

Challenge: Requirements in software development are often imprecise. Requirement specifications consist of prose text, emails and meeting notes. Translating them into formal models (such as UML) is a manual, error-prone process. Misunderstandings here lead to the most expensive errors later in the project.

The solution with local AI: We use Magistral to translate unstructured requirements into formal diagrams.

1. Input: The user uploads a PDF requirement specification or copies text into Open WebUI.
2. Reasoning process: An automated workflow hands the text to Magistral with the system prompt: “Analyze this text for actors, use cases and process logic. Identify logical gaps (e.g. missing error handling).”
3. Generation: Magistral generates valid code for PlantUML or Mermaid (e.g. for an activity diagram). Thanks to its reasoning capability, it can make implicit assumptions explicit (e.g. “If the user is not logged in, they have to be directed to the login,” even if that is missing from the text).
4. Visualization: By means of workflow automation, the PlantUML code is rendered directly into a graphic, which is returned together with a list of the identified gaps.

Value: Standardization of the documentation and quality assurance of the requirements before a line of code is written (“shift left”). Since requirements often contain sensitive business strategies, local operation is essential.

Use case 2: The relentless test designer (model: Magistral)

Challenge: Test-case creation is often monotonous work. Testers tend to test the “happy path” and overlook edge cases. Combinatorial explosions (e.g. with complex forms) often overwhelm human testers.

The solution with local AI: The test designer leverages Magistral’s logical depth.

1. Input: A user story or the results from use case 1.
2. Analysis: Magistral applies formal test methods, such as equivalence partitioning and boundary value analysis. It “thinks up” scenarios that could break the system (destructive testing).
3. Workflow:
   • Magistral identifies all input fields.
   • It generates test data for boundary values (e.g. age 17, 18, 120, -1).
   • It creates a test matrix.
4. Via workflow automation, these test cases are converted directly into the format of Jira Xray or Tricentis Tosca and imported into the test-management tool via API.

Value: Massive time savings and higher test coverage through systematic, AI-supported analysis. The data never leaves the local network.

Use case 3: Legacy code refactoring & modernization (model: Devstral)

Challenge: Many companies sit on “legacy code” – functioning but outdated software (e.g. Java 6, old PHP code) that no one wants to touch anymore. The knowledge about it has often retired along with employees.

The solution with local AI: Devstral uses its huge context window (128k) to understand entire files or modules.

1. Context: We load the source code of an old component into Devstral’s context.
2. Agentic task: The prompt reads: “Analyze this code. Explain the business logic. Propose a refactoring to modern standards (e.g. Java 21 records, streams). Preserve the logic.”
3. Iterative process: Devstral rewrites the code. Since it acts agentically, it can also write unit tests for the old code to make sure that the new code does the same thing (regression testing).
4. Output: A diff file or a direct commit proposal in the local GitLab.

Value: Risk minimization during modernization. Since legacy code often contains deep company know-how, it must under no circumstances be loaded into public cloud LLMs.

Use case 4: Synthetic test data generation (GDPR-compliant) (model: Magistral)

Challenge: Tests require realistic data. Anonymizing production data is laborious and carries re-identification risks. Simple random generators often produce domain nonsense (e.g. the postal code does not match the town).

The solution with rzfz.ai: Magistral generates semantically correct, synthetic data.

1. Modeling: We define the data schema (e.g. a JSON structure for a “policyholder”).
2. Logic injection: We give Magistral rules: “Generate 50 records for customers from Austria. If federal state = Vienna, then the postal code has to start with 1. The date of birth has to match the status ‘pensioner.’”
3. Reasoning: Magistral uses its logic capabilities to keep to these dependencies (something at which simpler models often fail).
4. Persistence: The workflow automation writes the generated data directly into the Box’s local PostgreSQL database, from where it can be injected into test environments.

Value: 100% GDPR compliance, since no real data is touched, while at the same time delivering high domain quality of the test data.

Use case 5: The autonomous bug hunter (model: Devstral)

Challenge: Finding bugs that only occur under certain conditions (e.g. race conditions) is extremely difficult. Static code analysis finds syntax errors, but no logical problems in the flow.

The solution with rzfz.ai: A local agent that monitors Git commits.

1. Trigger: A developer pushes code. The workflow automation detects the change.
2. Analysis: Devstral reads the changes (diff) and the affected files in full text.
3. Reasoning: Devstral looks for logical errors: “In line 50, user is accessed, but user could be null if the database query in line 40 fails. A null check is missing.”
4. Report: The agent posts this hint as a comment directly on the merge request in the local Git server.

Value: A “pair programmer” that never sleeps and reviews every commit. The error detection happens before the code is merged into the master branch.

Use case 6: Self-healing unit tests (model: Devstral)

Challenge: Code changes, tests break. Maintaining unit tests is often more expensive than developing the features themselves.

The solution with rzfz.ai: Devstral’s capabilities in the area of “agentic coding.”

1. Scenario: A build fails because a unit test is red.
2. Diagnosis: The workflow automation catches the error from the CI/CD pipeline (e.g. Jenkins) and sends the stack trace as well as the changed code to Devstral.
3. Fix: Devstral analyzes why the test fails. Was it an intentional change of logic? Then the test has to be adjusted. Was it a bug? Then the code has to be fixed.
4. Action: Devstral proposes the corrected code. In an advanced stage, the agent can execute the fix locally, run the tests again, and on success commit the fix.

Value: A drastic reduction in maintenance effort for test suites and more stable builds.

Use case 7: Intelligent log analysis and root cause analysis (model: Magistral)

Challenge: When something goes wrong in production or the test system, ops teams often have to wade through gigabytes of log files. Correlating errors across various microservices is hard for humans.

The solution with rzfz.ai: Magistral as a forensic analyst.

1. Ingest: Relevant log excerpts (e.g. the 5 minutes around a crash) are transmitted to the rzfz.ai Box.
2. Analysis: Magistral correlates timestamps and error messages. It recognizes patterns: “The timeout in the payment service (14:00:01) caused the NullPointerException in the order service (14:00:02).”
3. Explanation: The model generates a summary in natural language for the ops team: “The cause is probably an overload of database X. Recommended measure: check the connection pool.”

Value: A significant reduction in MTTR (mean time to repair). The knowledge from the logs never leaves the secured network in the process.

Use case 8: Automated documentation maintenance (model: Devstral)

Challenge: Code documentation is almost always outdated. Nobody enjoys updating the wiki or the Swagger definitions after a code change.

The solution with rzfz.ai: A documentation agent that monitors the code base.

1. Scan: Devstral iterates regularly over the repository.
2. Comparison: It compares the code with the existing documentation (e.g. Markdown files or docstrings).
3. Update: On deviations, Devstral generates updated descriptions of the classes, methods and API endpoints. It can even update diagrams (see use case 1).
4. Commit: The updated documentation is submitted as a pull request.

Value: The documentation is always “live” and in sync with the code. Onboarding new developers is massively accelerated.

Use case 9: The agile ticket assistant

Challenge: In dailies, a lot is discussed but little is documented. “Would you quickly create the ticket for the bug in the login?” – and then it is forgotten or only rudimentarily (“login doesn’t work”) created.

The solution with rzfz.ai: The agile ticket assistant, integrated into the communication flow.

1. Input: A developer speaks a short note into the mobile app of Open WebUI or writes a quick sentence into the chat: “Hey Jira, bug in the checkout process. When you order as a guest and choose PayPal, a 500 error comes up.”
2. Processing: The Box uses speech-to-text (if audio) and then Magistral for structuring.
3. Enrichment: Magistral asks for missing information or adds context (e.g. browser version, priority). It formulates a professional error description with “steps to reproduce.”
4. Action: Via workflow automation, the ticket is created through the Jira API and assigned to the right team.

Value: Lowering the barrier to clean documentation. Better ticket quality leads to faster processing.

Use case 10: Local RAG knowledge bot for testers (Magistral + PostgreSQL + pgVector)

Challenge: Testers often need to know: “How does the cancellation logic work for tariff X again?” The answer is somewhere in 500 PDFs on SharePoint.

The solution with rzfz.ai: A local RAG system (retrieval augmented generation).

1. Indexing: All specialist concepts, wikis and old test plans are read in by the Box, converted into vectors and stored in the local PostgreSQL database.
2. Query: The tester asks in the chat: “How does the system behave on cancellation after 14 days?”
3. Retrieval & generation: The workflow automation searches for the relevant text passages in PostgreSQL. Magistral receives these as context and formulates a precise answer, including a source reference (“According to specialist concept V2.3, page 45…”).

Value: The entire company knowledge is available immediately and in dialogue. Since no document leaves the building (unlike with ChatGPT uploads), the IP (intellectual property) remains protected.

5. Implementation: the workflow automation architecture

How do we technically assemble these use cases? The heart of orchestration on the rzfz.ai Box is workflow automation with various tools. Unlike cloud services such as Zapier or n8n, here it runs locally in a Docker container, directly next to the AI model.

A typical workflow (e.g. for the bug hunter, use case 5) follows a clear pattern, which we can call the “agentic pattern”:

1. Trigger node: Listens for events (webhook from GitLab, file change, schedule).
2. Data fetching: Retrieves the necessary data (code, logs, text).
3. AI agent node / chain: This is where the magic happens. We use the “Basic LLM Chain” node or specialized agent nodes. This node communicates via http://localhost:9090 with the llama.cpp server. Here we configure parameters like temperature (low for code/logic, higher for creative texts) and the system prompt.
4. Tool use: The agent can decide to call tools. In the workflow automation we can provide the agent with “tools,” e.g. “Calculator,” “Database Query” or “Git Commit.” Devstral is particularly good at recognizing when to use which tool.
5. Output parser: The AI’s response (often JSON) is parsed and validated.
6. Action node: The result is processed (create Jira ticket, send email, save file).

Visual metaphor for the report: Imagine the workflow automation as a digital production line. The raw materials (data) come in, robot arms (nodes) process them. But at one station there is no longer a rigid robot but an intelligent craftsperson (the AI model) who makes decisions, performs quality checks and can improvise when the workpiece deviates slightly from the norm. That is the difference between classic automation and AI agents.

6. Strategic classification: cloud vs. local in a cost comparison

A frequent counterargument against local AI is the acquisition costs (CAPEX). “But the cloud is cheaper, I only pay for what I use.” That is a fallacy, especially with “reasoning” models and agentic workflows.

1. Token economy: Reasoning models like Magistral or OpenAI o1 generate massive amounts of “internal thinking tokens.” In the cloud, you pay for each of these thoughts. A single complex refactoring task can consume thousands of input and tens of thousands of output tokens. With daily use by a development team, these OPEX (operational expenditures) add up enormously.
2. Flat-rate effect: The rzfz.ai Box is a one-time investment. Whether you ask the model 10 times or 10,000 times a day costs the same (apart from electricity). That encourages experimentation. Developers do not hesitate to use the AI because “the budget is tight.”
3. Latency: For agents that execute many small steps one after another (loops), the network latency of the cloud adds up. Locally, the call happens in the millisecond range over localhost.

Cost factor	Cloud AI (e.g. GPT-4 API)	Local AI (rzfz.ai Box)
Reasoning (thinking time)	Expensive (billed per token)	Free (included)
Code scan (large context)	Very expensive (large input context)	Free
Recurring tasks	Linearly rising costs	Fixed costs (amortization)
Data transfer	Costs + security risk	No transfer, no costs

7. Conclusion: local matters.

The title of this article is a program. “Local matters” is not just a technological statement, it is a stance. The EU AI Act has defined risk classes and demands transparency and governance. Many companies see this as a burden. We at SEQIS see it as an opportunity.

Solutions like the rzfz.ai Box prove that compliance does not have to be an innovation blocker. On the contrary: by running the AI locally, we win back freedoms that we had long since given up in the cloud.

• We can use Magistral to analyze our most secret business strategies.
• We can unleash Devstral on our most valuable asset – our source code.
• We can build systems that are deeply integrated into our IT landscape without punching holes in firewalls.

The future of AI is hybrid, but the heart of it – the processing of sensitive data and intellectual property – has to lie locally. Unified memory hardware, open-source models and intelligent orchestration by means of workflow automation make this possible today.

I invite you: do not wait for the cloud to become secure. Bring the security into the house. Experiment. Build your first local agent. Let us shape the future of software quality together – efficiently, sovereignly and locally.

Yours, Alexander Vukovic, SEQIS Founder & Chief Evangelist

Sources and further information

• SEQIS – Your local AI consultancy, accessed on 18 November 2025, seqis.ai
• rzfz.ai – Local. Open Source. Independent. Secure., accessed on 18 November 2025, rzfz.ai
• Magistral – Mistral AI, accessed on 18 November 2025, mistral.ai/news/magistral
• Devstral – Mistral AI, accessed on 18 November 2025, mistral.ai/news/devstral
• Tutorial: Offline Agentic coding with llama-server · ggml-org llama.cpp · Discussion #14758, accessed on 18 November 2025, github.com/ggml-org/llama.cpp/discussions/14758
• mistralai/Magistral-Small-2509 – Hugging Face, accessed on 18 November 2025, huggingface.co/mistralai/Magistral-Small-2509
• mistralai/Devstral-Small-2507 – Hugging Face, accessed on 18 November 2025, huggingface.co/mistralai/Devstral-Small-2507
• What Is a Reasoning Model? – IBM, accessed on 18 November 2025, ibm.com/think/topics/reasoning-model

---

First published on the SEQIS Blog.

Originally published at SEQIS Blog