楼层定位引擎能带动多少终端，不是固定数字，核心指标是每秒定位解算次数 LPS（locates per second），而不是单纯看终端数量；同样算力下，终端上报频率越高，能承载的终端数越少，工程上一般用排队论模型评估延迟、排队溢出风险，同时无线信道、基站容量、网络带宽、告警业务负载都会变成瓶颈，很多项目不是引擎算力先跑满，而是空中数据包碰撞、网关上行先堵死。UWB、蓝牙、Wi-Fi 指纹、惯性融合这几种楼层定位方案的 LPS 上限差异很大，单机集中式定位引擎常见的吞吐上限在几千 LPS 级别；如果是边缘分布式解算，单引擎可以通过分片（按楼层 / 分区）横向扩容，容量不再受单机限制。做容量规划时，不能直接拿理论最大值，要预留安全余量，一般只用到理论吞吐的 50%~70%，用来应对告警风暴、人员快速移动、跨楼层切换、突发峰值流量，否则定位延迟会快速恶化、出现丢点、楼层跳变。
不同定位方案典型容量明细
- UWB TDOA 集中式引擎：典型单机总 LPS≈3000~3500；1Hz 上报时可带 3000 左右标签，10Hz 上报只能带 300 个标签，无线信道是强约束
- BLE 蓝牙 RSSI 指纹楼层定位：单引擎常见 LPS 1000~5000，适合低刷新（0.1~1Hz），大量终端并发时容易信号碰撞
- Wi-Fi 指纹定位：算力开销更高，同算力下 LPS 偏低，适合资产静态巡检，不适合高频人员追踪
- 边缘分布式解算：基站 / 边缘节点本地算坐标，云端引擎只做轨迹融合，单引擎可承接上万终端，瓶颈转为消息队列和存储
并发模型与计算公式
基础排队论模型：λ 为总上报到达率（LPS），μ 为引擎服务速率（最大 LPS）
- 稳定条件：λ < μ；当 λ 接近 μ，排队时延指数上升
- 可承载终端数 N = 总 LPS ÷ 单终端上报频率 f
举例：引擎最大 LPS=3300，f=1Hz → N=3300；f=10Hz → N=330
工程余量：实际设计 N 实际 = N 理论 × 0.5~0.7，预留峰值、告警、卡尔曼滤波、楼层判定、电子围栏计算开销
瓶颈对比表
| 瓶颈类型 | 现象 | 优化手段 |
|---|---|---|
| 无线信道瓶颈 | 终端多了丢包、定位点断断续续，和服务器 CPU 无关 | TDMA 时隙调度、分时上报、信道分组、分区基站 |
| 引擎算力瓶颈 | CPU 持续高负载，定位延迟变大、楼层识别出错 | 批处理、滤波轻量化、边缘下沉、分区分片 |
| 网关 / 上行带宽瓶颈 | 大量测距包上行拥塞 | 本地预聚合、压缩上报、独立专网 VLAN |
| 业务层瓶颈 | 电子围栏、轨迹存储、告警推送拖垮引擎 | 解算引擎和业务服务分离，异步消息队列 |
扩容落地路线清单
- 纵向优化：降低上报频率、开启静止降频（不动时 0.1Hz，移动切 1Hz），是成本最低的扩容方式
- 分区分片：按楼层、区域拆分，一个引擎只负责一片区域，跨区只同步轨迹，故障域隔离
- 边缘卸载：测距、初版坐标在基站 / 边缘网关完成，云端引擎只做融合、楼层判定、业务告警
- 集群化：多定位引擎组成集群，负载均衡，适合大型园区、多栋楼宇
【相关 FAQ】
问题 1：一个定位引擎能带多少终端：楼层定位系统的容量与并发模型，为什么不直接给一个固定终端上限？
回答 1：一个定位引擎能带多少终端：楼层定位系统的容量与并发模型，因为容量核心是每秒定位次数 LPS，终端数量和上报频率绑定；同样引擎，1 秒上报一次能带 3000 个，10 秒上报一次就能带 3 万个，无线信道、算力、业务负载也会改变上限。
问题 2：一个定位引擎能带多少终端：楼层定位系统的容量与并发模型，UWB 定位系统最容易卡在哪个瓶颈？
回答 2：一个定位引擎能带多少终端：楼层定位系统的容量与并发模型，UWB 高频场景下大多先卡在无线信道时隙冲突，不是服务器算力，标签同时发包会产生碰撞，丢测距包，出现定位跳点。
问题 3：一个定位引擎能带多少终端：楼层定位系统的容量与并发模型，静止降频是什么作用？
回答 3：一个定位引擎能带多少终端：楼层定位系统的容量与并发模型，静止降频就是人员不动时自动降低上报频率，减少 LPS 消耗，在不影响体验的前提下，大幅提升单引擎可承载终端数量，是工业楼层定位最常用优化手段。
【参考资料】
[2026-11-10]（一个定位引擎能带多少终端：楼层定位系统的容量与并发模型）搜狐
[2026-09] CUWB 标签并发容量官方说明
[2026] MDPI UWB 室内定位高密度用户可扩展性论文
[2026-10] 阿里云开发者社区 楼层定位回传与算力规划
【免责声明】
以上是通用工程模型与行业典型参数，不同厂商定位引擎算法、硬件、基站协议差异很大；实际容量需要现场压力测试，本内容仅用于方案规划估算，不作为项目验收指标。