一、从一个真实的痛点说起

大模型的算力，往往集中在一台主力机上——比如一台大内存的 Mac。它跑得动 30B 的模型，而你的笔记本、平板、手机跑不动。

于是问题来了：人在外面，怎么用上家里那台机器的算力？

不只是大模型。家里的 Mac 通常还跑着一堆有用的服务：代码仓库（Gitea）、博客预览、远程桌面……理想情况下，这些都应该随时随地能访问。

传统做法有三条路，但每条都不太顺手：

方案 痛点
公网 IP + 端口转发 运营商大多不给公网 IP；家庭宽带封端口；暴露公网有安全风险
花生壳 / frp 等内网穿透 需自建或买服务；速度受中继带宽限制；配置繁琐
向日葵 / TeamViewer 只适合远程桌面，访问 Web / SSH / API 不灵活，免费版有限制

Tailscale 给了一条更优雅的路。它基于 WireGuard 做虚拟组网（Mesh VPN）：把不同设备拉进同一个”虚拟局域网”，每台设备拿到一个固定的内网 IP，彼此直连通信——不管隔着几个路由器、在不在同一个城市。

Tailscale 虚拟组网示意

读完你会得到：

  • 一个零配置的远程访问方案（不需要公网 IP、不需要端口转发、不需要备案）
  • 两套远程调用本地大模型的完整实践（LM Studio / llama.cpp）
  • 把本地模型接进 AI 编码工具（harness 模式）的配置与踩坑
  • 若干实测数据和血泪教训

二、安装与登录

macOS 用 Homebrew 一条命令搞定：

1
brew install --cask tailscale

Windows / Android / iOS 从 官网 下载客户端即可。

安装后登录同一账号（Google / GitHub / Microsoft 均可），设备就自动加入同一个虚拟网络了。没有别的步骤——这就是它最大的优点。

三、常用命令

macOS / Linux 上常用命令行操作：

1
2
3
4
tailscale status        # 查看所有设备及在线状态
tailscale ip -4         # 查看本机 Tailscale IP（形如 100.x.x.x）
tailscale up            # 上线（首次可能需要授权）
tailscale ping <设备名>  # 测试到某设备的连通性

tailscale status 的输出类似（以下 IP 均为示例）：

1
2
3
100.64.0.1   dev-macbook       user@  macOS    -
100.64.0.2   win-laptop        user@  windows  active; direct ...
100.64.0.3   phone             user@  ios      offline

为方便下文举例，我们给这三台设备起个名字：

设备 角色 示例 Tailscale IP
dev-macbook Mac 主力机（跑服务的机器） 100.64.0.1
win-laptop Windows 笔记本（访问方） 100.64.0.2
phone 手机 100.64.0.3

这个 100.x.x.x 地址是固定的，跨网络、跨地区都稳定可用，可以直接当内网地址用。

四、实战一：从 Windows 访问 Mac 上的本地服务

最基础的场景。假设 Mac 上跑着几个本地服务（Gitea 在 3000 端口、博客预览在 4123 端口），想让 Windows 也能访问。

1. 确认服务监听在 0.0.0.0

这一步是关键：服务必须监听所有网卡（0.0.0.0），否则只有本机 localhost 能访问。用 lsof 确认：

1
2
lsof -iTCP:3000 -sTCP:LISTEN -P   # Gitea  → 期望 *:3000
lsof -iTCP:4123 -sTCP:LISTEN -P   # Hexo   → 期望 *:4123

一个容易误判的坑：lsof 输出 IPv6 *:3000 不代表只监听 IPv6。这里的 * 是双栈 socket，表示监听所有接口（含 IPv4）。看到 *:PORT 即正常。

好消息是，**Gitea、Hexo 默认就监听在 0.0.0.0**，通常无需改动。

2. 从 Windows 直接访问

Mac（dev-macbook，100.64.0.1）上的服务跑着，在 Windows（win-laptop）浏览器里直接打开：

1
2
http://100.64.0.1:3000    # Windows 访问 Mac 上的 Gitea
http://100.64.0.1:4123    # Windows 访问 Mac 上的 Hexo 博客预览

没有端口转发，没有额外配置。

3. Gitea 的 ROOT_URL 修正（可选）

如果发现 Gitea 的**页面链接、clone 地址都指向 localhost**，那是因为它默认配置了 ROOT_URL=http://localhost:3000/。在 Windows 上 localhost 指 Windows 自己，点链接会失效。

改一下 custom/conf/app.ini 即可：

1
2
3
4
[server]
DOMAIN = 100.64.0.1
ROOT_URL = http://100.64.0.1:3000/
SSH_DOMAIN = 100.64.0.1

重启生效：

1
brew services restart gitea

不改也能用：登录、浏览仓库都正常。只有想让链接和 clone 地址完全可用时才需要改。

五、实战二：远程调用本机的大模型（重点）

这才是 Tailscale 最被低估、也最有价值的用法。

痛点很直接：大模型吃显存/内存，只有一台主力机跑得动。但你可能想在笔记本、手机、平板上——甚至在外面——继续用这台机器的模型。传统做法要么把端口暴露到公网（危险），要么根本连不上。

远程调用本机大模型数据流

Tailscale 的思路很干净：把模型服务的 API 端口暴露在虚拟内网上，任何已加入 Tailnet 的设备都能直接调用，既安全又免配置。

下面三套方案，按上手难度递增。

1. LM Studio（图形界面，最易上手）

LM Studio 可以图形化管理模型，并内置一个 OpenAI 兼容的 API 服务。

1
brew install --cask lm-studio

关键步骤：

  1. 打开 LM Studio，在 Developer / Local Server 页加载一个模型，启动服务
  2. 打开「Serve on Local Network」选项（默认可能只绑 127.0.0.1，开启后才能被其他设备访问）
  3. 服务默认监听 1234 端口，提供 OpenAI 兼容接口：
1
2
3
4
5
# 在 Mac 本机验证（列出可用模型）
curl http://localhost:1234/v1/models

# 在 Windows / 手机等其他设备上（经 Tailscale）调用
curl http://100.64.0.1:1234/v1/models

返回模型列表 JSON 即成功：

1
2
3
4
5
6
7
{
  "data": [
    { "id": "qwen3-coder-next", "object": "model" },
    { "id": "qwen/qwen3.8-27b", "object": "model" },
    { "id": "qwen/qwen3-30b-a3b", "object": "model" }
  ]
}

因为接口路径是 /v1/...，任何支持自定义 OpenAI Base URL 的客户端都能直接用：把 Base URL 填成 http://100.64.0.1:1234/v1，API Key 随意（本地不校验），就能在别的设备上调用这台 Mac 的模型。

2. llama.cpp（命令行，最适合常驻 + 远程）

llama.cpp 是最底层的 GGUF 推理引擎，llama-server 同样提供 OpenAI 兼容接口。相比 LM Studio，它纯命令行、资源占用低，最适合后台常驻和远程调用。

下载预编译版（macOS Apple Silicon）：

1
2
# 从官方 release 下载 llama-bXXXX-bin-macos-arm64.tar.gz，解压到 ~/tools/llama.cpp/
xattr -dr com.apple.quarantine ~/tools/llama.cpp/   # 关键：清除 macOS 隔离属性，否则会被拦截

常用工具：llama-cli（命令行对话）、llama-server（HTTP 服务）、llama-bench（测速）、llama-quantize（量化）。

直接启动（关键是 --host 0.0.0.0，否则无法被 Tailscale 访问）：

1
2
./llama-server -m model.gguf --host 0.0.0.0 --port 8081 \
  -ngl 99 --flash-attn on --ctx-size 32768 --cont-batching -t 8

封装成启动脚本更好用——用别名切换模型、用环境变量控制绑定：

1
2
3
# run-llama.sh 用法示意
HOST=0.0.0.0 API_KEY=llama-local-2026 ./run-llama.sh codernext   # agent 首选模型
HOST=0.0.0.0 API_KEY=llama-local-2026 ./run-llama.sh coder32     # 纯代码补全

HOST 默认 127.0.0.1（仅本机）。**要用 Tailscale 远程访问，必须改成 0.0.0.0**——这是最关键的一步。

其他设备即可调用：

1
2
3
4
5
curl http://100.64.0.1:8081/v1/models
curl http://100.64.0.1:8081/v1/chat/completions \
  -H "Authorization: Bearer llama-local-2026" \
  -H "Content-Type: application/json" \
  -d '{"model":"<模型名>","messages":[{"role":"user","content":"你好"}]}'

实测速度（M2 Max 64GB，Metal 后端）：

模型 架构 量化 输出速度
Qwen3-Coder-Next MoE（80B/A3B） Q3_K_XL 33 t/s
Qwen3-30B-A3B MoE（激活 3B） Q4_K_M 81.4 t/s
Qwen3.8-27B Dense Q4_K_M 15.9 t/s

一条经验：MoE 架构（激活参数少）远快于 Dense。Mac 上的瓶颈常在算力而非内存，优先选 MoE 模型。

3. 接入 Codex / Claude 等 AI 编码工具（harness 模式）

这是”远程本地大模型”最爽的用法：把本地模型接进 AI 编码工具，让它们跑你家里的算力。

本地模型接入 AI 编码工具（harness）

因为 llama-server / LM Studio 都提供 OpenAI 兼容接口，只要工具支持自定义 base_url，把地址指向 Tailscale IP 即可：

1
2
3
4
5
{
  "base_url": "http://100.64.0.1:8081/v1",
  "api_key": "llama-local-2026",
  "model": "<与 /v1/models 返回的模型名完全一致>"
}

几个实测踩出来的坑：

  1. model 字段必须和 /v1/models 返回的完整名精确一致，否则报”模型不存在”。
  2. 跑 agent 场景，模型必须支持原生 tool calling。不是所有”编码很强”的模型都能当 agent 用——有些只会把工具调用输出成普通文本，agent 框架无法解析 → 直接失败。选模型时要专门验证这一点（实测下来，专门的 coding agent 模型如 Qwen3-Coder-Next 表现最好）。
  3. MoE 模型记得关 thinking。例如 Qwen3-30B-A3B 开 thinking 时，思考链会吃光 token 预算，导致空输出，加 --reasoning off 即可。
  4. 同网段优先走局域网 IP。手机与 Mac 在同一 Wi-Fi 时，用 192.168.x.x 直连比走 Tailscale 更快（绕开可能的海外中继）。

4. AI 时代：把本机算力变成”共享基础设施”

放到更大的视角看，这件事的意义不止于”省事”。AI 时代，算力正在成为一种基础设施——而 Tailscale 让它变得像局域网一样随手可用：

  • 一个人，一套模型，全设备协作：家里的 Mac 跑着模型，手机、平板、笔记本、甚至其他机器都能作为客户端接入。模型只下载一份，算力却四处可用。
  • 人 + AI 的协作模式：本地模型接入编码工具后，你不再受限于某一台设备——通勤路上用手机对着本地 agent 提需求，回到家接着让它跑。设备和 AI 助手是解耦的。
  • 数据不出内网的私有 AI：所有推理都在你自己的机器上完成，请求只走 P2P 虚拟内网，没有任何数据发往第三方云端。对代码、文档等敏感内容，这一点尤其重要。
  • 对客户端透明，生态通吃：因为都是 OpenAI 兼容接口，任何支持自定义 Base URL 的工具都能接入，不必为每个客户端单独适配。
  • 比暴露公网安全：端口只存在于虚拟内网，公网扫描不到、无攻击面；比某些内网穿透方案更省心。

一句话：Tailscale 让”把本机算力当成服务来用”变得毫无门槛——这正是个人开发者在 AI 时代最需要的一块拼图。

六、实战三：远程控制桌面（RustDesk / UU 远程）

Tailscale 负责”网络连通”，但如果你需要的是看屏幕、操作鼠标键盘这种完整远程控制，还得配一个远程桌面工具。这里给两条路线。

1. RustDesk（开源，配合 Tailscale 直连）

开源免费的 RustDesk，可以自建中继：

1
brew install --cask rustdesk

RustDesk 本身支持 P2P，但打不通时会走公共中继（慢）。配合 Tailscale 后，两台设备处在同一虚拟内网，RustDesk 直接 P2P 直连，速度快、延迟低，还不用自建中继服务器。

适合：想要开源可控、数据自主，或已在用 Tailscale 组网的场景。

2. UU 远程（网易出品，开箱即用）

如果你只想装上就能用、不折腾组网，UU 远程（网易出品）是这两年很值得推荐的选择：

  • 免费：个人使用基本免费（这也是它快速蹿红的原因）
  • 主打低延迟：面向游戏串流优化，官方定位就是”超低延迟远程串流”，远程办公、远程玩游戏都够用
  • 全平台：Windows / macOS / Android / iOS 等主流平台都有客户端
  • 开箱即用：登录账号、两端配对即可，不需要自己组网或配 P2P

适合：不想折腾、追求简单，或者主要用途是远程玩游戏 / 图形化操作的场景。

3. 什么时候用哪个？

你的需求 推荐
想访问 Web 服务 / SSH / API（不需要图形界面） Tailscale（本文主线）
图形化远程控制，且想开源可控 / 已有 Tailscale 组网 RustDesk + Tailscale
图形化远程控制，只想开箱即用、主打低延迟 UU 远程
远程玩游戏 / 需要高帧率串流 UU 远程

三者并不冲突：Tailscale 是”网络层”的通用方案（Web/SSH/API/大模型都能用），UU 远程 / RustDesk 是”远程桌面”层。完全可以 Tailscale 做内网互联，需要看屏幕时再叠加一个远控工具。

七、踩坑与注意事项

  1. 服务默认只绑 localhost：很多本地服务（各类工具的 API）默认只监听 127.0.0.1，**必须显式改成 0.0.0.0 或开启”局域网访问”**才能被 Tailscale 访问。这是最常见的”连不上”原因，排在第一位。
  2. 双栈 socket 判断：lsof 显示 IPv6 *:PORT 不要误判为仅 IPv6，* = 监听所有接口。
  3. 防火墙：macOS 应用防火墙若开启会挡入站连接，需放行对应程序（或用 socketfilterfw 关闭）。
  4. 登录同一账号：两端设备必须在同一个 Tailscale 账号（同一 Tailnet）下才能互通。
  5. 并非完全匿名：Tailscale 的控制面（协调服务器）仍是中心化的，只是数据面走 P2P。对隐私要求极高的场景可了解 Headscale（开源自建控制面）。
  6. 与局域网 IP 的区别：同网段时用局域网 IP（如 192.168.x.x）也行，但 Tailscale IP 在跨网络、异地、切换 Wi-Fi 时始终稳定，更省心。

八、小结

Tailscale 把”让不同设备互相访问”这件事，从”配置网络”简化成了”装个软件、登录账号”。典型用途：

  • 远程访问家里的开发机 / NAS / 服务
  • 本地开发服务多设备联调
  • 在外调用家里机器上的本地大模型（共享算力）
  • 异地组网、出门在外回连家里的电脑

它几乎是当前最省心的方案。配合 RustDesk / UU 远程、LM Studio 这类工具，一套免费的”远程开发 + 远程算力”工作流就搭起来了。

如果只是想开箱即用地远程看/控制桌面，网易 UU 远程 也是很好的选择；但要访问 Web / SSH / API、或共享本机大模型，Tailscale 才是那个”底座”。

参考资料