---
type: "post"
id: "the-release-includes-the-refiner-model-a-lora-f17cb4"
slug: "the-release-includes-the-refiner-model-a-lora-f17cb4"
title: "The release includes the refiner model, a LoRA fine-tune of LiquidAI’s LFM3-1.7B."
description: "Phonon’s published refiner is a LoRA fine-tune of LiquidAI’s LFM3-1.7B, designed to turn raw speech-recognition transcripts into text ready for the destination app."
retrieval_nugget: "Phonon’s published refiner is a LoRA fine-tune of LiquidAI’s LFM3-1.7B, designed to turn raw speech-recognition transcripts into text ready for the destination app. Its detailed recipe, data accounting, prompt contract and downloadable quantized artifacts make this a useful, inspectable example for teams building local voice workflows."
published_at: "2026-11-06"
updated_at: "2026-11-07"
record_date: "2026-11-06"
date_kind: "published_at"
topics: ["models","multimodal"]
entities: ["Phonon","Phonon Refiner 1.7B","LiquidAI","LFM3-1.7B","Parakeet TDT 0.6B v2","DeepSeek-V4.1-Flash-1017"]
related_patterns: []
novelty_label: "new_fact"
what_changed: "Phonon released a 1.7B transcript-refiner LoRA fine-tuned from LiquidAI’s LFM3-1.7B for its local voice-typing app."
prior_refs: ["https://newruntime.com/posts/liquid-ai-launches-lfm3-an-open-weight-2b-d00d7d/","https://newruntime.com/posts/llama-cpp-v0-8-0-adds-liquidai-lfm3-a547b8/"]
source_url: "https://huggingface.co/Infatoshi/phonon-refiner-1.7b"
source_urls: ["https://huggingface.co/Infatoshi/phonon-refiner-1.7b"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:the-release-includes-the-refiner-model-a-lora-f17cb4"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/the-release-includes-the-refiner-model-a-lora-f17cb4/","markdown":"https://newruntime.com/posts/the-release-includes-the-refiner-model-a-lora-f17cb4.md","json":"https://newruntime.com/posts/the-release-includes-the-refiner-model-a-lora-f17cb4.json"}
markdown_url: "https://newruntime.com/posts/the-release-includes-the-refiner-model-a-lora-f17cb4.md"
---

# The release includes the refiner model, a LoRA fine-tune of LiquidAI’s LFM3-1.7B.

## Retrieval answer

Phonon’s published refiner is a LoRA fine-tune of LiquidAI’s LFM3-1.7B, designed to turn raw speech-recognition transcripts into text ready for the destination app. Its detailed recipe, data accounting, prompt contract and downloadable quantized artifacts make this a useful, inspectable example for teams building local voice workflows.

## Summary
Phonon’s published refiner is a LoRA fine-tune of LiquidAI’s LFM3-1.7B, designed to turn raw speech-recognition transcripts into text ready for the destination app. Its detailed recipe, data accounting, prompt contract and downloadable quantized artifacts make this a useful, inspectable example for teams building local voice workflows.

## What happened
The Hugging Face repository describes Phonon Refiner 1.7B as the correction model in Phonon, a local voice-typing app for Apple Silicon Macs. The app first uses Parakeet TDT 0.6B v2 to produce a raw transcript. The refiner then rewrites that transcript toward the text the speaker intended to type: correcting misrecognized terms when supported by evidence, removing filler and false starts, retaining the final wording after a self-correction, and formatting text for its destination. The published model is the refiner used in Phonon 1.0; the repository also identifies the 0.2.3 refiner as commit `74ea4b6`.

The release provides the files that the app downloads on first launch. Its native-engine target is a GGUF Q4_K_S refiner of 988,453,696 bytes, accompanied by a 214,803,168-byte DFlash2 speculative drafter, described as unchanged from 0.2.3. The repository also provides an MLX fallback: `model.safetensors` is 1,133,072,561 bytes and contains the same refiner in MLX 4/6/8-bit form. The GGUF and drafter run on Phonon’s native Metal engine; the MLX weights are loaded when that engine cannot run on a Mac. The listing includes configuration, tokenizer, engine metadata and license files, and Hugging Face displays SHA-256 values on individual file pages.

The model is fine-tuned from LiquidAI/LFM3-1.7B using rank-16 LoRA on all linear layers, with a learning rate of 2e-4, two epochs, batch size 16 and a maximum of 1,024 tokens. The merged weights are quantized for the two deployment targets. The GGUF target uses Q4_K_S, a 4-bit token embedding and output head, plus an importance matrix derived from public training rows. The MLX fallback uses 4-bit weights with group size 64, 6-bit attention and 8-bit embeddings, described as about 5.2 bits per weight.

The repository reports 76,960 training rows. Half are writing-mode rows generated by DeepSeek-V4.1-Flash-1017 from written specifications, using transcripts from public technical audio, programming livestreams and synthetic dictations. The other half are rows from the 0.2.3 refiner, including technical talks, term-repair examples and hard negatives. All targets passed an edit gate intended to undo unsupported word substitutions. The author says no personal dictations, user data or evaluation sets were used, and says evaluation videos were held out by video ID. No audio is redistributed with the weights.

Phonon selects one of four mode lines—minimal, casual, formal or prompt—based on the destination app. The prompt mode is intended for AI assistants, terminals and code editors; casual mode covers personal messaging; formal mode covers email and work chat. The model is instructed to preserve meaning and never invent or drop content. An optional vocabulary line can supply terms the speaker may use. The repository specifies greedy decoding, thinking off and no repetition penalty, and describes output-length safeguards in the app. The supplied material does not state a separate price for the model or app.

## What the archive adds
This is a new event, but it sits beside earlier coverage of Liquid AI’s model distribution. Our note on [Liquid AI’s LFM2.5-24B-A2B release](https://newruntime.com/posts/liquid-ai-released-lfm2-5-24b-a2b-a-c47d5c/) argued that published artifacts and a launch path make a model release practically testable. A separate [llama.cpp v0.8.0 note](https://newruntime.com/posts/llama-cpp-v0-8-0-adds-liquidai-lfm3-a547b8/) covered LFM3-family support. This release is distinct: it documents a task-specific fine-tune and the app’s local deployment files.

## Trend signal
The release is consistent with the view that model portability depends on keeping training and operational assets inspectable and exportable. The archive’s [owned learning loop assumption](https://newruntime.com/shifts/owned-learning-loop/) says providers will not lock customers in by making memory, fine-tuning data or traces unexportable. Here the weights, recipe and training-data accounting are published, though this does not establish how users can export app-level data.

## Why now
The repository ties the model to Phonon 1.0 and describes it as the app’s current refiner, while also identifying the earlier 0.2.3 model version. That makes the publication relevant to the app’s current first-launch download path. The supplied material gives no further launch date or explanation for the timing.

## Why it matters
Voice transcription and text cleanup are different jobs. A recognizer can produce a usable draft while still mishandling technical vocabulary, repetitions, restarts or the format expected by a chat, email or coding agent. Phonon’s design makes that separation explicit: one model transcribes, and a second, locally runnable model revises the transcript under a destination-specific contract.

For teams, the useful lesson is not that this model has been proven better than alternatives; the supplied material does not establish that. It is that a narrow editing model can be shipped with its prompt format, training recipe, data counts, quantization choices and fallback path documented. Those details make reproduction and inspection more feasible, and expose where errors could enter. In particular, the rule to correct terminology only with evidence and the app’s fallback to raw text when output length looks implausible are concrete safeguards against a fluent rewrite silently changing what a speaker meant.

A builder evaluating a similar workflow can inspect the model files and test the four modes against their own terminology and destinations. They should treat the repository’s evaluation description as a starting point, not as proof of accuracy for their users: the supplied excerpt does not include comparative scores or a full evaluation result. The practical question is whether local refinement improves usable text without introducing unsupported edits, at acceptable latency and device cost.

## Limits and uncertainty
The source is the model repository and describes the author’s process; it does not independently validate the claims about data provenance, leakage checks, or behavior. The supplied material gives an evaluation setup—120 held-out 30-second lecturer segments, dictionary assistance and other probes—but does not provide the results, comparative baselines or uncertainty estimates. It therefore does not establish accuracy, quality gains over the 0.2.3 refiner, latency, memory use, battery impact or suitability for languages beyond those represented in its materials. Nor does the listing establish the app’s price, adoption, commercial-use terms beyond naming the LFM Open License v1.0, or how user data is handled in the app.

## Skill to build now
Prototype a two-stage dictation pipeline on a small set of your team’s real, consented examples: transcribe first, then refine with a destination-specific instruction. Include technical terms, filler, false starts and self-corrections, and compare the refined output with both the raw transcript and the intended text. Count unsupported edits as failures, not improvements. This mirrors the repository’s separation of tasks and makes the key trade-off—readability versus fidelity—visible before you adopt a local refiner.

## Reader takeaway
Phonon’s release is valuable less as a general-purpose language model than as a well-documented local component for cleaning dictated text. Its distinct modes, explicit fidelity rules and downloadable GGUF and MLX artifacts offer a concrete blueprint to inspect. But the repository details alone do not prove that it improves accuracy or fits every device and workflow; teams should test it against their own speech and vocabulary.

## Open question
How does the refiner perform against the raw transcript and the previous model on its disclosed evaluation sets?

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Models](https://newruntime.com/topics/models.md): Explore the models topic hub.
- topic hub: [Multimodal](https://newruntime.com/topics/multimodal.md): Explore the multimodal topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)