Trénování modelů pro edge

Proč je trénování pro edge jiné

Trénování modelů pro edge hardware (MCU, mobilní SoC, NPU, DSP, FPGA) vyžaduje jinou filozofii než pro cloud. Cílem není pouze maximalizovat přesnost, ale optimalizovat více kritérií současně: latenci, spotřebu energie, paměťovou stopu, spolehlivost, bezpečnost a udržitelnost aktualizací v terénu. Tento článek systematicky rozebírá workflow od definice metrik přes volbu architektury a přípravu dat až po kompresi, hardware-aware trénování, profilaci na cílovém zařízení a MLOps pro flotily edge uzlů.

Typologie edge hardwaru a jejich omezení

• MCU (TinyML): řádově desítky–stovky kB RAM, jednotky MB Flash, bez OS nebo s RTOS; inference do jednotek ms, příkon v mW.
• Mobilní/Embedded SoC: CPU (ARM), GPU, DSP a/nebo NPU; RAM 1–16 GB; TDP 2–15 W; běžné v robotice a průmyslu.
• NPU/AI akcelerátory: pevná sada podporovaných operátorů; nejvyšší výkon při int8/4; omezení na specifické layouty tensorů.
• DSP: excelují v audio/časových řadách a low-power režimech (FFT, MFCC); výkon závisí na knihovnách (např. CMSIS-DSP).
• FPGA: flexibilní, ale vyžadují pečlivý mapping operátorů; vhodné pro deterministickou latenci.

Důsledek: trénink musí předvídat konkrétní limity (operátorová podpora, přesnost datových typů, paměť, šířka sběrnic, cache line, DMA přenosy).

Vícekriteriální cíle: jak správně nastavit metriky

• Výkon: přesnost (Top-1, mAP, F1), robustnost (auROC na OOD, odolnost vůči šumu a kompresi).
• Latence: percentily P50/P95 na cílovém zařízení, end-to-end včetně I/O, pre/post-processingu.
• Energie: J/inference nebo mWh/událost, korelovat s DVFS a teplotou.
• Paměť: VRAM/SRAM peak, trvalá paměť modelu (weights), pracovní buffery (aktivace, im2col, scratch), velikost binárky.
• Spolehlivost: míra fail-safe, detekce selhání (confidence, entropy, conformal prediction), fallback pipeline.

Doporučení: používat multi-objective optimalizaci (vážený součet nebo Pareto fronta) a explicitně sledovat accuracy–latency–energy trade-off.

Příprava dat: od sběru k doménové robustnosti

• Kurátorský sběr: reprezentativní pro reálné podmínky (světlo, vibrace, komprese, mikrofonní šum, RF interference).
• Čištění a verze dat: kontrolované datasety s data cards, verzování (hash, semver), auditovatelnost.
• Augmentace: photometric i geometric, doménově specifické (např. blur od vibrací, rolling-shutter, spektrální šum).
• Syntetická data: generativní simulace, domain randomization; nutná realistická fyzika a senzorové modely.
• Aktivní učení: iterativní výběr vzorků s nejistotou pro anotaci; snižuje náklady.
• Polo-/samo-učení: využití neoznačených dat z flotily (pseudo-labels, contrastive learning) při respektování zásad soukromí.

Výběr architektury: malé, rychlé a účelové

• Vision: MobileNet/ShuffleNet/FBNet/MnasNet, EfficientNet-Lite, NAS pro konkrétní latency budget; depthwise separable a group konvoluce.
• Audio/časové řady: DS-CNN, TCN, lehké GRU/LSTM, attention s omezeným rozsahem (linformer, performer), případně spiking s event-driven zpracováním.
• Jazyk: miniaturní transformery s kvantizací a weight tying; případně adaptery místo plného přeučení.
• Grafy a senzory: lehké GNN (SGC, GraphSAGE s prunováním sousedství), klasické featury + malé MLP na DSP.

Princip: nejdříve trénujte přesný teacher (referenční baseline), poté navrhujte student s ohledem na hardware.

Hardware-aware trénování: učit rovnou to, co poběží

• Kvantizace-aware trénování (QAT): simulace int8/int4 během tréninku, kalibrace per-kanál, sym./asym. rozsahy, fake-quant uzly.
• Prunování: strukturované (kanály, whole kernels) pro reálné zrychlení; N:M sparsita; postupné magnitude-based s fine-tuningem.
• Distilace: logits, feature mapy i relační distilace; multi-task distilace pro sdílené hlavy (detekce + segmentace).
• Neural Architecture Search: latency/energy aware (měřit na cíli nebo přes přesné cost modely); multi-objective NAS.
• Mixed precision: FP16/bfloat16 při tréninku, inference int8/4; pozor na kumulaci chyb v normalizacích.
• Regularizace pro robustnost: augmentations-as-noise, label smoothing, adversariální trénink v budgetu.

Kompresní pipeline: pořadí kroků a kontrolní body

1. Návrh a natrénování teacher (FP32) na plných datech.
2. První student: menší architektura + distilace (FP32).
3. Prunování strukturované → fine-tune.
4. QAT (int8; případně int4 u vhodného hardware) → fine-tune s menším LR.
5. Export do cílového formátu a on-target validace metrik: přesnost, latence, energie, paměť, teplota.

Každý krok archivujte (model card + měření) pro audit a snadný návrat při regresi.

Optimalizace pro konkrétní akcelerátory

• MCU/TinyML: volit integer-only s CMSIS-NN/TFLM; minimalizovat aktivace (re-use bufferů), vyhýbat se ops mimo kernel s podporou.
• NPU: respektovat podporované ops a layouty (NHWC/NCHW); fúze (Conv+BN+Act); vyhnout se dynamickým tvarům.
• DSP: transformovat předzpracování (MFCC, mel-filterbanky) do pevně vyladěných rutin; používat fixed-point.
• GPU v SoC: dbát na koalescentní přístupy do paměti, dlaždicování a limit aktivací; preferovat menší batch=1.
• FPGA: kvantizovat na int8/4; navrhovat pipeline s overlapem I/O a compute; omezit branching.

Toolchain a formáty modelů

• Trénink: PyTorch/TensorFlow + skripty pro QAT, prunování, distilaci.
• Konverze/kompilace: ONNX → ONNX Runtime/TVM; TF → TFLite/TFLM; Core ML pro iOS; TensorRT pro Jetson; Arm NN/Compute Library; vendor SDK (SNPE, NPU toolchain).
• Formáty: .tflite, ONNX, Core ML; pro MCU FlatBuffers a generované kernelové tabulky.
• Operátorová kompatibilita: před tréninkem zkontrolovat, které vrstvy budou “fallbackovat” na CPU a vyhnout se jim.

On-device a federované učení

• Federated learning: model trénován lokálně na zařízeních; server agreguje gradienty/parametry; přínos pro soukromí a personalizaci.
• On-device fine-tuning: krátké session, malé LR, adaptery/LoRA/BN-statistiky místo plného update; respektovat energetické rozpočty.
• Differential privacy: přidání šumu k gradientům; sledovat dopad na přesnost.
• Kontrola driftu: detekce změn distribuce dat (PSI, MMD, kolmogorov-smirnov) a trigger retréninku.

Profilace a měření na cíli

• Latence: měřit end-to-end včetně I/O, předzpracování a postprocessingu; používat percentily, warm-up, pinning vláken.
• Energie: externí power monitory; reportovat J/inference i mW v klidu a při špičce; korelovat s teplotou a throttlingem.
• Paměť: peak aktivací, fragmentace heapu, DMA buffery; analyzovat při různých vstupních rozlišeních.
• Stabilita: soak testy, dlouhodobý provoz, brown-out scénáře, restart a zotavení.

Robustnost, bezpečnost a bezpečné selhání

• Robustnost: testy na OOD datech, šum, komprese, přepaly/šero, vibrace; augmentace odpovídající terénu.
• Bezpečnost modelu: podepsané modely, kontrola integrity, šifrované OTA, ochrana před model extraction a adversarial vstupy.
• Fail-safe: detekce nízké jistoty → degradovaný režim, tradiční heuristiky, nebo předání do cloudu.
• Explainability: lehké metody (CAM/Grad-CAM na edge, logování feature statistik pro audit).

MLOps pro fleet edge zařízení

• Verzování: semver modelů i dat; model cards s metrikami a podporovaným HW.
• A/B a canary: rollout na část flotily; sběr telemetrie (latence, energie, confidence, crash rate).
• OTA aktualizace: inkrementální balíčky, delta update; možnost rychlého rollbacku.
• Monitoring: metriky v čase, alerty na drift, anomálie, nárůst NACK/timeoutů akcelerátoru.

Praktické vzory podle domény

• Detekce objektů na SoC: teacher (YOLOvX/RT-DETR) → student (Anchor-free lite) + distilace; vstup 320×320; QAT int8; fúze Conv+BN; cíl <10 ms a <1.5 J/inference.
• Keyword spotting na MCU: DS-CNN <50 k parametrů; MFCC na DSP; int8 QAT; dvojitý práh pro spolehlivost; příkon průměrně <1 mW v always-on režimu.
• Predikce vibrací stroje: TCN/1D-CNN s prunováním kanálů; kvantizace int8; batch=1 stream; výstupní hysteréze proti falešným alarmům.

Checklist: před nasazením na edge

1. Definované SLA: přesnost, latence P95, energie, paměť, teplota.
2. Model kompatibilní s operátory akcelerátoru, otestovaný export a fúze.
3. QAT/Pruning/Distilace dokončeny, dosažený Pareto-optimální bod.
4. On-target profilace: latence, energie, paměť, stabilita, dlouhodobý běh.
5. Bezpečnost: podpis, šifrované OTA, kontrola integrity, fail-safe režim.
6. MLOps: verze modelu/datasetu, canary plán, telemetrie, rollback.

Časté chyby a jak se jim vyhnout

• Trénink v FP32 bez myšlenky na kvantizaci → pozdější ztráta přesnosti; řešení: QAT od počátku.
• Nepodporované operátory → CPU fallback a vyšší latence; řešení: early linting ops a restrikce grafu.
• Poddimenzovaná paměť aktivací → OOM; řešení: menší rozlišení, menší šířka sítě, tiling, re-use bufferů.
• Laboratorní metriky ≠ terén → zhoršení po nasazení; řešení: testy v reálných podmínkách a dlouhé soak testy.

Závěr

Úspěšné trénování pro edge je disciplína na průsečíku strojového učení, embedded inženýrství a MLOps. Klíčem je myslet „hardware-first“: od volby architektury a QAT přes strukturované prunování a distilaci až po přesnou profilaci na cílovém zařízení, bezpečné OTA a průběžné monitorování. Správně zvládnutý proces přináší modely, které jsou nejen přesné, ale i rychlé, energeticky úsporné a spolehlivé v reálném světě.