Setting up a NAS for AI without GPU
The UGREEN DXP4800 Pro is a device primarily intended for file storage and network access. Its design focuses on serving as a network-attached storage solution, which means it lacks the dedicated graphics processing unit (GPU) that AI workloads usually rely on. AI tasks typically demand strong computational power, and a device like this is not built to handle those. Still, an experimenter chose to try using the UGREEN DXP4800 Pro as a platform for AI by installing Ollama and linking it with Open WebUI. The aim was to see if it was possible to operate small 4B language models on such a device, regardless of whether it was efficient or not.
The configuration involved Docker to manage the setup. Docker Compose was used to create a container for Ollama with port 11434 exposed. Then, Open WebUI was added to provide a browser-based interface for managing the AI tasks. To connect the interface to the Ollama backend, port 3000 on the NAS was mapped to port 8080 in the Docker container. This setup allowed the user to interact with the AI system through a web browser, rather than just through the command line. Although the process was manageable, it was immediately clear that the NAS’s hardware wasn’t built for handling AI workloads. While the system worked, it lacked the performance needed for anything beyond basic AI experiments.
Speed is not the UGREEN DXP4800 Pro’s strength
Qwen3 4B performed at around 5.4 tokens per second. While that may sound acceptable for a small device, it's significantly slower compared to cloud-based AI systems. The delay becomes obvious during the text generation process, as each word takes time to appear. The system consumed approximately 197% of CPU power and used nearly 3.1GB of RAM while processing. Additionally, the machine heavily used swap space, which further slowed things down. Observing the system as it painstakingly created a response one token at a time was frustrating, even though the final output was correct.
Gemma 3 4B performed even more slowly, managing just around 3.2 tokens per second. Not only was it slower, but it also unnecessarily activated features for processing visual data, which were irrelevant to the tasks at hand. This made the system even more sluggish. Still, in a test involving diagnosing a Pi-hole configuration issue, it eventually identified the correct problem. It took over four minutes to reach that conclusion, but at least the result was accurate.
Useful for certain everyday tasks
Despite its speed issues, the system demonstrated some usefulness for specific, routine tasks. For instance, when asked to reformat a set of technical notes into usable Markdown, the system completed the task in under two minutes. It retained crucial details like port numbers, file paths, and mounting instructions while organizing the information into a structured format. Because this task didn't demand immediate results, it was a good match for the system's limitations. The user could start the process and then attend to other work, rather than waiting for results in real time.
In another test, the system struggled with a Pi-hole issue. The model initially misdiagnosed the problem and took over 17 minutes to resolve it, ultimately requiring the user to restart the service manually. In contrast, the Gemma 3 4B model correctly identified the problem in just over four minutes. This test underscored the system’s major issue: speed. While it could provide useful insights, it required significant time to do so, which limited its practicality for tasks that needed quick resolution.
The setup proved useful in the context of what it wasn’t meant to achieve. It wasn’t designed for high-intensity AI tasks or complex problem-solving. Instead, it aimed to assist with minor, everyday jobs like formatting text, organizing technical notes, and handling small-scale AI chores. For these purposes, it was adequate, especially when users could initiate a task and return to it later without needing constant attention.