How to use local Qwen remotely from any device

A 27B model does not have to run on the device in a person's hands. Qwen can remain on one GPU host while an approved phone, tablet, laptop or office computer connects to a private interface. The user device needs a browser or compatible client. Identity, a narrow network path and a gateway in front of the model server matter most.

“Any device” means a device the company has admitted. It does not mean publishing the model port to the whole internet.

One model, three client types

approved device
  |
  +-- phone / tablet / browser
  +-- laptop / IDE / API client
  +-- automation / service identity
  |
access gateway
  |
model API -> GPU host

A browser is the practical route for phones, tablets and ordinary computers. The user does not install a coding tool. They sign in to a company interface, select permitted sources and see citations or task history. That interface needs authentication, per-user sessions, limits and operation logs.

A coding client has broader reach. Qwen Code can read a repository and run local tools, so it belongs on a developer device under the relevant policy. Server automation receives its own identity and limits; it should not borrow a person's key.

What we actually tested

In the retained evaluation, Qwen Code ran on a MacBook while the model ran on a home PC with an RTX 3090. The client read a local repository copy and sent the prompt plus required tool results over HTTP on trusted home LAN, authenticated with an API key, to the selected vLLM profile on port 18020. The service had one inference slot.

We did not test task quality on a phone or concurrent multi-user service. Browser access, a private overlay network and per-user identities are a deployment pattern that still needs checks on the target devices. The MacBook run proves separation between client and GPU; it is not a benchmark of the complete remote architecture.

Route 1. A web interface on the private network

A phone or tablet does not need the raw API. It needs a small web application that accepts the question, authenticates the user, attaches permitted sources and only then calls Qwen over localhost or a protected server network.

HTTPS + company sign-in
          |
 web interface / application gateway
          |
  http://127.0.0.1:18020/v1

With Tailscale, approved devices can reach the application through Tailscale Serve. Its documentation distinguishes private Serve from public Funnel. This pattern uses a private route; the raw model endpoint does not go through Funnel.

An example for an interface listening locally on port 3000, with values to replace:

tailscale serve --https=443 http://127.0.0.1:3000
tailscale serve status

HTTPS alone does not provide application authorization. The gateway still needs to know who is asking, which documents they may reach, how many tasks they may start and where the audit record belongs.

Route 2. A private network for apps and clients

When a user has Qwen Code, a desktop application or an approved mobile client, their device can join a private overlay network. Tailscale publishes clients for platforms including Windows, macOS, Linux, iOS, Android and ChromeOS.

Access should name a specific group, service and port. Current Tailscale Grants describe source, destination and allowed capabilities under a deny-by-default model. A company should add device approval, posture requirements, lost-phone revocation and periodic policy review.

On a fixed office network, a private address, firewall and rule for a selected subnet can provide a similar boundary. Keep the guest network outside it. A 192.168 address does not establish trust by itself.

Route 3. An SSH tunnel for one engineer

SSH is a useful fallback for a laptop with a terminal. It is a poor daily interface for a phone, tablet or larger group. A port forward can look like this:

ssh -N \
  -L 18020:127.0.0.1:18020 \
  gpu-user@gpu-host.example

The client then calls http://127.0.0.1:18020/v1. Host-key verification and a restricted SSH account are part of the setup. The API key remains a second boundary, and a broken tunnel must stop the task without a risky automatic replay. Replace the port when using another server profile.

Name the secret and the data flow

Do not put a key in a repository, a file synchronized to a personal cloud account or mobile application code. One person may use a mode-0600 user file. A company needs a secret store, rotation and identity assigned to each user or service.

A file opened on a laptop can remain on that laptop, while the content Qwen needs crosses to the GPU workstation. A phone attachment also reaches the gateway, parser, logs or cache according to the application design. A local model removes one external provider from the route. It does not eliminate the data flow.

Seven checks before handover

1. New device: without approval it cannot see the interface or port.
2. Lost phone: device revocation ends active sessions and blocks new ones.
3. Wrong role: the user cannot retrieve a source outside their scope.
4. Missing key: the API refuses the request.
5. Second user: queueing, a limit or refusal is visible.
6. Broken connection: the client does not repeat a side-effecting action.
7. GPU restart: the interface reports failure and a synthetic test confirms recovery.

Run the checks on at least one phone, one computer away from the office and a device that deliberately fails policy. Only then does “works from any device” describe tested scope.

Where self-service stops

One person can set up a private tunnel and client. A company also needs an interface, sign-in, roles, limits, observability, a lost-device procedure and a named service owner. One GPU adds queueing because the measured home profile had one active slot.

Syntalith designs the route from user device to model: web interface, private network, API gateway, data policy, load measurement, monitoring and administrator handover. An AI process audit fixes the architecture and scope. Book a free process scan to decide which devices and data should receive access.