Frostmourne is my personal AI infrastructure platform, built on Ubuntu Server with Docker and separate GPU-pinned Ollama instances. Gemma handles the main agent workload, while Devstral handles delegated coding tasks. The project combines workload configuration, restricted agent access, automation, and monitoring.
Current state
Independent inference
Separate GPU-pinned Ollama instances run Gemma on the NVIDIA RTX 5090 for the main agent and Devstral on the RTX 4090 for coding workloads.
Agent workflows
Hermes Agent, delegated coding workloads, and Discord integration connect the inference platform to ongoing work.
Controlled operations
Restricted Docker management gives AI agents a constrained operational interface. Custom troubleshooting and verification guard plugins support investigation and checking.
Frostmourne is built on a workstation-class platform selected for concurrent local inference, memory capacity, and sustained GPU workloads.
Processor
AMD Ryzen Threadripper PRO 5955WX with 16 cores and 32 threads.
GPU accelerators
NVIDIA RTX 5090 · NVIDIA RTX 4090
Memory
128 GB DDR4-3200 ECC memory, configured as 4 × 32 GB in quad-channel mode.
Motherboard
Supermicro M12SWA-TF workstation motherboard with Socket sWRX8/SP3.
Storage
1 TB PCIe Gen 4 NVMe M.2 solid-state drive.
Networking & management
The onboard 10 GbE interface connects to a 10 GbE network switch. The dedicated 1 GbE IPMI management port connects to a separate 2.5 GbE switch, maintaining an independent path for out-of-band administration and reducing reliance on the primary network path.
Power & cooling
1700 W Super Flower power supply and an ARCTIC Freezer 4U-SP3 processor cooler.
The hardware layout supports two independently assigned inference workloads while retaining CPU and memory capacity for containers, agents, telemetry, and supporting services.
Architecture
Logical components of the platform. This view describes responsibilities; it does not prescribe undocumented ports, network boundaries, or request routing.
Custom troubleshooting and end-to-end verification guard plugins
Security considerations
Restricted Docker management is the stated operational boundary for AI agents. The exact permitted actions and the implementation of those restrictions remain to be documented.
Troubleshooting and verification guards support workflow discipline. Their presence alone does not establish a security boundary or prove isolation.
Challenges & troubleshooting
/ Troubleshooting case study
Diagnosing CPU fallback in containerized Ollama
Earlier in Frostmourne’s development, Qwen3 14B was used as an inference workload. It initially appeared unresponsive, but eventually answered, narrowing the immediate symptom to slow inference rather than a completely unavailable service.
Investigation
The host did not have an ollama command. Docker inspection identified the running container, and docker exec -it ollama ollama ps showed the model using 100% CPU with a 32,768-token context.
The container configuration already requested GPU access. However, docker exec ollama nvidia-smi returned Failed to initialize NVML: Unknown Error. The configured GPU request and actual access inside the running container did not agree.
Recovery and verification
Recovery work focused on restoring Ollama’s GPU access and checking model placement again. A later reading showed mixed CPU/GPU placement. ComfyUI’s allocation was also checked during the investigation and confirmed to be using its assigned GPU resources correctly.
Initial reading
100% CPU Qwen3 14B · context 32768
Intermediate reading
78% CPU / 22% GPU Qwen3 14B · context 32768
Final readings
100% GPU Qwen3 14B · context 32768
Measured response time
15.93 ms median Five warmed Qwen3 14B runs · fixed one-word prompt
The final command output confirmed full GPU placement without a recorded context reduction. Subsequent reboots and later workloads confirmed that the GPU placement persisted. These percentages are Ollama’s reported CPU/GPU placement, not GPU utilization measurements.
The response-time figure is a follow-up measurement recorded on September 27, 2026. It reports Ollama’s median total_duration across five warmed runs; each generated the requested one-word response as two output tokens.
Engineering takeaway
A running container with a GPU request is not proof that inference is using the GPU. Check device access inside the container, inspect model placement, and verify the original performance symptom after recovery.
Build history
Selected milestones, grouped by engineering area.
PROJECT MILESTONE
Multi-GPU inference architecture
Established independent Ollama workloads across the RTX 5090 and RTX 4090.
Explicit GPU assignment separates the two inference workloads.
Technical context
Separate Ollama instances are pinned to the RTX 5090 and RTX 4090, giving each workload an explicit GPU assignment.
PROJECT MILESTONE
Hermes Agent integration
Integrated Hermes Agent into the personal AI platform.
Introduced agent workflows alongside local inference.
PROJECT MILESTONE
Delegated coding workloads
Added delegated coding to the platform’s capabilities.
Extended the system into task execution and coding workflows.
PROJECT MILESTONE
Discord integration
Connected the platform with Discord.
Added a communication integration for the agent platform.
PROJECT MILESTONE
Restricted Docker management
Added constrained Docker management for AI agents.
Defined a limited operational scope for agent-driven container management.
PROJECT MILESTONE
Telemetry foundation
Integrated Telegraf, InfluxDB, and Grafana for infrastructure telemetry.
Made monitoring part of the platform’s operational design.
PROJECT MILESTONE
GPU dashboards
Added GPU telemetry and dashboards.
Provided visibility into GPU behavior during inference workloads.
PROJECT MILESTONE
Troubleshooting guard
Added a custom troubleshooting guard plugin.
Introduced a dedicated guard into the troubleshooting workflow.
PROJECT MILESTONE
End-to-end verification guard
Added a custom verification guard plugin.
Made end-to-end verification an explicit part of the workflow.