IndustrialIntel-1.7B-GGUF

Inspiration

Industrialization is critical to economic growth, especially in Africa, yet the potential of language models to support industrial operations remains relatively underexplored. I was inspired to explore how we could bring the power of language models into industrial operations while keeping them offline, privacy-preserving, and practical on commodity hardware.

One promising application is fault detection and maintenance. Industrial systems generate large volumes of alarms and sensor readings. When something goes wrong, operators need to quickly understand what is happening, how serious it is, and what to investigate.

IndustrialIntel-1.7B

A small offline language model that turns industrial alarms and sensor readings into concise decision support for control-room operators.

It runs entirely on commodity hardware with no network connection, so operational data never leaves the site.

Contents

• What it does
• How I built it
• Example
• Results
• Runtime
• Usage
• Training
• Data
• Limitations
• What next
• Citation

What it does

IndustrialIntel is a small language model that turns industrial alarms and sensor readings into concise, actionable decision support for operators. Given an alarm and telemetry packet, it returns four things:

IndustrialIntel is designed to sit alongside existing PLC/DCS/SCADA systems, adding an intelligent decision support layer without replacing existing control or safety systems.

Most importantly, it runs entirely offline on commodity hardware, allowing sensitive operational data to remain on-site while providing fast, local decision support.

How I built it

I built IndustrialIntel by fine-tuning a small language model (Qwen3-1.7B) to interpret industrial alarms and sensor readings, using simulated industrial process data and documented fault conditions from the Tennessee Eastman Process benchmark.

• I transformed raw process data into structured industrial incident scenarios containing alarms and relevant sensor readings.
• I generated labels directly from documented process faults and observable sensor conditions, without using another LLM to generate the answers.
• I filtered the data to ensure faults were detectable from the information provided and that explanations only referenced sensors actually present in the input.
• I fine-tuned Qwen3-1.7B using LoRA and evaluated it on completely held-out process runs.
• Finally, I quantized the model to Q4_K_M GGUF and deployed it with llama.cpp for fast, entirely offline inference on commodity hardware.

<a id="example"></a>

<details> <summary><b>Example</b></summary>

Input

UNIT: Reactor Cooling
MODE: Normal Production
WINDOW: last 30 min

ACTIVE ALARMS:
- HIGH_REACTOR_COOLING_WATER_FLOW [HIGH]

TELEMETRY:
Reactor cooling water flow: 44.02 m3/h | falling 2.0%, 5.4 sigma above normal
Reactor cooling water outlet temperature: 94.817 deg C | stable
Reactor level: 75.678 % | stable
Reactor temperature: 120.38 deg C | stable

Assess the situation and identify what the operator should investigate first.

Output

ASSESSMENT:
Possible reactor cooling water inlet temperature step change.

EVIDENCE:
Reactor cooling water flow above normal and falling 2.0%.

PRIORITY:
MEDIUM

NEXT CHECK:
Check reactor cooling water supply temperature and the cooling water system.

</details>

Results

Measured on held-out simulation runs. No run used in training appears in the test set.

95% confidence intervals on fault identification do not overlap: base [3.1%, 8.3%], tuned [86.1%, 93.0%].

Grounding. The base model cited a sensor absent from its packet in 65 of 440 answers. IndustrialIntel did so in none, across 1,359 evidence citations. This is checkable rather than a matter of opinion, because the packet lists exactly which sensors exist.

Safety direction. The model never gave a false all-clear: it never reported "normal" while a fault was present. It did call 2 of 36 normal packets a fault.

Not carried by easy cases. The fault that raises the fewest alarms (reactor cooling inlet temperature, about one alarm per event) was identified in 51 of 51 cases. The loudest fault (A feed loss, about eighteen alarms) scored 48 of 56.

Runtime

Measured on a MacBook Pro M1 Pro with the ADTC reference profiler.

Two profiler runs on the same machine gave 68.5 and 94.39 tokens/s. Throughput varies run to run; both are far above the 15 tokens/s reference used for scoring.

Usage

llama-cli -m IndustrialIntel-1.7B-Q4_K_M.gguf \
  --reasoning off --temp 0 --single-turn \
  -sys "You are an offline process-operations assistant for a control room. You receive an alarm and telemetry packet and give the operator a short, grounded assessment. Cite only signals present in the packet. Never invent readings. If nothing is abnormal, say so." \
  -p "$(cat packet.txt)"

--reasoning off matters. The model was trained with thinking disabled. Serving it with thinking enabled produces a format it never learned.

<a id="training"></a>

<details> <summary><b>Training</b></summary>

• Base: Qwen3-1.7B
• Method: LoRA, rank 16, alpha 32, on the q/k/v/o and gate/up/down projections
• Trainable: 17.4 M parameters, 1.00% of the model
• Precision: bfloat16 on Apple Silicon MPS
• Loss: computed on the answer tokens only. The operator packet is 88% of each sequence and is supplied free at inference.
• Schedule: AdamW, lr 1e-4, cosine, effective batch 8, sequence length 768
• Duration: stopped at the half-epoch checkpoint, step 129 of 258, once the training loss stopped falling

</details>

<a id="data"></a>

<details> <summary><b>Data</b></summary>

Built from the Tennessee Eastman Process benchmark: Downs & Vogel (1993) for the process specification, Rieth et al. (2017) on Harvard Dataverse for the simulation data (public domain).

TEP was chosen for one property. It publishes the root cause of every fault, and the physical meaning of every sensor channel. That makes every training label checkable.

</details>

<a id="limitations"></a>

<details> <summary><b>Limitations</b></summary>

1. Trained on a simulation. The Tennessee Eastman Process is a widely used benchmark, but it is not a real plant. Transfer to a specific facility is unproven.
2. Five fault classes. Behaviour on a fault outside this set is unknown. The model may name the nearest class it knows rather than abstaining.
3. Alarm thresholds are TEP-specific. Each plant needs its own.
4. Part of the accuracy gain is vocabulary. The base model names no root cause at all in 266 of 291 answers; it describes the readings instead. That is not useful in a control room, but it is not the same as being wrong.
5. The "next check" advice was never scored. We cannot report the share of answers that pass every operator requirement at once.
6. Decision support only. Not a controller, not a safety system, not a replacement for a process engineer.

</details>

What Next for IndustrialIntel?

More exciting things are

1. Validate IndustrialIntel on real industrial data, particularly from African manufacturing, energy, mining, and process industries.

2. Partner with industrial operators and engineers in manufacturing plants, refineries, mines, energy facilities, and other process industries to develop plant-specific models and explore integration with existing PLC/DCS/SCADA systems for real-world deployment.

Citation

@misc{industrialintel2026,
  title  = {IndustrialIntel-1.7B: Offline Industrial Alarm Triage on Commodity Hardware},
  author = {Okunowo, Similoluwa},
  year   = {2026},
  note   = {Africa Deep Tech Challenge 2026, Laptop LLM track}
}

Built for the Africa Deep Tech Challenge 2026. The design target is the infrastructure constraint that African process industries actually face: unreliable connectivity, limited compute, and a requirement that operational data stays on site.