Open Weight Models · Windows · Lesson 7
Manage models, memory, and privacy
Inspect resource use, troubleshoot common problems, and keep local inference under your control.
Windows version. Use PowerShell for terminal commands. The exercises and setup instructions below are tailored to this version.
What you will learn
- Distinguish downloaded model files from models currently loaded in memory.
- Investigate slow responses and common local service errors with a short, repeatable check.
- Explain the local/cloud boundary and keep the unauthenticated local API on loopback.
Know what is stored and what is running
Use the model name and tag consistently. A downloaded model can remain on disk while no model is running. Conversely, finishing a chat does not necessarily unload its model immediately. Check the two states separately before trying to solve a storage or memory problem.
The following commands have different purposes. The remove command is a reference for deliberate cleanup after the course; do not run it as part of the observation exercise.
| Command | What it tells you or changes |
|---|---|
| ollama list | List models available locally; ollama ls is an alias. |
| ollama ps | List currently loaded models, including their processor allocation. |
| ollama show gemma3:1b | Inspect this model's details. |
| ollama stop gemma3:1b | Unload this model from memory without deleting its local copy. |
| ollama rm gemma3:1b | Delete this local model copy. You may need to download it again to use that name. |
Stop and remove solve different problems
Use stop when you want to release the model's runtime resources. Use rm only when you intend to remove a local model. Removing one name may not reclaim all shared model data used by another named model.
Measure your computer instead of guessing
Use Task Manager's Performance view to observe available memory and CPU/GPU activity while testing. Combine that view with ollama ps, which describes the loaded model's processor allocation. Do not infer GPU offloading from one utilisation graph alone.
Keep the short course prompt and selected context setting consistent when comparing a first request after unloading with a second request. Download size, runtime memory, and response time are different measurements. Other applications and driver support can affect what you observe.
If memory is constrained, close unnecessary applications, unload a model you are no longer using, and shorten the test. Check the current Windows hardware guidance before changing drivers or assuming that a larger model will fit.
- Compare a first request after unloading with a second request using the same short prompt. Record both times; loading can make the first slower.
- Keep the model, prompt, requested answer length, and other running tasks similar when comparing timings.
- Record responsiveness and answer quality together. A faster incorrect response does not improve your study assistant.
- If memory becomes constrained, close unnecessary applications, unload an unused model, and shorten the test before considering larger hardware or model changes.
PowerShell: inspect loaded models · powershell
ollama psDiagnose the native Windows app
Start with ollama list. A connection failure with a recognised command usually points you towards the running app or server configuration. Open Ollama from Start and retry. A port conflict can mean the app is already listening, so inspect the owner before changing anything.
The first diagnostic block reads the listener and associated process; it does not terminate it. If access is restricted, retain the message and consult your device administrator. The second block reads recent server log lines from the documented Windows log location. Review log contents before sharing them.
| Symptom | Windows check |
|---|---|
| Command not found | Reopen PowerShell; inspect Get-Command ollama and the completed installation. |
| Cannot connect | Launch the native Ollama app from Start; inspect its server log if the failure continues. |
| Port in use | Try ollama list and inspect the listener's OwningProcess; do not start another server. |
| Model not found | Compare the exact tag with ollama list; recreate cybercorps-study from Modelfile if needed. |
| Slow response or memory error | Inspect Task Manager and ollama ps; use one short request and review context/resource use. |
PowerShell: identify a listener on port 11434 · powershell
$ollamaListeners = Get-NetTCPConnection -LocalPort 11434 -State Listen
$ollamaListeners | Select-Object LocalAddress, LocalPort, OwningProcess
$ollamaListeners | Select-Object -ExpandProperty OwningProcess -Unique | ForEach-Object { Get-Process -Id $_ }PowerShell: inspect the current server log · powershell
$ollamaLog = Join-Path $env:LOCALAPPDATA "Ollama\server.log"
Get-Content -LiteralPath $ollamaLog -Tail 60Configure local-only mode on the Windows server
A loopback request can still select a cloud model. Keep the course's local gemma3:1b or cybercorps-study model and the default loopback listener. Do not change the listener to expose the unauthenticated API to the network.
For explicit local-only operation, quit Ollama from its notification-area icon. In Windows, search for Edit environment variables for your account. Under User variables, create or edit OLLAMA_NO_CLOUD with value 1, save all dialogs, then launch Ollama again from Start. This follows the documented Windows server-environment process.
Check the server log from the new startup for Ollama cloud disabled: true. The PowerShell block reads the saved user value and searches the current log; a saved value by itself does not prove that the server inherited it. Inspect the matching timestamp and retain it with your setup evidence.
This disables Ollama cloud models and web search, not every network connection on the computer. Downloads, updates, other clients, saved histories, and backups remain separate considerations. Setting a variable only in an already-open client shell does not update an existing desktop server.
PowerShell: verify the persisted setting and restarted server · powershell
[Environment]::GetEnvironmentVariable("OLLAMA_NO_CLOUD", "User")
$ollamaLog = Join-Path $env:LOCALAPPDATA "Ollama\server.log"
Select-String -LiteralPath $ollamaLog -SimpleMatch "Ollama cloud disabled: true"
ollama listCreate a local operation checklist
Record the downloaded models and inspect gemma3:1b from PowerShell.
Run a short request, inspect ollama ps, and observe Task Manager's memory and processor views. Record what this machine actually does.
After the request completes, stop gemma3:1b and compare its loaded state with its continued presence in ollama list.
Time two comparable short requests, noting whether the first reloads the model.
Set OLLAMA_NO_CLOUD=1 in Windows User variables, fully restart the tray application, and record a current startup log entry confirming that cloud features are disabled. If you cannot configure a managed device, record that limitation.
Use the read-only listener/log commands to document your first diagnostic step for connection failure and a port conflict. Keep deletion outside this observation exercise.
You have completed this task when…
- Your evidence distinguishes disk availability from a model loaded in memory.
- You have observations from your own machine and a practical first check for three common errors.
- Your checklist distinguishes local inference from cloud routing and keeps the unauthenticated API on loopback.
Official documentation
Use these references for platform requirements, current options, and further detail.
- Ollama: CLI reference
- Ollama: CLI command definitions
- Ollama: context length
- Ollama: hardware support
- Ollama: troubleshooting
- Ollama: local-only mode and server configuration
- Ollama: authentication
- Ollama: cloud models
- Ollama: native Windows installation
- Ollama: Windows server environment and local-only mode
- Microsoft: inspect TCP connections and process ownership