HN Debrief

Show HN: Run an 80B Qwen in 4.3 GB of RAM on a Mac, and a 35B on an iPhone

  • AI
  • Hardware
  • Open Source
  • Developer Tools
  • Apple

Swiftlet is a GitHub project that runs very large Qwen Mixture-of-Experts models on Apple devices by keeping only a small working set in RAM and streaming the rest from SSD. The headline result is an 80B model on a Mac in roughly 4.3 GB of RAM at around 4.5 to 5 tokens per second, plus a 35B model on an iPhone at about 1 token per second. This is not a claim that phones suddenly became fast LLM boxes. It is a systems hack around the usual memory wall, aimed at making sparse open-weight models usable on ordinary hardware.

If you care about local AI products, watch memory bandwidth and model sparsity more than raw FLOPS. The practical near-term opportunity is not replacing cloud inference wholesale, but finding offline, private, or background tasks where slow local models are already good enough.

Discussion mood

Mostly excited and bullish. People liked seeing giant open-weight models squeezed onto ordinary Apple hardware, and the dominant mood was that this kind of awkward prototype is exactly how local AI gets better. The pushback was practical rather than dismissive: prefill is slow, memory bandwidth is the real constraint, and cloud inference will keep winning where latency and throughput matter most.

Key insights

  1. 01

    More RAM barely helps yet

    The current implementation can use more RAM cache with --cache-gb, but extra cache does almost nothing for speed right now because GPU dispatch is the bottleneck. In the author’s tests, moving from 1 GB to 6 GB raised cache hit rate from 43 percent to 70 percent with basically no tokens-per-second gain. That changes the read on the project. It means the SSD streaming trick is already good enough that lower-level execution overhead now dominates, and it also shows expert reuse across tokens is real rather than theoretical.

    Do not assume bigger memory caches will rescue local inference performance on their own. If you are building similar systems, spend effort on kernels, dispatch, and data movement before buying more RAM.

      Attribution:
    • leonickson #1
  2. 02

    Bandwidth is the constraint, not FLOPS

    Several commenters cut through the usual GPU-spec argument and focused on the thing that actually limits local LLMs: how fast weights can be moved and read. Raw compute has climbed dramatically, but consumer VRAM capacity and bandwidth have grown far less generously, which is why local inference keeps turning into a memory-placement problem. That framing makes Swiftlet easier to understand. It is not squeezing more math out of a Mac or iPhone. It is trying to survive a bandwidth-starved regime by relying on sparsity and clever storage access.

    When evaluating local model hardware, stop using TFLOPS as the headline metric. Track VRAM or unified memory size, memory bandwidth, and whether the model architecture is sparse enough to exploit them.

      Attribution:
    • formerly_proven #1
    • root_axis #1
    • apimade #1
    • cududa #1
    • zmmmmm #1
  3. 03

    Local wins only in specific product niches

    The sharpest economic argument was that centralized inference will keep dominating whenever users want fast replies from very large models and providers can batch many requests together. The case for local inference gets stronger when latency can stretch, models can be smaller, or the product benefit comes from privacy, offline operation, or control rather than maximum capability. That is a much narrower claim than 'everything goes on-device,' but it is also the one that held up best against the objections.

    Design local AI products around tasks where waiting is acceptable or data locality is a selling point. If your value depends on frontier quality at interactive speed, assume the cloud still wins.

      Attribution:
    • gpt5 #1
    • anon373839 #1
    • zozbot234 #1
    • hobofan #1
  4. 04

    Apple may win by packaging, not training

    The Apple thesis was not that it will build the best foundation model first. It was that Apple can let frontier labs burn the money, then wrap mature models in better privacy, tighter OS integration, and a cleaner consumer experience. Commenters argued that this fits Apple’s pattern in other product categories. If on-device models become merely good enough, Apple could capture a lot of value without ever leading the benchmark race.

    For product strategy, separate model leadership from product ownership. A company with trusted distribution and deep device integration can win a large AI market even if it never owns the top model.

      Attribution:
    • greggsy #1
    • dd8601fn #1
    • dghlsakjg #1
    • red_green_yell #1
  5. 05

    Local models still need web access

    A practical limit surfaced quickly: many real use cases need current web information, and you cannot meaningfully 'download the internet' for normal local setups. The suggested answer was not full self-contained intelligence but hybrids such as search APIs, SearXNG, or web snapshot services from cloud providers. That keeps the model local while admitting that retrieval stays networked.

    If you are planning a local-first assistant, budget for retrieval infrastructure from day one. The model can live on-device while search and fresh context come from an external service.

      Attribution:
    • pbronez #1
    • morgoo #1
    • gizmodo59 #1
  6. 06

    SSD wear fears are mostly about writes

    The drive-lifetime panic got corrected. NAND flash mainly wears out from writes, not reads, and several commenters said heavy read-mostly workloads should be fine in practice. One commenter did raise a more technical caveat around read disturb in 3D TLC flash and linked a paper suggesting nonstop sequential reads can still force refreshes sooner than people expect. The useful bottom line is that SSD streaming is not obviously a drive killer for ordinary use, but 24/7 weight streaming at high throughput is still a hardware question worth measuring rather than hand-waving away.

    Do not dismiss SSD-offload systems as automatic NAND burners. For serious deployments, monitor actual read patterns and endurance data instead of relying on the simpler 'reads are free' rule.

      Attribution:
    • petu #1 #2
    • zozbot234 #1
    • Alpha3031 #1
    • sudo_cowsay #1

Against the grain

  1. 01

    This may be a dead-end demo

    One skeptical comment argued that projects like this create false hope by making an extreme setup look like a roadmap, when the underlying limits still point away from cheap consumer hardware running trillion-parameter models. That reframes Swiftlet as a clever showcase of today’s sparse-model tricks rather than evidence that storage-offloaded local inference will scale smoothly into the future.

    Treat these demos as probes of the design space, not forecasts. If your roadmap depends on giant local models becoming cheap by default, build a fallback plan.

      Attribution:
    • pizza234 #1
  2. 02

    Prefill pain undercuts the token-rate headline

    The project’s decode speed sounds respectable, but commenters kept stressing that long prompt ingestion is where the user experience falls apart. If large chunks of the model sit in slower memory, prefill becomes throughput-bound in a way optimization slogans cannot hide. That makes the benchmark look much better for short generations than for interactive work with long contexts or coding sessions.

    Ask for prefill numbers before judging any local inference stack. Decode tokens per second alone can hide the part users feel most.

      Attribution:
    • kennywinker #1
    • fsuts #1
    • rhdunn #1
    • IsTom #1

In plain english

3D TLC
Three-dimensional triple-level cell flash, a common SSD memory technology that stores three bits per cell.
decode
The stage of inference where the model generates output tokens one by one after processing the prompt.
dispatch
The overhead involved in scheduling and launching work on a processor like a GPU.
GPU
Graphics Processing Unit, a processor that is widely used for parallel AI computation.
kernel
Here, a low-level compute routine optimized for a specific operation on hardware such as a GPU.
LLM
Large language model, a machine learning model trained on large amounts of text to generate and analyze language.
NAND
A type of flash memory used in SSDs.
open-weight
A model released with its learned numerical parameters so others can run or fine-tune it themselves.
prefill
The first stage of inference where the model processes the input prompt before it starts generating new tokens.
quantization
A technique that stores model weights in lower-precision formats to reduce memory use and often improve speed.
Qwen
A family of language models released by Alibaba.
RAM
Random-access memory, the fast working memory a computer uses while programs are running.
SearXNG
An open source metasearch engine that can query multiple search providers through a self-hosted interface.
SSD
Solid-state drive, a storage device built from flash memory that is much faster than a hard disk but slower than RAM.
tokens per second
A common inference speed metric showing how many text tokens a model can generate each second.
unified memory
A system design where the CPU and GPU share one memory pool instead of each having separate memory.
VRAM
Video random-access memory, the memory on a GPU used to hold model weights and intermediate tensors during training or inference.

Reference links

Project and related implementations

  • Swiftlet
    The submitted project that streams sparse model weights from SSD to run large Qwen models on Apple devices.
  • TurboFieldfare
    The earlier project Swiftlet was said to build on and that already supports models like Gemma.
  • BigMoeOnEdge
    Another project mentioned as doing similar edge inference work for large sparse models.

Apple model reference

Storage endurance and hardware discussion

  • Read-disturb paper on 3D TLC flash
    Cited in the debate over whether heavy SSD read workloads could still shorten drive life via read disturb effects.
  • Taalas products
    Used as an example of putting a model directly into silicon rather than running it as software on general-purpose hardware.

Benchmarks and demos

Claude Code provenance