What Continuous Audio Monitoring Costs to Run All Day

Every figure on this page is derived from inputs named in the sentence that uses them. The unit prices are assumptions, clearly marked, because there is no single public price list for this; substitute your own and the structure of the answer will not change, which is the point.

The inputs, stated once

The configuration below is a plausible always-on sound event detector. Nothing here is measured; it is a worked example with every assumption exposed.

  audio          16 kHz mono, 16-bit PCM
  window         1.0 s
  hop            0.5 s          (50% overlap)
  duty           24 h/day, 30.4 days per month
  model cost     20 ms of one CPU core per window   [ASSUMPTION]
  gate cost      0.2 ms of one CPU core per window  [ASSUMPTION]
  compute price  $0.04 per vCPU-hour                [ASSUMPTION]
  egress price   $0.09 per GB                       [ASSUMPTION]
  storage price  $0.023 per GB-month                [ASSUMPTION]
  hosted audio   $0.006 per minute of audio         [ASSUMPTION]

Inference cost per stream

Start with how many times the model runs. A 0.5 s hop over 24 hours:

  inferences/day = 86,400 s / 0.5 s = 172,800

  CPU-seconds/day = 172,800 * 0.020 s = 3,456 s
                  = 0.96 core-hours/day
  core-hours/month = 0.96 * 30.4 = 29.2

  cost/month = 29.2 * $0.04 = $1.17 per stream

One dollar and change per stream per month. Scale it: 1,000 streams is 960 core-hours per day, which is 40 cores running flat out and $1,168/month. 100,000 streams is 4,000 cores and $116,800/month, at which point the 20 ms assumption is the most valuable number in your business and worth a week of optimisation. Halving it halves the line.

Notice what the hop does. Moving from a 0.5 s hop to 1.0 s halves the inference count and halves this line, at the cost of coarser onset timing. Moving to a 0.25 s hop doubles it. The window length, by contrast, changes the per-inference cost rather than the count, and for a convolutional model on a mel spectrogram that cost is close to linear in window length — so doubling the window at a fixed hop roughly doubles the same line. These are the two knobs, and neither is a modelling decision you would otherwise think about in cost terms.

Moving and storing the audio

If the model runs somewhere other than where the microphone is, the audio has to get there. That is a separate line and it is usually larger.

  raw bytes/s   = 16,000 * 2 = 32,000 B/s
  raw bytes/day = 32,000 * 86,400 = 2,764,800,000 B
                = 2.76 GB/day

  egress/day    = 2.76 * $0.09 = $0.249
  egress/month  = $0.249 * 30.4 = $7.57 per stream

Transport is 6.5 times the compute. That is the single most useful result on this page, and it inverts the intuition that the model is the expensive part. It is not, for continuous audio at low sample rates, because inference on a small classifier is cheap and moving bytes continuously is not.

Encoding fixes most of it. Opus at 24 kbit/s is 3,000 B/s, which is 259 MB/day and $0.71 per stream per month — a factor of 10.7. The caveat is that a lossy codec at that bitrate is optimised for speech intelligibility and discards spectral detail a classifier may be using, so the model must be trained or at least validated on decoded audio rather than on originals. A model trained on clean WAV and served decoded Opus is a distribution shift nobody logged.

Retention adds its own line. A 30-day rolling raw archive of one stream is 82.9 GB, which at the assumed storage price is $1.91 per stream per month, and it grows without bound if nobody sets a lifecycle policy. The same 30 days as Opus is 7.8 GB and $0.18. Storing only triggered segments is cheaper again by whatever your trigger rate is, at the cost of never being able to re-examine what the detector rejected — the same irreversible trade an unattended hydrophone deployment has to make for storage reasons rather than cost ones.

The per-minute API path

Hosted audio APIs are commonly priced per minute of audio processed rather than per inference. Under the stated assumption of $0.006 per minute:

  minutes/day   = 1,440
  cost/day      = 1,440 * $0.006 = $8.64
  cost/month    = $8.64 * 30.4 = $263 per stream

  versus the self-hosted compute line: $1.17
  ratio: 225x

Two hundred times is not a margin, it is a different business model. Per-minute pricing is designed for bursty transactional workloads — a voicemail, a meeting, a support call — where the average utilisation of a dedicated process would be a few percent and you are paying for the absence of idle capacity. A stream that runs 1,440 minutes a day has no idle capacity to avoid paying for. It is the worst possible fit for usage-based pricing, and the crossover is easy to compute: the hosted path wins whenever your daily audio volume per stream is under roughly 6.5 minutes, which is where $0.006 per minute equals the $0.039 daily self-hosted compute cost.

The honest exception is capability. If the task genuinely needs a large hosted model — open-vocabulary description, transcription with speaker attribution, anything requiring a model too big to run on your own hardware economically — then the comparison above is not the right one, because the cheap local path does not do the job. Most continuous monitoring does not need that. It needs a small classifier over a fixed label set, which is the case the arithmetic above describes.

What gating and billing granularity do to the total

Two structural effects change the total more than any per-unit price negotiation will.

Gating. Most seconds contain nothing. Put a cheap energy or spectral-flux gate in front of the classifier and only pass windows above a floor. Assume the gate costs 0.2 ms per window and 8% of windows pass:

  gate:       172,800 * 0.0002 s = 34.6 s/day
                                   = 0.0096 core-hours/day
  classifier: 0.08 * 0.96          = 0.0768 core-hours/day
  total:                             0.0864 core-hours/day

  cost/month = 0.0864 * 30.4 * $0.04 = $0.105 per stream
  versus $1.17 ungated: an 11x reduction

Note where the floor is. Even if the classifier became free, the gate still runs on every window, so it sets a hard minimum of $0.012 per stream per month. Below that, the only remaining lever is not listening. The gate also removes false positives for free, since silence that never reaches the classifier cannot be misclassified — the arithmetic for what that is worth is in the false-alarm derivation for a home detector.

Billing granularity. Serverless function platforms typically bill in minimum increments — 100 ms is a common floor — and charge per invocation on top. A 20 ms inference billed at a 100 ms minimum is billed at five times what it uses:

  billed seconds/day = 172,800 * 0.1 s = 17,280 GB-s at 1 GB
  at $0.0000167 per GB-s  [ASSUMPTION]
                     = $0.289/day = $8.78/month

  invocations/month  = 172,800 * 30.4 = 5.25 million
  at $0.20 per million    [ASSUMPTION]
                     = $1.05/month

  serverless total   = $9.83 versus $1.17 always-on: 8.4x

A workload that never idles should not be on a platform whose entire value proposition is not charging you when you idle. Batch several windows per invocation and the invocation charge and the minimum duration both amortise — 20 windows per call is 262,000 invocations a month and 400 ms of real work against a 100 ms floor, which removes both penalties at the cost of adding up to 10 seconds of detection latency. Whether that latency is acceptable is the actual design question, and it is worth noticing that it was a cost question in disguise.