--- title: Teaching Automatic1111 to Speak Metal on an M1 | daily.dev description: A developer details a personal fork of Automatic1111 optimized for Apple Silicon (M1/M3 Pro), aiming to close the performance gap with Draw Things without... canonical: https://daily.dev/posts/teaching-automatic1111-to-speak-metal-on-an-m1-45rpgxe1o twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Teaching Automatic1111 to Speak Metal on an M1 | daily.dev og:description: A developer details a personal fork of Automatic1111 optimized for Apple Silicon (M1/M3 Pro), aiming to close the performance gap with Draw Things without... og:url: https://daily.dev/posts/teaching-automatic1111-to-speak-metal-on-an-m1-45rpgxe1o og:image: https://api.daily.dev/og/posts/45RPgxe1o.png og:image:alt: Teaching Automatic1111 to Speak Metal on an M1 og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Teaching Automatic1111 to Speak Metal on an M1 **[Hacker News](https://daily.dev/sources/hn)** · 13 min read · 0 upvotes · 0 comments ## Summary A developer details a personal fork of Automatic1111 optimized for Apple Silicon (M1/M3 Pro), aiming to close the performance gap with Draw Things without abandoning the WebUI, checkpoints, extensions, and workflow. The work includes a shape-selective Metal Flash Attention path, deferred Metal command-buffer submission (avoiding per-call commits), unified-memory-aware attention routing instead of fixed VRAM thresholds, streaming online softmax for the sub-quadratic fallback, removal of obsolete MPS workarounds gated by PyTorch version, and a fused GroupNorm+SiLU Metal kernel. Several promising ideas—packed QKV projections and moving residual blocks into MPSGraph—were implemented, benchmarked, and then deleted because full-generation timing showed them to be neutral or slightly slower despite good microbenchmarks. Results: the M3 Pro workload moved from roughly 8-10 seconds to 3-7 seconds, and a matched M1 Mac mini comparison showed 12.8s vs 8.7s (about 1.47x throughput), with NGMS treated separately since it reduces actual guidance work rather than engine overhead. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why did fusing GroupNorm and SiLU into one Metal kernel help Stable Diffusion 1.x inference on Apple Silicon? Because GroupNorm followed by SiLU appears repeatedly throughout the SD 1.x UNet as two separate PyTorch dispatches with an intermediate activation written out and read back. A single fused Metal kernel handles normalization and activation in one dispatch per batch/group pair using a 256-thread threadgroup, computing sum and squared sum in FP32 before writing the FP16 result, eliminating the extra dispatch and memory traffic. _Anyone tuning PyTorch MPS kernels can compare notes on fusion techniques like this via daily.dev._ ### Why does committing the Metal command buffer after every attention call hurt Stable Diffusion performance on Apple Silicon? Because Stable Diffusion calls attention repeatedly inside every UNet evaluation, and on a short five-step generation, repeatedly submitting tiny chunks of GPU work becomes a meaningful fraction of total runtime. Integrating the Metal Flash Attention kernel into PyTorch's existing MPS command-buffer stream instead of committing after each call removed that overhead and was one of the largest contributors to the overall speedup. _Developers chasing GPU overhead bugs like this can find similar deep dives on daily.dev._ ### Why did moving Stable Diffusion residual blocks into MPSGraph make full image generation slower despite faster microbenchmarks? Because although isolated microbenchmarks showed mid and low-resolution blocks improving by 1-5% (smallest blocks up to 9% faster), a full-generation test showed the MPSGraph version at a median of 9.6533 seconds versus 9.5556 seconds for the existing PyTorch/Metal path, about 1.02% slower overall. The graph overhead ate the dispatch savings because the largest spatial blocks, where most compute happens, did not improve enough. _Engineers weighing microbenchmark wins against real-world throughput can track similar case studies on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 34 comments across hackernews (as of 2026-08-12). **TL;DR:** Much of the discussion questions why anyone would still optimize Automatic1111 given that Comfy, Forge Neo, InvokeAI, and stable-diffusion.cpp have largely superseded it, though the author defends the effort as a fun deep technical exercise tied to a broader plugin/API ecosystem. **Sentiment:** 20% positive · 35% mixed · 45% skeptical **The case for** - Some acknowledge A1111-based forks can still be useful for batteries-included workflows like masking, inpainting, and quick upscaling. - The author's detailed engineering rationale (unified memory, plugin ecosystem, LoRA support) was seen as a legitimate reason to keep improving the stack rather than switching UIs. - Confirmed LoRA composition works fine with the speedups, addressing a specific technical question. **The pushback** - Several see SD 1.5 and Automatic1111 itself as outdated relative to newer tools like ComfyUI, Forge Neo, and Maestro. - One commenter objected to the post reading like AI-generated content, calling it disrespectful to readers. - Doubts raised about whether the effort is worthwhile when alternative UIs are already 'vastly superior' on Mac. **By community** - hackernews (mixed): Debate splits between nostalgia/technical appreciation for the optimization work and skepticism that Automatic1111 is still worth targeting given newer alternatives. **Hottest debate:** Whether continuing to optimize Automatic1111 makes sense at all when ComfyUI, Forge Neo, and InvokeAI have largely replaced it. **Open questions** - How well do A1111 and its variants actually run on Mac hardware compared to Windows? - Will the Metal optimizations extend beyond attention/UNet to other parts of the pipeline like inpainting and multi-model memory tuning? **Highlights** > A1111 also had its time. Comfy takes a couple hours to learn, and then it’s vastly superior. Like, if you are already on Mac there is no reason to also kick yourself in the face trying to go back to 1111. > — [SV\_BubbleTime on hackernews · 2 comments](https://news.ycombinator.com/item?id=49273850) > Totally and sdcpp and drawthings were inspiration for this work. It's not just about the UI, there's a whole stack of plugins, APIs etc. It would be a bigger shift, than just use other UI. Composition etc. Plus this was fun to learn where the attention and time spent is eating up. I plan to git into the UNet, and then do some Multi-Model Memory Attention tuning as well, for Refining and Inpaint Swaps for the 8Gb Macs. > — [dmikeyanderson on hackernews](https://news.ycombinator.com/item?id=49274397) > I love AI content. I hate content written by AI. It's not serious. It shows that the author doesn't care about showing what he's up to. He cares about making content to post on a blog. And that's disrespectful to the reader. > — [selectodude on hackernews · 1 comments](https://news.ycombinator.com/item?id=49274905) > Automatic1111 wasnt being updated, people moved to Forge Neo, ComfyUI and Maestro. > — [IronWolve on hackernews · 3 comments](https://news.ycombinator.com/item?id=49273753) > A1111 (or rather Forge Neo at this point) can still be pretty useful (for a Windows user) if somebody just want a batteries-included approach because it makes it trivial to move back and forth between masking, manual inpainting, tacking on a high‑res fix and/or upscale, and swapping things out on the fly quickly. Caveat: No idea how well A1111 and its variants function on Mac though. These days I mostly use ComfyUI because after building out a node‑based workflow, it’s easy to export as a JSON file with websocket outputs that I can integrate into my programs. https://github.com/Haoming02/sd-webui-forge-classic/tree/neo > — [vunderba on hackernews](https://news.ycombinator.com/item?id=49274935) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49272282) · 40 points · 34 comments ## Similar posts on daily.dev - [Zero-Copy GPU Inference from WebAssembly on Apple Silicon](https://daily.dev/posts/zero-copy-gpu-inference-from-webassembly-on-apple-silicon-oqawturhp) · Hacker News · 13 upvotes · 0 comments - [Announcing vllm-metal: Concurrent Serving on Apple Silicon](https://daily.dev/posts/announcing-vllm-metal-concurrent-serving-on-apple-silicon-qubj1vfph) · vLLM · 0 upvotes · 0 comments --- Tags: [#performance](https://daily.dev/tags/performance), [#pytorch](https://daily.dev/tags/pytorch), [#stable-diffusion](https://daily.dev/tags/stable-diffusion) [View this post on daily.dev](https://daily.dev/posts/teaching-automatic1111-to-speak-metal-on-an-m1-45rpgxe1o) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Teaching Automatic1111 to Speak Metal on an M1","url":"https://daily.dev/posts/teaching-automatic1111-to-speak-metal-on-an-m1-45rpgxe1o","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/teaching-automatic1111-to-speak-metal-on-an-m1-45rpgxe1o"},"datePublished":"2026-08-12T16:03:26.055Z","dateModified":"2026-08-12T16:52:53.168Z","description":"A developer details a personal fork of Automatic1111 optimized for Apple Silicon (M1/M3 Pro), aiming to close the performance gap with Draw Things without...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/38bd2011662ca64b8b23099871158b45?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/38bd2011662ca64b8b23099871158b45?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/teaching-automatic1111-to-speak-metal-on-an-m1-45rpgxe1o","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"performance,pytorch,stable-diffusion","timeRequired":"PT13M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Teaching Automatic1111 to Speak Metal on an M1"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/teaching-automatic1111-to-speak-metal-on-an-m1-45rpgxe1o#faq","mainEntity":[{"@type":"Question","name":"Why did fusing GroupNorm and SiLU into one Metal kernel help Stable Diffusion 1.x inference on Apple Silicon?","acceptedAnswer":{"@type":"Answer","text":"Because GroupNorm followed by SiLU appears repeatedly throughout the SD 1.x UNet as two separate PyTorch dispatches with an intermediate activation written out and read back. A single fused Metal kernel handles normalization and activation in one dispatch per batch/group pair using a 256-thread threadgroup, computing sum and squared sum in FP32 before writing the FP16 result, eliminating the extra dispatch and memory traffic. Anyone tuning PyTorch MPS kernels can compare notes on fusion techniques like this via daily.dev."}},{"@type":"Question","name":"Why does committing the Metal command buffer after every attention call hurt Stable Diffusion performance on Apple Silicon?","acceptedAnswer":{"@type":"Answer","text":"Because Stable Diffusion calls attention repeatedly inside every UNet evaluation, and on a short five-step generation, repeatedly submitting tiny chunks of GPU work becomes a meaningful fraction of total runtime. Integrating the Metal Flash Attention kernel into PyTorch's existing MPS command-buffer stream instead of committing after each call removed that overhead and was one of the largest contributors to the overall speedup. Developers chasing GPU overhead bugs like this can find similar deep dives on daily.dev."}},{"@type":"Question","name":"Why did moving Stable Diffusion residual blocks into MPSGraph make full image generation slower despite faster microbenchmarks?","acceptedAnswer":{"@type":"Answer","text":"Because although isolated microbenchmarks showed mid and low-resolution blocks improving by 1-5% (smallest blocks up to 9% faster), a full-generation test showed the MPSGraph version at a median of 9.6533 seconds versus 9.5556 seconds for the existing PyTorch/Metal path, about 1.02% slower overall. The graph overhead ate the dispatch savings because the largest spatial blocks, where most compute happens, did not improve enough. Engineers weighing microbenchmark wins against real-world throughput can track similar case studies on daily.dev."}}]} ```