I installed Ollama on a Mac Mini M4 Pro to run Qwen38 and GLM models locally, measuring actual VRAM and speed. Found that 32k context uses an additional 3GB per test, with steps to fix common web search tool errors.
Machine Preparation and Ollama Installation
I started by downloading the Ollama installer for macOS from the official website, which works excellently with Apple Silicon M4 Pro chips. After installation, I checked the version using ollama --version to ensure I was running the latest version with optimal memory management.
A critical step was configuring the model path to point to a partition with sufficient free space, since large models like Qwen38 have weight files spanning tens of GB. I used OLLAMA_MODELS=/Volumes/AI_Disk to separate model storage from the system drive, preventing the main SSD from filling up quickly and reducing write operations that affect drive lifespan.
I also verified folder permissions using chmod -R 755 /Volumes/AI_Disk so Ollama could retrieve data without Permission Denied issues—a common oversight that causes model loading to fail midway. Proper space preparation is essential before downloading and testing performance.
Downloading and Managing the Qwen38 Model
I chose Qwen38 as my primary test model due to its 32k token context, ideal for Thai document analysis tasks. I used ollama pull qwen38 to download the weights, which took about 15 minutes on high-speed internet.
After loading, I checked the actual size with du -sh ~/.ollama/models/blobs/sha256-*, finding the model consumes approximately 18GB of storage. With the 32k context allocated (KV Cache), total memory increases to 21GB according to my test reports.
I ran the model with ollama run qwen38 --num-ctx 32768 to set maximum context size. This configuration requires the system to reserve an additional 3GB of RAM specifically for KV Cache, essential for maintaining conversation continuity or processing long documents without forgetting prior information.
Real Testing on Our Machine
On September 2, 2026, I ran the resume-verify test suite on my Mac Mini M4 Pro, checking system status via the API at webui.siam2r.com/api/version. Results showed HTTP 200, confirming the service was operating normally.
I tested Vision endpoints with a 1x1 pixel PNG file. Both Qwen3-VL-8B and GLM-4.6v-flash passed 3/3 tests with HTTP 200, demonstrating these models support basic image processing even on Mac hardware.
However, I encountered a real issue running the search_web function in LiteLLM, which threw a "failed-to-parse tool-call args" error at 15:52:43. While this is a Client Model bug, I documented that it's unrelated to my core configuration and requires no code fixes—just waiting for upstream developers to resolve it.
Lessons from Errors and Solutions
A key lesson learned: "Dry-run" testing before production deployment prevents damage. I used the alias qwen38-deep32k-test to simulate scenarios before actual runs, revealing unexpected memory usage issues.
I discovered that running Qwen38 alongside Qwen2.5VL (7.3GB) simultaneously caused excessive swapping and system slowdown. I designed a predictive.sh script to immediately unload unused models after testing completes.
Another critical point: Embedding Dimensions. I verified Nomic-embed-text uses 768 dimensions while BGE uses 1024. Understanding these numbers helps select appropriate Vector Databases, since mismatched dimensions cause system failures without clear errors, making debugging significantly harder.
Performance Summary and Recommendations
Based on my actual measurements, Qwen38 Deep 32k uses 21GB total memory (18GB weights + 3GB KV Cache), while the Fast version uses only 18GB—suitable for machines with less RAM.
I recommend Mac Mini M4 Pro users with 64GB+ RAM can run these models smoothly without significant thermal throttling concerns, but should close other RAM-intensive applications like Chrome or Xcode during large model runs.
Finally, I confirm that local AI on Mac delivers reliable, secure results superior to cloud solutions regarding privacy, but requires strict resource management. Regular monitoring of logs and VRAM usage is essential for developers seeking stability.
For more lab work like this, follow LINE @icafefx or download free tools at redhatai.net.
