🔥承渊政道：个人主页
❄️个人专栏: 《C语言基础语法知识》 《数据结构与算法》 《C++知识内容》 《Linux系统知识》 《算法刷题指南》 《测评文章活动推广》 《大模型语言路线学习》 《MySQL数据库学习》 《Python知识内容》 《cpolar知识学习》
✨逆境不吐心中苦,顺境不忘来时路!✨
🎬 博主简介:
我手里的 AI 接口越多,反而越容易产生一种很烦的感觉：**明明模型越来越多,真正调用起来却越来越乱.**本地有Ollama,云端又可能有DeepSeek、通义千问或者别的API.每换一个客户端,就重新填一次 Base URL、模型名和密钥;想把本地模型给别的应用用,还得先想“这个接口到底怎么接”.我对这种状态有点受不了.不是因为配置有多难,而是因为同一件事重复做太多次.接口地址应该统一,令牌应该统一发,模型应该在一个地方管理. 原文里的这套 New-API 方案正好就是从这个痛点出发,而且它有一个很真实的折腾底色：拿一台已经刷了ARM 版飞牛 NAS 的 N1 盒子继续榨价值,再把 Windows 上正在运行的Ollama接进去.更有意思的是,原文不是“页面打开就算成功”,而是一路做了很多验证：N1 部署 New-API → 初始化后台 → Windows 安装 Ollama → qwen3.5:0.8b 本地对话 → /v1/chat/completions API 测试 → New-API 添加 Ollama 渠道 → 创建令牌 → 再用 New-API 的 3000 端口调用 → 最后通过cpolar把 New-API 带到公网. 这篇我会保留这个人的性格：喜欢把旧硬件继续榨干,也有一点“接口洁癖”——零散东西可以多,但对外最好只留一个入口;每接一层,都要亲手发一次请求确认.
目录
- 1.New-API解决的不是“模型不够”,而是“入口太多”
- 2.先把New-API装到N1飞牛NAS上
- 3.初始化New-API：先把网关本身准备好
- 4.Windows上准备一个真正能回答问题的Ollama
-
- 4.1安装Ollama
- 4.2下载 `qwen3.5:0.8b`
- 5.再测一次Ollama API：我不想把“能聊天”当成“接口能用”
- 6.把Ollama接进New-API
- 7.创建New-API令牌：统一入口还得配统一鉴权
-
- 原来
- 现在
- 8.本地接口统一以后,最后一个问题才是：外面能不能调
- 9.安装cpolar
- 10.先把New-API的 `3000` 端口映射出去
- 11.随机地址能用以后,再换固定二级子域名
- 12.总结
1.New-API解决的不是“模型不够”,而是“入口太多”
按照原文定位,New-API 是从 One API 延伸出来的大模型接口聚合与管理系统.
它想解决的核心问题很明确：
- 下层可以接不同的大模型服务;
- 本地 Ollama 也可以作为渠道接入;
- 上层尽量统一成 OpenAI API 形式;
- 令牌、用户和调用记录集中管理.
原文还列出了异构接口转换、Token 额度与权限、高可用路由、日志与资产监控等能力.
不过这篇正文真正逐项跑通的是：
Ollama 渠道接入、模型识别、令牌创建、OpenAI 格式请求以及公网访问.
所以这一版不会把权重轮询、故障重试、并发限制等功能写成本文已经完整验证.
对我来说,这套东西最大的变化不是“又装了一个 AI 工具”,而是：
以前是每个应用自己去找模型;现在变成应用先找 New-API,再由 New-API 去找模型.
这个入口一旦统一,后面的管理才有意义.
2.先把New-API装到N1飞牛NAS上
原文用的折腾主机是N1盒子,而且已经刷入ARM版本飞牛NAS.
这个人物设定其实源文自己就很鲜明：旧设备能继续用,就不轻易让它吃灰.
先打开飞牛NAS的Docker,确保Docker服务已经启动.
然后进入系统设置开启 SSH.
电脑按下 Win + X,打开【终端（管理员）】PowerShell.
通过 SSH 连接飞牛 NAS.
原文命令保持不变：
# 其中，n1为你的飞牛Nas用户名，IP地址为你的飞牛IP地址
ssh n1@192.168.50.228
连接成功后切换 root：
sudo -i
接着下载 New-API 一键部署脚本：
curl -L https://gitee.com/jun-wan/script/raw/master/new_api_deploy/deploy_sqlite.sh -o deploy_sqlite.sh && ls
授权并执行：
chmod +x deploy_sqlite.sh && bash deploy_sqlite.sh
脚本首先会让你选择安装位置.
原文因为N1外接了扩展硬盘,所以选择了：
2
将 New-API 安装在外置硬盘.
脚本执行完成后,原文显示部署成功.
这里我会先停一下.
旧 N1 能不能承担 New-API,不需要先猜性能,最直接的判断就是：脚本能不能部署完,Web 页面能不能正常打开.
原文这一层已经验证成功.
3.初始化New-API：先把网关本身准备好
第一次访问 New-API,需要先做初始化.
数据库检查页面点击【下一步】。
创建管理员账号和密码.
接着选择使用模式.
原文这里选择的是：
自用模式
然后点击【初始化系统】.
初始化完成后进入主页面.
如果没有自动登录,就点击右上角【登录】,使用刚才设置的管理员账号和密码进入后台.
到这里,New-API 只是“网关本身装好了”.
我不会在这里就说“本地模型已经统一管理”,因为它还没接到任何真实 Ollama.
下一步才是关键.
4.Windows上准备一个真正能回答问题的Ollama
原文专门补了一段 Ollama 安装过程.
如果已经有本地 AI 服务,这一节可以跳过;但原文为了完整验证,还是从 Windows 上重新装了一遍.
4.1安装Ollama
重新打开 PowerShell,执行：
irm https://ollama.com/install.ps1 | iex
然后查看版本：
ollama –version
Ollama 能正常返回版本信息,这一层成立.
4.2下载 qwen3.5:0.8b
原文先给出了 Ollama 模型搜索地址：
https://ollama.com/search
本次选择的是：
qwen3.5:0.8b
原文说明它大约 1G 左右,用来做测试.
下载并运行：
ollama run qwen3.5:0.8b
随后输入：
你好
原文实际进行了本地对话测试.
这里有一段很具体的个人实测信息,我保留它,因为它正好让这篇不像纯说明书：
原文作者当时使用的是 3060ti,并记录这次回答基本在 3 秒左右输出完成.
这个数字只代表原文这套设备和这次测试,不扩展成通用性能结论.
对话测试完成后退出：
/bye
到这里,我们已经确认：
模型不是只“下载了”,而是真的能回答.
5.再测一次Ollama API：我不想把“能聊天”当成“接口能用”
这一步很符合我喜欢的验证方式.
命令行对话成功,只能说明模型运行正常;New-API 接下来要对接的是 API,所以还需要单独测 API.
原文写 Ollama 支持 OpenAI 兼容的：
/v1/chat/completions
PowerShell 测试命令如下：
Invoke-RestMethod -Method Post -Uri "http://localhost:11434/v1/chat/completions" -ContentType "application/json" -Body '{"model": "qwen3.5:0.8b", "messages": [{"role": "user", "content": "hi"}], "stream": false}'
如果是在 CMD,则使用：
curl http://localhost:11434/v1/chat/completions -H "Content-Type: application/json" -d "{\\"model\\": \\"qwen3.5:0.8b\\", \\"messages\\": [{\\"role\\": \\"user\\", \\"content\\": \\"你好\\"}], \\"stream\\": false}"
原文确认 API 请求成功.
这里有一个源文细节：原文正文写“端口默认为”,但后面没有把数字接上;实际两条测试命令都使用了：
11434
这一版不会帮源文偷偷补写成“默认端口就是 11434”,只保留真实命令里已经出现的值.
现在才可以进入下一步：
让 N1 上的 New-API 真正去找到 Windows 上的 Ollama.
6.把Ollama接进New-API
登录 New-API 后台,进入【渠道管理 → 添加渠道】.
原文配置方式是：
- 类型：Ollama
- 名称：自定义
- 密钥：随机填写一个
- API 地址：填写 Windows 当前局域网 IP
原文说明 Ollama 默认不需要密钥连接,所以这里只按源文方式填写.
如果不知道 Windows 局域网地址,可以执行：
ipconfig | findstr "IPv4"
填写地址后,点击获取模型列表.
如果配置正确,New-API 会列出刚才本地 Ollama 中的模型.
原文选择：
qwen3.5:0.8b
然后提交渠道.
提交以后继续点测试.
出现测试成功提示,才说明：
N1 上的 New-API 已经能访问 Windows 上的 Ollama.
这一步很关键.
因为从这里开始,系统关系已经发生变化：
客户端不必直接找 Ollama,New-API 可以作为中间入口.
原文还展示了其他局域网 AI 服务也可以继续接入.
之后在模型广场中可以看到多台本地 AI 服务的模型.
这就是我说的“接口洁癖”真正开始舒服的地方：后端模型可以越来越多,但前面的管理入口别跟着一起变多.
7.创建New-API令牌：统一入口还得配统一鉴权
接下来进入【令牌管理】,点击【添加令牌】.
填写相关信息后提交.
创建完成后复制令牌.
然后原文没有只在页面里看一眼,而是直接用 CMD 请求 N1 上的 New-API.
下面代码块包含源文原始示例令牌和地址,本版按“技术内容不擅自改动”的规则原样保留：
# 修改其中的192.168.50.228为你的N1飞牛Nas地址，以及sk-xxxxxxx
curl http://192.168.50.228:3000/v1/chat/completions ^
-H "Content-Type: application/json" ^
-H "Authorization: Bearer sk-MbmNWNXhaGrNlZRe6r1ZxEOoROiE5HpIfU6zL8353FJ4msZO" ^
-d "{\\"model\\": \\"qwen3.5:0.8b\\", \\"messages\\": [{\\"role\\": \\"user\\", \\"content\\": \\"你好\\"}], \\"stream\\": false}"
请求成功.
到这里才真正完成了一个非常清楚的前后对比.
原来
下游客户端直接面对：
Ollama 地址 + Ollama 模型
现在
下游客户端面对： New-API 地址 + New-API Token + OpenAI 格式接口
New-API 再去决定请求落到哪个后端模型.
所以我不会把这一步写成“秒变云端 AI”.
更准确的说法是：
局域网里的 Ollama 已经被 New-API 包在统一入口之后,并且通过 New-API Token 完成了一次实际 API 调用.
8.本地接口统一以后,最后一个问题才是：外面能不能调
到这里,局域网链已经完整了：
Windows Ollama → N1 New-API → Token → API 请求成功.
问题只剩一个：
New-API 地址还是：
192.168.50.228:3000
离开家里的局域网以后,这个地址不能直接使用.
原文给了两个很明确的情景：
- 上下班路上继续使用家里的算力;
- 把 Token 给异地朋友调用.
这些属于源文明确提出的使用场景,但没有写成已经真实发生过的个人故事,所以这里仍然保持为情景化描述.
如果真要把这套接口交给外部应用,真正需要扩出去的是：
New-API 的 3000 端口.
不是 Ollama 的 11434.
这也是整篇职责边界最重要的一点.
9.安装cpolar
原文先介绍 cpolar 用于把局域网服务映射到公网.
然后写“回到刚才的 PowerShell 终端窗口”执行以下安装命令.
这句话的环境表述按源文保留,命令本身也不修改：
sudo curl https://get.cpolar.sh | sh
安装后查看服务状态：
sudo systemctl status cpolar
接着注册 cpolar 账号.
然后通过飞牛 NAS IP + 9200 进入 Web UI.
原文地址：
http://192.168.50.228:9200/
使用 cpolar 账号登录.
到这里,cpolar 本身已经可管理.
10.先把New-API的 3000 端口映射出去
原文进入【隧道管理 → 隧道列表】后,页面默认有两条隧道：
- ssh：指向 22,TCP
- website：指向 8080,HTTP
原文还说明 HTTP 隧道会生成 http 与 https 两个公网地址.
随后新建隧道.
关键值是：
本地地址：3000
创建完成后进入在线隧道列表.
原文以 https 地址做访问测试,并提醒加载稍慢,需要等待.
页面成功加载.
这一步我只下一个结论：
New-API Web 页面已经能通过公网地址打开.
源文进一步描述可以在外部调用 Token,但这一节没有再次提供一条公网 /v1/chat/completions 请求做 API 级验证,所以新版不会把“公网 API 调用已完成”写成和局域网 curl 同等级别的实测结论.
这是这篇需要保持的一个边界.
11.随机地址能用以后,再换固定二级子域名
原文说明随机域名大约每：
24 小时
会重置一次。
如果只是测试,随机地址没什么问题;如果 API 已经写进客户端、机器人或工作流里,地址变化就会比较麻烦.
这才是固定地址真正有意义的地方.
进入 cpolar 预留页面：
https://dashboard.cpolar.com/reserved
原文示例保留结果为：
- 地区：China TOP
- 二级域名：newapi01
列表中显示了一条已保留的二级子域名记录：
原文同时提醒,每个账号的二级域名不同,以自己实际保留为准.
接着进入隧道列表,找到：
newapi
点击编辑,把域名类型改为二级子域名,并填写前面保留好的地址。
更新以后,在在线隧道列表中看到 newapi 地址切换成固定二级子域名形式.
最后再使用 https 访问.
访问成功.
原文最后还给了一个小提示：
首页显示的网站地址,可以在【系统设置】>【服务器地址】中修改.
12.总结
这篇看起来是在“部署 New-API”,但真正完整跑通的是一条很有层次的 AI 接口链：
Windows Ollama → N1 飞牛 New-API → New-API Token → 局域网 OpenAI 格式调用 → cpolar → 固定公网入口.
原文实际完成了：
- N1 盒子运行 ARM 版飞牛 NAS;
- 开启 Docker;
- 开启 SSH;
- ssh n1@192.168.50.228;
- sudo -i;
- 下载 deploy_sqlite.sh;
- 选择外置硬盘安装;
- New-API 页面成功打开;
- 初始化管理员账号;
- 选择“自用模式”;
- Windows 安装 Ollama;
- 使用 qwen3.5:0.8b;
- 原文 3060ti 实测约 3 秒完成一次回答;
- PowerShell / CMD 测试 /v1/chat/completions;
- New-API 添加 Ollama 渠道;
- ipconfig | findstr "IPv4" 获取 Windows 地址;
- New-API 获取到 qwen3.5:0.8b;
- 渠道测试成功;
- 创建 New-API Token;
- 通过 192.168.50.228:3000/v1/chat/completions 实际调用成功;
- 安装cpolar;
- 192.168.50.228:9200 进入管理界面;
- 新建指向 3000 的隧道;
- https 公网页面访问成功;
- 随机域名约 24 小时重置;
- 保留 newapi01;
- 隧道名 newapi;
- 固定二级子域名页面再次访问成功.
这篇人物性格也很鲜明,而且不是靠虚构故事：
旧 N1 不舍得扔,就继续榨;接口太散看着难受,就统一;每接一层,不看到真实请求成功就不算结束.
真实故事感来自原文已经存在的操作：
N1 部署 → Windows Ollama 对话 → 3060ti 约 3 秒出结果 → 单独测 API → New-API 渠道测试 → Token curl 再测.
所以这篇不用再硬编“某天朋友突然找我要接口”.
原文中“5 分钟部署”“高可用多模型云枢纽”“商业级稳定性”“全世界任意角落自由调度算力”等表达比较大,而正文没有对部署总耗时、高可用故障切换、公网 API 长期稳定性做完整测试.
因此新版把结论收回到实际证据：
New-API 已经把本地 Ollama 收进统一的 Token + OpenAI 格式入口；公网侧则完成了 New-API 页面和固定地址的访问验证.
对我来说,这已经比“把本地模型变成云模型”更有价值.
因为真正舒服的变化是：以后模型可以继续加,但下游应用不用跟着一个个重新改入口.
🚀真正的勇者不是流泪的人,而是含泪奔跑的人!
敬请期待下一篇文章内容
每日心灵鸡汤: 你以为你在活自己,其实只是活在别人的框架里!
绝大多数中国人一辈子都活在别人的框架里.一个从小被父母、学校、单位和社会不断规定“应该怎样活”的人,很难形成真正属于自己的判断,于是只能依赖外部叙事、群体共识和多数人的选择获得安全感.也正因为如此,他往往会试图控制别人:别人必须和自己一样,必须认可同样的价值、走同样的路、遵守同样的规则,因为一旦别人活出了另一种可能,就等于在动摇他赖以维持安全感的那套世界.他不是单纯想控制别人,而是在通过控制别人,证明自己接受的那套叙事是对的.更深一层,很多所谓“群体共识”本身也不是自然形成的,而是被掌握资源、权力和利益的人不断设计、强化和传播的:什么叫成功,什么叫体面,什么叫稳定,什么值得追求,往往都服务于某种既有秩序.于是人一边被控制,一边又替这套秩序去控制别人,最后甚至分不清哪些欲望真正属于自己.可人生本来就有很多种活法:可以努力,也可以无聊;可以工作,也可以发呆;可以追求成功,也可以旅行、独处、停下来;可以去发现,也可以去创造.真正找到自己,是不再需要靠群体的认可证明自己,也不再要求别人按照同一种方式活.
