Windows 8B fresh-install validation — issues found and performance results

I tested the Edge0 8B model end-to-end on a fresh Windows setup and wanted to report both the installation issues encountered and the resulting runtime performance.

Hardware / software

• CPU: Intel Core i5-1155G7, 4 cores / 8 threads
• GPU: Intel Iris Xe (Tiger Lake GT2)
• RAM: 16 GB
• GPU: integrated only, no NVIDIA GPU
• OS: Windows 10/11 x64
• Visual Studio 2022 Community
• CMake 4.4.4
• Vulkan SDK 1.4.363.0
• Rust stable 1.99.0
• Node.js 24.21.0
• npm 11.19.0

What worked

After resolving the installation issues, the complete 8B path worked:

• Edge0 8B MLX model converted to GGUF successfully
• LoRA converted successfully
• 147/147 LoRA pairs passed the base-model cross-check
• GGUF/LoRA artifacts passed their validation
• Local llama-server.exe launched successfully
• Model + LoRA loaded successfully
• Interactive inference worked
• Casual conversation was coherent
• The conversion wrapper was ultimately idempotent: rerunning it detected matching artifacts and skipped reconversion

Issues encountered

1. Doctor could not detect the engine version correctly

The engine itself reported its version correctly when launched interactively:

0.4.1-dev (build 11108, commit f780eff51)

However, the Doctor version probe failed to capture the output when launching the process with the Windows CREATE_NO_WINDOW configuration.

This resulted in the application reporting a version-probe failure even though the executable was present and runnable.

This looks like a Windows subprocess/output-capture compatibility issue in the Doctor check.

2. Missing Python dependency

The LoRA conversion required PyYAML, but the dependency was not available in the Python environment used by the converter.

The failure surfaced as:

ModuleNotFoundError: No module named 'yaml'

Installing PyYAML into the exact Python environment resolved it.

It would be useful if the conversion tooling either declared/provisioned this dependency or produced a clear prerequisite error before starting conversion.

3. Incorrect base-model path in the LoRA verifier

The LoRA converter generated the base GGUF under:

%USERPROFILE%\.edge0\models\edge0-8b-gguf\edge0-8b.gguf

but the verifier looked under the repository's:

Edge0\windows\models\edge0-8b-gguf\edge0-8b.gguf

This caused a FileNotFoundError even though the generated base GGUF existed in the expected .edge0 model directory.

I corrected the verifier to derive the base path from the adapter/model directory.

4. Windows console encoding issue

The conversion itself completed, but the wrapper's final status message contained a Unicode arrow (→), which caused a UnicodeEncodeError under the Windows console code page.

Changing the output to ASCII (->) resolved this.

This would be worth making Windows-safe in the repository rather than allowing successful conversion to end with a traceback.

5. Fresh-install/toolchain friction

A few additional issues were machine/environment specific rather than Edge0 bugs:

• Existing machine-level ComSpec pointed at an invalid Gradle path, breaking Tauri commands.
• Windows Smart App Control blocked some Rust tooling.
• Visual Studio workload modification encountered installer/process-state errors.
• npm dependencies had to be installed before the Tauri build.

These are probably useful context for reproducing the installation, but I would distinguish them from the repository-level issues above.

Runtime performance

After the installation/conversion issues were resolved, the local 8B model was usable interactively.

Observed measurements during casual conversation included:

The initial request had a relatively expensive prefill (~16.97 s), while subsequent requests benefited substantially from the already-running model/context state.

Example later interaction:

• ~9.9 tok/s decode
• ~10.6 tok/s prefill
• ~4.14 s prefill time
• 31 input tokens / 44 output tokens

The model remained responsive enough for casual conversation on this CPU + integrated-GPU system.

Overall result

The important point is that the underlying 8B model/runtime path did work on this relatively modest integrated-GPU machine.

Most of the friction was around Windows installation, dependency handling, path assumptions, subprocess detection, and console portability rather than model conversion or inference itself.

I thought this might be useful as a real-world fresh-install validation report, especially because the machine is not a high-end GPU system.