The things people ask first.

Those are model runners, and both can serve an OpenAI-compatible endpoint that more than one application points at. The difference CIU is making is what gets loaded. NF4DQ packs a 27B model into 13.23 GiB against 17.66 GiB for the usual 4-bit format, so a model that did not previously fit on a 16 or 24 GB card now does, with room left for context. CIU also works out what your machine can run before it downloads anything. If you already have a setup you are happy with, the format is the reason to look, not the server.

Only the model download. Inference runs locally and the API binds to 127.0.0.1, so it is not reachable from your network unless you deliberately change that.

NF4DQ is registered as ggml type 43, which does not exist upstream. A stock llama.cpp build will not load these GGUFs correctly. The fork is public and the installer handles it for you.

Prompt processing. NF4DQ has no tile loader yet, so prefill takes a fallback path and runs at roughly half the speed of Q4_K_M. Generation is about 25 percent faster. Long prompts with short answers are the case where this format is the wrong choice.

Not usefully. There is no Vulkan kernel yet, so those cards fall back to a CPU path that runs at well under one token per second.

Yes. Build the fork and load the GGUFs in llama.cpp directly. CIU exists to make that a single command and to keep one model resident for everything else on the machine.