Instructions to use AIMS2025/DeepSignal-S1 with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Notebooks
- Google Colab
- Kaggle
- Local Apps Settings
- llama.cpp
How to use AIMS2025/DeepSignal-S1 with llama.cpp:
Install (macOS, Linux)
curl -LsSf https://llama.app/install.sh | sh # Start a local OpenAI-compatible server with a web UI: llama serve -hf AIMS2025/DeepSignal-S1:BF16 # Run inference directly in the terminal: llama cli -hf AIMS2025/DeepSignal-S1:BF16
Install from WinGet (Windows)
winget install llama.cpp # Start a local OpenAI-compatible server with a web UI: llama serve -hf AIMS2025/DeepSignal-S1:BF16 # Run inference directly in the terminal: llama cli -hf AIMS2025/DeepSignal-S1:BF16
Build from source code
git clone https://github.com/ggml-org/llama.cpp.git cd llama.cpp cmake -B build cmake --build build -j --target llama-app # Start a local OpenAI-compatible server with a web UI: ./build/bin/llama serve -hf AIMS2025/DeepSignal-S1:BF16 # Run inference directly in the terminal: ./build/bin/llama cli -hf AIMS2025/DeepSignal-S1:BF16
Use Docker
docker model run hf.co/AIMS2025/DeepSignal-S1:BF16
- Llama new
- LM Studio
- Jan
- Ollama
How to use AIMS2025/DeepSignal-S1 with Ollama:
ollama run hf.co/AIMS2025/DeepSignal-S1:BF16
- Unsloth Desktop
- Pi
How to use AIMS2025/DeepSignal-S1 with Pi:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf AIMS2025/DeepSignal-S1:BF16
Configure the model in Pi
# Install Pi: npm install -g @earendil-works/pi-coding-agent # Add to ~/.pi/agent/models.json: { "providers": { "llama-cpp": { "baseUrl": "http://localhost:8080/v1", "api": "openai-completions", "apiKey": "none", "models": [ { "id": "AIMS2025/DeepSignal-S1:BF16" } ] } } }Run Pi
# Start Pi in your project directory: pi
- Docker Model Runner
How to use AIMS2025/DeepSignal-S1 with Docker Model Runner:
docker model run hf.co/AIMS2025/DeepSignal-S1:BF16
- Lemonade
How to use AIMS2025/DeepSignal-S1 with Lemonade:
Pull the model
# Download Lemonade from https://lemonade-server.ai/ lemonade pull AIMS2025/DeepSignal-S1:BF16
Run and chat with the model
lemonade run user.DeepSignal-S1-BF16
List all available models
lemonade list
- Hermes Agent
How to use AIMS2025/DeepSignal-S1 with Hermes Agent:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf AIMS2025/DeepSignal-S1:BF16
Configure Hermes
# Install Hermes: curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash hermes setup # Point Hermes at the local server: hermes config set model.provider custom hermes config set model.base_url http://127.0.0.1:8080/v1 hermes config set model.default AIMS2025/DeepSignal-S1:BF16
Run Hermes
hermes
- Atomic Chat
- OpenClaw
How to use AIMS2025/DeepSignal-S1 with OpenClaw:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf AIMS2025/DeepSignal-S1:BF16
Configure OpenClaw
# Install OpenClaw: npm install -g openclaw@latest # Register the local server and set it as the default model: openclaw onboard --non-interactive --mode local \ --auth-choice custom-api-key \ --custom-base-url http://127.0.0.1:8080/v1 \ --custom-model-id "AIMS2025/DeepSignal-S1:BF16" \ --custom-provider-id llama-cpp \ --custom-compatibility openai \ --custom-text-input \ --accept-risk \ --skip-health
Run OpenClaw
openclaw agent --local --agent main --message "Hello from Hugging Face"
Install (macOS, Linux)
curl -LsSf https://llama.app/install.sh | sh
# Start a local OpenAI-compatible server with a web UI:
llama serve -hf AIMS2025/DeepSignal-S1:# Run inference directly in the terminal:
llama cli -hf AIMS2025/DeepSignal-S1:Install from WinGet (Windows)
winget install llama.cpp
# Start a local OpenAI-compatible server with a web UI:
llama serve -hf AIMS2025/DeepSignal-S1:# Run inference directly in the terminal:
llama cli -hf AIMS2025/DeepSignal-S1:Build from source code
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
cmake -B build
cmake --build build -j --target llama-app# Start a local OpenAI-compatible server with a web UI:
./build/bin/llama serve -hf AIMS2025/DeepSignal-S1:# Run inference directly in the terminal:
./build/bin/llama cli -hf AIMS2025/DeepSignal-S1:Use Docker
docker model run hf.co/AIMS2025/DeepSignal-S1: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
| Scene | Condition | Cases | Controller | Mean wait (s/veh) | Mean queue (veh) | Mean journey (s/veh) |
|---|---|---|---|---|---|---|
| Nine-junction test | Clean | 72 | S1 | 45.823 | 10.473 | 107.316 |
| Fixed-time plan | 68.545 | 15.525 | 131.149 | |||
| YOLO+MP | 46.890 | 10.559 | 108.792 | |||
| Standard simulation | Clean | 5 | S1 | 20.450 | 3.565 | 38.215 |
| Fixed-time plan | 40.456 | 5.398 | 57.699 | |||
| YOLO+MP | 20.215 | 3.586 | 38.220 |
Perturbed views: S1 vs YOLO+MP — full values and three-metric chart
| Scene | Condition | Cases | Controller | Mean wait (s/veh) | Mean queue (veh) | Mean journey (s/veh) |
|---|---|---|---|---|---|---|
| Nine-junction test | Defocus σ=9 | 9 | S1 | 76.082 | 15.795 | 141.033 |
| YOLO+MP | 104.862 | 31.040 | 167.484 | |||
| Nine-junction test | 31 px motion blur | 9 | S1 | 67.382 | 17.232 | 131.573 |
| YOLO+MP | 124.591 | 30.184 | 188.343 | |||
| Nine-junction test | Fixed yaw ±15° / pitch ±8° | 9 | S1 | 63.681 | 15.445 | 129.042 |
| YOLO+MP | 87.008 | 21.179 | 154.362 | |||
| Nine-junction test | Dynamic shake 5° | 9 | S1 | 63.398 | 16.171 | 128.251 |
| YOLO+MP | 72.153 | 17.905 | 137.608 | |||
| Standard simulation | Defocus σ=9 | 5 | S1 | 27.511 | 4.101 | 44.431 |
| YOLO+MP | 92.970 | 9.754 | 109.153 | |||
| Standard simulation | 31 px motion blur | 5 | S1 | 20.276 | 3.581 | 38.102 |
| YOLO+MP | 111.256 | 10.239 | 127.707 | |||
| Standard simulation | Fixed yaw ±15° / pitch ±8° | 5 | S1 | 19.226 | 3.455 | 37.107 |
| YOLO+MP | 205.091 | 13.668 | 217.405 | |||
| Standard simulation | Dynamic shake 5° | 5 | S1 | 19.133 | 3.321 | 37.203 |
| YOLO+MP | 21.487 | 3.533 | 39.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 scenario | Flow per approach (vehicles/hour) | Temporal pattern | Control challenge |
|---|---|---|---|
| Balanced flow | All four: 360 each | Constant throughout | Basic 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 peak | All approaches: 200 → 700 → 200 | 0-60 s 60-120 s from 120 s | Adapt to rising demand and peak recovery |
| Shifted peak timing | All 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
简体中文
从路口画面直接作出交通信号决策。
DeepSignal 模型家族的视觉决策系列 · 当前版本 DeepSignal-S1-1.0
S1 代表 System One,强调快速、直接的视觉决策:结合路口画面与信号状态,输出合法控制动作。
看演示 · 看结果 · 试一次决策 · 申请模型 · 完整复现
核心创新与特色
视觉理解与信号决策,在同一个模型里完成。 连续三帧画面、路口信息与信号状态共同输入,直接返回合法控制动作及候选概率;无需独立的车辆检测与计数环节。
速度实测: 未量化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个路口独立测试 | 正常 | 72 | S1 | 45.823 | 10.473 | 107.316 |
| 固定配时方案 | 68.545 | 15.525 | 131.149 | |||
| YOLO+MP | 46.890 | 10.559 | 108.792 | |||
| 标准仿真场景 | 正常 | 5 | S1 | 20.450 | 3.565 | 38.215 |
| 固定配时方案 | 40.456 | 5.398 | 57.699 | |||
| YOLO+MP | 20.215 | 3.586 | 38.220 |
特殊视觉:S1与YOLO+MP — 完整数值与三指标图
| 场景 | 条件 | 案例数 | 控制方法 | 平均等待(秒/车) | 平均排队长度(辆) | 平均行程(秒/车) |
|---|---|---|---|---|---|---|
| 9个路口独立测试 | 失焦σ=9 | 9 | S1 | 76.082 | 15.795 | 141.033 |
| YOLO+MP | 104.862 | 31.040 | 167.484 | |||
| 9个路口独立测试 | 31像素运动模糊 | 9 | S1 | 67.382 | 17.232 | 131.573 |
| YOLO+MP | 124.591 | 30.184 | 188.343 | |||
| 9个路口独立测试 | 固定偏航±15° / 俯仰±8° | 9 | S1 | 63.681 | 15.445 | 129.042 |
| YOLO+MP | 87.008 | 21.179 | 154.362 | |||
| 9个路口独立测试 | 动态抖动峰值5° | 9 | S1 | 63.398 | 16.171 | 128.251 |
| YOLO+MP | 72.153 | 17.905 | 137.608 | |||
| 标准仿真场景 | 失焦σ=9 | 5 | S1 | 27.511 | 4.101 | 44.431 |
| YOLO+MP | 92.970 | 9.754 | 109.153 | |||
| 标准仿真场景 | 31像素运动模糊 | 5 | S1 | 20.276 | 3.581 | 38.102 |
| YOLO+MP | 111.256 | 10.239 | 127.707 | |||
| 标准仿真场景 | 固定偏航±15° / 俯仰±8° | 5 | S1 | 19.226 | 3.455 | 37.107 |
| YOLO+MP | 205.091 | 13.668 | 217.405 | |||
| 标准仿真场景 | 动态抖动峰值5° | 5 | S1 | 19.133 | 3.321 | 37.203 |
| YOLO+MP | 21.487 | 3.533 | 39.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°。
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
4-bit
16-bit
# Gated model: Login with a HF token with gated access permission hf auth login