Model experiments
Keeping the slow result in the record
A configuration that technically answers can still be too slow for everyday use. This test kept the unsuitable result in the record.
- Three-token greeting
- 25.175 s
- Saved smoke-test requests
- 4
The question
Would the locally identified qwen/qwen3.8-27b model be responsive enough for ordinary CPU use?
How the work was approached
CPU-only context/parallel settings and four tiny prompts; recorded output, completion tokens and elapsed time.
What the record shows
The hello request needed about 25 seconds for a three-token completion; one answer hit its token cap. The notes rejected this model as the source PC's daily driver.
What remains unresolved
Small smoke test, includes prompt/queue overhead, not decode throughput. Model name is the recorded local identifier. Not a general hardware/model ranking and no R640 claim.
What we are trying to achieve
The aim is practical usefulness on the machine doing the work. Keeping an unsuitable configuration in the record helps the next selection start from evidence and prevents a familiar model name or a successful load from outweighing an actual user’s wait.
Sources & reading notes
- QWEN3_8_27B_TUNING.mdPhase 2 / Short smoke results Retained project record Source record retained privately.
- results.jsonFour actual returned outputs and timings Retained project record Source record retained privately.
This is a dated, source-based research account, not a live machine report. Historical results, engineering preparation, research designs, open review gates, and measured pilots remain distinct.
