shubham0204
Demonstrations show it running DeepSeek and some graphics-intensive games. The GPU being shared over WiFi is an RTX 5090.
I wanted to dig deep into how WiFi as a protocol can be used for communicating with the GPU. In a normal situation, the GPU will communicate via PCIe with the CPU of the host computer, ensuring high-bandwidth data transfers. I found the following lines in a blog that WiCi has shared:
> So WiCi keeps the local-GPU contract while shrinking what actually crosses the link: cache stable facts, deduplicate repeated payloads, compress or stream large transfers, pipeline independent work, keep expensive state resident, and preserve true dependencies exactly.
What I feel is that WiCi has introduced an intermediate layer between the host and the GPU that facilitates communication. The commands intended for the GPU are first encoded in some intermediate language, passed through the network, and decoded back within the WiCi remote GPU (the external box holding the 5090) into commands that the CUDA driver understands.
WiCi does not seem to replace the physical PCIe protocol with IEEE 802.11 (WiFi) protocol over the physical medium. This is my assumption and I am not sure about it.
But if this product proves what it claims, then this would be a huge deal in my opinion. A shared GPU that different devices can use would be great for local LLMs.
Show HN: SmolChat – Running any GGUF SLMs locally, on-device in Android
Show HN: Android-Document-QA: On-Device RAG with Mediapipe and ObjectBox
https://github.com/shubham0204/Android-Document-QA
A simple Android app that allows the user to add a PDF/DOCX document and ask natural-language questions whose answers are generated by the means of an LLM.Currently, it uses the following tech-stack for multiple operations:1. Apache POI and iTextPDF for parsing DOCX and PDF documents2. ObjectBox for on-device vector-store and NoSQL database3. Mediapipe Text Embedding for generating on-device...