That is the approach XDA Developers’ Samarveer Singh describes with a repurposed Acer Nitro 5. Its Intel integrated graphics runs a small local vision-language model for household document questions, while an Nvidia RTX 3050 Ti Mobile remains available for media transcoding and game streaming. The result is slow, deliberately limited, and more interesting as a resource-allocation experiment than as a ChatGPT replacement.
Two graphics processors, different responsibilities
Singh’s laptop has a Core i7-11800H, 16GB of RAM, and the mobile RTX 3050 Ti. It was already serving the household through Jellyfin and Sunshine before AI entered the picture.
The motivation was sensitive paperwork. Singh wanted his parents to have somewhere other than a cloud chatbot to send bank statements, insurance documents, medical reports, and similar material for explanation.
Rather than compete with the existing workloads for the Nvidia GPU, he assigned the model to the Intel integrated graphics using llama.cpp’s Vulkan backend.
The underlying capability is documented: llama.cpp supports Vulkan, can include multiple acceleration backends in one build, and allows backend devices to be selected at runtime. This makes explicit device selection—not simply owning two GPUs—the important part of the arrangement.
The useful distinction: this is about keeping AI off a busy discrete GPU, not proving that integrated graphics is the fastest place to run it.
Why copying Vulkan0 is not enough
In Singh’s configuration, Vulkan0 identified the Intel GPU. He reports selecting it and monitoring Nvidia activity with nvidia-smi -l 1, where he did not see llama.cpp using the RTX.
That identifier should not become a universal recipe. The llama.cpp documentation provides --list-devices to enumerate available devices and --device to choose among them. Readers should identify the Intel adapter on their own machine rather than assume the first Vulkan device is always integrated graphics.
There is also a distinction between selecting a device and deciding how much work to place on it. The server documentation separately lists device selection and GPU-layer controls. Checking the runtime configuration matters more than assuming a Vulkan-enabled executable automatically uses the intended adapter.
Singh’s monitoring is evidence of his reported configuration, not proof that every component of another multimodal setup will avoid its discrete GPU.
A small vision model, with setup caveats
The chosen model was Liquid AI’s LFM3-VL-2B. Its image-and-text capability matters because the household task involves looking at document images, not merely answering typed questions. Liquid AI distributes a GGUF version for local CPU and GPU inference.
The official repository lists several quantizations, including approximately:
| Model variant | Listed file size |
|---|---|
| Q4_K_M | 1.10GB |
| Q5_K_M | 1.26GB |
| Q6_K | 1.43GB |
| Q8_0 | 1.85GB |
Those are model-file sizes, not complete application-memory requirements. The repository also identifies multimodal projector files used by the vision setup, so the language-model download should not be mistaken for the entire image-capable deployment.
Singh names llama.cpp build 11960 as the minimum for his setup. That exact compatibility floor is not independently established here; it should remain an attributed requirement from his account, not a blanket installation guarantee.
PDF handling also needs qualification. Singh converted pages into screenshots because his configuration did not directly accept the PDFs he wanted to use. That describes his workflow, not a universal prohibition on building PDF-processing tools around the model.
The real bottleneck was waiting for the answer to start
The most revealing part of the experiment is its latency breakdown. Singh reports the following results for a two-page scanned rental agreement and a question:
| Measurement | Reported result |
|---|---|
| Input tokens | 7,098 |
| Generated tokens | 252 |
| Prompt processing | 33.3 tokens/second |
| Time to first token | About 213 seconds |
| Answer generation | 6.11 tokens/second |
| Generation time | About 41 seconds |
| Total completion time | About 254 seconds |
These are measurements from one reported setup, not independently reproduced benchmarks.
The practical lesson is clear: quoting “six tokens per second” would conceal most of the wait. The first answer token arrived after roughly three minutes and 33 seconds; completing the response took another 41 seconds.
For an occasional background document summary, that may be acceptable. For a fluid conversation, it is a substantial interruption. This model is less a chatty assistant than a paperwork clerk who asks you to take a number.
Local inference changes the privacy boundary
Singh made the service accessible across the home network, keeping the laptop connected by Ethernet and adding browser shortcuts to household phones. llama.cpp’s server provides a web interface and multimodal support, which supports the general browser-accessible deployment approach.
The attraction is straightforward: document questions can be processed on household hardware instead of being submitted to an external inference service.
But local is not synonymous with secure. Singh’s account does not establish authentication, transport encryption, firewall restrictions, document retention, or whether access was confined to the LAN. Those remain unanswered deployment questions—not protections readers should assume.
For anyone adapting the idea, the sensible priorities are restricting access, understanding what gets stored, protecting the host, and testing with nonsensitive documents first. Those are deployment recommendations, not claims about safeguards Singh implemented.
The same caution applies to answers. Given the model’s reported limitations, summaries of medical, financial, insurance, or contractual material should be checked against the original document, not treated as professional advice.
A useful division of labor—not a universal upgrade
The strongest takeaway is not that every retired gaming laptop should become a document-AI server. It is that an explicitly selected secondary graphics processor can take on an occasional workload without assigning it to the GPU already doing the household’s heavier jobs.
Singh’s experiment accepts minutes of latency in exchange for local processing and a different division of labor. That is a defensible trade-off for infrequent, carefully checked summaries. It is not evidence of cloud-level intelligence, guaranteed security, or unchanged performance elsewhere on the laptop.
Sometimes a successful PC project does not win a benchmark. It simply gives an otherwise overlooked component something worthwhile to do.