Here is the entire system, drawn as an architecture rather than as code:

                 [ LOCAL HARDWARE ]              [ DIGITALOCEAN SERVERLESS ]
audio input  →   Nemotron ASR model    →   transcript   →   Nemotron translation   →   English text
(mic / file)     on-device (MPS/CPU)        (text only)      nemotron-3-nano-omni

Two inference steps, two different homes. Speech recognition happens on the user’s own machine. The transcript — plain text, no audio — crosses the network to DigitalOcean, where a larger language model translates it. The result comes back as English text.

The principle underneath is simple to state and easy to get wrong: partition by workload characteristics, not by convenience. It would have been convenient to run everything in one place. Instead, each stage lives where its economics and constraints actually fit. The rest of this article is about how to make that judgment yourself.

Run a stage locally when its input is sensitive or it fires at high frequency; rent it serverless when the model is heavy to host or the calls are bursty and occasional. That one-line rule covers most cases — here’s how to apply it deliberately.

When you’re deciding whether a given inference step should run locally or serverless, four axes do almost all the work. Run each stage of your pipeline through them.

Watch how the translation demo falls out of this almost mechanically.

Privacy. Audio is one of the most sensitive input types there is — it carries a voice, an identity, often a location and a mood. In this design, the raw audio never leaves the device; only the transcript crosses the wire. That doesn’t make the data flow risk-free — a transcript can still carry personally identifiable information, and you should treat it as sensitive and apply redaction before it leaves the device if your domain calls for it. But it sharply narrows what you’re transmitting and where your audio-handling boundary sits: the rawest, most identifying input — the voiceprint itself — is removed from the network path entirely. In a representative run of this demo, zero bytes of raw audio left the device; the 2.65 MB recording was processed locally, and only an 883-byte transcript was sent on — a 99.98% reduction versus the 3.7 MB an equivalent direct-audio request would have carried. For workloads touching regulated or sensitive input, that’s a meaningful and defensible reduction in exposure, and a much smaller surface to reason about with an auditor.

Cost shape. ASR runs continuously while someone is speaking — it’s the high-frequency stage. Paying per API call for something that fires that often compounds fast. Running it on hardware you already own makes its marginal cost effectively zero. Translation, by contrast, is the bursty step: it fires once per utterance, occasionally, in well-defined chunks. That’s exactly the shape where serverless pay-per-use beats keeping a GPU warm around the clock. In the same run, one translation cost about $0.0006 at assumed token rates — roughly 1,600 utterances per dollar — with the audio side costing nothing per call because it ran on hardware that was already there. (For how serverless inference latency and cost behave more broadly, see our LLM inference benchmarking writeup.)

Maintenance burden. The local ASR model here is small — nvidia/nemotron-3.5-asr-streaming-0.6b, well under a billion parameters. A model that size runs comfortably on consumer hardware, including Apple Silicon, and is cheap to keep around. The translation model is the kind of thing you’d rather consume than own: you don’t want to download it, version it, patch it, or babysit a server keeping it loaded. Serverless erases that entire operational surface.

Capability access. This is the one decision-makers feel most directly. Serverless inference means no GPU procurement cycle, no provisioning, no scaling policy to write. You get a hosted model behind an endpoint, and your time-to-value is measured in minutes. For a stage you don’t need to control tightly, that’s a strong reason to rent rather than build.

Notice what the framework is not: it isn’t ideological. Nobody decided “local good, cloud bad” or the reverse. The line got drawn by profiling each stage against four concrete questions. Do that honestly and the architecture tends to design itself.

The architecture above wasn’t the original plan, and the reason it changed is worth being direct about. The plan was to send audio directly to DigitalOcean’s nemotron-3-nano-omni — an omni-capable model — and let the cloud handle both transcription and translation in one hop. Cleaner diagram, fewer moving parts.

It didn’t work. In testing, the audio payloads reached DigitalOcean, but the model responded as if no audio had been provided at all. The most likely explanation is that the serverless gateway wasn’t forwarding the audio block to the model, or that it expects an undocumented payload shape that the demo never landed on.

There are two ways to respond to that. One is to burn a sprint reverse-engineering payload formats against a black box. The other is to ask whether the constraint is pointing at a better design. It was. Moving ASR local didn’t just route around the gateway limitation — it produced the stronger architecture, the one where sensitive audio never leaves the device and the high-frequency stage costs nothing per call. The constraint improved the system.

The takeaway generalizes. Hybrid boundaries are often discovered rather than designed up front, and a constraint that pushes work onto local hardware frequently makes the architecture better, not worse. Build your evaluations so these limits surface early and cheaply. This demo keeps an Audio Probe diagnostic tab in the app precisely so a team can re-verify the gateway’s behavior independently, rather than taking anyone’s word for where the boundary sits.

You don’t need the full implementation to trust the pattern, but you should see enough to know it isn’t a whiteboard fantasy. Two snippets carry the weight.

First, the serverless call. The thing to notice is how unremarkable it is:

from openai import OpenAI

client = OpenAI(
    base_url="https://inference.do-ai.run/v1",
    api_key=os.environ["MODEL_ACCESS_KEY"],
)

response = client.chat.completions.create(
    model=os.environ.get("DO_MODEL", "nemotron-3-nano-omni"),
    messages=[
        {"role": "system", "content": "Translate the user's text to English."},
        {"role": "user", "content": transcript},
    ],
    timeout=float(os.environ.get("DO_TIMEOUT_SECONDS", "90")),
)

That’s an ordinary OpenAI-style call pointed at a DigitalOcean endpoint. The integration cost is near zero — if your team has ever called a chat completions API, they already know how to do this. The model name, base URL, and timeout are all environment-driven, so swapping models or tuning behavior never touches code. The serverless half of a hybrid system is genuinely this small. (For the full picture of what the platform exposes — routing, prompt caching, observability — see the Serverless Inference deep dive.)

Second, the seam — the few lines where the local transcript hands off to the remote call:

# transcript comes back from local ASR, sometimes tagged like "<es-ES> hola..."
transcript = strip_language_tags(local_asr_result)   # remove "<es-ES>" etc.
english = translate_remote(transcript)               # the DigitalOcean call above

This is where hybrid systems live or die. The local ASR model emits language tags such as <es-ES> as part of its output; left in, they confuse the downstream translator. The fix is one cleaning step at the boundary. It’s mundane — and that’s the reassurance. The seam between local and serverless is small, explicit, and fully ownable by your team. There’s no magic in the handoff, just a contract about what text crosses the wire.

Here is what a single representative run actually produced, so the tradeoffs above aren’t just assertions:

Three honest caveats keep these numbers from overpromising. This is one representative run, not a benchmark distribution — treat the 3.3-second latency as a single measured example, not a guaranteed SLA, and expect a multi-sample spread once you profile your own workload. The cost figure assumes token rates of $0.50 per 1M input tokens and $0.90 per 1M output; confirm against the current pricing before quoting it. And the privacy win here is specifically the audio/byte reduction, not text PII removal: a regex scan of this transcript found no emails, phone numbers, or SSNs because the sample (a description of paragliding) contained none. A transcript in general can carry PII, which is exactly why redaction belongs on-device, before the serverless call.

What’s deliberately missing from this article: virtual environment setup, dependency installation, the first-run model download. Those belong in the repository README, and keeping them there lets the architecture stay in focus.

A detail a cautious evaluator will appreciate: the demo can run its entire interface with no API key and zero spend. Setting TRANSLATION_FAKE_MODE=true launches the full UI and returns placeholder translation text instead of calling DigitalOcean. A team can assess the user experience, the flow, and the architecture before committing a cent of budget — and before anyone has to provision credentials.

There’s also a readiness check, scripts.asr_status, that reports whether PyTorch and the ASR runtime are installed and whether hardware acceleration (Apple’s MPS, in this case) is actually available. It’s a small thing, but it signals something larger: the local side of the system is observable and debuggable in the same operational terms you’d expect from anything you’d put in production. Hybrid doesn’t mean the local half is a mystery box.

Translation is just one instance. The shape generalizes to any pipeline that has a sensitive or high-frequency stage sitting next to a heavy or occasional one. Once you start looking, the pattern is everywhere:

• Local redaction → serverless summarization. Strip personally identifiable information on-device, then send the safe, redacted text to a hosted model for summarization.
• Local embedding → serverless reasoning. Generate vector embeddings on your own hardware where the source documents live, then call a larger hosted model for the reasoning step.
• On-device capture → serverless enrichment. Capture and pre-process sensor or media data locally, send only the distilled result up for enrichment.

Each is the same move: keep the sensitive, constant, or hardware-friendly work local; rent the heavy, occasional, capability-defining work per use.

If you take one sentence into your next planning meeting, make it this: keep local what your hardware already does well and what must stay private; rent the rest per-use.

The strategic payoff is that this pattern lets a team adopt serverless inference incrementally. You don’t have to choose between full cloud dependence and full self-hosting. You can move exactly the stages that benefit from being hosted, keep tight control of your most sensitive and highest-volume work, and adjust the boundary as your costs, models, and constraints evolve. That optionality — redrawing the line without rebuilding the system — is what the hybrid approach buys you.

• Reference implementation: github.com/Jameshskelton/serverless_translation
• DigitalOcean Serverless Inference — product deep dive and available models catalog
• Related reading: LLM inference benchmarking
• Model references: nvidia/nemotron-3.5-asr-streaming-0.6b (local ASR) and nemotron-3-nano-omni (serverless translation)

The most useful next step isn’t to copy the translation tool — it’s to take your own two-stage workload, run each stage through the four-axis framework, and adapt the seam. The code at the boundary is small. The decision behind it is what matters.