Can local AI answer as fast as the cloud — on hardware you can actually buy?

01Introduction: the premise and the bar

A private, self-hosted assistant — offline-capable, entirely yours — only lands if it feels as immediate as the cloud services it replaces. Ask Alexa, Google Home, or Siri to turn off a light and it happens in about a second or two. If a local one takes five, nobody will use it, however private it is. Cloud-parity responsiveness isn't a nice-to-have; it is the bar this study measures against.

This work supports Kenzy, an open-source, local-first, whole-home voice assistant that runs on hardware the owner controls (kenzy.ai). The premise we set out to test is concrete: consumer and lower-end professional GPUs — the kind anyone can actually purchase — are enough to run a real voice assistant's brain locally, at real-time responsiveness on par with the cloud assistants. Not a toy: a tool-calling assistant that understands a spoken request, decides whether to act on a device or just answer, resolves who is speaking, and replies — with a realistic amount of context — fast enough to feel like a conversation rather than filing a ticket.

Two questions sit underneath that. A hardware question — how much GPU do you actually need, and does the expensive card buy anything? And an architecture question — keep the classic composed pipeline (speech-to-text → language model → text-to-speech), or move to a single speech-to-speech model that hears and speaks directly? We could not find measured, apples-to-apples numbers for this exact shape of problem, so we ran it ourselves.

Contributions. This paper reports: (1) a measured latency comparison of dense and Mixture-of-Experts language models on an identical, realistic tool-calling voice workload (§5); (2) a cross-GPU comparison that isolates the two things that move decode speed — memory bandwidth and quantization format (§7); (3) to our knowledge the first measured co-residency budget for a full local voice pipeline — all three models on one 32 GB card, with the context-capacity consequence quantified (§8, §10); (4) two negative results — speculative decoding for short replies (§6) and the speed of a full-duplex speech-to-speech model (§9); and (5) a complete reproduction recipe (Appendix E).

02Background and terminology

This section defines the vocabulary used throughout, so the numbers that follow can be read precisely. Every term is also collected, with expanded definitions, in the Glossary.

The voice turn, and the two architectures

A voice turn is one complete exchange: the user speaks, the assistant acts and/or replies aloud. There are two ways to build the machinery behind it.

The composed pipeline chains three specialized models. Speech-to-text (STT, also called automatic speech recognition) turns the recorded audio into text. A language model (LLM) reads that text — together with its instructions, the list of devices it can control, and who is present — and produces either a reply, a tool call (a structured request to run a function, e.g. "turn off light.office"), or both. Text-to-speech (TTS) turns the reply text back into spoken audio. This is the architecture Kenzy ships today.

The speech-to-speech alternative (S2S) folds all three into one model that takes audio in and emits audio out, with no text hand-offs — and, in the best of them, can listen and speak at the same time (full duplex) and call tools mid-sentence. We evaluate one such model in §9.

Tokens, context, and the workload it carries

Language models read and write tokens — sub-word chunks of text; a token is roughly ¾ of an English word. Everything the model is given for a single request — its standing instructions, the catalog of tools it may call, the smart-home device list, the injected facts about people and rooms, and the user's transcribed utterance — is its context (or prompt), measured in tokens. When this paper refers to a representative production context of ~8,731 tokens, that is the real per-request prompt a deployed Kenzy assistant assembles; its composition is broken down in Appendix A. That single number is what we hold fixed so every configuration is compared on the same, realistic load — not a short synthetic prompt that would flatter first-token latency.

How we talk about latency

A model answers in two phases. Prefill reads the whole context in one pass; its cost sets the time to first token (TTFT) — the pause before the assistant starts producing its answer. Then decode generates the reply one token at a time; its speed is decode throughput, in tokens per second. For a voice assistant the two derived quantities that a person actually experiences are time to first spoken word (STT + TTFT + the first slice of TTS) and, for a command, time to act (STT + however long until the tool call is complete). Keep those two straight from raw throughput; §4 shows why throughput barely matters here.

What runs, and on what

Weights can be stored at reduced precision — quantization — to save memory and move faster. The Blackwell-generation cards here run a 4-bit format called NVFP4 on dedicated FP4 tensor cores; the older Ada-generation card cannot, and uses 8-bit FP8 instead (§7, §8). A dense model runs all of its parameters for every token; a Mixture-of-Experts (MoE) model has many "expert" sub-networks and a router that activates only a few per token, so a large model can do a small amount of math per token (§5). During decode, the model re-reads its cached attention state — the KV cache — for every token, which is why decode speed tracks memory bandwidth, and why the size of the KV-cache pool determines how much context fits (§8). Serving is handled by an inference engine — vLLM for the language models, llama.cpp for the speech-to-speech model.

03Methodology

3.1 · What the workload represents

The benchmark drives the exact request a deployed assistant issues. Every request carries the representative production context of 8,731 tokens defined in §2: the assistant's 31 real tools (~4.7k tokens of JSON schemas), a 240-device smart-home topology, the standing system instructions, and the per-request injection of people, rooms, and occupancy state. The utterances come from a 50-prompt corpus spanning five categories that mirror real usage — simple commands, context-dependent commands, conversational questions, explicit tool calls, and longer multi-clause requests. Each prompt is run 10 times, giving n = 500 requests per configuration. The corpus categories, with examples, are in Appendix A.

3.2 · What we measured

The language-model benchmark isolates only the model's work — the LLM stage — because that is the part in question; speech-to-text and text-to-speech are measured separately and folded back in for the end-to-end comparison (§10). Per request we record: time to first token (TTFT); total latency until the response or tool call is complete; decode throughput in tokens per second; and tool-call rate (whether the model emitted the expected structured call). Unless noted, reported figures are the median across the n = 500 requests of a configuration.

3.3 · How we measured it

The client runs on the GPU host and issues requests against localhost, so the numbers are the model's work, not network transit. Language-model serving is vLLM 0.27 with automatic prefix caching enabled — the large shared context is encoded once and amortized across requests, exactly as a real deployment reuses its stable prompt — and greedy (deterministic) decoding. Each configuration is warmed before measurement so the prefix cache and CUDA kernels are primed and cold-start does not contaminate the sample. The full serving flags and model identifiers are in Appendix C; hardware and software versions in Appendix B.

3.4 · Measured versus derived

Every figure in this paper is measured on the hardware named, with a single exception, flagged wherever it appears: a matched-quantization FP8 run of the models on the 5090 was blocked by a network fault on that rented host and is derived analytically from the measured Ada FP8 and 5090 NVFP4 runs. It is used only for illustration and never for a headline claim.

04Result: throughput is a red herring

The instinct is to chase tokens-per-second. For a voice assistant, that instinct is wrong, and it is worth dismantling before any number below can be read correctly.

Human speech runs about 150 words per minute — roughly 3–4 tokens per second of spoken audio. The slowest model we measured generates text at ~70 tokens per second; the fastest, ~270. That means the model produces words 20× to 70× faster than they can be spoken. Once the first token lands, the model is always far ahead of the voice playing it. Throughput would only bind if you were generating long documents — which a voice assistant never does.

What a person feels is the pause before the assistant starts talking — not how fast it talks once it has started.

So the metrics that matter are time to first token (how long the pause is) and, for a command, time to act (how long until the lights actually change). Keep that in mind: several models below post gaudy tokens-per-second numbers that change nothing about how responsive they feel.

05Result: dense vs. Mixture-of-Experts

The central comparison. Two models, same quantization (NVFP4), same 5090, identical serving config:

• Qwen3.8-27B — a dense model: every one of its 27B parameters runs for every token.
• Qwen3.6-35B-A3B — a Mixture-of-Experts model: 35B parameters total, but a router activates only ~3B of them per token.

Intuition says the 35B model should be slower — it is bigger. Intuition is wrong, because "bigger" here means more parameters on disk, not more math per token. The MoE does far less work per token, and both prefill (which sets TTFT) and decode (which sets throughput) collapse accordingly.

The MoE also gets the caller and room right from the injected context — its tool call carries the resolved speaker and room, not a guess. The one place it trails the dense model is tool-call rate (71% vs. 78% overall; both 98–100% on the explicit tool-call category) — worth validating against a real skill suite, but not a latency concern.

06Result: speculative decoding is a trap for short replies

The 27B model ships a multi-token-prediction (MTP) head — a lightweight draft that lets the GPU verify roughly two tokens per forward pass. It is the classic way to buy throughput. We enabled it expecting a free win. It isn't one — for our workload it is a net loss:

Speculation raises throughput by half — and makes the pause worse, because under speculation vLLM chunks the prefill into smaller pieces and the draft head adds cost to the very first token. For short assistant replies (a tool call is ~30–60 tokens) the two effects cancel and you're left with a slightly slower turn. MTP only pays off when generation is long — with step-by-step "thinking" enabled it cut total latency ~29% — which is exactly the mode a voice assistant should avoid. The right call for the voice path: MTP off.

07Result: three GPUs, one workload

Decode speed is bound by memory bandwidth, so the card matters. We ran the same workload on three:

The 96 GB PRO 6000 is the same speed as the 5090. Same-architecture, same GDDR7 bandwidth — decode throughput was identical (79 vs. 81 tok/s on the dense model), TTFT within ~7%. Its extra 64 GB of VRAM buys capacity — bigger models, more concurrent users, longer context — not single-request speed. For a one-household-at-a-time assistant, the 5090 leaves nothing on the table.

The RTX 6000 Ada is the interesting one. It can't run NVFP4 (no FP4 tensor cores), so it uses FP8 — and it has ~60% of the 5090's memory bandwidth. Both effects show up:

For our purposes the Ada is the worse buy: slower, and its extra VRAM only enables an FP8 MoE that the 5090 runs faster in NVFP4 anyway. But if you already own one, the MoE on it is perfectly usable — a tool command in ~636 ms.

08Result: VRAM, and how much context each card holds

Two practical questions for anyone sizing hardware: will the model fit, and how much conversation can I give it? The table below reports the memory the weights occupy and the maximum context window that fits with the language model alone on the card, at high memory utilization. The realistic co-resident figure — with speech-to-text and text-to-speech sharing the card — is lower and is measured in §10.

Two things fall out. First, context is not a constraint. Even the tightest config — the dense model on the 5090 — holds ~53k tokens, roughly 6× the ~8.7k a representative deployment uses. The MoE's smaller per-token memory gives it ~2.7× the context of the dense model on the same card. (These are the LLM by itself; running speech-to-text and text-to-speech on the same 5090 — the realistic single-box setup — trims the MoE's pool to ~112k, still ~13× the need. That number, and a sharp caveat about its sensitivity to the memory-utilization setting, are in §10.) Second, FP8 weights are ~1.3× the size of NVFP4, so the FP8 MoE (34 GB) can't fit a 32 GB 5090 at all — it needs the 48 GB Ada. But the 5090 runs that same MoE in NVFP4 (23 GB) and faster, so the extra VRAM buys nothing here. The one model that genuinely needs 32 GB is the MoE in NVFP4; a 24 GB card is too tight for it.

09Result: the speech-to-speech alternative

The composed pipeline (speech-to-text → LLM → text-to-speech) works, but it is three models and an orchestration layer. A newer idea folds all of it into one speech-to-speech model that hears audio and speaks audio directly, with no text hand-offs — and, in the best of them, can listen and talk at the same time (full duplex) and even call tools mid-sentence.

We tested the leading open one, NVIDIA NemotronLabs VoiceChat-11B. Its own serving stack wants an 80 GB datacenter GPU — a non-starter for a home. But a community llama.cpp fork reimplements the full-duplex pipeline (audio encoder + language model + neural speech codec + a tool/turn-taking head) and runs it, in 4-bit, on a 5090 in about 10 GB. It works, and the standout is real:

Two honest findings temper it. First, it needs a system prompt to behave as a home assistant — out of the box it refused device control as a "safety violation." Second, and more important, it is slow to first word. We had initially estimated ~500–700 ms; measured, it is ~1–1.7 seconds — the full response computes in ~1.7 s on this 4-bit llama.cpp path (NVIDIA's optimized stack claims ~450 ms turn-taking; this one is materially slower). It is, in fact, the slowest option to first word — which only matters because of what §10 shows next.

10Result: the full pipeline, on one clock

Now we can compare fairly. The model numbers above are one stage. A voice turn also needs speech-to-text before the LLM and text-to-speech after it — and, if you want everything on one box, those two models have to share the GPU with the LLM. The two conversion models are lightweight specialists: speech-to-text is faster-whisper "small", text-to-speech is Kokoro-82M (see Appendix B).

So the honest single-box stage budget is speech-to-text ≈ 219 ms (co-resident) and text-to-speech first audio ≈ 17 ms, around the LLM's first token. The speech-to-speech model, by contrast, is the whole pipeline in one — so "~1.7 s" already includes hearing and speaking.

Putting all three on the same clock — t=0 is the moment you stop speaking, everything co-located on one 5090:

The composed MoE pipeline wins every checkpoint. That reverses an intuition we held going in — that a single speech-to-speech model would feel more immediate. It doesn't, at least not in this 4-bit form. What the speech-to-speech model uniquely offers is true full duplex — you can interrupt it mid-sentence and it is still listening, and it calls tools without stopping — plus a tiny ~10 GB footprint. That is an interaction-style choice, not a speed one.

11Discussion: what we'd ship

• Model: the 3B-active MoE (NVFP4), thinking off, speculative decoding off. It makes the model stage feel instant — ~260 ms — and holds ~112k tokens of context even with speech-to-text and text-to-speech co-resident.
• Card: a single RTX 5090, for the voice assistant. It is the sweet spot: as fast as a 96 GB workstation card for this workload, and it runs the winning model in the format that needs its 32 GB. Bigger cards buy capacity, not speed — for voice. But see the limitation below: the moment you add a long-horizon agent, the extra VRAM stops being idle.
• Architecture: keep the composed pipeline for now. It is faster and more capable (stronger reasoning, a real 31-tool surface, multilingual, long context). The speech-to-speech model is a compelling second path for natural back-and-forth conversation — and its ~10 GB footprint and full-duplex feel will keep pulling on us — but it isn't the responsive, tool-calling spine today.

Yes — consumer hardware can run a voice assistant that answers as fast as the cloud, with every word kept in the house. The winning model is a 35B that only wakes 3B of itself, on a card you can buy today, answering before you've finished lowering your hand.

12Limitations and threats to validity

This is an engineering report, and its scope is deliberately narrow. The honest boundaries:

• The single derived figure. A matched-quant FP8 run of the models on the 5090 was blocked by a host network fault and is derived analytically, not measured (§3.4). It is illustrative only; no headline rests on it.
• Single-host samples, one run each. Each configuration is n = 500 requests on one rented instance of that GPU. We report medians, but we did not repeat across multiple physical cards of the same model or multiple cloud regions, so we cannot separate card-to-card and host-to-host variance from the effects we attribute to architecture and bandwidth. The large, consistent gaps (≈3×) are well outside plausible host noise; smaller ones (e.g. 79 vs. 81 tok/s) should be read as "indistinguishable," not ranked.
• The Ada FP8 kernel is a floor, not a ceiling. The RTX 6000 Ada numbers use an un-tuned FP8 path; a tuned kernel would narrow — not erase — the gap to Blackwell. We present the Ada as "the worse buy for this task," which its bandwidth deficit alone supports, but its throughput figure should be read as a lower bound.
• Co-residency timings are small-sample. The co-resident speech-to-text (~219 ms) and text-to-speech (~17 ms) figures, and the end-to-end chain, were validated on a handful of live turns rather than a 500-run battery. They establish that the pipeline fits and holds together at the stated budget; treat the exact milliseconds as representative, not distributional.
• Synthetic and single-voice audio. Speech-to-text accuracy and timing were exercised with clean input, not a corpus of far-field, accented, or noisy household speech. Real-room word-error-rate is out of scope here and is studied separately in Paper 02.
• Tool-call rate needs a real skill suite. The MoE's lower overall tool-call rate (71% vs. 78%) is a quality signal we flag but did not chase; validating it against the full skill surface, and against multi-turn dialogues, is future work. Nothing here measures answer correctness beyond whether the expected tool was called.
• Point-in-time software. Results are tied to specific model weights and to vLLM 0.27 / llama.cpp as of August 2026 (Appendix B). Inference stacks move quickly; the speech-to-speech model in particular is on a fast-moving community runtime and should improve.
• Scope is the voice pipeline. The "one 5090 is enough" conclusion holds for a one-household-at-a-time voice assistant. It does not cover concurrent multi-user serving or long-horizon agents; that boundary is quantified next.

13Conclusion

Measured end to end, on hardware anyone can buy, a private voice assistant answers as fast as the cloud services it replaces — faster, in the configuration we recommend. The felt latency of a voice turn is set by time-to-first-token and audio conversion, not by generation throughput; a Mixture-of-Experts model that activates ~3 billion of its 35 billion parameters completes the language stage in ~260 ms, and speech-to-text, that model, and text-to-speech all co-reside on one 32 GB RTX 5090 with a ~112k-token context pool to spare — first spoken word in ~330 ms, device action in ~480 ms. The premise holds, within the limits above: cloud-parity responsiveness is achievable locally, on a single publicly-buyable card, with nothing leaving the house. The one place it breaks — long-horizon agents sharing the box — is a capacity problem with two clear answers (a second GPU, or a 40–48 GB card), not a wall.

GGlossary

Active parameters

In a Mixture-of-Experts model, the number of parameters actually used to process a given token — far smaller than the total. Latency tracks active parameters, not the total in the model's name.

Composed pipeline

The three-model voice architecture used by Kenzy: speech-to-text → language model → text-to-speech, with an orchestration layer between them.

Context (context window, prompt)

Everything a model is given for one request, measured in tokens: instructions, tool catalog, device topology, injected household state, and the user's utterance. The maximum a model can hold is its context window; how much fits on a given card is set by the KV-cache pool.

Decode

The generation phase, producing the reply one token at a time. Its speed is decode throughput (tokens/second) and is limited by memory bandwidth.

Dense model

A model that runs all of its parameters for every token — the conventional architecture. Here, the 27B model.

FP8 / NVFP4 quantization

Reduced-precision weight formats. NVFP4 is a 4-bit format that runs on Blackwell FP4 tensor cores (RTX 5090, PRO 6000). FP8 is an 8-bit format used on the older Ada card, which lacks FP4 hardware; FP8 weights are ~1.3× the size of NVFP4.

Full duplex

The ability to listen and speak at the same time — so the user can interrupt mid-sentence and be heard. A property of the speech-to-speech model evaluated in §9.

Greedy decoding

Deterministic generation that always takes the highest-probability next token (no sampling randomness), so measurements are repeatable.

KV cache

The stored attention state (keys and values) the model re-reads for every generated token. The pool of GPU memory set aside for it determines how much context fits; on the hybrid model here, its size is unusually sensitive to the memory-utilization setting (§10).

llama.cpp

An open inference engine used here to run the speech-to-speech model, via a community fork, in 4-bit on a consumer GPU.

Memory bandwidth

How fast a GPU can move data between its memory and compute units, in terabytes/second. Because decode re-reads the weights and KV cache each token, decode throughput tracks bandwidth more than raw compute.

Mixture-of-Experts (MoE)

A model split into many "expert" sub-networks with a router that activates only a few per token. A large model can thus do a small amount of math per token. Here, the 35B-A3B model (35B total, ~3B active).

Prefill

The phase that reads the entire context in one pass before generation begins. Its cost sets the time to first token.

Prefix caching

An inference-engine optimization that encodes a shared, stable prompt prefix once and reuses it across requests — matching how a real deployment reuses its fixed instructions and tool list.

Speculative decoding (MTP)

A throughput technique that drafts several tokens with a lightweight head and verifies them in one pass. Multi-token prediction (MTP) is the variant shipped with the 27B model. It raises throughput but can worsen first-token latency — a net loss for short replies (§6).

Speech-to-text (STT / ASR)

Converts recorded audio into text. Here, faster-whisper "small."

Text-to-speech (TTS)

Converts reply text into spoken audio. Here, Kokoro-82M.

Speech-to-speech (S2S)

A single model that takes audio in and produces audio out with no text hand-offs, optionally full-duplex and tool-calling. Here, VoiceChat-11B.

Time to first token (TTFT)

The delay between sending a request and the model emitting its first output token — the pause a listener feels before the assistant starts. The metric that matters most for voice.

Time to act

For a command, the delay from the user finishing speaking to the device action firing (STT plus the model completing its tool call).

Token

The sub-word unit models read and write; roughly ¾ of an English word.

Tool call (function calling)

A structured request the model emits to run a named function with arguments (e.g. control a device) rather than only replying in prose.

vLLM

The open, high-throughput inference engine used to serve the language models here (v0.27).

AAppendix A · Workload and context composition

Every language-model request carried the same 8,731-token context — the prompt a deployed Kenzy assistant actually assembles for one voice turn. Its major components:

• Tool schemas — ~4,700 tokens. JSON-schema definitions for the assistant's 31 real tools (device control, media, timers, memory, presence queries, and so on), exactly as sent to the model.
• Smart-home topology. A 240-device home: entities, areas/rooms, and the relationships the model needs to resolve "the office lamp" to a specific device.
• Standing system instructions. The assistant's persona, policy, and output-format rules.
• Per-request injected state. The people present, the rooms, and current occupancy — the context that lets the model resolve who is speaking and where.
• The user utterance. The transcribed request itself.

The corpus of 50 prompts, each run 10 times (n = 500), spans five categories chosen to mirror real household usage:

BAppendix B · Hardware and software

The Blackwell cards required a very recent CUDA/driver stack (CUDA 13) to build the FP4 kernels; see the trap in Appendix E. Prefix caching was enabled; decoding was greedy; the benchmark client ran on the GPU host against localhost.

CAppendix C · Serving configuration

The language models were served with vLLM using automatic prefix caching, greedy decoding, and the Qwen tool-call and reasoning parsers. On the 32 GB 5090, the operative fit settings were a high memory-utilization target with a bounded max context and concurrency:

# vLLM 0.27 · RTX 5090 · NVFP4 MoE (representative)
--max-model-len 12288        # context window sized to the ~8.7k workload + headroom
--max-num-seqs 16            # bounded concurrency
--gpu-memory-utilization 0.90 # high util → large KV pool (see §10 sensitivity note)
--enable-prefix-caching       # amortize the fixed prompt prefix
--tool-call-parser qwen3_xml  # the model emits XML-style tool calls

Two settings decided the co-residency result (§10): the memory-utilization target sets the KV-cache pool, and on this hybrid Mamba-attention model that relationship is steep — 0.90 → 111,616 tokens, 0.85 → 31,744 tokens. The recipe is to set utilization high and load the small speech models into the remaining headroom, not to lower utilization to "make room."

DAppendix D · Full results

EAppendix E · Reproducibility & cost

Everything here was measured, not modeled (the one exception is flagged in §3.4: the matched-quant FP8 run on the 5090, blocked by a network fault on that rented host, is derived analytically and labeled as such). The harness sends the production-shaped context and corpus to any OpenAI-compatible endpoint, streams the response, and records TTFT / total / decode / tool-rate per request with warm-up to prime the prefix cache. The models are public — unsloth/Qwen3.8-27B-NVFP4, unsloth/Qwen3.6-35B-A3B-NVFP4, the FP8 variants, and NVIDIA NemotronLabs VoiceChat-11B via the community llama.cpp fork — and serving is stock vLLM 0.27 and llama.cpp. GPUs were rented by the hour; the entire study, including the false starts, cost well under the price of the card it recommends.

FAppendix F · Metrics reference, by card

Every quantity the study reports, consolidated into card-column grids for quick lookup. Some of this restates earlier tables on purpose — this appendix is meant to be the single reference surface. Values are coded: plain text is measured directly; cyan with a superscript ᶜ is calculated or estimated from measured quantities; an em dash (—) means not separately measured. The estimates are deliberately conservative — where a derivation would be unreliable (a hybrid model's KV pool on a card we didn't run), the cell is left blank rather than guessed.

F.1 · The cards

F.2 · Dense model — Qwen3.8-27B

F.3 · Mixture-of-Experts model — Qwen3.6-35B-A3B

F.4 · Co-residency and the speech-to-speech alternative (RTX 5090)

Two configurations that live only on the 5090: all three pipeline models sharing one card (the capacity result of §10), and the single speech-to-speech model (§9). Both fully measured.

RReferences

1. Qwen team. Qwen3 language models. Weights used here in NVFP4/FP8 via the Unsloth redistributions. huggingface.co/Qwen · huggingface.co/unsloth
2. vLLM project. vLLM: a high-throughput and memory-efficient inference engine for LLMs (v0.27). github.com/vllm-project/vllm
3. NVIDIA NemotronLabs. VoiceChat-11B — full-duplex speech-to-speech model. huggingface.co/nvidia
4. llama.cpp. LLM inference in C/C++, and the community VoiceChat fork used to run the S2S model in 4-bit on a consumer GPU. github.com/ggml-org/llama.cpp
5. SYSTRAN. faster-whisper — CTranslate2 reimplementation of OpenAI Whisper (model: "small"). github.com/SYSTRAN/faster-whisper
6. hexgrad. Kokoro-82M — compact text-to-speech model. huggingface.co/hexgrad/Kokoro-82M
7. NVIDIA. NVFP4 and the Blackwell FP4 tensor cores — architecture documentation for the 4-bit path used on the RTX 5090 and PRO 6000.
8. The Kenzy Project. Kenzy — an open, local-first, whole-home voice assistant. kenzy.ai · github.com/lnxusr1/kenzy
9. Kenzy Research. Paper 02 — wake-word arbitration on commodity hardware. research.kenzy.ai/wake-arbitration.html