Detection Time Cut 65%, False Alarms Down 80%: How to Read the Two Numbers Behind Edge Fire-Detection AI

The first few minutes of response time decide the scale of casualties and property loss in an underground parking garage EV fire. The core problem is the fire-detection system itself. When false alarms repeat, managers start ignoring alerts or switching the system off, and response is delayed when a real fire actually breaks out — no matter how good the detection performance is, an alarm that has lost the operator’s trust behaves the same as one that never fires. Superb AI, working with Korea’s National Fire Research Institute, developed an early-detection AI model for underground-garage EV fires, and reported achieving a 65% reduction in detection time and an 80% reduction in the false-alarm rate while running in real time on an edge device¹ (Document 2, Superb AI entry). This article’s conclusion is that of the two figures, the one that actually governs field operation is the 80% reduction in the false-alarm rate.

The assumption this article breaks

The assumption is that "a detection model is better the faster it catches something." From this writer’s perspective, in a system under 24-hour continuous surveillance, a single alarm triggers a fire-department dispatch, vehicle evacuation, and a parking-garage shutdown. A system with frequent false alarms gets its alerts switched off or ignored by managers, and at that moment, any reduction in detection time loses its meaning. The false-alarm rate is the floor of trust; detection time is a performance figure discussed only above that floor.

Core framework: three confirmation axes

To turn the two performance figures (65%, 80%) into a spec that can actually be applied in the field, the three items below need to be filled in. Document 2 does not state these three items, so they are left, as they are, marked "confirmation needed" — nothing here is filled in arbitrarily.

Takeaway: the two figures — "65% shorter detection time, 80% fewer false alarms" — are given, but the optical and algorithmic conditions that produced those figures are not disclosed. Until the three confirmation axes are filled in, there is no basis for carrying this performance over as-is to a different site (an underground garage with different lighting or camera placement).

The numbers, and the blanks behind them

Takeaway: neither ratio has a baseline stated in the document. Whether the comparison is against existing heat/smoke detectors or an existing video-based model, and what the camera resolution, frame rate, and lighting conditions were, cannot be confirmed from the information provided. An underground parking garage is an environment where low light², backlighting, and vehicle headlights all mix together, so until these conditions are disclosed, these figures should not be carried over as-is to a different site.

On the deployment side — NPUs and remote management

The same document also carries news on deployment infrastructure. DEEPX reported building a physical-AI deployment environment linked with AWS IoT, and said it supports remote management of edge devices based on its DX-M1 NPU³ (Document 2, DEEPX entry).

Takeaway: for something like fire detection, where devices are scattered across dozens of underground garages, model updates and firmware management determine operating cost just as much as raw performance does. "Running in real time" and "remote management" are separate problems, and the fact that both pieces of news landed in the same month reads, in this writer’s view, as a signal that edge AI is shifting from a performance race to an operations race.

The other side — how large have the big models grown

News in the opposite direction appeared in the same period. Tencent’s Hy4 preview, released on August 28, is a MoE⁴ model with 770 billion total parameters and 49 billion active parameters, a maximum context of 1 million tokens, and was released as a free, open model (Document 1, GLOBAL NEWS).

Takeaway: a model at this scale does not run on an edge device. A division of labor is settling in where small models handle field detection while large models are used further back in the pipeline, for things like training-data generation and labeling assistance (this writer’s view). The condition under which large models gain the advantage is not real-time inference, but the post-processing stage (data generation, labeling) where latency is acceptable. That said, whether this division of labor is actually reflected in real deployment pipelines cannot be confirmed from the document, and it cannot be confirmed before sample testing.

Field Checkpoints

If you are evaluating adoption of an edge fire-detection model, require the vendor to document the following.

• ☐ The baseline and test-dataset conditions behind the detection-time and false-alarm-rate figures
• ☐ The illuminance (lx) range and performance at the lowest illuminance
• ☐ Whether WD (Working Distance)⁵ is secured at the camera’s installation position — whether the entire target zone falls within the field of view (FOV) without being blocked by vehicles or pillars
• ☐ Edge-device specifications (compute unit, heat, power) and the remote-update method
• ☐ The verification procedure when a false alarm occurs (whether a human is involved)

¹ Edge Device: a unit that performs inference directly near the camera, without sending video to a server.
² Low Light: a condition with insufficient illumination. It increases image noise, which is a cause of missed and false detections.
³ NPU (Neural Processing Unit): a semiconductor dedicated to neural-network computation.
⁴ MoE (Mixture of Experts): a structure that activates only a subset of expert blocks out of the total parameters for inference.
⁵ WD (Working Distance): the distance from the front of the lens to the subject. It is considered secured only when it simultaneously satisfies both the field-of-view and focus conditions.

Related reading: Edge AI Inference Latency Is Decided by the Camera Interface Before the NPU — GigE Vision 3.0 RDMA and Decoupled Inspection Architecture