Emergency management needs 911 NLP inference capacity to stay N+1 during firmware windows. How should upgrades be planned?
Select an answer to reveal the explanation.
Short Explanation
Keep at least one spare ambulance in service while the others get maintenance—same idea for 911 NLP GPUs. Roll firmware through subsets so N+1 capacity stays up, instead of flashing the whole fleet at once.
Full Explanation
Emergency-management 911 NLP inference that must stay N+1 through firmware windows should use rolling upgrades: upgrade and validate subsets while remaining capacity still meets N+1 spare. Rolling design keeps citizen-facing inference available if a subset fails validation, instead of betting the entire pool on one simultaneous flash. Flashing every inference node at once with no spare capacity reserved collapses N+1 to N-all-down for the length of the window and any rollback. Canceling all firmware work permanently because municipal systems “cannot be patched” accumulates vulnerability and unsupported skew; the requirement is safe sequencing, not permanent freeze. Upgrading only during declared disasters—when change freezes typically tighten—targets the worst possible operational moment for firmware risk. Exam caveat: N+1 is a capacity planning constraint during the window; sites may use N+2 for critical 911 tiers, but the tested idea is preserving redundancy while subsets move. Operational check: before the window, calculate how many nodes can be drained while still meeting N+1, upgrade that cohort, validate health and inference smoke tests, restore them, then proceed to the next cohort.