A pitch for local inference on Apple silicon leads with 512GB of unified memory and 200B-parameter models. Capacity decides what you can load. Memory bandwidth decides how fast it answers, and autoregressive decoding reads the weights once per token — so the ceiling is bandwidth divided by the bytes a model actually touches. Run that division and the post's two headline promises, huge models and always-on agents, turn out to pull against each other on the same machine.
Not a build — one division and one measurement, both cheap enough to do before buying anything. First the ceiling: tokens per second is bounded by memory bandwidth divided by the bytes read per token, and the bytes read is roughly the quantised size of the parameters that are actually active. Do it for three cases — a 30B dense model at 4-bit, a 200B dense model at 4-bit, and a mixture-of-experts model of similar total size where only a fraction activates — and notice that only the third stays interactive. Then measure instead of trusting the division: run one prompt on the machine you actually have, record tokens per second, then record it again with the context filled, because attention cost grows with context and an agent's context is never short. Finally price it with a denominator: cost per token is hardware divided by the tokens it generates over its life, which makes utilisation the whole argument rather than a detail. Hardware figures here come from a GenAI Works post seen 2026-08-28 — an $899 M6 Mac mini said to be 13.5× the M1 on LLM processing, an M5 Ultra Mac Studio with up to 512GB unified memory and 1.2 TB/s — and the same post closes by soliciting investment. Re-derive every number from published specifications before relying on any of it.
Why
The arithmetic is the whole card, and it is arithmetic anyone can redo. Autoregressive decoding is memory-bound rather than compute-bound: to produce one token the machine reads the active weights out of memory, so the rate is bounded above by bandwidth divided by those bytes. At 1.2 TB/s, a 200B dense model quantised to four bits is roughly 100GB per token read, which is on the order of a dozen tokens per second as a theoretical ceiling and less in practice. That is perfectly good for a job that runs while you sleep and genuinely unpleasant for an agent, because an agent emits many tokens per step and its latency compounds across steps. So the two promises in the post — models this large, and always-on assistants — describe two different machines' worth of work on one machine. The resolution is architectural: in a mixture-of-experts model total parameters set the capacity requirement while active parameters set the speed, which is why which 200B model matters far more than the number. And sub-2bit-local-llm is the other lever on the same fraction — fewer bits per weight is fewer bytes per token, so quantisation buys throughput exactly as directly as it buys room.
The economics claim is stated without its denominator. "Cloud: pay for every token. Local: buy the hardware once and run agents all day" is true only at high utilisation, because cost per token is hardware divided by the tokens actually generated over the machine's life. A desk that is idle nineteen hours a day has a terrible number no matter how cheap the box was. Which reframes the real question: it is not local versus cloud, it is whether you have a workload that generates tokens continuously. Agents are the first workload that does — they produce tokens without a human waiting for each one, which is precisely why they are the case that makes local inference pencil out and why the post is right to name them, even if it skips the reasoning. Privacy is the second reason and it is stronger, because it does not depend on utilisation at all: files, prompts and agent context never leaving the machine is a constraint some work simply has, and a constraint is not an optimisation you can be argued out of.
And the provenance belongs on the card, not in a footnote. The post ends with "Our round is open. Invest from $1,000 with up to 22% bonus shares before August 31." Every figure in it is offered by a party raising money on the strength of those figures — which does not make them false, but does make them promotional, and this catalogue's standing rule is to re-derive rather than repeat. Notice too what the post concedes and then walks past: Apple is not replacing NVIDIA in the data centre. The claim is about the desk. That is a genuinely different fight with different constraints — batch size one, latency instead of throughput, a fixed memory budget instead of an elastic one — and the honest version of the argument is that the desk was never the fight NVIDIA was optimising for.
How it works
The division that sets the ceiling
Tokens per second ≲ memory bandwidth ÷ bytes read per token. At 1.2 TB/s, with weights at 4-bit:
Model
Active bytes per token
Theoretical ceiling
Verdict
30B dense
~15 GB
~80 tok/s
comfortably interactive
200B dense
~100 GB
~12 tok/s
batch work only
200B total MoE, ~20B active
~10 GB
~120 tok/s
interactive — architecture, not size
These are ceilings, not measurements; real throughput lands well below them, and falls further as context grows.
Capacity and bandwidth fail differently
Decides
How it fails
Unified memory size
what fits at all
hard — it does not load
Memory bandwidth
how fast it answers
soft — it loads, and you wait
Spec sheets lead with the first because its failure is legible. The second is the one you live with.
Cost per token has a denominator
hardware ÷ tokens generated over its life. Three regimes:
Idle desk — a few thousand tokens a day: cloud wins on cost by a wide margin.
Agents looping — tokens produced without a human waiting: the denominator gets large and local wins.
Privacy-constrained work — the comparison does not apply, because one side is not permitted. A constraint is not an optimisation.
What the post concedes, and what it is really claiming
Conceded: not the data centre. The claim is the desk.
The desk is batch-size-one, latency-bound, fixed-memory — a different problem, not a smaller one.
The post closes by soliciting investment, so every figure above is promotional until re-derived from published specifications.
애플 실리콘 로컬 추론을 권하는 글은 512GB 통합 메모리와 200B 파라미터 모델로 시작합니다. 용량은 무엇을 올릴 수 있는지를 정합니다.얼마나 빨리 답하는지를 정하는 것은 메모리 대역폭이고, 자기회귀 디코딩은 토큰 하나마다 가중치를 한 번 읽습니다 — 그래서 상한은 대역폭 ÷ 토큰당 실제로 만지는 바이트입니다. 그 나눗셈을 해 보면, 글이 나란히 내건 두 약속 — 거대 모델과 상시 에이전트 — 이 같은 기계 위에서 서로 반대로 당긴다는 것이 드러납니다.
만드는 일이 아니라 나눗셈 하나와 측정 하나이고, 둘 다 무엇을 사기 전에 할 만큼 쌉니다. 먼저 상한 — 초당 토큰은 메모리 대역폭 ÷ 토큰당 읽는 바이트로 묶이고, 그 바이트는 대략 실제로 활성화되는 파라미터의 양자화 크기입니다. 세 경우에 대해 해 봅니다 — 30B 밀집 모델 4비트, 200B 밀집 모델 4비트, 그리고 총 크기는 비슷하되 일부만 활성화되는 MoE — 그러면 셋째만 인터랙티브하게 남는다는 것이 보입니다. 그다음 나눗셈을 믿지 말고 측정합니다 — 실제로 가진 기계에서 프롬프트 하나를 돌려 초당 토큰을 적고, 컨텍스트를 채운 뒤 다시 적습니다. 어텐션 비용은 컨텍스트에 따라 자라고, 에이전트의 컨텍스트는 결코 짧지 않기 때문입니다. 마지막으로 분모를 붙여 값을 매깁니다 — 토큰당 비용 = 하드웨어 ÷ 수명 동안 실제로 생성한 토큰. 그러면 가동률이 세부가 아니라 논증 전체가 됩니다. 하드웨어 수치는 2026-08-28 에 본 GenAI Works 게시물 기준입니다 — 899달러 M6 Mac mini(LLM 처리 M1 대비 13.5배 주장), 최대 512GB 통합 메모리·1.2 TB/s 의 M5 Ultra Mac Studio — 그리고 같은 글이 투자 권유로 끝납니다. 어느 숫자든 공개 사양에서 다시 유도한 뒤 쓰십시오.
왜
나눗셈이 카드의 전부이고, 누구나 다시 해 볼 수 있는 산수입니다. 자기회귀 디코딩은 연산이 아니라 메모리에 묶입니다 — 토큰 하나를 만들려면 활성 가중치를 메모리에서 읽어야 하므로, 속도의 상한은 대역폭 ÷ 그 바이트입니다. 1.2 TB/s 에서 4비트로 양자화한 200B 밀집 모델은 토큰당 대략 100GB 를 읽는 셈이고, 이는 이론 상한으로 초당 10여 토큰, 실제로는 그보다 낮습니다. 자는 동안 도는 작업에는 충분하고, 에이전트에게는 정말로 괴로운 수치입니다 — 에이전트는 한 스텝에 많은 토큰을 뱉고, 지연이 스텝마다 누적되기 때문입니다. 그래서 글의 두 약속 — 이만큼 큰 모델, 그리고 상시 어시스턴트 — 은 기계 두 대 몫의 일을 한 대 위에 올려놓은 것입니다. 해법은 구조입니다 — MoE 에서는 총 파라미터가 용량 요구를, 활성 파라미터가 속도를 정합니다. 그래서 숫자보다 "어떤" 200B 인지가 훨씬 중요합니다. 그리고 sub-2bit-local-llm 은 같은 분수에 걸린 다른 지렛대입니다 — 가중치당 비트가 적으면 토큰당 바이트가 적으므로, 양자화는 자리만큼이나 직접적으로 속도를 삽니다.
경제성 주장은 분모 없이 진술됐습니다."클라우드는 토큰마다 지불, 로컬은 한 번 사고 종일 돌린다" 는 가동률이 높을 때만 참입니다. 토큰당 비용 = 하드웨어 ÷ 수명 동안 실제 생성한 토큰이니까요. 하루 열아홉 시간 노는 책상은 상자가 아무리 쌌어도 숫자가 나쁩니다.그래서 진짜 질문이 바뀝니다 — 로컬이냐 클라우드냐가 아니라, 토큰을 끊임없이 생성하는 작업을 가지고 있느냐입니다.에이전트가 그런 최초의 작업입니다 — 사람이 토큰 하나하나를 기다리지 않고도 토큰이 나옵니다. 로컬 추론의 셈이 맞아떨어지는 경우가 정확히 그것이고, 글이 에이전트를 지목한 것은 이유를 생략했을 뿐 옳습니다.두 번째 이유는 프라이버시이고 더 강합니다 — 가동률에 전혀 의존하지 않기 때문입니다. 파일·프롬프트·에이전트 컨텍스트가 기계를 떠나지 않는 것은 어떤 일이 그냥 갖고 있는 제약이고, 제약은 설득으로 물릴 수 있는 최적화가 아닙니다.
그리고 출처는 각주가 아니라 카드 본문에 있어야 합니다. 글은 이렇게 끝납니다 — "우리 라운드가 열려 있습니다. 8월 31일 전까지 1,000달러부터, 최대 22% 보너스 주식."모든 수치가 그 수치로 돈을 모으는 쪽에서 제시된 것입니다. 틀렸다는 뜻이 아니라 홍보물이라는 뜻이고, 이 목록의 상시 규칙은 반복하지 말고 다시 유도하라입니다. 글이 인정하고 지나가는 부분도 보십시오 — 애플이 데이터센터에서 NVIDIA 를 대체하는 것은 아니다. 주장은 책상에 대한 것입니다. 그것은 제약이 다른 진짜로 다른 싸움이고 — 배치 크기 1, 처리량이 아니라 지연, 탄력적이 아니라 고정된 메모리 예산 — 정직한 버전의 주장은 책상이 애초에 NVIDIA 가 최적화하던 싸움이 아니었다는 것입니다.
동작 방식
상한을 정하는 나눗셈
초당 토큰 ≲ 메모리 대역폭 ÷ 토큰당 읽는 바이트.1.2 TB/s, 가중치 4비트 기준:
모델
토큰당 활성 바이트
이론 상한
판정
30B 밀집
약 15 GB
약 80 tok/s
여유 있게 인터랙티브
200B 밀집
약 100 GB
약 12 tok/s
배치 작업 전용
총 200B MoE, 활성 약 20B
약 10 GB
약 120 tok/s
인터랙티브 — 크기가 아니라 구조
이것은 상한이지 측정값이 아닙니다. 실제 처리량은 한참 아래이고, 컨텍스트가 자랄수록 더 떨어집니다.
용량과 대역폭은 다르게 고장난다
정하는 것
고장나는 방식
통합 메모리 크기
애초에 올라가는가
단단하게 — 안 올라감
메모리 대역폭
얼마나 빨리 답하는가
무르게 — 올라가고, 기다림
사양표가 앞의 것을 앞세우는 이유는 그 고장이 눈에 보이기 때문입니다. 같이 살아야 하는 것은 뒤의 것입니다.
토큰당 비용에는 분모가 있다
하드웨어 ÷ 수명 동안 생성한 토큰. 세 국면:
노는 책상 — 하루 몇 천 토큰: 클라우드가 큰 차이로 이깁니다.
에이전트가 도는 경우 — 사람이 기다리지 않고 토큰이 나옴: 분모가 커지고 로컬이 이깁니다.
프라이버시 제약 작업 — 비교 자체가 성립하지 않습니다. 한쪽이 허용되지 않기 때문입니다. 제약은 최적화가 아닙니다.
글이 인정한 것, 그리고 실제 주장
인정: 데이터센터가 아니다. 주장은 책상입니다.
책상은 배치 크기 1, 지연에 묶이고, 메모리가 고정 — 더 작은 문제가 아니라 다른 문제입니다.
글은 투자 권유로 끝납니다. 위의 모든 수치는 공개 사양에서 다시 유도하기 전까지 홍보물입니다.