Practical Open-Source AI Engineering, Tested One Clean Run at a Time
Make it run. Make it useful.
Open-source AI is becoming easier to access, but turning a model into something useful is still an engineering problem. Choosing the right model, getting it to run on available hardware, managing memory, connecting an API, handling unexpected outputs, and keeping the whole system maintainable are challenges that documentation alone does not always resolve.
Run It Clean exists to make those decisions easier.
I'm Jonah Vance, an independent AI developer and technical writer based in Seattle, Washington. I focus on the practical side of open-source AI engineering, with Qwen as the starting point: how to choose a model, deploy it, evaluate its behavior, and build applications around it without adding unnecessary complexity.
This site is built around a straightforward idea: start with what works, test what matters, and be honest about the trade-offs.
You do not need the largest model, the most expensive GPU, or the most complicated architecture to solve every problem. You need a setup that fits your actual requirements—and a clear understanding of what it can and cannot do.
That is what Run It Clean is here to help you find.
Meet Jonah Vance
An Independent Developer Who Cares About What Actually Works
My interests sit at the intersection of software development, open-source AI, and practical infrastructure.
My technical foundation includes Python, APIs, backend services, databases, Docker, and application deployment. As I became more interested in open-source AI, I found myself spending more time on the engineering questions that appear when language models move beyond demonstrations and into real applications.
A model may look impressive in a benchmark and still be a poor fit for a particular machine. A deployment guide may describe the right general approach but leave out a dependency conflict or an important configuration detail. An application may return convincing text while producing malformed JSON, failing on edge cases, or consuming more resources than the task justifies.
These are the problems I want to understand and explain.
My approach is to break a complicated setup into smaller, verifiable steps. First, identify the actual requirement. Then examine the available tools, hardware, software dependencies, and constraints. Test the essential parts, pay attention to failure modes, and only add complexity when there is a clear reason to do so.
I am particularly interested in the practical questions that developers face when working with Qwen and related open-source tools:
Which model size makes sense for a specific task?
How much memory does a deployment realistically require?
When does quantization offer a useful compromise?
Is local inference worth the setup and maintenance effort?
How should an application handle structured outputs and tool calls?
When is a local model sufficient, and when is a hosted API the better option?
I do not believe every technical question needs an elaborate answer. Sometimes the best solution is a smaller model, a simpler deployment, or a decision not to deploy locally at all.
The goal is not to make AI engineering look impressive. It is to make it more understandable, predictable, and useful.
Why I Started Run It Clean
Because Getting a Model to Run Is Only the First Step
Open-source AI gives developers more control over their tools and infrastructure. Depending on the model, deployment method, and application, it can also offer opportunities to manage costs, keep data within a chosen environment, and customize systems around specific workflows.
But greater control comes with additional decisions.
You may need to compare model variants, understand quantization, resolve package incompatibilities, configure an inference server, estimate hardware requirements, and determine whether the resulting application is reliable enough for its intended purpose.
The difficult part is often not finding another model. It is deciding what to do with the options already available.
Run It Clean was designed to address that gap between finding a model and building something useful with it.
Instead of treating every release as a reason to upgrade, I want to focus on the questions that remain important after the announcement:
Can you run it with the resources you already have?
Does it solve the task you actually care about?
What needs to change in your existing application?
What are the ongoing costs of running and maintaining it?
What happens when the model produces an unexpected result?
Would another tool or deployment approach be simpler?
These questions guide the site's tutorials, technical explanations, evaluations, and field notes.
A successful setup is not simply one that starts without an error. It is one that performs a useful job within reasonable limits.
What Run It Clean Covers
The site begins with Qwen and focuses on the engineering work surrounding open-source language models. The content is organized around five practical areas.
1. Qwen Starting Point
Understand the options before choosing a model.
Not everyone arrives with experience in local inference or open-source model infrastructure. This section provides a practical introduction to the Qwen model family, model sizes, context windows, memory requirements, and common deployment options.
You will find explanations designed to help you make an informed first decision, including comparisons between Qwen and hosted AI APIs.
The aim is to replace guesswork with a basic understanding of what each option requires.
2. Local Model Lab
Get the model running—and understand why it works.
This section covers local installation, inference tools, quantization, hardware planning, and troubleshooting.
Topics include running Qwen with Ollama, working with llama.cpp or vLLM, estimating VRAM requirements, exploring CPU inference, and understanding the compromises involved in running models on different machines.
Instructions should be useful beyond the happy path. Where relevant, articles will explain dependencies, configuration choices, common errors, recovery steps, and the conditions under which a particular approach may not work.
3. Build with Qwen
Move from a working model to a useful application.
A model running in a terminal is a starting point, not necessarily a finished product.
This section explores how to connect Qwen to Python applications, use local APIs, validate structured JSON, build retrieval-augmented generation (RAG) systems, and experiment with tool calling and agent workflows.
The emphasis is on engineering fundamentals: input validation, error handling, predictable interfaces, testing, and maintainable application design.
The guiding question is simple: what is the smallest implementation that reliably solves the problem?
4. Benchmarks and Trade-offs
Look beyond a single performance number.
Comparing models requires more than putting two headline figures side by side.
This section examines the factors that influence practical decisions, including inference speed, memory use, output quality, context handling, cost, reliability, and operational complexity.
Where comparative testing is presented, the relevant model versions, hardware, quantization settings, evaluation methods, and limitations should be made clear. Vendor-reported figures and independent measurements will be distinguished rather than treated as interchangeable evidence.
The purpose is not to declare one model universally superior. It is to explain which option makes sense under particular conditions.
5. Field Notes
Learn from the parts that do not go according to plan.
Technical work rarely follows documentation perfectly. Dependencies change, configurations behave differently across machines, and a promising experiment sometimes leads to a dead end.
Field Notes explores these realities, from troubleshooting a deployment to reconsidering a hardware purchase or deciding that a cloud GPU is more practical than a home server.
These articles focus on the reasoning behind technical decisions, what can be learned from a failure, and what should be checked before trying the same approach.
Not every experiment needs to produce a success story to be useful.
How I Approach Technical Content
Start with the Smallest Useful Version
I prefer to begin with the simplest setup that can answer the question.
If a small model is sufficient, there is little reason to start with a larger one. If a basic local endpoint meets the requirement, a complex agent framework can wait. If an existing machine can handle the workload, upgrading hardware should not be the default recommendation.
This approach keeps experiments easier to understand and makes it simpler to identify which component is responsible when something goes wrong.
Show the Conditions Behind the Answer
Technical instructions are only useful when readers understand the conditions under which they apply.
Where relevant, articles should identify the software versions, model variants, configuration parameters, hardware assumptions, commands, and other details needed to reproduce a result.
If a conclusion depends on a particular environment, that limitation belongs in the explanation.
A command that works under one configuration should not automatically be presented as a universal solution.
Treat Failures as Useful Evidence
I do not consider a failed setup a reason to hide the experiment.
A dependency conflict, an out-of-memory error, an unexpected output format, or an unreliable tool call can reveal important information about a system's limitations.
When an article discusses a failure, the goal is to explain what happened, what evidence is available, what was changed, and whether the underlying issue was actually resolved.
Where the cause remains uncertain, that uncertainty should be stated rather than replaced with a convenient explanation.
Evaluate the Whole Workflow
A model's output speed is only one part of its usefulness.
For an actual application, it also matters whether the output is correct enough for the task, whether structured responses can be validated, how often requests fail, how much memory is consumed, and how much effort is required to keep the system running.
Depending on the use case, privacy, latency, infrastructure cost, and maintenance may matter as much as raw performance.
The right evaluation starts with the job the system needs to perform.
What You Can Expect from Run It Clean
I want every article to help you make progress on a real technical decision.
Depending on the topic, that may mean providing:
Step-by-step implementation instructions and relevant commands.
Model and hardware selection guidance based on practical constraints.
Configuration examples with explanations of important parameters.
Troubleshooting guidance for common deployment problems.
Testing methods that help you evaluate a result independently.
Comparisons that explain costs, benefits, and limitations.
Simpler alternatives when a proposed solution introduces unnecessary complexity.
I also want readers to be able to distinguish a reproducible tutorial from an exploratory note, an illustrative example from a measured result, and a documented capability from an assumption that still needs testing.
Not every article will contain a full benchmark or a complete deployment experiment. Some topics are better served by careful documentation analysis, a focused implementation guide, or a clearly labeled example.
The important thing is to be transparent about what the article establishes—and what it does not.
What Run It Clean Will Not Do
Trust is easier to lose than to build, especially in a field where tools and claims change quickly.
There are a few boundaries I intend to keep.
No invented test results. Example numbers, estimates, and hypothetical scenarios will not be presented as actual measurements.
No exaggerated model claims. A successful example does not prove that a model will perform equally well across different tasks, environments, or users.
No unnecessary hardware pressure. Recommendations should consider existing equipment, smaller models, quantization, CPU inference, and cloud options before assuming that an expensive upgrade is necessary.
No vendor marketing disguised as independent analysis. Vendor documentation and published benchmarks can be useful sources, but their claims should be attributed appropriately.
No complexity for its own sake. Additional frameworks, services, and infrastructure should earn their place by solving a meaningful problem.
No pretending that uncertainty does not exist. If an implementation has not been tested in the stated environment, a result is inconclusive, or important details remain unknown, the explanation should make that clear.
The purpose of these boundaries is not to make every answer cautious or complicated. It is to make recommendations more useful because their limits are understood.
A Little More About the Person Behind the Blog
Outside technical work, I enjoy hiking and photography around the Pacific Northwest, spending time in independent cafés, and reading technical documentation with a good pour-over coffee nearby.
I am also interested in the infrastructure that supports software beyond the application itself: home servers, networking, storage, and the practical decisions involved in maintaining a system over time.
These interests reflect a broader preference for understanding how things work rather than simply assuming that they will.
That same curiosity shapes Run It Clean. I enjoy taking a complicated technical setup, separating it into understandable parts, and figuring out which pieces are necessary, which are optional, and which introduce problems that are easy to overlook.
I want the writing to feel like a conversation with a technically capable friend: direct enough to be useful, detailed enough to be reproducible, and honest enough to acknowledge when a different approach might be better.
You do not need to be an AI infrastructure specialist to follow every article. You should, however, come away with a clearer understanding of the decisions involved and the next step worth taking.
Who This Site Is For
Run It Clean is written primarily for developers and independent builders in the United States and beyond who want to work with open-source AI in practical ways.
You may be a software developer exploring local inference for the first time, an independent builder trying to keep infrastructure costs under control, a technical founder evaluating options for a small product, or an engineer looking to add language-model capabilities to an existing application.
You may already understand Python and APIs but have limited experience with GPU memory, quantization, or inference servers. Or you may be comfortable running models locally and want a more systematic way to evaluate their behavior.
Whatever your starting point, this site is intended to help you answer three questions:
What is the simplest setup that meets my requirements?
How can I verify that it works under my conditions?
What trade-offs am I accepting by choosing it?
If those are the questions you ask before adopting a new tool, you are in the right place.
Looking Beyond Qwen
Qwen is the starting point for Run It Clean, not a limitation on the site's long-term scope.
As the open-source AI ecosystem evolves, the site may also explore related models, inference tools, deployment infrastructure, and application frameworks.
Any expansion will follow the same editorial standard: focus on the practical engineering questions, explain the evidence behind a recommendation, and help readers understand the conditions that make one approach more suitable than another.
The objective is not to cover every new release. It is to build a useful body of technical knowledge that readers can return to when they need to make a decision or solve a problem.
Tools will change. Model names will change. Hardware requirements and deployment methods will evolve.
The need for clear instructions, reproducible evaluation, and honest technical judgment will remain.
Let's Build Something Useful
Open-source AI becomes more valuable when developers can move beyond demonstrations and build systems that solve real problems.
That does not require chasing every release or assembling the most complicated stack. It requires asking the right questions, testing the assumptions that matter, and choosing tools that fit the job.
That is the standard I want Run It Clean to work toward: practical tutorials, transparent evaluations, useful troubleshooting, and recommendations that respect your time, hardware, and budget.
Thanks for stopping by. I hope you find something here that helps you get your next project running a little more smoothly.
Make it run. Make it useful.
Jonah Vance
Editor, Run It Clean