提交一个大活，AI 跑了四十分钟，回来一看没结果。
先别急着换模型。看一件事：有没有报连接错误、超时、或者流中断。
有，那是跑断了。没有、但输出内容不对，那是跑错了。
这两种失败长得很像——都是“跑了很久、白跑了”——但原因和解法完全相反。跑错了要改提示词、拆任务、加验证；跑断了改这些一点用没有，它下次还是断在同一个地方。
这篇只说跑断的那一种。
一次提交跑很久，靠的是一条一直活着的连接
现在越来越多的任务是“一次提交、长时间执行”：几百页文档的翻译和摘要、大批量数据清洗、长音视频转写、一次提问跑几十分钟的深度检索、整个代码库的分析。
这类任务在技术上通常有两种承载方式。
一种是流式输出。服务端边生成边往回推，客户端保持一条 HTTP 长连接接着，直到结束。好处是能实时看到进度，代价是这条连接要活几十分钟甚至更久。
另一种是异步任务：提交后拿到一个任务 ID，服务端在后台跑，你轮询或者等回调。这种对连接的要求低得多，但不是所有服务都提供。
绝大多数人用的是第一种，因为它是默认的。而问题就出在这条要活很久的连接上。
它会在哪儿断
中间设备回收会话。 路由器、防火墙、运营商侧的 NAT 设备都对连接有老化时间，空闲超过阈值就回收表项。流式输出期间通常有数据流，一般不会被判定为空闲——但模型在推理、还没开始吐字的那段静默期是例外。这段能撑多久，取决于服务端有没有发心跳来占住这条连接，各家实现不一样。
中间层的空闲超时。 你和模型服务之间可能还隔着代理层和负载均衡，这些环节各自有自己的空闲超时设置，常见值只有几十秒到几分钟。任何一环先超时，整条连接就断了。
IP 变了。 拨号重连、链路切换、地址租约到期，都会换 IP。IP 一变，正在进行的 TCP 连接立刻失效，没有任何缓冲。
链路切换。 这一条最反直觉：为了冗余配置的自动切换，恰恰是长连接的杀手。切换发生的那一刻，正在进行的连接必然中断——哪怕新链路质量更好，这次中断已经发生了。
丢包耗尽重传。 跨境链路丢包率高的时候，TCP 重传次数耗尽，连接会被判定失效。这种断法最隐蔽，因为带宽测出来完全正常。
断一次的代价不只是重跑
服务端那边可能还在跑，但你已经收不到了——这取决于具体实现，有些会在客户端断开时终止生成，有些不会。
不管哪种，已经消耗的 token 照样计费。四十分钟的任务断在第三十五分钟，那三十五分钟的钱一分不少。
更麻烦的是发现得晚。长任务的特点就是你不在场，等回来看到断了，一轮时间已经过去。如果这个任务卡在流程上——比如一批素材等着它出结果——耽误的就不止四十分钟。
先自查，别急着买东西
下面几件事不花钱，而且能解决相当一部分问题。
看服务端有没有异步接口。 如果有，长任务优先走异步加轮询，别用流式。这一条能绕开绝大多数连接问题，是性价比最高的做法。
做一次长连接保持测试。 注意不是 ping。ping 测的是短包往返，长连接要的是“一条连接能不能活四十分钟”。在业务高峰时段建一条连接放着，看多久会断，断在哪一层。这个数比任何速率测试都有意义。
查中间设备的会话超时。 路由器和防火墙上的会话老化时间，很多默认值是按网页浏览设计的，对长连接偏短。这个值调大，成本为零。
关掉链路自动切换。 如果你的方案配了多链路自动切换，长任务和直播这两类场景要单独确认：切换时正在进行的连接会不会断。会断的话，把自动切换改成人工介入的兜底。
用有线。 无线的抖动和干扰在四十分钟的尺度上会被放大，这个变量不值得留着。
做完这几项还是断，那才轮到链路本身。
这时候需要的是什么
长运行任务对链路的要求，跟聊天式使用完全是两回事，跟看视频也不是一回事。
带宽基本不是瓶颈。纯文本的调用消耗极小，几十分钟的任务加起来可能还不如一个视频通话的一分钟。加粗管子解决不了任何问题。
真正需要的是三样：
连接不被中途回收。 这取决于链路上每一跳的会话保持策略。跨境路径上经过的环节越多、越不可控，被回收的概率越大。
IP 固定不变。 只要 IP 会变，长连接就有随时失效的可能，而且这种断法查起来最麻烦——现象看起来像服务端出问题，实际是你这边换了地址。
出故障时有确定的责任方。 长任务断了要能查，能拿到那一时段的链路状态，能找到人问。这一条听起来不像技术指标，但在排障时它比任何参数都实用。
我不会说哪条线路保证不断——没有人能保证。能承诺的是可用性指标、有没有备份路径、以及出问题时找谁。这三件事写不进合同的，都不算承诺。
为什么 VPN、机场这类方案跑长任务必然不行
先说清楚：不是它们慢。很多这类服务测速跑得很漂亮，看视频、刷网页完全够用。问题在于承载方式，跟速度无关。
路由是漂的。 走公网转发，路径随公网状况变化，今天走香港明天绕日本。中途换路就是换连接，正在跑的任务当场断。
出口 IP 是共享且会变的。 多人共用一个出口，IP 池还会轮换。IP 一变，长连接立刻失效，没有任何缓冲。这一点在聊天式使用里几乎感觉不到，因为每次请求都是新连接；但长任务靠的就是那一条连接活着。
中间经过哪些环节，你看不见。 会话被哪一跳的设备回收了，查不出来，因为那些跳不在你的可见范围内，也没有任何人对它们负责。你能拿到的只有一句“断了”。
自己搭一套也一样。 换一家便宜的、或者自己找台机器搭，都解决不了这个问题——因为出境之后走的可能还是同一段公网。换的只是入口，不是路径。
这不是调参数、加重试能补的，是结构问题。
那该看什么
判断标准可以很简单：这条路径上的每一段，你能不能说出承运方是谁。
说得出来的，断了能查那一时段的链路状态、能找到人问、能追责。说不出来的，长任务就别指望它。
万联的跨境传输部分由中国电信等合规运营商提供，持有《增值电信业务许可证》，可签合同、可开发票、可电信直签。IP 是独享固定的，路径明确，出问题有确定的对接方。
我不会说它保证不断——没有人能这么说。能承诺的只有三件事：可用性写进合同、有没有备份路径、以及出故障时找谁。这三条写不进合同的，都不算承诺。但对长任务来说，这三条恰恰比测速数字有用得多。
回到开头那个判断
任务跑了很久没结果，先分清是跑断了还是跑错了。
跑错了，去改提示词、拆任务、加中间验证，换线路一点用没有。
跑断了，按上面那几项自查一遍：有没有异步接口、长连接能活多久、中间设备的会话超时设多少、有没有配自动切换。
这两条路走岔了，会浪费很多时间——我见过换了三个模型都没好的，最后测出来是链路问题，任务根本没跑完，压根不是模型跑错了。