The headline is striking: ten minutes of audio transcribed in 1.65 seconds on an iPhone. The question for a robot waiting on a spoken instruction is different: when can it act on the last word?
QVAC’s October 14 TranscribePsy release reports that long-recording result for its Core ML build on an iPhone 17 Pro Max, excluding cold start. On 160 shorter utterances, average processing latency is 207.3 milliseconds. The release explains that fixed-size windows leave short inputs padded. Its current models process complete utterances rather than streaming speech. First-load measurements include Core ML compilation, at roughly 12 seconds in the reported tests.
These figures describe different events. None should be substituted for the others in a product promise.
The clock starts before inference
For an offline voice command, elapsed time includes the speaker finishing, the system deciding that speech has ended, any necessary loading, transcription and interpretation. A recogniser can be extraordinarily fast at processing stored audio while still waiting for the whole command to arrive.
That is not a defect in a batch-transcription model. It is a mismatch if a developer uses a throughput result to predict an interactive control loop. A robot that must respond to an interruption has a different timing requirement from an application transcribing a voice note after recording.
Fixed-size accelerator windows create another distinction. A long recording can keep the hardware busy with full windows. Very short commands may use only a fraction of each window while paying much of the same processing overhead. The relevant benchmark distribution is therefore the length and frequency of the commands the product will actually receive.
Keeping a model warm is a system choice
A first-load compilation cost should not be presented as a delay on every command. Equally, it should not disappear from the product plan. A device needs a strategy for installation, initialisation and recovery after the operating system evicts an application.
Keeping a recogniser resident can reduce waiting but reserves memory that cameras, planners and controllers may also need. Loading it on demand saves resident capacity while introducing another source of delay. Model size alone does not settle that trade-off.
The 254-million-parameter release is relevant to physical AI as a component for local voice interfaces, not as a demonstrated robot controller. Its language coverage and complete-utterance interface define where that component can be useful. A deployment test should measure from microphone input to accepted command on the actual device, including warm and first-use cases separately.
The useful achievement is that capable transcription can fit on modest hardware. The engineering lesson is in the spread between the numbers. A machine can consume a recording hundreds of times faster than real time and still have to wait for a person to finish saying what they want.
References
Questions, news tips or corrections? Contact [email protected].
