SUMO大规模路网仿真性能优化：从GUI卡顿到6分钟跑完的排查指南

前阵子我接了模拟项目X的一个改造：一个中等规模城市局部路网，380个信号灯、3400条边，早高峰3600秒里要涌入4万多次车次。最初我图省事，直接开着sumo-gui看动画，边跑边用TraCI轮询每辆车的坐标做热力图。结果那叫一个惨烈——仿真刚开始还勉强能动，车辆一多，GUI刷新速度掉到每秒零点几仿真步，一个晚上过去连一半都没跑完。后来我冷静下来，认真把SUMO性能优化和调试的路子捋了一遍：先量化、再定位、再逐项砍开销。最后同一套需求，命令行跑6分多钟跑完，内存从3个多G降到不到1个G。

这篇不是讲理论，是把我在这个过程中踩过的坑、试过的办法、以及最后沉淀下来的一套调试checklist整理出来。适合正在用SUMO跑大规模路网、被运行时长和内存折磨过，或者被“车辆莫名消失”“仿真越跑越慢”这类问题卡住的人。如果你只是拿小路口跑demo，前面几节可以跳着看，但第4章的排查思路建议留着，迟早用得上。

1. 从“一晚上跑不完”到“六分钟跑完”：先搞清楚瓶颈在哪

1.1 一个让我抓狂的仿真项目背景

模拟项目X的原始需求并不复杂：复现早高峰时段某局部路网的交通流，输出每5分钟的平均排队长度、路段旅行时间和区域OD旅行时间分布。听起来很常规，但坑在规模。原始路网来自公开地图数据经过转换工具导入，实际仿真范围里还包括了研究区域外围的三四条过境干道，边数飙到3400条。需求方面，早高峰OD矩阵换算下来有4.2万车次，瞬时在线峰值大概在6000到8000辆。

我最初的配置是“全都要”：开着sumo-gui实时看，fcd输出每步写一次全量坐标，同时TraCI脚本里每步循环对每辆车调用getSpeed和getPosition。结果就是开头说的，慢到怀疑人生。更要命的是，仿真跑到中段时，GUI界面上的车辆开始一帧一帧“瞬移”，我以为是数据或者路网出问题了，后来才明白，那是性能跟不上，仿真时间和墙钟时间的比值已经崩了。

现在回头看，这个项目最大的教训不是“SUMO慢”，而是“我根本不知道它慢在哪”。我连一个基线数据都没记录就闷头跑，自然谈不上优化。所以后来我做的第一件事，不是找优化参数，而是先建立一套可重复的测量方法。

1.2 量化基线：时间、内存、每步耗时的测量方法

优化之前先量化，这句话听起来像废话，但在SUMO项目里真没几个人一开始就做。我的做法是固定三件事：固定路网文件、固定路线文件、固定随机种子。然后只改变运行方式和输出配置，记录三类指标：墙钟运行时间、峰值内存、每秒能跑多少仿真步。

墙钟时间和峰值内存在Linux下用一条命令就能拿到：

/usr/bin/time -v sumo -c sim.sumocfg --end 3600 --no-step-log --no-warnings

注意看输出里的Elapsed (wall clock) time和Maximum resident set size。前者是总耗时，后者是峰值内存。如果机器上没有/usr/bin/time，bash内置的time也行，但拿不到峰值内存，只能看耗时。

每秒仿真步数怎么看？最简单的是不开--no-step-log，让SUMO往stderr刷每一步的时间点，单位时间刷出的行数就是步速。但刷屏本身也有开销，所以实际测量时我建议跑两遍：一遍开step log大概看趋势，一遍关掉step log拿准确的墙钟时间。

把基线数据记成一张表，后面每改一个配置就重跑一遍，填同一个表。不要凭感觉“好像快了”，一定要有数字。我后面会给出我自己那张表长什么样，但先别急着看，因为你自己的数据才最重要。

1.3 排除法定位：GUI渲染、数值输出、TraCI调用，到底是谁拖后腿

有了基线，就可以用排除法定位瓶颈。SUMO慢通常不是单一原因，但每个原因对总耗时的贡献差异很大。我的顺序是：先关GUI，再关输出，最后关TraCI轮询。

第一次对比：同样配置，sumo-gui换成纯命令行sumo。我这次改造里，关掉GUI之后运行时间直接砍掉一大半。GUI不会增加仿真的计算量，但它每帧要刷新整个路网的可视化状态，车辆多的时候，这部分开销非常可观。如果你只是要结果不是要演示动画，别犹豫，用命令行。

第二次对比：把fcd输出去掉或加大采样间隔。fcd是浮点车辆轨迹，每步写所有车辆经纬度和速度，数据量极其夸张。我在模拟项目X里把每步输出改成每60步输出一次，运行时间又缩了一大截。这里有个容易忽略的点：输出文件如果落在机械硬盘上，IO会拖慢整体；SSD会好一些，但数据量大了照样有压力。

第三次对比：TraCI脚本里把每辆车每步的get调用注释掉，跑一把空循环。如果明显变快，说明轮询开销是重要瓶颈。这节的具体优化办法放到第3章讲。

排除法做完，我基本确认了两件事：这个场景里的头号瓶颈是GUI渲染，第二是fcd高频输出，第三才是TraCI轮询。顺序可能跟你的项目不一样，但排查思路是通用的——一次只改一个变量，别同时改两个以上，否则你没法判断到底是哪个改动起了作用。

2. 四个马上能用的提速开关：步长、车辆规模、路由生成和并行副本

2.1 step-length：精度换速度，但别把行为模型也换了

SUMO仿真时把连续时间切成离散步长，默认通常是1秒。如果你把--step-length改成0.1秒，理论上3600秒仿真要跑36000个仿真步，而不是3600步。虽然每步的计算量不完全一样，但总步数翻了10倍，运行时间大概率也跟着往上走。

在我的项目里，我把step-length从0.1秒调回0.5秒，速度提升非常明显。0.1秒的小步长确实能让车辆跟驰、变道、排队消散看起来更细腻，但如果你要的只是区域层面的旅行时间、排队长度这类宏观指标，0.5秒甚至1秒往往已经够了。问题是，很多人习惯性地用0.1秒，因为某个教程里这么写过，或者觉得“越精细越正确”，完全没想过自己根本不需要这个精度。

改步长必须重新校准，这个不能省。我建议至少对比一组信号周期内的排队消散时间和路网总旅行时间，确认在你关心的指标上差异可接受。如果差异很大，说明你的模型里有一些对步长敏感的行为参数，这时候不要硬缩步长，先去看看那组参数。

2.2 限定仿真边界：路网裁剪、流量缩放与在线车辆上限

SUMO每跑一个仿真步，都要遍历当前在线车辆，并更新它们所在车道的状态。路网越大、车辆越多，单步开销越大。模拟项目X的原始路网把研究区域外围的过境干道也包了进来，这些干道上的车对研究区域里的排队指标没有任何贡献，纯粹在消耗CPU。

我的处理是用netedit把研究区域外圈的路剪掉，把原本被截断的流量折算成边界节点的进出流。这个步骤有点繁琐，但收益非常直接。路网边数从3400降到2000左右，每步遍历成本明显下降。如果你暂时不想动路网，也可以用scale参数把总需求先缩放一下，比如--scale 0.5，用来跑通流程或者调试脚本是可以的。注意缩放后的结果不能直接当真实结论用。

还有一个容易被忽略的开关是最大在线车辆数。SUMO如果让所有车都进入路网，车流拥堵到一定程度时，系统里可能累积上万辆动弹不得的车，每步都在做无效更新。调试阶段设置一个合理的在线车辆上限，能避免这种“拥堵雪崩”导致的时间爆炸。正式跑结果时这个上限要慎用，压太狠会改变需求加载行为，尤其是出发时间被迫延后的车，旅行时间会失真。

2.3 把路由计算从仿真运行时挪到运行前

SUMO在仿真过程中如果开了动态重路由，车辆会根据路况信息重新计算路径。路径搜索不便宜，车辆一多，重路由风暴会直接拖垮性能。但很多人其实根本不需要动态路径，他们要的只是一个稳定的OD需求下的静态用户均衡或系统均衡路径。这种情况下正确的做法是：把路由分配放到仿真之前完成。

我平时的流程是：OD矩阵先用od2trips转成trips文件，再用duarouter根据路网算路径，得到route文件，SUMO运行时只加载route，不做任何实时路径计算。这一步做完，仿真的单步计算量会明显下降，而且结果还更好解释——至少你知道车辆走的是哪条路，而不是任由仿真内部随机重路由。

如果确实要模拟实时信息诱导，也尽量把重路由触发周期拉大。比如车辆每300秒才评估一次是否换路，而不是每步都去搜索。高频重路由在大型路网里基本是性能灾难，除非你做的研究主题就是动态诱导策略本身，否则先从静态跑通。

2.4 多场景并行：单进程模拟的无奈与xargs的妙用

SUMO的微观仿真引擎核心模拟循环是单进程的，别指望它自动吃满你机器的16个核。但做参数扫描或者多随机种子实验时，可以让每个核各自跑一个SUMO实例。模拟项目X里我要重复跑8个随机种子取平均值，一开始串行跑，后来改成并行，8个种子总耗时几乎等于原来跑1个的时间。

Linux下我用xargs就很方便：

seq 1 8 | xargs -P 4 -I{} sh -c 'sumo -c sim.sumocfg --seed {} --tripinfo-output tripinfo_{}.xml'

-P 4表示同时跑4个进程，你可以按CPU核心数调整。注意每个进程的输出文件名一定要分开，否则多个进程抢同一个文件，轻则互相覆盖，重则写出损坏数据。跑完再用Python脚本把tripinfo汇总，基本不费事。

并行的一大坑是内存。8个SUMO实例同时跑，内存峰值会叠加。我机器是16G内存，跑模拟项目X单实例峰值不到1G，所以并行8个没问题；如果你单实例已经吃掉5G，就不要无脑开8路。并行之前先看一眼第1章说的峰值内存数据。

3. TraCI调优与调试：轮询、订阅和采样周期

3.1 为什么“每辆车每步get一次”能把仿真拖垮

TraCI本质上像一种远程接口协议，你调用一次getSpeed，背后要经过进程间通信、数据序列化、请求响应处理。单次调用的绝对耗时可能微秒级，但架不住数量大。假设路网里同时有6000辆车，你每步对每辆车调2个get变量，那就是每秒几万次调用。这些调用叠加起来，比仿真计算本身还贵。

我一开始写TraCI脚本时就是这种最朴素的写法：循环里嵌套一个for veh_id in veh_list，个个都get。跑了一会儿发现，脚本倒是简单，仿真时间却成倍拉长。所以第一原则是：不要在仿真循环里对每辆车做高频单点轮询。要拿实时状态，就用订阅机制。

3.2 用批量订阅替代高频轮询

TraCI提供了订阅机制，让SUMO在每个仿真步结束时把你关心的变量批量推送回来。你用不着每辆车单独去问，只需要在车辆出现时订阅一次，后续整批取结果。大致思路是这样：

import traci traci.start(["sumo", "-c", "sim.sumocfg"]) # 车辆出现后订阅它，后续数据由SUMO主动推送 traci.vehicle.subscribe("veh_0", ["speed", "position"], 0, 3600) step = 0 while step < 3600: traci.simulationStep() data = traci.vehicle.getSubscriptionResults("veh_0") # 在这里批量处理 data，而不是逐条get step += 1 traci.close()

注意，不同SUMO版本的TraCI API细节会有些差异，用之前先查你本地版本的文档。思路比接口重要：一次订阅代替一百次轮询。如果只关心某个交叉口附近的车辆，还可以用context subscription，按区域订阅周围的车辆状态，比手动维护车辆列表更高效。

订阅也不是越多越好。如果你把整个路网所有车辆的十几个变量全部订阅，每步推送的数据包会很大，内存也会涨。我自己只在需要采集热力图的时段订阅位置和速度，并且在下一次车辆重生前取消旧的订阅，避免订阅列表越积越长。

3.3 输出越少，跑得越快：tripinfo与fcd的正确用法

仿真结果输出是另一大隐藏开销。很多新手喜欢一上来就开fcd输出，因为“数据全”，结果跑完一看文件好几个G，跑的时候还慢得要死。

我的习惯是分层次使用输出：日常调试阶段只开--tripinfo-output，它每辆车只写一行记录，包含出发时间、到达时间、旅行时长、路径长度等，信息量足够回答大部分问题。需要看某条路段上的排队变化，就开--summary-output，它按固定间隔输出全局或全区统计，数据量比fcd小几个量级。只有当你真的要逐车逐位置重建轨迹时，才开fcd，而且一定要把采样周期拉大。比如原本每步输出一次，改成每30步或60步输出一次。对大多数排队长度和旅行时间分析来说，5秒或10秒采样间隔完全够用，没必要每0.1秒存一个点。

另外一个实用技巧：输出文件路径放到本地SSD或内存盘上。如果网络磁盘很慢，IO等待会反过来拖慢仿真。我自己跑大实验时会把输出写到/tmp，跑完再转存，能省不少时间。

3.4 给自己的脚本加“事件日志”

TraCI调试脚本时，另一个后悔没早做的事是：不要每步print状态。你print一句到终端，看似没多少开销，但仿真跑几千步，几千辆车，输出重定向到文件之后体积可能比fcd还大，而且根本没法看。

正确的做法是给脚本加事件日志。车辆出发时记一条“depart”，到达时记一条“arrive”，速度异常偏低时记一条“stuck”，堵到设定阈值时记一条“jam”。用Python的logging模块，按级别分开存，日常跑只输出warning，追查问题时再临时把某个模块调成debug。这样既不影响性能，排查问题也有迹可循。

4. 调试那些“看似随机”的问题：种子、警告和消失的车辆

4.1 先把复现环境钉死：固定种子与save-configuration

SUMO很多行为涉及随机性，比如车辆速度的扰动、部分出发时间、信号灯配时里如果带了随机相位，都会让结果每次不一样。如果你不固定随机种子，一个bug可能会“时隐时现”，追起来极其痛苦。

我现在的习惯是每条实验命令里都带--seed 42这样的固定值。调试阶段用同一个固定种子，至少在同一个版本里结果可复现。若要确认问题是不是随机性导致的，再换两三个种子对比，而不是每次跑出来都不一样。

还有一个很实用的参数是--save-configuration，它能把当前所有命令行参数、路网文件路径、需求文件路径写进一个配置文件。很多人调试时在命令行里临时加了一堆参数，跑通了，但过两天想复现，完全忘了当时加了什么。用这个参数把配置存下来，连同SUMO版本号一起记进实验记录，复现问题就有据可查。

4.2 警告不是噪声，每一条都有来历

SUMO跑起来会在stderr里输出大量警告。新手的常见操作是看到刷屏就心慌，或者干脆加上--no-warnings眼不见心不烦。但警告恰恰是问题线索，尤其性能异常和车辆行为异常，绝大多数都能在警告里找到伏笔。

我总结过一张常见的“警告-原因-动作”对照表：

这几个问题不只是正确性问题，也是性能问题。车辆反复尝试插入或反复搜索路线，都会额外消耗CPU。我见过一次仿真越跑越慢，回头一查，是几百辆车在一条断头路上反复被teleport，每隔几秒就触发一次重定位，纯属路网问题。

4.3 一次“车辆凭空消失”的完整排查

模拟项目X调试过程中遇到过一个最典型的“灵异事件”：fcd轨迹里，某辆车从路网中段开始突然消失，tripinfo里也没有它的到达记录。我最早怀疑是TraCI订阅漏数据，后来发现纯命令行跑也一样，排除了脚本问题。

于是用sumo-gui打开同一份配置，按车辆ID追踪。观察发现，车辆在某个交叉口前排队等待，等了很久之后被SUMO标记为teleport，然后被挪到下游的一个车道。由于teleport发生的一瞬间位置不连续，fcd输出里看起来就像“凭空消失”。再去查原路网，发现那个交叉口的转向连接被人为删掉了一条，车辆没有合法转向路径，只能停在原地等，直到超出teleport阈值。

修复办法是用netedit把缺失的转向连接补上，重新跑一遍，车辆正常通过。这个问题彻底改变了我调试时的第一反应：车辆行为异常，先查路网，再查路由，最后才怀疑脚本。路网几何和连接关系是所有仿真的地基，地基有问题，上层什么都说不准。

4.4 模型不收敛、交通流锁死的检查顺序

还有一种情况不是车辆消失，而是整个路网开始“冻结”：车辆速度渐次变成0，排队长度一路向上，仿真每步耗时越来越长。遇到这种情况，我从上到下按顺序排查。

先看信号灯控制逻辑。如果某个交叉口相位设置不当，出现长周期或者某个方向永久红灯，排队会以这个交叉口为源头向上游蔓延。再看道路限速和车辆最大速度设置。如果导入路网时某条快速路限速被设成10km/h，那它就会变成人为瓶颈。然后看公交站点、停车位和车道功能，公交车停靠会阻塞一条车道，如果旁边没有绕行条件，排队效应会被放大。最后检查teleport参数。--time-to-teleport设得太大，会让已经堵死的车长时间占据车道，进一步恶化拥堵；设得太小，又会出现大量不自然的跳跃。一般是根据你的仿真场景标定一个合适值，没有通用答案。

遇到锁死不要慌，先把输出降到最低，只开summary输出，观察拥堵是从哪个交叉口先开始的。盯住源头，比在全局数据里猜要快得多。

5. 优化效果到底怎么样：我的对比数据与经验排序

5.1 同一路网、同一种子，只改一个变量

最后给一组我在模拟项目X实测下来的对比数据。路网和需求完全一样，随机种子固定，只改一个变量。不同机器、不同路网规模下数字会变，但量级关系差不多。

你可以看到，每一步单看都有缩水，但叠加起来才是最后“6分钟跑完”的结果。而且峰值内存的下降比时间更明显，这让后面的并行多种子实验变得非常从容。

5.2 各项优化的收益排序与取舍

如果要在新项目里重来一次，我会按这个优先级处理：先关GUI，这是投资最小收益最大的一步；然后删掉或大幅降低fcd输出，我见过太多项目被无意义的全量轨迹拖垮；接着评估step-length能不能放宽到0.5秒甚至1秒，这需要校准支撑；再然后是TraCI脚本改造，订阅替代轮询；最后才是路由预计算和并行化。

有几个取舍要特别说清楚。降低fcd采样会造成轨迹曲线不够平滑，如果你要输出的图是“平均速度-时间”这种统计量，影响很小；如果要做单辆车的微观轨迹动画，采样间隔太大会出现瞬移感，这时候要退一步。step-length也一样，它会影响排队消散和变道行为，不能只盯运行时间。TraCI订阅看起来满分，但如果订阅了太多变量或太多车，压力会转移到内存上，要控制范围。

并行化的取舍更直接：它能用机器换时间，但会引入输出文件管理的复杂度。建议先做完前面的优化，再考虑并行。不要一上来就想着开100个进程，模型本身跑得慢，并行只是让错误跑得更快。

5.3 我给自己的调试checklist

现在每次开新仿真任务，我都会按这个清单走一遍：

1. 先用最干净的命令行跑通：关GUI、关fcd、单种子、单步长，确认能完成且结果可解释。
2. 记录基线时间和峰值内存，写进实验笔记。
3. 逐步打开我真正需要的输出项，每打开一个就重跑一次，确认它带来的时间开销可接受。
4. TraCI脚本先实现订阅，再实现逻辑，不在循环里做任何高频get。
5. 遇到异常行为，先用GUI单步追踪，再查路网连接，再查路由文件，最后才怀疑平台本身。
6. 多种子实验时固定种子、固定版本、固定命令，并行只加在最后。

这个清单看起来平平无奇，但真的能救命。尤其第1条，很多人急着看结果，一上来就是全配置、全输出，最后连问题出在哪儿都不知道。

我个人的体会是，SUMO的性能问题绝大多数不是平台不行，而是我们把它当成了一个“一键能跑”的黑盒子。它其实更像一个精密的仪器，你得先搞清楚它每一步在算什么、在写什么、在跟谁通信。你对着基线数据一刀一刀砍，砍到后面会发现，真正重要的不是某个参数多神奇，而是你终于知道自己到底需要什么结果、哪些过程可以舍掉。

这次项目改造完后，我又把同样的方法带到了另一个更大的路网上，效果依然稳定。性能优化不是一次性工作，而是伴随仿真模型生命周期反复做的事。每次修改路网或需求，都值得重新跑一次基线。保持这个习惯，你的SUMO项目会少掉很多“跑不动”的深夜。