过去一周，即时配送行业最热闹的不是补贴战，而是“AI调度”从PPT走向IDC机柜。美团、饿了么、达达陆续放出消息：用大模型做词元级订单预测，把骑手轨迹、商家出餐、路况都变成token喂给推理引擎。但实测下来，理想很丰满，带宽和网络软件的现实很骨感。
我们拉了三套典型方案做72小时对比。方案A：公有云IDC+通用GPU。优点是弹性扩容快，词元推理延迟稳定在120ms左右；缺点是公网带宽抖动大，晚高峰骑手端指令下发延迟能飙到800ms，且按流量计费让中小平台直呼用不起。适合日单量50万以下、不愿自建机房的区域平台。
方案B：自建边缘IDC+专用推理卡。我们把服务器放在城市配送站机房，词元处理走本地环回，端到端延迟压到40ms，带宽成本几乎为零。但问题来了：网络软件栈太陈旧，Kubernetes调度和RDMA没调通，一旦某个区县爆单，GPU利用率瞬间打满，扩容要等物理上架。适合单城日单量200万以上、有运维团队的头部玩家。实测中，这套方案在午高峰的订单超时率比方案A低37%，但故障恢复时间长了4倍。
方案C：混合组网+智能网卡。这是本周某新锐履约网络软件商推的方案：IDC只做词元粗筛，精细推理下沉到带DPU的服务器，带宽按业务优先级动态切片。实测优点很明显——晚高峰骑手App卡顿率下降62%，词元吞吐量提升2.3倍。缺点是贵，智能网卡和授权费让TCO比方案A高45%，且需要重新培训网络运维。适合正在冲IPO、需要讲AI故事且对稳定性极端敏感的即时配送平台。
结论很直接：别只看词元推理的QPS，先看你的IDC到骑手之间的那根“带宽管子”和网络软件能不能扛住即时配送的脉冲流量。本周已经有平台因为盲目上大模型，导致午高峰调度指令丢包，骑手在原地转圈。AI是好东西，但履约网络的底座如果还是十年前那套，词元越多，翻车越快。
0 留言