Local AI on an Older Desktop: Keeping a Small Test in Perspective

Preparing an older desktop

The starting point was an older Ryzen 7 1700 desktop with about 15 GiB of usable RAM and two 11 GB GTX 1080 Ti cards. It was being prepared for local chat and coding. Those specifications describe the machine, but they do not establish how it will behave during a longer session or a different workload.

Docker, the NVIDIA Container Toolkit and Ollama were installed, and the Qwen 3.5 9B model was downloaded for local testing. That software preparation was one part of the work. The hardware observations and the small coding sample still needed to be considered on their own terms.

Selecting a graphics card for local AI

One GPU repeatedly reported fan/power errors and a kernel GPU error after driver activation. Testing another revision of the same driver family did not resolve those errors. The root cause remained unproven.

Selecting a graphics card for local AI

That distinction matters when describing the result. The errors were observed after driver activation, but their timing does not establish what caused them. The unsuccessful driver test also does not, by itself, establish physical damage or identify a particular fault. The supported conclusion is narrower: the tested revision did not resolve the reported errors.

I selected the ASUS card alone for inference. This was a choice about which card to use, not evidence of a repair. Excluding the other card would not physically isolate or repair it. The selection should also remain distinct from a claim that a particular runtime configuration was verified.

Inspecting a small coding response

A short coding response produced an addition function and an assertion. Both were inspected, not executed. That wording is important: reading generated code and running it provide different kinds of evidence. An assertion appearing in the response does not mean the assertion was run or passed.

The sample produced 25 tokens in 0.583 seconds. It was a tiny warm sample, not a sustained performance or reliability benchmark. The timing describes that small generation; it does not establish how longer responses, extended sessions or other tasks would behave.

Keeping the result in proportion

There are useful observations here without turning them into a larger success claim. Software was installed, a model was downloaded, a short response was generated, and its code was inspected. Separately, one GPU reported errors that the tested driver revision did not resolve, and the cause remained unproven.

For me, the useful distinction is between preparation, selection, observation and verification. Keeping those categories separate makes this account more precise. It avoids presenting a selected card as a repaired system, an inspected snippet as executed code, or a brief warm sample as proof of sustained speed and reliability.