AI基站与端侧算力组网：算力下沉的工程实践

AI 基站正在成为端侧算力组网的重要载体。传统基站只承担无线接入和转发AI 基站则在基站侧集成 GPU、NPU 等推理算力使视频分析、工业质检、自动驾驶协同、大模型推理等任务在网络边缘就近完成。端侧算力组网要做的事是把分散在基站、边缘机房和终端附近的算力节点组织成一张可调度、可扩展、可监控的资源网络。最近行业里关于英伟达寻找中国 AI 基站供应商、计划在明后年启动端侧算力组网的讨论很多具体供应链和商业节奏还存在不确定性但技术方向已经很明确AI 推理正在从集中式云上向分布式边缘下沉。这里不展开商业层面的细节而是从工程角度拆解 AI 基站与端侧算力组网是什么、需要哪些组件、如何搭建最小可运行环境以及落地时最容易踩的坑。1. AI 基站与端侧算力组网算力为什么要下沉到基站侧1.1 AI 基站解决什么问题基站是移动网络里分布最密集、位置最稳定的基础设施之一。每个基站都有机房或机柜空间、供电系统、回传链路和运维体系。把这些条件利用起来在基站侧部署小型服务器或 AI 加速卡就能把原本要传到云端的推理任务留在本地完成。典型场景包括智慧城市的视频结构化分析摄像头画面不再全部回传中心机房工业园区的缺陷检测生产数据不出园区车路协同里的风险识别时延要求压到几十毫秒以内还有大模型应用的端侧推理把向量化、检索增强或轻量生成放在离用户更近的位置。这些场景有一个共同点对时延敏感、数据量大、隐私要求高。如果全部依赖云端网络抖动和回传带宽会成为瓶颈。例如一个园区部署几百路摄像头每路按 1080P 25 帧计算全部回传云端做分析专线带宽和存储成本会迅速失控。AI 基站把推理能力下沉后摄像头画面在本地完成结构化只有告警和摘要需要回传流量可以下降一到两个数量级。1.2 什么是端侧算力组网先区分三个层次。终端侧算力指的是手机、车载盒子、摄像头、工业设备上的处理器边缘侧算力指的是靠近用户的边缘机房、园区网关或基站上的计算节点云端算力则是集中式数据中心。端侧算力组网这个概念在本文语境里主要指把边缘侧也就是基站和边缘机房中的异构算力节点连接成网络统一对外提供推理能力。组网不是简单地把几台机器接到同一个交换机。端侧算力组网至少要解决四件事服务发现新节点加入后能自动被调度端识别算力感知调度端要了解每个节点的 GPU 占用、队列长度和健康状态任务路由推理请求要能按规则分发到合适的节点故障处理节点宕机、网络中断或模型加载失败时系统要能自动切换。举例来说一个城市有五十个 AI 基站节点每个节点加载了不同的模型。某个摄像头请求“识别画面中的车辆型号”调度端必须先知道哪些节点加载了该模型再根据负载选择最空闲的节点最后把请求发过去。如果节点没有心跳上报调度端就会盲目转发导致大量请求失败。这就是“能算”和“能组网”的区别。1.3 端侧算力组网与云端推理的差异先把两种模式放在一起对比能更清楚地看出各自的定位。维度云端集中式推理端侧算力组网部署位置数据中心基站、边缘机房、园区网关单次请求时延受骨干网和公网影响通常较高就近处理可控制在几十毫秒级回传带宽视频等大流量数据全部上云成本高数据本地消化只回传结果或摘要资源弹性高可大规模扩容相对有限需要调度器合理分配故障影响面单点故障影响范围大单个节点故障可被周边节点接管运维复杂度集中在数据中心节点分散需要远程管理和自动化升级这个对比不是为了说明端侧可以完全替代云端。适合端侧的是时延敏感、流量大、隐私要求高的推理任务适合云端的是模型训练、全局数据分析、低频大计算任务。AI 基站把一部分推理请求拦在边缘云端只处理真正需要全局视角的任务整套系统的成本和时延反而更优。基站之所以适合做算力节点还因为运营商已经有一套成熟的站址维护体系有供电、有传输、有巡检、有备件。算力下沉到基站可以复用这些基础设施不需要像自建边缘机房那样重新解决供电和链路问题。这也是“AI 基站”这个概念与普通边缘服务器最大的区别。2. 组网架构与关键技术选型2.1 端侧算力组网的分层模型一套通用的端侧算力组网可以分成四层节点层、网络层、调度层和应用层。节点层是 AI 基站里的算力单元常见形态是边缘服务器加 GPU/NPU 加速卡也可能是 Jetson 这类嵌入式设备。节点层负责加载模型、执行推理、上报状态。网络层是节点之间的回传链路包括园区以太网、SPN、5G 回传等承载推理请求、心跳和模型更新数据。调度层包含服务注册、健康检查、任务路由、负载均衡和失败重试是整个组网的中枢。应用层则是视频分析、质检、车路协同等业务通过统一的推理 API 访问底层算力。调度层是端侧算力组网最容易做坏的环节。常见做法有几种小规模场景使用中心化网关所有任务统一经过网关分发实现简单适合节点数少于几十个的场景中大规模场景使用 K3s 或 Kubernetes 在边缘节点上做容器调度把节点组成集群由 K8s 负责编排再大一些会引入服务网格和消息总线承担流量治理和应用解耦。没有绝对最优的方案需要根据节点数量、请求量和网络条件选择。2.2 组网协议与通信选型节点之间的通信可以分为三类推理数据、控制信令、监控指标。三类数据的频率和可靠性要求不同不应该混用同一种协议。通信类型推荐协议适用场景说明推理请求gRPC / HTTP模型调用Triton 默认监听 8000HTTP和 8001gRPC控制信令MQTT心跳、设备状态、命令下发消息体积小适合弱网环境指标采集PrometheusGPU 利用率、队列长度、时延Triton 默认在 8002 暴露 metrics协议选型的核心原则是重要数据走可靠连接高频小报文走轻量通道监控指标与业务通道分离。推理请求建议用 gRPC因为它支持流式传输和多路复用配合 Protobuf 能明显减少序列化开销。心跳和控制命令建议用 MQTT体重小、断线重连逻辑成熟不会给基站回传链路增加太多压力。监控指标单独走 Prometheus便于接入 Grafana避免业务请求和指标采集互相干扰。2.3 NVIDIA 生态在端侧算力组网中的角色NVIDIA 在端侧场景提供的不是单一硬件而是一套从芯片到推理框架的软件栈。以 Jetson 系列为例Orin Nano、Orin NX、AGX Orin 覆盖不同功耗和算力档位适合做基站侧、车辆侧或园区侧的推理节点JetPack SDK 统一提供驱动、CUDA、TensorRT 和多媒体库Triton Inference Server 负责模型部署和并发调度DeepStream 处理视频流NIM 则把大语言模型封装成标准接口降低端侧部署门槛。值得注意具体型号的算力、显存和功耗参数随版本更新变化较快。例如 Jetson 系列在不同硬件迭代中的 TOPS 数值差异很大选型前应以官方最新规格为准不要照搬老文章里的数字。工程团队落地时真正要关心的是三个问题目标模型在目标设备的推理耗时要多少、能否满足业务时延、显存是否装得下模型和运行时。这三个问题都要用实际设备测过才算数。3. 搭建最小端侧算力组网实验环境3.1 硬件和软件准备如果本机没有独立 GPU也可以用 CPU 运行极小的模型做流程验证但推理性能会明显受限模型加载时间也会很长。推荐的学习环境是一台带 NVIDIA GPU 的 Linux 主机或者一块 Jetson 开发板。三个算力节点可以用 Docker 隔离出来模拟多基站组网。角色学习环境建议生产环境形态算力节点本机 Docker 容器映射 GPU边缘服务器 加速卡或 Jetson 设备调度网关本机运行轻量 Python 服务高可用网关组或 K3s 集群客户端本机模拟用户请求业务系统、摄像头网关、车载单元软件依赖版本要提前对齐。常见组合是 Ubuntu 22.04、Docker 24 及以上、NVIDIA Container Toolkit 1.15 及以上、Triton 24.x 容器镜像、Python 3.10。相关版本信息只作为参考落地前要到官方仓库确认一次尤其是 Triton 镜像 tag 和 CUDA 版本之间的匹配关系。3.2 最小组网拓扑实验拓扑设计成三个节点加一个调度网关节点分别模拟三个基站侧的算力单元。[ 客户端/业务系统 ] | [ 调度网关 10.20.30.10 ] | ------------ | | | [节点1] [节点2] [节点3] 10.20.30.21 10.20.30.22 10.20.30.23三个节点分别运行一套推理服务网关负责收集节点状态并把请求路由到可用节点。实际环境中这些节点可能分布在不同区县中间隔着数台路由设备在实验环境里它们可以就是同一台机器上的三个容器。端口规划建议先定下来网关 HTTP 端口 8080节点推理端口分别用 8000、8100、8200避免冲突。3.3 初始化节点Docker 与 GPU 支持先确认 Docker 能把 GPU 转发给容器。安装 NVIDIA Container Toolkit 后执行以下命令sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi如果最后一条命令能打印出 GPU 信息说明 Docker 已经能访问 GPU。这一步是整个实验的地基很多后续报错都源自这里没配好。比如容器内看不到 GPUTriton 启动时就会报 CUDA 相关错误初学者经常误以为是镜像或模型的问题。接着创建三个节点目录每个目录放一份模型仓库和 Compose 文件。目录可以命名为node1、node2、node3后续在这三个目录里分别启动服务。4. 在节点上部署统一推理服务让组网有“能算”的节点4.1 组织模型仓库每个推理节点需要一份模型仓库。下面以 ResNet18 的 ONNX 模型为例展示标准目录结构和配置。实际项目的模型可能是 YOLO、PP-OCR、大语言模型量化版本等目录规则是一样的。/data/models/resnet18_onnx/ ├── 1/ │ └── model.onnx └── config.pbtxt模型配置文件config.pbtxt内容如下name: resnet18_onnx platform: onnxruntime_onnx max_batch_size: 8 input [ { name: input data_type: TYPE_FP32 dims: [3, 224, 224] } ] output [ { name: output data_type: TYPE_FP32 dims: [1000] } ]max_batch_size表示一次推理最多合并多少个请求Triton 会自动做请求合并提高 GPU 利用率。dims必须和导出模型时的输入输出保持一致这里如果写错Triton 会在启动阶段直接报错现象非常明显。ONNX 模型建议在导出时固定动态轴或者在配置里准确声明否则max_batch_size无法生效。4.2 用 Docker Compose 启动三个节点以一个节点为例Compose 文件如下其余节点复制后修改端口和容器名。# docker-compose.yml version: 3.8 services: triton: image: nvcr.io/nvidia/tritonserver:24.05-py3 container_name: triton-node-1 command: tritonserver --model-repository/models --model-control-modeexplicit --load-modelresnet18_onnx --http-port8000 --grpc-port8001 --metrics-port8002 ports: - 10.20.30.21:8000:8000 - 10.20.30.21:8001:8001 - 10.20.30.21:8002:8002 volumes: - /data/models:/models:ro deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [ gpu ]--model-control-modeexplicit让 Triton 只加载显式指定的模型而不是扫描整个模型仓库。这个参数在生产环境很有用可以避免把未准备好的模型目录一并加载。三个节点使用不同端口时注意container_name不能重复否则后启动的容器会覆盖先启动的容器。启动命令和验证方式如下docker compose up -d docker logs -f triton-node-1正常启动时日志里会出现类似内容-------------------------------- | Model | Version | Status | -------------------------------- | resnet18_onnx | 1 | READY | --------------------------------然后在另一个终端请求健康检查接口curl http://127.0.0.1:8000/v2/health/live curl http://127.0.0.1:8000/v2/health/ready两个接口都返回true说明推理服务已经就绪。4.3 节点注册与健康检查推理服务就绪后节点还需要向调度网关注册自己否则网关不知道有哪些算力可用。用一个简单的 Python 脚本把节点 ID、IP、端口、健康状态上报给网关。# node_heartbeat.py import json import time import requests NODE_ID node-1 GATEWAY http://10.20.30.10:8080/register TRITON_HEALTH http://10.20.30.21:8000/v2/health/ready def collect_status(): try: health requests.get(TRITON_HEALTH, timeout2).text except Exception as exc: health ferror: {exc} return { node_id: NODE_ID, health: health, ts: int(time.time()), model: resnet18_onnx, } while True: payload collect_status() try: resp requests.post(GATEWAY, jsonpayload, timeout3) print(register ok, resp.status_code, payload) except Exception as exc: print(register failed, exc, payload) time.sleep(5)心跳周期在实验里设 5 秒生产环境通常设 10 到 30 秒。太短会导致网关压力大、信令链路占用高太长会导致故障发现慢节点宕机后请求还会继续被路由过去。网关收到心跳后更新节点状态表连续多轮没有收到心跳就把节点标记为不可用。5. 端侧算力组网的关键设计和优化5.1 任务路由与算力感知调度实验环境可以直接把请求轮询发给三个节点但真实基站侧节点负载差异很大。有的节点正在跑视频流分析GPU 利用率接近满载有的节点刚空闲下来。调度端应该根据节点上报的 GPU 利用率、排队请求数和健康状态做加权路由。一个简化版的路由选择逻辑如下# dispatcher.py import random nodes { node-1: {url: http://10.20.30.21:8001, gpu_util: 0.3, weight: 1}, node-2: {url: http://10.20.30.22:8001, gpu_util: 0.8, weight: 1}, node-3: {url: http://10.20.30.23:8001, gpu_util: 0.1, weight: 1}, } def pick_node(): candidates [] for node_id, cfg in nodes.items(): if cfg[gpu_util] 0.7: weight max(1, int((1 - cfg[gpu_util]) * 10)) candidates.extend([node_id] * weight) if not candidates: candidates list(nodes.keys()) return random.choice(candidates)这个示例展示的是思路真实生产环境中调度器要维护动态节点状态表权重根据 GPU 利用率实时变化同时还要处理模型版本差异比如只有部分节点加载了大模型调度端必须按模型名过滤节点否则请求会被转发到没有对应模型的节点上。5.2 推理结果的缓存与一致性同一个摄像头画面在短时间内可能被多个业务重复分析同一个检索请求也可能反复命中。端侧推理节点可以对结果做短期缓存减少重复计算降低算力消耗。比如园区车牌识别同一辆车在闸机前停留三秒视频流会产生几十帧包含同一画面的结果缓存可以保证只有第一帧触发完整推理后续帧直接复用。但缓存必须设置合理的 TTL并且要考虑模型版本变化。模型升级后旧缓存应失效如果业务要求实时判别比如人脸支付、闯红灯抓拍缓存更不能无限期生效。建议缓存只用于特征稳定、容忍微小延迟的结果对强实时结果保持透传。5.3 时延、带宽和可靠性取舍端侧组网里的每一项优化都有代价核心是在四个目标之间做取舍。优化目标手段代价降低时延本地优先路由请求尽量留在本节点需要本地模型完整占用显存节省带宽只回传结果、告警和摘要端侧逻辑复杂需要流式分析能力提高可靠性多节点冗余部署失败自动重试需要更多算力和模型拷贝统一版本中心仓库下发模型依赖回传链路