构建者聚焦：NodeGhost
构建者聚焦
Acurast隧道和NodeGhost各自的作用，以及二者结合后会发生什么
为产品加入LLM的常见做法，是把兼容OpenAI的客户端指向一个托管API，再把提示词发送到第三方提供商的服务器。模型不属于您，机器也不属于您。而自托管通常也只是把工作负载搬到租来的云GPU上。
这个来自Acurast app-tunnel系列的示例，改为在一部经过证明的智能手机上运行模型。Acurast隧道让这个绑定在本地的模型可以通过公共HTTPS URL访问，而NodeGhost则借助其Bring Your Own Model（自带模型）支持，将其作为可直接替换的兼容OpenAI端点提供服务。两项能力，中间只需一步注册。
这是一次普通的OpenAI调用，而回答它的模型运行在一部手机上。
项目概览
01 /
项目简介
一个量化后的Qwen2.5-3B模型，运行在一台经过证明的Acurast Processor上，并作为普通的兼容OpenAI端点使用。
02 /
实现基础
两项能力：负责可访问性的Acurast隧道，以及提供标准API接口的NodeGhost BYOM网关。一次端点注册即可把二者连接起来。
03 /
状态
一个可运行的参考示例，目前即可部署在Acurast Canary网络上，并坦诚说明3B模型在移动CPU上的吞吐量。
01 / 章节
Acurast隧道的作用
让位于NAT之后的手机上绑定在本地的服务可以从任何地方访问，且无需入站连接。
Acurast Processor位于运营商NAT之后，没有公网IP。默认情况下，在其上绑定到127.0.0.1的服务从外部是不可见的。隧道改变的正是这一点。
无需入站连接即可实现入站访问。手机从不接受任何传入连接。它主动向一组中继发起连接并保持连接打开，发送到隧道公共URL的流量会沿着同一条线路回传到本地端口。运营商NAT和没有公网IP都不会造成阻碍，因为手机上没有任何东西在等待入站流量。
带有自动TLS的公共HTTPS URL。每条隧道都在
https://<clientId>.<your-domain>:8443上启动，证书通过ACME自动签发。调用方只需通过普通HTTPS访问一个普通子域名。每次运行都使用全新身份。每个部署都会生成一个新的P-256密钥作为隧道身份，并由该密钥派生出一个新的子域名。URL按部署生成：它只在部署运行期间有效，部署结束时即失效，部署会在启动时通过回调报告其实际URL。如果您需要一个固定地址，可以将密钥保存在bundle中（这样泄露的bundle也会带上该地址），或者让使用方在URL变化时重新注册。
它转发的是端口，而不是协议。隧道并不知道自己承载的是LLM流量，它只是转发一个TCP端口。同系列的app-tunnel/cargo示例通过同一个隧道客户端运行SSH，这表明隧道是一个通用的基础组件，而其背后的服务可以随意替换。
它运行在经过证明的手机上。该部署只会匹配经过证明的Acurast手机，隧道客户端与工作负载一起运行在Shell运行时的proot沙箱中，并通过本地JSON-RPC桥与Processor协同工作。
02 / 章节
NodeGhost的作用，以及BYOM交接
在可部署于任何地方（包括手机上）的后端之前，提供可直接替换的OpenAI API。
README对NodeGhost的描述范围很窄，而这也正是本示例所依赖的全部内容：它通过Pocket Network路由推理请求，提供兼容OpenAI的API，并支持Bring Your Own Model。
可直接替换的兼容OpenAI API。NodeGhost提供与OpenAI API相同的接口，因此现有的客户端、库和工具在更改base URL后即可继续使用。
通过Pocket Network路由。请求经由POKT去中心化层路由，而不是直接访问单一提供商的端点。
Bring Your Own Model（自带模型）。运营者不使用NodeGhost托管的模型，而是将API密钥指向自己的兼容OpenAI后端。在本示例中，这个后端就是Acurast Processor上的llama-server，通过隧道访问。
交接过程。隧道报告其URL后，您将它作为BYOM端点注册到NodeGhost。（示例中的注册调用省略了端点密钥，因为llama-server默认无需认证即可运行。）此后，一个标准的chat-completions请求会经由NodeGhost、再通过隧道到达手机上的模型，响应中会带有模型名称，从而确认请求是在哪里处理的。
03 / 章节
二者如何组合
一次注册，就能把可访问性与标准API结合起来，让请求落到一部手机上。
单独来看，隧道和兼容OpenAI的网关都很普通。这个示例的关键在于二者的结合：只需多一步，也就是把隧道URL注册为BYOM后端，一个托管在手机上的模型就变成了可直接替换的推理端点，而调用方应用完全不需要改动。
手机 · Acurast Processor（Shell运行时 / proot）
llama-server :8080
Qwen2.5-3B-Instruct-Q4_K_M
Qwen2.5-3B-Instruct-Q4_K_M
↓
隧道 · Acurast隧道
向中继发起外连 -> https://<clientId>.<your-domain>:8443
（临时P-256身份、ACME TLS、由回调报告的URL）
（临时P-256身份、ACME TLS、由回调报告的URL）
↓
网关 · NodeGhost（兼容OpenAI，经POKT路由）
隧道URL注册为BYOM端点
POST https://<gateway>/v1/chat/completions
-> 经由隧道路由 -> 在手机上完成推理
POST https://<gateway>/v1/chat/completions
-> 经由隧道路由 -> 在手机上完成推理
04 / 章节
目前已实现的功能
一个可部署的示例，能让OpenAI请求落到托管在手机上的模型。
部署时，Processor会搭建一个proot Ubuntu环境，构建一个小型回环适配层，使本地服务器能在沙箱内正确绑定，在运行时下载llama.cpp和Qwen2.5-3B模型，并在一个以健康检查为门槛的就绪循环之后启动服务器。只有在模型加载完成后，隧道才会打开。
您可以通过回调接收端跟踪整个过程：环境搭建、下载、模型加载、模型就绪，最后是一个携带公共隧道URL的
started事件。将该URL注册到NodeGhost，发送一个普通的聊天请求，答案就会从手机上返回。立即体验。
浏览示例，在Canary上部署，并观看请求落到一部手机上：github.com/Acurast/acurast-example-apps/tree/main/apps/app-tunnel/llm
05 / 章节
坦诚的上限
任何能力都有局限，而这一局限很容易说清楚。
一个量化为Q4的3B模型，在移动ARM CPU上每秒大约生成3个token。一段约120个token的回复大约需要45秒，而且模型在多步推理上会犯一些基本错误。这是该模型在这种硬件上的上限，而不是隧道、运行时或网络的限制。
在实践中，这种模式适合异步、批处理或短上下文的工作：后台摘要、分类、排队生成，以及不在人工关键路径上的智能体步骤。它并不是为交互式聊天而设计的。为了吞吐量选择更小的模型，或者因为希望模型运行在自己掌控的硬件上而接受延迟，都是合理的选择。
可推广的方向
隧道并不关心它转发的是什么，NodeGhost也不要求后端必须托管在云上。同系列的cargo示例通过同一条隧道运行SSH，证明了这一点。经过证明的手机上任何绑定在本地的服务都可以通过这种方式访问，任何OpenAI形态的工作负载都可以原封不动地架在它前面。这里的模型只是恰好位于另一端的那个东西而已。
关于技术栈
NodeGhost是一个去中心化AI推理网关，通过Pocket Network路由，提供兼容OpenAI的API，并支持Bring Your Own Model。了解更多：nodeghost.ai。
Pocket Network是NodeGhost路由请求所经由的去中心化层。了解更多：pocket.network。
Acurast是一个由经过证明的智能手机组成、提供分布式边缘算力的去中心化网络，工作负载会被部署到网络中经过证明的手机上。了解更多：acurast.com。
本示例是Acurast的参考构建，发布在acurast-example-apps代码库中。
在Acurast上构建？
如果您正在经过证明的手机上运行自己的模型、智能体后端或其他服务，欢迎与Acurast团队交流。加入Discord。
