#macOS #iOS #Tools #GitHub情报 #GFW

🧩 Surge 周边工具合集：从配置、订阅到家庭网关

Surge 本身已经是一个完成度很高的代理客户端，但对于玩家来说，往往不只是在客户端里切个节点这么简单：规则和模块越攒越多，多端 Profile 怎么同步，订阅和自建节点怎么整理，电视和游戏机又怎么接入，最后都会变成另一套需要维护的系统。这些项目有的已经陪我用了多年，也有的才刚起步；从配置生成、订阅管理、图形管理，到局域网网关、格式转换、模块维护和移动端订阅管理，刚好把这些空隙补得七七八八。

1️⃣ Surgio

🔗：GitHub | Docs

Surgio 是本次合集里资历最老、也最像“配置即代码”的一个。第一行代码提交于 2019 年 8 月 20 日，至今已接近七年；MIT 协议开源，GitHub 有 1.8k 星，2026 年 5 月还在更新。它是运行在 macOS、Linux 或 WSL 上的 Node.js 命令行工具：把机场订阅或自建节点当作 Provider，把 Surge 配置模板当作 Template，最后按 Artifact 定义生成不同客户端可直接使用的配置，还能一并上传到自己的存储。

Surgio 最早就是为 Surge 而生，后来也支持 Clash、Quantumult X、Loon、Stash 和 sing-box 等。它的优势不是“点一下就能用”，而是能把配置放进 Git，按模板稳定生成多份 Profile，再交给定时任务或 CI 自动更新。代价也很直白：需要写 JavaScript 配置和模板，先把 Provider、Template、Artifact 这套概念理顺。如果你已经维护着一套复杂配置仓库，Surgio 依然是七个里最成熟、最可控的方案。我非常喜欢 Surgio 这个项目，也算是使用 5 年的老用户了。

2️⃣ Sub-Store

🔗：GitHub | 官方前端

如果 Surgio 是「把配置当代码写」，Sub-Store 就是这件事最流行的图形化版本。它从 2020 年开始发展，现有近 1 万 GitHub Star，支持 Surge、Loon、Quantumult X、Stash、Egern、Shadowrocket 和 sing-box 等多种客户端。最常见的用法是把几家机场订阅和自建节点收进同一个面板，按地区、协议和名称过滤、重命名、排序或用脚本处理，最后生成一个给 Surge 使用的订阅地址。

Sub-Store 可以把多份订阅合成一个链接、托管和修改订阅或文件，也能将不同客户端格式互相转换。对于不想维护 Surgio 模板和自动化、但又想让多机场节点进入同一套策略组的用户，Sub-Store 基本是最成熟的选择。需要注意的是，订阅链接本身往往带有敏感信息；无论用官方前端、Surge 模块还是自部署实例，都应确认实际请求经过的是自己信任的服务。

3️⃣ Surge Shallow

🔗：GitHub

如果说 Surgio 是给习惯写代码的人准备的，Surge Shallow 就是把这套事情收进一个 macOS 原生界面。它是最近刚开源的 SwiftUI 工具，目前为 macOS 26 准备；可以导入已有的 Surge .conf / `.dconf`，集中管理 Ruleset、模块、Proxy、Proxy Group 和 macOS / iOS / iPadOS 之间的差异，检查无误后直接写入 Surge 的 iCloud 目录。

Surge Shallow 目前没有 Surgio 那种自动化和跨客户端野心，但对于不想长期手改大段配置、又不想维护 Node.js 工程的人，反而是更舒服的中间层。

4️⃣ OpenSurge for Mac

🔗：GitHub

名字容易让人误会，它并不是 Surge 的插件或兼容客户端，而是一个受 Surge 网关模式启发、基于 mihomo 的 macOS 项目。OpenSurge for Mac 可以把一台 Mac 变成局域网网关，手机、电视、游戏机、VR 设备可以按设备走不同出口；既能只手动让指定设备接入，也能通过 DHCP / DNS 接管让一段网络自动使用它。它明显不是普通用户“装完就忘”的代理客户端，更适合有常开 Mac、了解家庭网络拓扑、又不想单独买软路由的人。

5️⃣ Script-Hub

🔗：Web | GitHub

Script-Hub 不管理节点和订阅，专门把不同客户端的重写、模块、插件和规则集互相转换：QX 重写、Surge 模块、Loon 插件和规则集可以转换成 Surge / Egern 模块、Stash 覆写、Shadowrocket 模块或 Loon 插件。

它本身可以作为 Surge 模块安装，随后在浏览器打开 script.hub 操作。遇到一个只有 QX 或 Loon 格式的模块可以转换后直接导入。它也支持本地文本的纯前端转换；但若要读取远程资源、处理需要脚本转换的内容，仍需留意代理、MITM 和脚本权限。Script-Hub 是格式兼容层，Surge Relay 则是在这个兼容层之上继续解决模块的长期维护问题。

6️⃣ Surge Relay

🔗：GitHub

Surge Relay 是七个里和 Surge 最直接的一款，专门管理 Surge 模块。对于经常用 Script-Hub 把 Loon、Quantumult X 等格式转换成 .sgmodule 的人。它把模块来源和备用地址集中在一台 Mac 上管理，调用本地 Script-Hub 转换逻辑生成稳定的 `.sgmodule`，再发布到 GitHub 或 iCloud Drive。模块还能统一编辑、删除、汇总，按需要屏蔽 MITM hostname、禁用部分 Script 或 Rewrite；也提供 Web 端远程管理，并可配合 Surge Ponte 从其他设备操作。它更像是给模块重度用户准备的“发布流水线”，而不是另一个配置编辑器。

7️⃣ 塔台

🔗：TestFlight | 开发者说明

这是七个里最早期、也最轻的一款，也是一个 Vibe Coding 项目。目前只在 iOS TestFlight 测试，开发者的说法是：在 iPhone 上本地管理机场订阅和自建节点，再转换为不同客户端所需的配置；数据不上传服务器，项目也宣称开源。截图里能看到订阅、规则、导入几个入口，以及按地区查看节点的界面。

它和 Surge 的关系没有前两个直接，公开资料目前也没有列出所有导出格式。但“订阅收集、节点整理、再导出配置”本来就是很多 Surge 用户的前置工作；如果它能稳定发展，本地优先的移动端管理会是一个很有意思的补位。现阶段更适合愿意试 TestFlight、也愿意接受功能变化的人。

👀 七个项目放在一起看，Surge 的周边需求其实已经分成了几条完全不同的路线：Surgio 适合把配置当工程维护、需要自动生成和部署的人；Sub-Store 适合管理、合并和转换多份订阅；Surge Shallow 适合重度使用 Surge 但希望图形化管理的人；OpenSurge 是家庭网络方案，不应当当作 Surge 替代品；Script-Hub 负责跨客户端格式转换；Surge Relay 适合长期维护模块来源的人；塔台则仍在验证移动端本地订阅管理这件事。

有意思的是，最成熟的 Surgio 依然是命令行工具，新项目却都在把配置、网关或订阅做成更直观的 App。Surge 的本体当然还是整个工作流的核心，但围绕它长出来的这些工具，正在把“代理配置”从一份文件变成可以长期维护的一套系统。

频道：@NewlearnerChannel

#Mac #AI #GitHub情报

🐥 TurboFieldfare：用 2 GB 内存在任意 M 系列 Mac 上运行 Gemma 4 26B

一套纯 Swift + Metal 自研推理引擎，把 14.3 GB 的 MoE 大模型装进约 2 GB 内存，让 8 GB 的 MacBook Air 也能本地跑 26B 模型

✨ 特点

- 2 GB 内存跑 26B 模型：利用 Gemma 4 26B-A4B 的混合专家架构，每个 token 只激活约 3.88B 参数，常驻内存仅保留共享核心与 KV 缓存，其余专家权重按需从 SSD 流式读取。
- 不是 MLX 或 llama.cpp 的封装，针对 Gemma 4 的层结构从零编写的运行时，自研全部 Metal kernel（量化 GEMV、注意力、MoE、采样与融合算子）
- 同一份 .gturbo 模型可供原生 Mac 应用、命令行工具和本地 OpenAI 兼容服务器三种方式使用，服务器支持流式输出、函数工具调用和提示词前缀复用
- 从 Hugging Face 按字节区间边下边重打包，全程不落完整源文件，约 15 GB 传输量直接生成带哈希校验的本地模型
- 可选视觉扩展包：额外安装 1.1 GB 的视觉塔即可让应用、命令行和服务器统一支持图片输入（需 M2 及以上）
- 103 个公开实验记录：仓库完整记录了 kernel、缓存、I/O、预填充等方向上成功与失败的全部实验

⚙️ 机制

TurboFieldfare 的核心思路是「让不该进内存的权重留在 SSD 上」。运行时常驻约 1.35 GB 共享核心（注意力、路由器、词嵌入和共享专家）加 FP16 KV 缓存（4K 上下文约 305 MiB）；每层 128 个路由专家（共 30 层、约 12.9 GB）留在磁盘，由路由器每 token 选出 top-8，先查询该层 16 槽 LFU 缓存，未命中的用有界并行 pread 读入 Metal 可见缓冲区，同时 GPU 并行计算常驻的共享专家分支，I/O 与计算相互掩盖。预填充按最多 128 token 分块，让一次读取的专家服务多行计算。作者实测显式 pread 比 mmap 被动缺页快得多：冷读单个 3.36 MB 专家 2.8 ms 对 10 ms，整体吞吐 4 tok/s 对 0.5 tok/s；约 41% 的专家会在下一个 token 复用，16 槽缓存命中率约 67%。

主要依赖：仅 3 个外部包。swift-transformers（分词）、swift-nio（服务器）、SwiftMath（公式渲染），其余全部自研。

实测性能：8 GB M2 MacBook Air 解码 5.1–6.3 tok/s，24 GB M5 Pro 达 31–35 tok/s（同机 mlx-lm 为 76–82 tok/s，但需要 8–10 GB 常驻内存与约 15 GB GPU 分配）。差距主要来自 M5 三倍于 M4 的 SSD 读取带宽。运行要求 macOS 26、Metal 4、Swift 6.2，仅支持 Apple Silicon。

👨🏻‍💻 使用场景

- 8 GB 入门款 Mac 用户跑大模型：最便宜的 M2 MacBook Air 也能本地运行 26B 级模型做草稿撰写、摘要和问答，不用为了本地推理专门升级 32 GB 以上的机器
- 开发者接入本地 OpenAI 接口：服务器监听本机 8080 端口，把 OpenCode 或任意 OpenAI SDK 的 base URL 指过来，即可零 API 成本地调试提示词、函数工具调用等流程
- 保护隐私的离线办公：模型装好后完全离线运行，处理合同、病历、内部文档等敏感材料时数据不出本机
- 端侧推理工程学习：实验记录加系统设计文档完整展示了 mmap 与 pread 的取舍、专家缓存策略、I/O 与 GPU 重叠等决策过程，适合想学 Metal 推理优化的工程师
- 多任务并行的轻量后台:推理只占 2 GB 内存，可以边开着浏览器、IDE 和设计软件边让模型在后台生成，不会挤爆内存

🖊 作者背景
Andrey Mikhaylov - Senior iOS & Metal 工程师

- Lapse（伦敦社交相机应用，总融资 $42.3M）：资深 iOS、Metal 与相机工程师（2024 至今）。负责月处理约 1 亿资产的媒体管线，自建 Metal 实时照片视频管线，吞吐为原 Core Image 方案 10 倍
- Prisma Labs（Prisma、Lensa 开发商）：资深 iOS 与 Metal 工程师、视频团队技术负责人（2021–2024）。构建端侧实时人脸修饰管线，老设备上 17 ms/帧

项目名取自他最喜欢的鸟，田鸫（fieldfare）。

频道:@NewlearnerChannel