Product architecture
Local AI.
Built for teaching.
The language model is one part of the product. AI Server Home adds a teacher application around it: selected standards, lesson planning, built-in revisions, and a personal library of saved work.
Three architectural decisions
Build the teaching workflow.
Then choose the right compute.
Architecture decision
The application makes it
a teaching tool.
A teacher should be able to plan a lesson, improve it, and keep the work. The application brings those steps together around a local AI model.
Give the model a clear starting point.
The teacher selects curriculum standards and adds a learning goal, available time, materials, and learner needs. The application assembles that context before requesting a draft.
Keep the teacher’s work in the loop.
Built-in revision uses the current working draft, including the teacher’s edits and latest instructions. The teacher can review suggestions, make changes, and save personal lessons and versions.
Implemented workflow · Educator review remains essential
The current workflow supplies selected, captured standards and teacher-provided context. Source records remain separate from AI suggestions. It does not automatically retrieve a district’s adopted curriculum or prove that every suggestion is correct.
Architecture decision
A compact model.
A deliberate workflow.
Our first matched educator comparison tested Qwen3.5-4B and Qwen3.5-9B INT4 OpenVINO models. 4B completed each of the four tasks faster. The quality results explain why reliable source selection also belongs in the application.
| Task | 4B time | 9B time | 4B / 9B full checks |
|---|---|---|---|
| Exact standard + provenance | 23.80 sec | 50.53 sec | Needs review / Needs review |
| Components + relationships | 27.04 sec | 71.19 sec | Needs review / Needs review |
| Discover a standard by meaning | 26.45 sec | 41.10 sec | Needs review / Pass |
| Recognize a nonexistent code | 8.22 sec | 13.08 sec | Needs review / Pass |
4B answered faster on all four tasks. 9B did better on two source-checking tasks. Both models still missed details. We kept 4B as the selected local model and put source selection and the teaching workflow in the application. The teacher still needs to check the answer.
One response per model per task, temperature 0, 2,048-token cap, thinking disabled and effective answer-generation parameter parity checked. Different output lengths and tool choices affect total time. These earlier tool-assisted trials measure a different workflow from the current guided lesson application. No 29B result was located in the recovered archive.
Read the prompts, answers and failed checks ↗Architecture decision
Give embeddings
their own place to run.
In our first embedding runtime comparison, the same 200 sequential single-input requests were sent to Ollama and then OVMS/NPU. All 400 returned HTTP 200 and finite, nonzero 1,024-dimensional vectors. The sequence contained 20 unique synthetic input texts with repetitions.
First run · Whole-host CPU comparison
Compare the workload with the idle baseline.
Saved idle baseline: about five minutes, 138 samples. Each workload: 200 requests, 64 CPU samples, roughly two minutes. These are whole-host CPU readings, not model-only utilization. The idle system already had OpenVINO services running. This is an alternate-runtime comparison, not an OpenVINO-on/off test; artifacts and execution devices differ.
Inspect the baseline calculation ↓Compare embedding timing, throughput and memory
| Measure | Ollama comparison | OVMS / Intel NPU |
|---|---|---|
| Successful requests | 200 / 200 | 200 / 200 |
| First request | 1.242 sec | 3.197 sec |
| Median after first | 0.908 sec | 0.665 sec |
| Empirical p95 | 1.221 sec | 0.685 sec |
| Whole-workload throughput | 1.471 requests/sec | 1.483 requests/sec |
| Whole-host CPU activity ≈ | 89.8% | 3.7% |
| Peak embedding cgroup charge | 2.015 GiB | 5.515 GiB |
| One-minute idle cgroup charge | 2.005 GiB | 5.214 GiB |
The NPU was active during the OVMS embedding test, while whole-host CPU activity was lower than in the Ollama test. The two runtimes completed the overall workload at almost the same rate. OVMS kept more memory allocated afterward; Ollama unloaded naturally. The complete measurements are available in the appendix.
One A-then-B pass on a 30.4 GiB usable-RAM development appliance. Different runtime artifacts and devices; this does not isolate a hardware speedup. Seven synthetic queries retained the same top-three documents, a small-fixture consistency check rather than general retrieval accuracy. Historical NPU evidence does not prove that every current lesson performs embeddings.
Inspect every request, vector and telemetry sample ↗How it works for teachers
The tools around the model.
How is a lesson grounded in curriculum?
The teacher selects the standards and supplies the lesson context. The application sends those source records with the request and keeps their attribution visible. AI suggestions are separate from the original standards. The current workflow does not automatically search a district’s entire curriculum collection.
Can a teacher change the draft?
Yes. The teacher can edit the working draft or ask for a revision using different examples, a shorter activity, or added support. The application includes the current draft and latest instructions in the revision request. The teacher reviews the changes before keeping them.
Which tools run on the local appliance?
The teacher application, language-model runtime, packaged standards and saved-lesson database run on the appliance. The appliance also provides a local embedding service for retrieval workflows. A lesson using selected standard captures does not necessarily call that embedding service. Full disconnected operation, including sign-in, still needs qualification testing.
What happens while a draft is being generated?
The current application accepts one generation at a time and reports busy when another request overlaps. An expanded pass completed 12 lesson requests across three scenarios with a 36.0-second median response. That timing excludes browser rendering and saving; it is not a supported-user count.
Expanded application measurements
Twelve lesson requests.
Three teaching scenarios.
We exercised the current application’s real local model with three fictional Grade 3 lesson requests: introduce one half, compare thirds and fourths, and correct unequal intervals. Each scenario ran four times, interleaved and submitted one at a time.
| Teaching scenario | Completed | Median | Observed range |
|---|---|---|---|
| Introduce one half | 4 / 4 | 35.858 sec | 35.828–36.694 sec |
| Compare thirds and fourths | 4 / 4 | 49.069 sec | 49.042–49.802 sec |
| Correct unequal intervals | 4 / 4 | 35.832 sec | 35.638–36.105 sec |
Measured through the deployed application’s preparation and inference adapter, with the same Qwen3.5-4B INT4 OpenVINO model and generation settings. Includes source preparation and model response validation; excludes browser, sign-in and saving. The aggregate depends on this scenario mix. A single run with four samples per scenario does not establish a service guarantee or multi-user capacity.
The appliance’s services and configuration were unchanged afterward. Draft completion is separate from lesson quality. A spot-check again found suggestions for unavailable materials; educators still need to review the content and teacher instructions.
Download all 12 measurements ↓Earlier application baseline
What we measured in the application.
See generation timing and overlapping requests
| Scenario | Submitted | Completed | Busy | Completed time |
|---|---|---|---|---|
| Functional create + revise | 2 | 2 | 0 | 42.046 / 49.084 sec |
| Serial · two waves | 2 | 2 | 0 | 41.802 sec median |
| Two submissions · two waves | 4 | 2 | 2 | 41.794 sec median |
| Four submissions · two waves | 8 | 2 | 6 | 41.573 sec median |
Across 16 submissions, eight model responses completed and eight overlapping requests were rejected by the unchanged application guard. There were no transport or adapter failures. Actual simultaneous generation stayed at one; the two- and four-submission stages do not establish medium/heavy backend capacity.
These are application-adapter measurements, excluding HTTP authentication, browser/network/rendering, and saving. Samples are too small for p95 latency, reliability guarantees, or supported-user estimates. Warm/cold state was not established. The functional create/revise inputs differ and are not pooled with fixed-input timing samples.
Download evidence summarySystem and software
What is running.
- Processor
- Intel Core Ultra X7 358H
- Operating system
- Ubuntu 26.04.1 LTS
- Enumerated accelerators
- Intel Arc B390 integrated GPU and Panther Lake NPU
- Generation model identifier
- OpenVINO/Qwen3.5-4B-int4-ov
- OpenWebUI
- 0.11.3
- OpenVINO Model Server
- 2026.5.0.6ec5e369a
- OpenVINO backend
- 2026.5.0-23099-d015add94c1
- OpenVINO GenAI backend
- 2026.5.0.0-3455-a521ae75728
- Generation controls
- Temperature 0 · max_tokens 2048 · nonstreamed · thinking and model tools disabled
- Source context
- Packaged, integrity-checked standard captures selected by the application
Application-controlled context.
The teacher interface supplies selected captured standards, teacher text, and revision context. The saved assistant is managed in OpenWebUI and uses the appliance-local OpenVINO language runtime. Account-based saved lessons and versions use PostgreSQL.
The model does not freely browse the teacher database. A real saved assistant is used; the wire-level application of its saved system prompt retains an operator-attestation limitation.
Evidence of integration
Beyond a package list.
- Loaded library paths include OpenVINO and OpenVINO GenAI in the language-server process.
- Kernel xe driver counters show advancing GPU compute activity for that process during the observed stages.
- Available host memory remained above 14.7 GiB during the application test. CPU baseline comparisons are shown with the embedding study above.
- Service identity, configuration, start-time, and readiness checks were unchanged after the measurements.
Limits of the evidence
Keep the claims specific.
- GPU counters show process activity, not isolated per-request utilization or a measured GPU speedup.
- NPU utilization was not measured in this application pass. The historical embedding test above supplies separate NPU activity evidence; per-lesson NPU use remains unproven.
- The installed GPU monitoring tool did not recognize the xe device; kernel counters supplied the activity evidence.
- Independent software-ingredient counting and system/OS acceptance remain Intel review decisions.
What we learned from testing
A complete draft still needs a teacher’s check.
The AI created a lesson and then revised it when asked. Both drafts had the requested lesson sections, but they did not follow every instruction: a whiteboard-only lesson also included paper and notebooks.
The application provides the source context, editing and revision tools. The teacher checks the content, the materials and whether the lesson fits the learners. Producing a complete draft does not mean it is ready for the classroom.
How did we test the current workflow?
An isolated test harness used the deployed application’s actual preparation and model-request code with fictional lesson requests. We measured creation, revision and overlapping submissions. We did not save production lessons or include browser, sign-in or save time in the results. Inputs, outputs and methods are in the appendix.
What still needs validation?
Broader educator review, consistent adherence to teacher instructions, end-to-end browser timing and disconnected operation remain to be validated. Intel determines program eligibility and verification; these measurements do not establish certification.
The detail behind the decisions
Explore the full evidence.
Compare model answers, inspect the CPU baseline, and download request-level measurements and known limitations.