自己机器上 llama.cpp 跑通了，想让同事、手机或局域网里另一台机器也能调这个模型，结果发现只有本机 127.0.0.1 能连上。这篇按顺序讲清服务怎么起、监听地址怎么改、防火墙和路由哪一步容易漏，以及开放出去之后该做哪些限制。
自己机器上把 llama.cpp 跑通了，模型也正常出词，想让同事、手机或者局域网里另一台机器也能调这个服务，结果对方一请求就连接被拒绝——大概率不是模型没加载，而是服务只绑在本机回环地址上，外面根本看不到这个端口。这篇按实际排查顺序讲：先确认起的是哪种入口，再改监听地址和端口，然后过一遍防火墙和网段，最后说清开放出去之后该卡哪些边界。
整条链路就四段：服务进程有没有带 HTTP 接口、它监听的地址允不允许外部进来、主机与网络的放行规则、请求方填的地址对不对。任何一段断了，现象都是「连不上」，但修法完全不同，所以别一上来就改配置，先定位断在哪一段。
先分清：llama.cpp 的三种跑法哪种才带 API
llama.cpp 至少有三种常见用法：命令行对话、单次推理（跑一个提示就退出）、以及常驻的 HTTP 服务模式。只有第三种会开出接口路径供别的程序调用，前两种进程跑完就结束了，自然也没有端口可连。很多人以为「我明明跑起来了」，其实跑的是对话模式，看日志只有生成结果，没有监听提示。
- 判断标准一：启动日志里有没有出现监听地址、端口和接口路径的提示行，没有就是没进服务模式
- 判断标准二：进程是否常驻不退出，退出即结束的都不是服务
- 判断标准三：本机用命令行或浏览器请求一下接口路径，能回内容才算服务真的起来了
- 判断标准四：用系统命令看这个端口有没有被监听，比猜日志更快
如果对「服务模式」「监听」「回环地址」这些词的含义还没完全对齐，先去站内的基础设施术语区把概念过一遍，不然后面改参数容易改错位置。具体入口在 /ai-dict/category/infra。
改监听地址和端口：把服务从本机推到局域网
服务模式默认只绑本机回环地址，这是设计上的安全默认值，不是 bug。要让它被局域网里别的机器访问，需要把这个地址改成对外的全网卡地址（常见写法是监听所有网卡），并显式指定端口；改完必须把进程重启，参数才生效。命令的字段名在不同发布版本里会有出入，起服务之前到站内的部署测算页核对一下当前写法和说明，路径是 /models/deploy。
- 第一步，先在本机自测用本机地址请求一次接口路径，确认服务本身能回数据。回不了就别急着改监听，问题在服务没起好。
- 第二步，改监听地址和端口把监听地址从回环改成对外地址，端口挑一个没被占用的。启动后观察日志里报出来的实际监听值是否和你写的一致。
- 第三步，换一台机器验证用局域网里另一台机器，先确认能 ping 通主机 IP，再请求接口路径。这一步通了，说明监听这一层没问题。
- 第四步，注意端口冲突同一台机器上多个服务抢同一个端口会直接启动失败，报错通常出现在启动瞬间。与其排查是谁占了，不如先换一个端口试。
还是连不上：按这个顺序排查
服务本机自测能通、别的机器连不上，问题就落在网络上。这时候不要反复改服务参数，按下面的顺序逐层排除，每层只回答一个是非题，能最快定位到断点。
| 排查层 | 怎么测 | 通了说明什么 | 不通就查什么 |
|---|---|---|---|
| 服务本机自测 | 本机请求接口路径 | 服务本身正常 | 回到监听设置那一步 |
| 主机防火墙 | 查放行规则里有没有这个端口 | 本机允许外部进来 | 放行该端口或对应进程 |
| 网段可达 | 从另一台机器 ping 主机 IP | 两层在同一网络 | 是不是跨网段、连了 VPN 或走了访客网络 |
| 请求方地址 | 看客户端里填的是主机 IP 还是 localhost | 填对了目标 | localhost 永远指它自己，改成本机局域网 IP |
最常见的漏项是主机防火墙没放行，或者请求方把地址填成了 localhost——后者看着像网络问题，其实只是地址写错。跨网段、VPN、访客网络这几种情况都靠 ping 不通快速识别，别在应用层反复试。
开放出去之后：谁能在什么范围内用什么
这类本地推理接口通常不带账号体系，安全性完全靠网络边界。局域网内开放和公网开放是两件性质完全不同的事：前者被同网设备调用，后者等于把一个无认证的推理入口挂到互联网上。需要外网访问时，优先走隧道或内网穿透并叠加一层认证，不要直接把端口映射出去。也不建议把它放进不设防的访客网段，那里面谁都能扫到。
- 范围上先限定：只开给需要的网段，别默认全开放
- 并发上要约定：本地单机推理扛不住多人同时发起长文本请求，排队比拒绝体验更好
- 时段上可约定：高峰与非高峰给不同的人用，避免互相拖慢
- 评估上要提前：还在选框架或选卡的时候，按模型规模核一遍显存和内存够不够，站内 /compute/sizing 可以对照算
- 监控上留一手：至少能看到是谁在频繁调用，出问题时能定位
如果同时还在对比要不要换别的服务方式对外提供接口，可以到站内的服务或中转导航里看一圈现成方案，地址在 /sites，先搞清各自适合什么场景再决定要不要自建。
客户端怎么接：把地址填对就够了
服务端开放出来之后，客户端这一侧其实很简单：任何支持自定义接口地址的工具，填入主机的局域网 IP 加端口就行，模型名按服务端实际报出来的写。网页端、脚本、别的桌面工具可以同时调同一个服务，区别只在于各自配置里的地址字段填得对不对。
遇到报错先分清两类：一类是「连不上」，属于地址写错或服务没起；另一类是「连上了但返回异常」，属于参数或模型名不对。两类的报错位置完全不一样，别混在一起调。想先量一下往返延迟再决定给多少人共享，可以用站内的测速工具建个基线：/tools/speed-test。
下一步在你动手改监听之前，先到站内把接口与部署相关术语、当前部署写法核对一遍，能少踩一轮参数写错的坑。→常见问题
为什么我本机能用，同事那台就是连不上？
九成是服务只绑在本机回环地址上，只有本机能访问。把监听地址改成全网卡地址并重启，再确认主机防火墙和局域网同网段这两项，基本就通了。
开放到局域网会不会有安全风险？
有。接口一般没有账号密码，能连上就能调。所以只在可信内网开，别直接映射到公网，需要外网访问就套隧道加一层认证，也别把它放在访客网段里。
多人同时用同一个接口会怎样？
单机推理靠一张卡，并发一上来排队会明显变长，长上下文请求尤其明显。给共享接口约定并发上限和错峰时段，或者干脆按人数核一遍显存再决定放多少人进来。
