Show HN: Open-source engine running Gemma 4 26B in 2 GB RAM on any M-series Mac

Show HN: Open-source engine running Gemma 4 26B in 2 GB RAM on any M-series Mac(github.com)

331 points by gitpusher42 3 hours ago | 95 comments

Hi HN,

I built a specialized inference engine for running 4-bit Gemma 4 26B-A4B-IT on any M-series Mac using about 2 GB of RAM. It is called TurboFieldfare and is written in Swift and Metal.

I have always adored on-device AI. It feels like magic that you can run a powerful NN on your Mac or iPhone. So I wanted to push the limits a bit and run a model whose weights don’t fit in memory.

The model’s 4-bit quantized weights occupy roughly 14 GB, which makes running it with conventional inference tools almost impossible on an 8 GB or even 16 GB Mac once the OS, applications, and KV cache are included.

The trick is to keep the shared part of the model and the KV cache in RAM, then stream only the routed experts needed for each token from SSD. An SSD is way slower than RAM, so the runtime uses a small expert cache and bounded parallel `pread`. While those reads are in flight, the GPU runs the shared part of the layer.

I ran more than 100 experiments. Most didn’t work. A few got me here. The experiments are described in the GitHub repo.

It currently generates 5–6 tok/s on an 8 GB M2 MacBook Air and 31–35 tok/s on an M5 MacBook Pro.

I also added an experimental OpenAI-compatible local server. It supports streaming and tool calls, and reuses one prompt prefix from the KV cache.

Try it! The Mac app is easy to install. On the first run, it will download 15 GB of weights from Hugging Face. The model is surprisingly capable.

I would love any kind of feedback!

xenonite 1 hour ago |

With my M1 MBA, I am still on macOS 15. To compile it, just remove the two lines with

  opts.languageVersion = .version4_0

or surround them with

  if #available(macOS 26.0, *) {
    opts.languageVersion = .version4_0
  }

You'll miss out on a prefill speedup of 2.4x (as it yields 11.24x faster attention), according to the git comments, but it works. (On the 8-GPU-core MBA M1, I get 5-6 tok/s.)

gitpusher42 1 hour ago | |

Thank you! That’s useful. I might try lowering the minimum version later. The 2.4x prefill improvement will only work on the apple10 GPU family. The M1 uses apple7 as I remember

nvch 21 minutes ago |

12 tok/s and almost instant response on M1 Max Mac Studio (with faster SSD than laptops) are impressive – gives hope that large models may run locally from SSDs instead of memory.

gitpusher42 12 minutes ago | |

Thanks for sharing! SSD read speed is the biggest limiting factor here, unfortunately

giancarlostoro 30 minutes ago |

Nice, I think this is the second time I see this here on HN, I always wondered why we need to shove the entire model into memory, I don't care who King Charles is every single time. It always felt as though we already figured out how to break up large files and parse them efficiently with very little memory.

Frontier AI feels like its full of people who are brilliant at making models, but when it comes to scale and practicality, they just leave it to whoever sets up infrastructure to worry about. I wouldn't be surprised if frontier AI could be drastically cheaper if they just finetune and optimize their models to not consume all available RAM to only access less than 10% of the models knowledge.

vorticalbox 1 minute ago | |

Putting the whole model in memory is far faster then swapping to disk.

bigyabai 53 seconds ago | |

You're kinda describing the MoE architecture; you can offload expert layers and stream them as-needed if the experts are small enough and the SSD is fast enough.

Dense LLMs typically perform better, but require much more memory and prefill compute to get those results.

woadwarrior01 45 minutes ago |

> The measured result is a reference point, not a performance ceiling.

Claude was here.

sebmellen 34 minutes ago | |

I grind my teeth when I see it. It's so pervasive that I worry I'll pick up the same ticks by reading so much Claudeslop.

jddj 22 minutes ago | |

I'm sure it was a chatgptism first, but I wouldn't accuse a western company of distillation.

In all fairness, maybe it's just that they let some post-2022 recipe blogs get into the training runs around ~4.6-4.8 time

UmYeahNo 25 minutes ago | |

"I ran more than 100 experiments. Most didn’t work. A few got me here."

And here.

andrehacker 12 minutes ago | |

Let my karma burn for saying this: Maybe it is time to let this go man. These comments are really the new incarnation of "grammar policing". (1)

They don't anything of value, did the author use an LLM to fix his prose but no useless slop was added in the process: who cares ? Is the article useless slop: fine, downvote it to oblivion.

(1) For those not old enough to remember that wonderful practice please use your nearest LLM tofind out or, you know, visit a library and do your own research.

tredre3 2 hours ago |

I'm curious how your project compares to plain mmap!

Because llama.cpp will already run 26B in 2GB of RAM if you really want to (mmap enabled, repacking disabled).

It seems like the main difference is that your project synchronizes the SSD reads with inference activity, which you've presumably tuned to cause the least latency possible? Whereas the OS wouldn't care about any of that.

gitpusher42 1 hour ago | |

My first version used plain `mmap`. On the 8 GB M2, a cold 3.36 MB expert took 10 ms with mmap and 2.8 ms with `pread`. The full simulation was 0.50tok/s for `mmap` vs 4 tok/s for `pread`

With `mmap`, OS loads pages reactively as the model touches them. It doesn’t know which experts were selected or when their reads could overlap with GPU work

And common weights still use mmap for simplicity

So, I believe llama.cpp might run it under 2gb, but I assume it will be slower

nijave 1 hour ago | | |

Any idea if madvise helps? Admittedly I have very limited experience and only on Linux

a-dub 1 hour ago | | |

for a given expert, do you have a sense for what the spatiotemporal access pattern looks like?

Catloafdev 2 hours ago | |

Ya I'd be interested to see a comparison of using llamacpp with ssd offloading to compare real speeds.

freediddy 22 minutes ago |

I keep seeing more and more LLM models being loaded by incredibly under-powered machines. Is the GPU/memory crisis all lies? I get that running on an RTX 5090 will be much faster, but if we can use main memory instead of VRAM and get barely usable results, what is going on?

efficax 7 minutes ago | |

all the effort in this space is going into multiuser, datacenter workflows for high throughput inference. running in resource constrained environments is not where the money is. but it will be, especially if we look forward to a world where having 512gb unified ram is normal for "workstation" machines. The semiconductor space is slow enough to respond that it's likely it will take a few years before production capacity has ramped up enough to get us past the current supply crunch but it seems inevitable to me that we'll be able to run huge models like kimi 3 locally in the next few years (maybe 2029/2030 for it to really be affordable)

MaxMatti 17 minutes ago | |

Or maybe it's just lazy programmers, wouldn't be the first time.

mmastrac 1 hour ago |

I have a project that's almost ready to run DiffusionGemma as well. The two project might potentially work well together. I'm getting ~20tok/s on a 36GB M3 and there's strong possibility we might be able to crib faster kernels from each other.

Feel free to reach out.

(currently at https://github.com/mmastrac/diffgemma but not in a releasable state yet)

eamag 1 hour ago | |

Cool project! I looked into it recently and thought that running diffusion models locally doesn't really make sense: https://eamag.me/2026/why-parallel-diffusion-llms-are-slow-o...

What are your thoughts on this?

mmastrac 34 minutes ago | | |

TBH, I think there's some truth to that. I spent _ages_ tuning the kernels to match the tested FLOP count of my M3's processor. I only have an M3 though and wasn't able to push int8 very far on it, but I think there's a chance that M5-class machines and higher might have more capability in this regard.

What I also learned is that MLX/vLLM is probably within ~20% or so of the absolute max perf on Mac. I found some improvements over what they were doing, but we're at the point where it's challenging to optimize without per-stepping kernels.

I found a few improvements over stock DiffusionGemma along the way, like using top-k attention, which drastically improves perf on my mac without sacrificing any of the benchmarks I was able to throw at it.

FWIW some of the issues with Gemma being slow on Mac are specific choices they've made in the architecture that make it challenging to make use various optimizations that have popped up recently. I think a Kimi K3-style network hybrid with the diffusion bits of DiffusionGemma could have some serious sway.

I think that diffusion still has an edge locally, but with some architecture tweaks and CPU improvements it would actually be a winner (ie: training the network for smaller token batch sizes or flexibility in attention heads, a less expensive attention mechanism, and others).

addaon 2 hours ago |

> It currently generates 5–6 tok/s on an 8 GB M2 MacBook Air and 31–35 tok/s on an M5 MacBook Pro.

Where does this big a performance spread come from? I wouldn't naïvely expect SSD performance difference to be that big, and I would expect SSD performance to dominate...

GeekyBear 2 hours ago | |

The M5 SSD's performance uplift was fairly substantial, even when compared to the prior generation.

> In the Blackmagic Disk Speed Test, the SSD in the M5 MacBook Pro achieved read speeds of up to 6,323 MB/s, compared to just 2,031 MB/s on the M4 MacBook Pro. It's not like the M4 is "slow" in a vacuum, but the M5 SSD is over three times faster, which is a great generation uplift.

https://www.tomshardware.com/laptops/macbooks/m5-macbook-pro...

ambicapter 2 hours ago | | |

Extremely impressive.

wongarsu 2 hours ago | |

My suspicion is that this is simply due to the M5 having more memory, and the OS already having most of the file cached. The M2 has more memory pressure and would cache fewer of the SSD reads

If that's true, inference speed would be even lower if you have only 2GB total, including OS caches

GeekyBear 8 minutes ago | | |

The base level M5 doesn't just have more memory than the base level M2.

The memory bandwidth is bumped up by 50%, and the size of the on-die system level cache is bumped up by 50% as well.

gitpusher42 23 minutes ago | |

I am relying quite heavily on system caching and pread. And yeah, M5 is a way faster and I can guess Mac can cache something, even if process stays under 2gb.

It was 83ms read per token for M2 and 12ms on M5 pro. Total is 163ms/tok vs 30ms/tok for M5. So yeah, there is a faster read and faster gpu processing

owaislone 1 hour ago |

Exciting! Maybe techniques like these can enable systems with 30-60GB memory and very fast SSDs of the future run very large models hopefully.

gitpusher42 1 hour ago | |

Yeah! Check the Colibri and Flash-MoE projects. They’re already doing that.

https://github.com/danveloper/flash-moe https://github.com/JustVugg/colibri

hacklas 1 hour ago | |

How large?

With 64 GB of unified memory, you should be able to run a DeepSeek V4 Flash quantisation at 7–10 t/s, for example with: https://github.com/antirez/ds4 or https://github.com/steadfastgaze/MoEspresso (my engine).

The routed experts needed for the next tokens that are not already in memory need to be read from the SSD, so the speed becomes SSD reading bound and the larger the memory, the faster the inference.

mft_ 54 minutes ago | | |

Is there a particular quant of DS v4 Flash you'd recommend that works on 64GB machines? None of the antirez versions on HF look small enough?

Also, FWIW, I've been experimenting with Laguna-S-2.1. It runs reasonably quickly (llama.cpp, IQ2_M quant) but the outputs so far aren't impressive, and it gets stuck and perseverates. Very subjectively, at that level of quantisation, it seems to perform worse than Qwen 3.6 27B at Q4_K_XL.

mandeepj 1 hour ago | | |

> 7–10 t/s

Maybe use it for overnight batch work! Hopefully, you aren’t suggesting it using for realtime conversations!

boutell 25 minutes ago |

This is really neat! Question, on that MacBook Pro with presumably more RAM, is it still holding itself back in the RAM department?

ycui1986 45 minutes ago |

There are a lot of SSD streaming engines these days. But few to actually try some hard features.

There is one that could really improve the speed. Given almost all major models come with MTP head for speculative decoding. The same MTP head could also be used to speculative prefetch the expert weight residing on the SSD. If the expert weight can be preloaded before the GPU actually need them, the speed penalty from VRAM cache miss will be quite reduced.

If the technology demonstrates successful token rate improvement. future models could also come with pretraining heads to preload expert weights, and even make the training be aware of it.

zozbot234 1 minute ago | |

> The same MTP head could also be used to speculative prefetch the expert weight residing on the SSD. If the expert weight can be preloaded before the GPU actually need them, the speed penalty from VRAM cache miss will be quite reduced.

When using SSD streaming, the GPU is practically always waiting for the SSD to fetch the right expert, rather than the other way around. There is basically zero slack on the SSD side, so I'm not sure how "prefetching" is supposed to help. It would mostly hurt by fetching the wrong predicted experts, which already makes MTP practically unhelpful for typical (not widely batched) SSD streamed inference.

hacklas 27 minutes ago | |

Worth mentioning why this is harder than it looks.

There is a different set of experts at every layer, and each layer has a small router that decides which ones to use.

The router needs to look at the state produced by the experts below it.

Drafted tokens from the MTP head can be used to predict which experts the first layer will want, but not beyond that. To know what layer 10 experts needs, you have to run layers 1-9 which means loading their experts.

So, yes, instead of a next-token drafter like MTP, you'd want something trained to predict the expert activation across all layers at once.

IsTom 1 minute ago | | |

That kind of sounds like a branch predictor in a CPU.

y42 34 minutes ago |

Dont want to crash the party here, but I am still sceptic about all those on-premise-llm-approaches.

I think we strongly need something like that (shameless plug, I tried to build something around bitNet for the same reason: https://github.com/nickyreinert/bitNetRTR).

But at the end, all aproaches I saw, however genius they are: the actual results are always a mess. It's a better chat buddy, nothing else. It's e.g. far away from an decent coding assistants. I fine tuned Gemma with domain specific knowledge. Running it on a 16GB VRM GForce. Even then it's okai'sh but far way from a mind blowing experience. I ran some of the promised open source model on my 36GB MBPro M3, in Pi, Hermes, Continue. Can't compare the results to what Claude or Codex are offering.

You need at least something that's far away from consumer hardware, like those 7k'ish GForce machines with 96GB VRAM to get an idea of a good competitive model.

But... please, proof me wrong! =)

limecherrysoda 20 minutes ago | |

Gemini uses MoE and context caching, which is a similar approach.

You are not really accessing the biggest frontier model every time, and you're not really doing an end-to-end LLM request on each prompt.

I would go so far to say frontier models have peaked and improvements from here come from clever (or very elaborate) harnessing. "LLLMHs" - Large Large Language Model Harnessing !

TheRealPomax 26 minutes ago | |

This is an odd comment: the project is right there for you to use, so just try it and see if it holds up to the claims? Then you can comment about the fact that it either doesn't hold up, with numbers to back that up, or on how awesome it is because it works =)

tpurves 1 hour ago |

Okay this tidbit is interesting to me "5–6 tok/s M2 -> 31–35 tok/s on an M5 Pro". So where will be in just another gen or two?

my impression right now is that M5 gen is on the cusp of practicality for local inference.

If techniques like OPs here, start to make the RAM situation more amenable, by the time we get to M6 or M7 (or AMD's equiv next gen APUs on TSMC N2 nodes), local AI could be ready to go much more mainstream.

hatthew 1 hour ago | |

My assumption is that the difference is 90% from more memory. I'm making several assumptions because nothing here looks groundbreaking so I don't care to dig deeper, but the model + KV cache definitely cannot fit in memory on the 8GB machine, but probably can on the 24GB machine—or can at least get close. Assuming that this benchmark makes use of that, skipping SSD streaming will speed things up massively (I would have guessed much higher than the reported 6x speedup).

Aurornis 1 hour ago | |

I have an M5 128GB. Being on the cusp of practical is a good description. It will run, but prefill and token gen are still slow relative to my consumer GPU box.

It also gets very hot. If you’ve never heard the fans on Apple Silicon really spin up, it could surprise you. Makes the full GPU setup feel quiet by comparison.

I think after the hardware market calms down the ticket is going to be a light laptop with a second dedicated inference server on the network.

anthonypasq 33 minutes ago | | |

i wonder if Apple will eventually ship proprietary models with burned into the silicon for all local workloads

https://eu.36kr.com/en/p/3904844399445638

trollbridge 1 hour ago | |

The speed of this perfectly correlates with the memory bandwidth of an M2 vs M5 Pro.

luciana1u 1 hour ago |

26B in 2GB is the engineering equivalent of fitting your entire apartment into a storage unit and still having room to pace

gitpusher42 29 seconds ago | |

Thank you! Thankfully this is purely software engineering problem. And as usual there is no free lunch. You trade speed for lower memory usage

docheinestages 1 hour ago |

Is there a pipeline or approach to do this to any model? I'm particularly interested in Qwen 3.6 27B as it's the best for its size at the moment.

tracker1 1 hour ago |

This is actually very similar to some ideas I've been having for a while... that having a smaller entry model that knows enough about "expert" models that themselves are smaller to hand work over to could be better/faster/lighter in terms of working through real problems vs the megalith ones we currently use. Highly distilled experts and coordination with a fallback mode to a larger model option.

minraws 1 hour ago |

I have been working on doing the same for ling-3.0 seems very usable on my 5070 Ti now since it's only 5.1B active, you can even get pretty greedy and keep around 6% of each expert in memory and load the prompt and make the changes.

cagz 1 hour ago |

Is the 1/10+ reduction in memory usage applicable to larger models, i.e. would be possible to run a 200Gb model, by using 20Gb of memory?

gitpusher42 6 minutes ago | |

Size reduction is mostly based on Experts size. And it is limited by SSD speed. Check for Colibri and Flash-Moe, they are doing similar things with bigger models, but tok/s is not high

hsienchuc 2 hours ago |

I've run local video generation models on an 8GB graphics card and know firsthand that nothing runs smoothly when memory is insufficient. So seeing 14GB of weights crammed into 2GB of RAM is impressive.

If running continuously for over an hour (like an overnight batch task), will a fanless MacBook Air overheat and throttle? Can the SSD handle the continuous weight reads and sustained output speeds?

Great work, congratulations on the release!

m00x 2 hours ago | |

This is where MoEs shine though. You don't need all experts in memory at once. Diffusion inference doesn't have sparse inference.

rcarmo 1 hour ago |

Would be awesome if it ran Qwen (the MoE probably won't squeeze that low, but...). This because I have hardly been able to use Gemma for any sort of useful coding.

gitpusher42 1 hour ago | |

You’re right, Gemma isn’t the best model for coding (afaik more "everyday tasks" related). My first idea was to use Qwen, but its architecture was much more complex to implement in this stack. I chose Gemma so I wouldn’t spend all my time debugging custom kernels and could actually move the project forward with simpler approach

jwr 1 hour ago | | |

In defense of this model, Gemma is actually a very good general-purpose model that can work with multiple languages. I use it for spam classification and for processing dictation, which means that I hold the entire model in memory all of the time, which is somewhat problematic (64GB RAM total, but heavy usage by docker, databases, etc)

dofm 1 hour ago | |

Gemma 4's tool calling was recently fixed; that was the main issue with agentic use in my experience.

Otherwise IMO it codes about as well as the Qwen MoE for PHP and SQL. It's a fully impressive model (though it is not as mindbendingly impressive as the 12B, which is outrageously good for its footprint)

mxmlnkn 2 hours ago |

This sounds really cool. My intuition was that the selected experts might change heavily for each token, resulting in slow SSD loads for each token. This seems to be wrong. Did you create some statistics on how often the experts need to be changed? What is the longest token run without any expert change? What does such a token run look like? In which cases do experts change frequently?

gitpusher42 2 hours ago | |

The full route changes almost every token. The cache works through partial reuse, about 40% of experts repeat on the next token and 57% within two tokens, cutting I/O from 166 to 88 ms/token on M2 Mac.

The longest exact repeat we found was only two tokens. Coding tasks may have higher reuse if code related experts are selected repeatedly

memre12 1 hour ago |

Impressive if the numbers hold. Would love a table with per-token bytes read, measured SSD bandwidth, and cache hit rate—those four numbers would make the tok/s claims land better.

maxignol 1 hour ago |

I'm really excited about what's been happening couple last weeks for local inference. I feel like it all started after colibri [1] was released. Great work !

Anyone got recommendation about what local model to use for what purpose ? I feel like (as they were saying in moonshot blog post [2]) each llm can be an expert in its own categories and with several small local we might get good coverage for decent usage, granted each one is specialized enough.

[1] : https://github.com/JustVugg/colibri [2] : https://fireworks.ai/blog/kimik3-fable

gitpusher42 1 hour ago | |

I think I first saw Flash-MoE (https://github.com/danveloper/flash-moe) in April. Huge respect to them, it was a big inspiration for this project!

huangsemao 1 hour ago |

What part of the optimization process gave you the biggest speed gain?

gitpusher42 9 minutes ago | |

Switching from mmap to parallel pread. From 0.5tok/sec to almost 4tok/sec. Running GPU work while reading missed experts also helped a lot, 4.4 -> 4.7

yakupov_bulat 2 hours ago |

Wow, amazing!

What if there is enough RAM to fully load the model? I assume in that case I shouldn’t use your engine.

gitpusher42 2 hours ago | |

It depends on the use case.

I measured this exact model with a 4k context on the mlx engine. It runs at 75 tok/s on my M5 Mac Pro and using 14 GB of RAM. For my engine the same model uses 2 GB of RAM and produces 31–35 tok/s.

The project is still experimental so performance may vary as it continues to improve. If you want to save around 12 GB of RAM for other tasks and you are ok with 35 tok/s (afaik it is roughly comparable to ChatGPT’s speed for basic responses) my engine may be a good fit.

If you need maximum speed and flexibility just use MLX

0gs 2 hours ago | |

you could use mine ... github.com/0gsd/enough (it has other stuff too)

h2aichat 2 hours ago |

Hope you can do it for Windows users also (and small graphics cards). Thanks

gitpusher42 2 hours ago | |

Uh, I’m afraid it is Apple only. It is written using Apple’s GPU language, Metal, and heavily relies on the Apples’s shared memory architecture

Windows PCs would require a completely different approach

greggh 2 hours ago |

It does exactly what it says it does. On my Mac mini M4 with 16GB of ram it is running at just over 5 tok/s. That jump from M4 to M5 is crazy.

gitpusher42 2 hours ago | |

What exact specs do you have? It might be because it's the 256 GB version. afaik, those versions have much slower memory bandwidth than the 512 GB models

My friend tried it on an M4 MacBook Pro and got 25–27 tok/s

giobox 1 hour ago | | |

This is correct, the 256gb is substantially slower as uses fewer physical memory chips - less ability to read/write in parallel. The 512gb or larger models have substantially higher read/write rates, and typically performs 50-100 percent faster in benchmarks than the 256.

Was a primary factor in me buying a 512gb M4 Mac Mini, even though I planned to use large external SSD - I wanted faster spec boot volume.

greggh 57 minutes ago | | |

Yeah, its the 256gb version.

Pragmata 1 hour ago |

Would it be possible to use this for kimi k3?

what are the limitations

cyanregiment 1 hour ago |

You’re a mad man - thank you!

Do I understand correctly that Ollama doesnt do that, and that’s why responses hang forever on a M3 running the same model through Ollama?

trollbridge 1 hour ago | |

Please don’t use Ollama.

https://sleepingrobots.com/dreams/stop-using-ollama/

reddguard 29 minutes ago | | |

Doesn't Ollama use llama.cpp so their point stands even if they used it directly?

WithinReason 2 hours ago |

Nice job implementing expert caching!

gitpusher42 2 hours ago | |

Thank you! Under good conditions it achieves approx a 67% cache hit rate with 16 expert slots

WithinReason 49 minutes ago | | |

That's great, now I wonder how cache hit rate scales for larger models. Do you have any plans trying Qwen 3.6 or larger?

touwer 2 hours ago |

Cool! Is there any info on this doing harm to the SSD? (Or other parts?)

wtallis 2 hours ago | |

Reads don't wear out flash memory to any meaningful extent.

gitpusher42 2 hours ago | |

AFAIK it should not because it is only reading

weras 1 hour ago |

Rushing to try it!

gitpusher42 47 minutes ago | |

Thank you! Share your tok/s results later

sscarduzio 2 hours ago |

How does this compare to DwarfStar4?

fghorow 1 hour ago | |

I'm curious too!

One obvious thing is that the memory requirements for this are substantially smaller than DwarfStar-- which AFAIK can only start to be used at 64GB ram and upwards. Another obvious thing is that antirez is pretty obsessed with making sure that DwarfStar passes all of DeepSeek V4 Flash's generating tests (loosely). I suspect that is also true of DwarfStar's implementation of GLM5.2, but I don't use that.

liuliu 1 hour ago | |

DS4 is designed to do real-work. Gemma 4 is not going to cut it.

novoreorx 55 minutes ago |

It’s like how Super Mario Bro was managed to put into 40KB of ROM

gitpusher42 46 minutes ago | |

My friend just compared this project to running Cyberpunk on a very old machine at 16 FPS, huh

znpy 2 hours ago |

I wonder if i can run this on my MacBook Neo!

gitpusher42 2 hours ago | |

I haven't tried it but it should work! You can try it and share your results, it would be really appreciated

I tried it on my wife's M1 MacBook Air 512GB and it gets 4–5 tok/s

Also, it must be easy to adjust for iPhones and iPads in theory

trollbridge 1 hour ago | | |

iPhones and iPads have much slower flash.

trollbridge 1 hour ago | |

Yes, a Neo is roughly equivalent to an M1.