You need to agree to share your Hugging Face information to access this model

This repository is publicly accessible, but you have to accept the conditions to access its files and content.

Log in or Sign Up to review the conditions and access this model content.

DeepSignal S1

GitHub · Source Code & Reproduction

Traffic signal decisions, directly from intersection views.

The visual decision series in the DeepSignal model family · Current release DeepSignal-S1-1.0

S1 stands for System One, emphasizing fast, direct visual decisions: combining intersection views and signal state to produce legal control actions.

English | 简体中文 · DeepSignal family

Watch demos · Explore results · Try a decision · Request model access · Full reproduction

Design and Strengths

Visual understanding and signal decisions in one model. Three temporal frames, intersection information and signal state produce a legal control action and candidate probabilities directly, without a separate vehicle-detection and counting stage.

Measured speed: unquantized BF16, RTX 5090, 6,823 requests; 485 ms on average and 99.08% under one second. How it works · Full results · Latency statistics

Results are from controlled simulations. Latency measures model requests only, excluding camera capture, rendering and signal execution.

Results

Two evaluation settings, reported separately:

  • Nine-junction test: the same model is evaluated separately at nine simulated intersections, including T-junctions and four-arm intersections. Each run controls one junction; these tests do not evaluate coordination between junctions.
  • Standard simulation: the Town10HD virtual-city map in CARLA, with five traffic regimes at one four-arm intersection. Town10HD names the map.

This evaluation examines the traffic-control performance of direct visual decisions and the effects of changes in visual input. YOLO+MP combines YOLO vehicle detection with Max Pressure signal control; the comparison measures vehicle waiting, queues and journey time.

Clean views: comparable to YOLO+MP, with small gains on some metrics

Across 72 cases at the nine junctions, S1 reduces mean journey time by 1.36% relative to YOLO+MP; across five standard simulation regimes, mean journey time is essentially tied. Overall, S1 delivers comparable control in clean views, with small gains on some metrics.

The fixed baseline is a reasonable fixed-time plan optimized through engineering design, with parameters determined and frozen before evaluation and held unchanged throughout. Against this plan, S1 reduces mean journey time by 18.17% and 33.77% in the two settings, respectively.

Visual perturbations: control performance under input changes

Defocus, blur, camera shifts and shake can affect vehicle detection or lane-region alignment, with expected downstream effects on count-based signal control. In the two settings and four perturbations tested here, S1 records lower mean waiting, queues and journey time than YOLO+MP. Full data and charts covering all eight groups are provided in the results below.

Each perturbation covers one case at each of the nine junctions and five cases in standard simulation, using one seed per scene. YOLO lane regions are calibrated on clean views and frozen; fixed camera shifts are not recalibrated. These results apply to the tested setup and do not establish real-road, night-time or adverse-weather performance.

Clean views: three controllers — full values and three-metric chart
SceneConditionCasesControllerMean wait (s/veh)Mean queue (veh)Mean journey (s/veh)
Nine-junction testClean72S145.82310.473107.316
Fixed-time plan68.54515.525131.149
YOLO+MP46.89010.559108.792
Standard simulationClean5S120.4503.56538.215
Fixed-time plan40.4565.39857.699
YOLO+MP20.2153.58638.220
Perturbed views: S1 vs YOLO+MP — full values and three-metric chart
SceneConditionCasesControllerMean wait (s/veh)Mean queue (veh)Mean journey (s/veh)
Nine-junction testDefocus σ=99S176.08215.795141.033
YOLO+MP104.86231.040167.484
Nine-junction test31 px motion blur9S167.38217.232131.573
YOLO+MP124.59130.184188.343
Nine-junction testFixed yaw ±15° / pitch ±8°9S163.68115.445129.042
YOLO+MP87.00821.179154.362
Nine-junction testDynamic shake 5°9S163.39816.171128.251
YOLO+MP72.15317.905137.608
Standard simulationDefocus σ=95S127.5114.10144.431
YOLO+MP92.9709.754109.153
Standard simulation31 px motion blur5S120.2763.58138.102
YOLO+MP111.25610.239127.707
Standard simulationFixed yaw ±15° / pitch ±8°5S119.2263.45537.107
YOLO+MP205.09113.668217.405
Standard simulationDynamic shake 5°5S119.1333.32137.203
YOLO+MP21.4873.53339.882

Metrics: lower is better for all three. Mean wait includes stopped and insertion waiting; mean queue counts halted vehicles; journey time starts at planned departure, with unfinished vehicles contributing elapsed time at the evaluation cutoff. Detailed definitions.

Means in the tables and clean-view charts are shown to three decimal places to preserve small differences lost to rounding; this does not imply millisecond measurement accuracy or statistical significance.

Detailed interpretation and real-world context

What the Results Show

Clean Views: Assessing the Feasibility of Direct Visual Decisions

In clean views, S1 is broadly comparable to YOLO+MP, with small gains on some metrics; standard-simulation mean journey time is essentially tied. This supports the feasibility of producing signal actions directly from images. Broader evaluation is needed to establish whether the small differences observed across these limited scenes and seeds are consistent.

Visual Perturbations: Understanding the Effects of Input Changes

Traffic demand may stay the same while camera input changes because of lighting, maintenance or vibration. The four tests target distinct imaging problems: can S1 continue making effective signal decisions when images lose sharpness or stability, or no longer match the original viewpoint?

  • Defocus: inaccurate focus softens vehicle outlines. Mixed lighting, including headlights at night, can disrupt autofocus; manual focus adjustment or lens replacement can also leave the intersection out of focus. Softer vehicle and lane edges make recognition and counting harder.
  • Motion blur: movement during exposure creates directional smearing. In low light at dusk or night, a camera may use longer exposures. Moving vehicles or camera movement during exposure can then smear outlines and obscure separation between vehicles.
  • Fixed camera-angle shifts: a stable view from a changed direction. For example, maintenance-related re-aiming or a shifted mount can move lane and stop-line positions in the image, even after the camera becomes steady. Previously drawn lane regions may no longer align. Our comparison calibrates YOLO at the original pose, then holds the changed camera angle fixed without recalibration.
  • Dynamic shake: the viewpoint keeps moving over time. Wind gusts or vibrations from nearby heavy vehicles can shake a pole-mounted camera, shifting vehicle and lane positions across successive frames. Unlike a fixed angle shift, this disturbance continues over time.

These tests examine how visual input changes affect the complete control system. In particular, fixed camera shifts can combine changes in detection quality with lane-region misalignment, so the results should be interpreted in light of the no-recalibration setting. Richer traffic-scene understanding requires dedicated traffic-event evaluations.

The tests simulate visual changes that these real-world problems can produce; they are not completed night-time field or real-world adverse-weather validation. Real-world context and technical sources.

Sub-Second Decisions From a Visual Model

Across 6823 unquantized RTX 5090 decision requests, latency averages 485 ms, with 99.08% below one second; steady-state requests average 477 ms. System One emits structured control actions directly, without waiting for a long textual response, combining visual understanding, traffic-control performance and fast decisions.

How It Works

The model receives three temporal frames (a four-second window sampled every two seconds), static intersection information, current signal state and legal actions. It returns an action and candidate-action probabilities, without simulator vehicle counts or future arrival plans.

System One emphasizes fast, structured decisions without generating a token-by-token reasoning narrative. S1 draws on the decision paradigm illustrated by Jev and OneJev. It runs locally and does not call the commercial Jev service.

One 1.0 checkpoint covers simulations of nine junctions in the nine-junction evaluation (T-junctions and four-arm intersections) and five traffic regimes at one junction in the standard simulation setting. Training includes these scenes; using one checkpoint across them is not evidence of generalization to unseen intersections.

Inference Performance

Scope Count Mean Median P95 Max Under 1 s
All calls 6823 485.4 ms 479.0 ms 494.0 ms 2304.0 ms 99.08%
First call per run 133 911.1 ms 495.0 ms 1460.2 ms 2304.0 ms 52.63%
Subsequent calls 6690 476.9 ms 479.0 ms 493.0 ms 675.0 ms 100.00%

Statistics cover 133 S1 evaluation cases and 6823 decision requests with the unquantized BF16 model. Latency measures model decision requests, excluding camera capture, rendering and signal execution; first calls include initialization effects.

Deployment value: sub-second model decisions make consumer-GPU signal-control workstations a practical target. We also tested the unquantized model on an RTX 4090, observing approximately 900 ms per decision. This independent observation uses measurement conditions that have not yet been aligned and is not included in the table. Quantization and edge deployment are future directions for reducing compute requirements.

Runtime Requirements

Item Current guidance
Precision Unquantized BF16
Tested inference hardware RTX 5090; a separate RTX 4090 observation is approximately 900 ms
Model server Linux, NVIDIA GPU, Python 3.12; install dependencies from the complete model package
Single decision Use the included three-frame request; no simulator required
Full simulation Python 3.10, SUMO 1.18.0 and the matching CARLA environment; see reproduction instructions

A verified minimum-VRAM configuration has not been published; the tested hardware is not a minimum requirement.

Future Potential and Research Directions

We see S1's longer-term potential in expanding its decision-making capabilities through scene understanding. Visual input contains information beyond vehicle counts, such as whether road space is obstructed, which events are causing congestion, and the movement needs of different road users. Combining this information with traffic rules and signal state could support appropriate actions in more complex situations, creating greater room for future capability development.

The current results support the feasibility of direct visual decisions in controlled simulations. Our team is actively pursuing the following next-stage research directions to evaluate this potential; complex traffic-event handling and multi-junction coordination have not yet been validated.

  • Progress from observing traffic flows to understanding traffic scenes. With additional scenario data, traffic rules and safety constraints, explore understanding roadworks, incident blockages, emergency vehicles, and concentrated pedestrian or cyclist flows, assessing their effects on available road space, movement priorities and downstream congestion risk, and adapting signal actions accordingly.
  • Extend single-junction decisions to coordinated control. Explore sharing queues, signal states and incoming-flow information between adjacent junctions to coordinate release timing, support arterial green waves, limit downstream queue spillback and improve network traffic flow. This requires new communication mechanisms and network-level evaluation.
  • Evaluate broader applicability and reduce deployment costs. Run independent evaluations at previously unseen junctions, at night and in adverse weather, and explore quantization and edge deployment to assess transferability, response times and compute requirements.

Download and Quickstart

  • Watch demos: previews, GitHub videos and result data need no approval.
  • Try one decision: request access on the model page, download the complete model folder, then start the local server below.
  • Run a full simulation: separately request scene assets and follow full reproduction for v3 assets and scene-specific environments.

1. Download and start the model server (Linux, NVIDIA GPU, Python 3.12; model access approved):

git clone https://github.com/AIMS-Laboratory/DeepSignal-S1.git
cd DeepSignal-S1
python3.12 -m venv .venv-inference
.venv-inference/bin/pip install -U huggingface_hub
.venv-inference/bin/hf auth login
.venv-inference/bin/hf download AIMS2025/DeepSignal-S1 --exclude 'gguf/*' --local-dir ../DeepSignal-S1-model
.venv-inference/bin/pip install -r ../DeepSignal-S1-model/requirements.txt
.venv-inference/bin/python scripts/serve_model.py --model ../DeepSignal-S1-model --port 18404 --device cuda:0

2. In a second terminal, send the included real three-frame request (from the same repository directory):

curl --fail http://127.0.0.1:18404/v1/decide \
  -H 'Content-Type: application/json' \
  --data-binary @examples/nansha-defocus-request.json

The server should report DeepSignal-S1-1.0 and return a selected action with candidate-action probabilities. This request checks inference, not closed-loop traffic performance. Approved model access does not provide a hosted API; a full fresh-download closed-loop replay has not yet been certified.

Evaluation Scope

  • Engineering-optimized fixed baseline: a reasonable fixed-time plan optimized through engineering design, with parameters determined and frozen before evaluation and held unchanged throughout. The nine-junction evaluation uses the published per-intersection plans and the standard simulation setting uses 31/6/31/6 s.
  • Visual comparison: clean views compare all three controllers; perturbations compare S1 with YOLO+MP. Camera shifts occur after YOLO lane-region calibration, without recalibration.
  • Scope: results come from the two controlled simulation settings; deployment on real roads and under real weather remains to be validated.

See evaluation protocol, metric definitions, and media delivery.

Five traffic demand scenarios

Expand traffic rates and timing

All five regimes use the same four-way junction, varying directional demand, load and peak timing rather than road geometry. The table gives the settings used in the current evaluation.

Demand scenarioFlow per approach
(vehicles/hour)
Temporal patternControl challenge
Balanced flowAll four: 360 eachConstant throughoutBasic control with similar
demand in all directions
Sustained
directional imbalance
E and W: 600 each
N and S: 120 each
Constant
major/minor ratio 5:1
Prioritize persistently
busier approaches
Higher-load
directional imbalance
E and W: 750 each
N and S: 150 each
Constant
still 5:1
25% more total demand
than the preceding regime
Time-varying peakAll approaches:
200 → 700 → 200
0-60 s
60-120 s
from 120 s
Adapt to rising demand
and peak recovery
Shifted peak timingAll approaches:
200 → 200 → 700
0-60 s
60-120 s
from 120 s
Adapt to changes
in peak timing

Flows are expected arrival rates per approach, not per lane or exact hourly vehicle counts; arrivals are sampled randomly. All regimes use 70% straight, 15% left and 15% right turns. Time starts at simulation startup, with the final rate held until demand generation ends. Shifted peak timing reorders the time-varying rates by seed; the table shows the configuration behind the current results. Controllers receive identical vehicle plans.

Lane regions are calibrated on clean views and frozen; fixed shifts are not recalibrated. Dynamic shake peaks at 5° yaw/pitch and 2.5° roll.

Contact: dalei@scu.edu.cn

简体中文

GitHub 主仓库 · 源码与复现

从路口画面直接作出交通信号决策。

DeepSignal 模型家族的视觉决策系列 · 当前版本 DeepSignal-S1-1.0

S1 代表 System One,强调快速、直接的视觉决策:结合路口画面与信号状态,输出合法控制动作。

English | 简体中文 · 品牌首页

看演示 · 看结果 · 试一次决策 · 申请模型 · 完整复现

核心创新与特色

视觉理解与信号决策,在同一个模型里完成。 连续三帧画面、路口信息与信号状态共同输入,直接返回合法控制动作及候选概率;无需独立的车辆检测与计数环节。

速度实测: 未量化BF16模型、RTX 5090、6,823次请求,平均 485毫秒,99.08% 低于一秒。 工作原理 · 完整结果 · 延迟统计

以上效果来自受控仿真;延迟仅计算模型请求,不包含相机采集、渲染和信号执行。

评测结果

两组场景,分别评测:

  • 9个路口独立测试: 使用同一模型,分别在9个仿真路口进行测试,包含丁字和十字路口。每次独立控制一个路口,考察不同路口形态下的表现;此处未测试多路口协同控制。
  • 标准仿真场景: 采用CARLA仿真软件的 Town10HD虚拟城市地图,在其中1个十字路口测试5类车流;Town10HD是地图名称。

本次评测关注直接视觉决策的交通控制效果,以及视觉输入变化对控制表现的影响。YOLO+MP 指由YOLO车辆检测与最大压力(Max Pressure)信号控制组成的方案;比较指标为车辆等待、排队和行程。

正常画面:与YOLO+MP相当,部分指标略优

在9个路口独立测试的72个案例中,S1相对YOLO+MP的平均行程降低 1.36%;标准仿真场景的五类车流中,两者平均行程基本持平。正常画面下,S1的整体控制表现可与YOLO+MP媲美,部分指标略优。

固定对照采用经工程优化的合理固定配时方案,参数在评测前确定并冻结,评测期间保持不变。与该方案相比,S1在上述两组场景的平均行程分别降低 18.17% 和 **33.77%**。

视觉干扰:输入变化下的控制表现

失焦、模糊、机位偏移和抖动可能影响车辆检测或车道区域匹配,继而影响基于检测计数的信号控制,这类影响可以预期。在本次两组场景、四类干扰的测试中,S1的平均等待、排队和行程均低于YOLO+MP。完整数据与全部八组图表见下方结果。

每类干扰在9个路口各测试1个案例,在标准仿真场景测试5个案例,均为单种子仿真。YOLO车道区域在正常机位标定后冻结,固定偏角测试不重新标定。结果适用于本次设置,尚不代表真实道路、夜间或恶劣天气验证。

正常视觉:三方比较 — 完整数值与三指标图
场景条件案例数控制方法平均等待(秒/车)平均排队长度(辆)平均行程(秒/车)
9个路口独立测试正常72S145.82310.473107.316
固定配时方案68.54515.525131.149
YOLO+MP46.89010.559108.792
标准仿真场景正常5S120.4503.56538.215
固定配时方案40.4565.39857.699
YOLO+MP20.2153.58638.220
特殊视觉:S1与YOLO+MP — 完整数值与三指标图
场景条件案例数控制方法平均等待(秒/车)平均排队长度(辆)平均行程(秒/车)
9个路口独立测试失焦σ=99S176.08215.795141.033
YOLO+MP104.86231.040167.484
9个路口独立测试31像素运动模糊9S167.38217.232131.573
YOLO+MP124.59130.184188.343
9个路口独立测试固定偏航±15° / 俯仰±8°9S163.68115.445129.042
YOLO+MP87.00821.179154.362
9个路口独立测试动态抖动峰值5°9S163.39816.171128.251
YOLO+MP72.15317.905137.608
标准仿真场景失焦σ=95S127.5114.10144.431
YOLO+MP92.9709.754109.153
标准仿真场景31像素运动模糊5S120.2763.58138.102
YOLO+MP111.25610.239127.707
标准仿真场景固定偏航±15° / 俯仰±8°5S119.2263.45537.107
YOLO+MP205.09113.668217.405
标准仿真场景动态抖动峰值5°5S119.1333.32137.203
YOLO+MP21.4873.53339.882

指标说明: 三项指标均越低越好。平均等待包括停车等待和入网等待;平均排队长度以停车车辆数计;平均行程从计划出发计时,未完成车辆计入评估截止时的已耗时。详细指标定义。

表格与正常视觉图表的均值统一保留三位小数,以免舍入掩盖细小差异;这不代表测量具有毫秒级精度,也不表示差异具有统计显著性。

详细结果解读与现实场景对应

结果解读

正常视觉:验证直接视觉决策的可行性

正常画面下,S1的控制表现与YOLO+MP总体相当,部分指标略优;标准仿真场景的平均行程基本持平。这支持了直接从画面生成信号动作的可行性。当前有限场景与种子下的小幅差异,还需要更广泛评测来判断其稳定性。

视觉干扰:理解输入变化对控制的影响

现实路口的车流未必改变,摄像头输入却可能因光照变化、设备维护或风振而发生变化。四类测试分别对应不同的成像问题,考察S1在画面不再清晰、稳定或保持原机位时,能否继续作出有效的信号决策。

  • 失焦:对焦不准,车辆轮廓变软。 夜间车灯等复杂光源可能干扰自动对焦,人工调焦或更换镜头后也可能没有重新调好焦点。车辆边缘和车道细节随之变得模糊,增加识别与计数的难度。
  • 运动模糊:曝光期间的移动形成拖影。 傍晚或夜间光照不足时,摄像头可能采用更长曝光;车辆运动或曝光期间的相机晃动便可能形成方向性拖影,使车辆形状和相邻车辆的边界更难分辨。
  • 固定角度偏移:调整后稳定在新的机位。 例如检修后重新调整视角,或支架发生偏转:画面已经稳定,但停车线和车道在图像中的位置改变了,原先画好的车道区域可能不再对应。我们的对比先在正常机位为YOLO画线,再固定改变相机角度,不重新画线。
  • 动态抖动:视角随时间来回变化。 高杆摄像头可能受到阵风或邻近重型车辆引起的振动影响,车辆和车道在连续画面中的位置随之摆动;这与调整后保持不动的固定偏角不同。

这组测试观察的是视觉输入变化对整套控制方案的影响。尤其在固定偏角条件下,检测质量和车道区域错位的影响可能叠加,结果应结合不重新标定的设置理解。更丰富的交通场景理解能力,需要通过专门的交通事件任务来验证。

上述测试模拟的是这些现实问题可能造成的视觉变化,不等同于已经完成夜间现场或真实恶劣天气验证。现实场景对应与资料依据。

亚秒级决策:视觉模型也能快速响应

未量化模型在RTX 5090上的 6823 次决策请求平均耗时 485毫秒,99.08% 的请求低于1秒;稳态请求平均 477毫秒。System One直接输出结构化控制动作,无需等待长篇文字生成,让视觉理解、交通控制效果与快速响应能够同时兼顾。

工作原理

连续三帧画面(4秒观察窗、间隔2秒)、静态路口信息、当前信号状态与合法动作共同输入模型;模型返回动作及候选动作概率。无需提供仿真车辆计数或未来到达计划。

System One 强调快速、直接输出结构化决策,不生成逐字展开的长篇推理文字。S1借鉴 Jev 与 OneJev 所体现的决策范式,在本地运行模型,不调用商业Jev服务。

同一份1.0权重用于9个不同路口(丁字和十字路口),以及标准仿真场景一个十字路口的五类车流。训练覆盖这些场景;此处不将跨场景使用等同于未见路口泛化验证。

推理性能

范围 数量 平均 中位数 P95 最大值 小于1秒
全部请求 6823 485.4 ms 479.0 ms 494.0 ms 2304.0 ms 99.08%
每回合首请求 133 911.1 ms 495.0 ms 1460.2 ms 2304.0 ms 52.63%
后续请求 6690 476.9 ms 479.0 ms 493.0 ms 675.0 ms 100.00%

统计覆盖133个S1评测案例、6823次决策请求,使用未量化BF16模型。延迟仅计算模型决策请求,不含相机采集、渲染及信号执行;首请求包含初始化影响。

部署价值: 亚秒级模型决策让消费级GPU信控工作站成为可考虑的落地方向。同时,我们也在 RTX 4090 上测试了未量化模型的推理速度,单次决策约 900毫秒;这是一项独立测试观测,测量条件尚未对齐,不计入上表。后续将探索量化与边缘部署,进一步降低算力需求。

运行要求

项目 当前说明
模型精度 未量化 BF16
已测试推理硬件 RTX 5090;RTX 4090另有约900毫秒的独立观测
模型服务 Linux、NVIDIA GPU、Python 3.12;安装完整模型包内的依赖
只试一次决策 使用仓库附带的三帧请求,无需启动仿真器
完整仿真 Python 3.10、SUMO 1.18.0、匹配场景的CARLA环境;见复现说明

最低显存需求尚未形成经验证的公开配置;以上测试硬件不代表最低要求。

未来潜力与研究方向

我们更看重S1通过场景理解拓展决策能力的潜力。 视觉输入包含车辆数量之外的信息,例如道路是否被占用、拥堵由何种事件引起、不同交通参与者有什么通行需求。将这些信息与交通规则和信号状态结合,有望让模型针对更复杂的情况选择合适的动作,为后续能力提升打开更大的空间。

当前结果展示了直接视觉决策在受控仿真中的可行性。我们团队正围绕以下方向推进下一阶段研究,逐步验证上述潜力;复杂交通事件处理和多路口协同能力尚未完成验证。

  • 从观察车流进一步走向理解交通场景。 在补充场景数据、交通规则与安全约束的基础上,探索理解施工占道、事故阻塞、紧急车辆以及行人和非机动车集中通行等情况,判断事件如何影响可通行空间、放行顺序和下游拥堵风险,并据此调整信号动作。
  • 从单路口决策扩展到多路口协同。 探索共享相邻路口的排队、信号状态和到达车流信息,协调放行时机,研究干道绿波衔接、下游拥堵回溢抑制与区域通行效率提升。这需要新增通信机制和路网级评测。
  • 验证更广的适用范围并降低部署成本。 在未参与训练的新路口、夜间和恶劣天气下独立评测,并探索模型量化与边缘部署,进一步验证可迁移性、响应速度与算力需求。

下载与快速开始

  • 看演示: 本页预览、GitHub视频与结果数据无需审批。
  • 试一次决策: 先在模型页申请访问,下载完整模型目录,然后按下方启动本地服务。
  • 运行完整仿真: 另行申请场景资产,按完整复现说明配置v3资产与对应场景环境。

1. 下载并启动模型服务(Linux、NVIDIA GPU、Python 3.12;账号已获模型访问权限):

git clone https://github.com/AIMS-Laboratory/DeepSignal-S1.git
cd DeepSignal-S1
python3.12 -m venv .venv-inference
.venv-inference/bin/pip install -U huggingface_hub
.venv-inference/bin/hf auth login
.venv-inference/bin/hf download AIMS2025/DeepSignal-S1 --exclude 'gguf/*' --local-dir ../DeepSignal-S1-model
.venv-inference/bin/pip install -r ../DeepSignal-S1-model/requirements.txt
.venv-inference/bin/python scripts/serve_model.py --model ../DeepSignal-S1-model --port 18404 --device cuda:0

2. 在另一个终端发送仓库附带的真实三帧请求(进入同一仓库目录):

curl --fail http://127.0.0.1:18404/v1/decide \
  -H 'Content-Type: application/json' \
  --data-binary @examples/nansha-defocus-request.json

服务应报告版本 DeepSignal-S1-1.0,响应包含模型选择的动作及候选动作概率。该请求测试模型接口,不代表完成闭环交通评测。模型访问获批不提供远程托管API;从公开下载开始的完整闭环复跑尚未完成认证。

评测说明

  • 经工程优化的固定基线: 采用经工程优化的合理固定配时方案,参数在评测前确定并冻结,评测期间保持不变;9个路口独立测试使用已发布的各路口配时表,标准仿真场景使用31/6/31/6秒。
  • 视觉对照: 正常视觉比较三方,特殊视觉比较S1与YOLO+MP;相机偏移发生在YOLO画线之后,不重新标定。
  • 适用范围: 结果来自9个路口独立测试与标准仿真场景的受控仿真,真实道路和天气条件下的部署效果仍需验证。

详见评测说明、指标定义和素材交付说明。

5类交通需求场景

展开车流参数和时间设置

五类车流均设置在同一个十字路口,区别在方向分配、流量大小和高峰出现时点,而不是五个不同路口。下表列出当前评测使用的设置。

交通需求场景每个进口方向的流量
(辆/小时)
时间变化考察重点
均衡车流东、西、南、北各360全程恒定四向需求相近时
的基本控制能力
持续方向不均衡东、西各600
南、北各120
全程恒定
主次方向流量比5:1
持续向高需求方向
分配绿灯
更高流量的不均衡东、西各750
南、北各150
全程恒定
仍为5:1
比上一类总需求增加25%
考察较高负荷
时变高峰四向均为
200 → 700 → 200
0-60秒
60-120秒
120秒起
适应车流上升
及高峰消退
高峰时序变化四向均为
200 → 200 → 700
0-60秒
60-120秒
120秒起
改变高峰出现时点
考察时序适应能力

流量是每个进口方向的期望到达率,不是每车道流量,也不是每小时固定生成的车辆数;车辆按该流率随机到达。五类均采用直行70%、左转15%、右转15%。时间从仿真启动计,末档流量保持至需求生成结束。“高峰时序变化”按种子重排时变流量,上表为当前结果对应的配置。各控制器使用相同的车辆计划。

YOLO车道画线在正常机位完成后冻结;固定偏角测试不重新标定。动态抖动的偏航/俯仰峰值5°、横滚峰值2.5°。

联系:dalei@scu.edu.cn

GGUF Downloads / GGUF 下载

The same fusion checkpoint is also available as BF16 GGUF and 4bit IQ4_XS GGUF, with matching vision files. Files and deployment instructions. These are alternative deployment formats, not newly trained weights. The existing approval requirements remain unchanged. The traffic results and latency above must not be assumed to apply to these GGUF or edge configurations.

同一融合权重现提供 BF16 GGUF 与 4bit IQ4_XS GGUF,各有配套视觉文件。 文件下载、搭配和部署说明。这是部署格式转换,不是重新训练; 沿用本仓库访问审批。主页既有交通成绩和速度不直接代表 GGUF 或边缘端表现。

Downloads last month
12
GGUF
Model size
9B params
Architecture
qwen35
Hardware compatibility
Log In to add your hardware

4-bit

16-bit

Inference Providers NEW
This model isn't deployed by any Inference Provider. 🙋 Ask for provider support