셋째 계층으로서의 플래시

"초당 3기가바이트는 토큰엔 300배 너무 느리고 프롬프트엔 충분히 빨라. 애플은 정확히 그 문장 둘레에 모델을 짓고 폰에 넣었어."

맥이 이미 가진 셋째 계층

모든 맥엔 풀 아래의 계층이 있어. SSD, 메모리 트랙이 Air에서 캐시 없이 읽어 2.87 GB/s로 쟀고, Studio 것은 더 빠르고 여기선 안 쟀어. 여정 트랙의 첫 레슨은 차가운 모델이 그걸 건너는 걸 지켜봤어. 파일의 페이지가 그 속도로 플래시에서 폴트로 들어와, 16기가바이트에 6초, 한 번. 이 레슨이 묻는 건 플래시가 로딩 경로 이상일 수 있느냐야. 가중치가 거기 살면서 생성 중에 읽힐 수 있는지. 코드 블록이 퀘스트의 모델 셋에 산수를 해. 모델의 활성 전문가를 토큰마다 플래시에서 흘려보내면 SSD의 대역폭을 활성 바이트로 나눠. 작은 혼합 모델에 초당 1토큰쯤, GLM-5.3에 그 10분의 1. 프롬프트의 전문가를 한 번 로드하고 풀에서 디코드하면 앞에 1, 2초 들고 그 뒤론 풀의 상한으로 돌아. 토큰당으로 플래시는 Studio의 819 GB/s 버스보다 285배쯤 너무 느려(Air 자기 풀의 실측 97 GB/s보다는 34배, 메모리 트랙의 절벽). 프롬프트당으로는 잠깐 멈춤이야.

애플 자신의 답

애플의 연구 그룹은 2023년에 토큰당 판을 발표했어. "LLM in a flash", 읽기를 창으로 자르고 묶어 "models up to twice the size of the available DRAM"을 돌리며, 순진한 로딩에 대해 CPU에서 4–5배, GPU에서 20–25배 빠르게. 그다음 프롬프트당 판을 제품으로 출하했어. 3세대 애플 파운데이션 모델의 200억 파라미터 모델 AFM 3 Core Advanced, "activating just 1 to 4 billion parameters at a time": "the full model is stored in flash memory (NAND). Because NAND-to-DRAM bandwidth is too slow to swap weights token by token, as standard MoE models require, AFM 3 Core Advanced makes routing decisions per prompt. A lightweight, dense block selects a fixed set of experts during initial processing, periodically reselecting them during generation." 코드 블록의 둘째 칸을 모델의 아키텍처에 써 넣은 거야. 프롬프트마다 전문가를 한 번 고르고, DRAM으로 페이징하고, DRAM에서 디코드하고, 가끔 다시 고르기. 계층의 물리가 모델의 설계를 골랐고, 쥐 트랙의 이야기를 반대 방향으로 한 거야. 이번엔 워크로드가 배치에 맞게 빚어졌어.

이 집은 그 계층으로 뭘 하나

이 집의 MLX 서버는 플래시 계층을 반대 방향으로 써. 그 냉장 캐시는 프롬프트의 계산된 키-값 블록을 SSD에 저장하고 맞는 접두사가 돌아오면 복원해. "even after a server restart". 곡선 레슨의 프리필 벽을 한 번 치르고 연산 단계의 속도로 다시 계산하는 대신 3 GB/s로 다시 로드하는 것. 함대 트랙은 그 캐시가 0바이트인 걸 찾았어. 허브의 부하는 절대 디코드하지 않으니까. 긴 공유 접두사를 가진 채팅 허브에선 두 번째 질문을 첫 번째보다 싸게 만드는 그것일 거야. 그러니 2026년 맥에서 셋째 계층의 정직한 쓰임은 둘이야. 애플이 폰에서 출하하듯 프롬프트당 가중치, 이 집의 서버가 할 수 있듯 접두사당 캐시 블록. 그리고 부정직한 쓰임 하나, 토큰당 가중치, 산수가 300배 차이로 배제하는 것. 체크리스트 항목은 첫 쓰임을 맥의 런타임에 가져오는 거야. 오늘은 둘째만 있으니까.

Code

flash_tier.py — 토큰당 또는 프롬프트당: 양쪽으로 나눈 SSD의 대역폭·python

#!/usr/bin/env python3
"""Flash as the third tier. The Air's measured SSD read, and what streaming weights from
flash costs per token versus per prompt -- the arithmetic behind Apple's own choice to
route a NAND-resident model per prompt rather than per token."""
SSD = 2.87          # GB/s, air, F_NOCACHE 20 GiB file (T5); a Studio's SSD is faster and unmeasured here
POOL = 819.0
for name, active_gb, total_gb in [("AFM 3 Core Advanced (20B, 1-4B active)", 4 * 0.6, 20 * 0.6),
                                  ("Qwen3.8-Flash-Next (6B active)", 3.6, 108),
                                  ("GLM-5.3 (40B active)", 24.0, 452)]:
    per_token_from_flash = SSD / active_gb
    per_prompt_load = active_gb / SSD
    print(f"{name:42} experts from flash per token: {per_token_from_flash:5.1f} tok/s | load one prompt's experts once: {per_prompt_load:5.2f} s, then decode at {POOL/active_gb:4.0f} tok/s from the pool")
print("\nper token, flash is ~285x slower than a Studio's 819 GB/s bus (34x the Air's own 97); per prompt, it is a second or two -- which is why Apple's NAND-resident model 'makes routing decisions per prompt'.")
print("the household's MLX server uses the same tier the other way: KV blocks of a repeated prefix restored from SSD instead of recomputed -- zero bytes used so far, because its load never decodes.")

Exercise

메모리 트랙의 cliff.py로 네 SSD의 캐시 없는 읽기 속도를 재고, 그걸로 flash_tier.py를 돌려. 돌리고 싶은 가장 큰 혼합 모델의 토큰당과 프롬프트당 수치를 카드에 쓰고, 계층의 정직한 쓰임 둘(프롬프트당 가중치, 접두사당 캐시) 중 네 런타임이 오늘 할 수 있는 걸 써.

Hint

2026년 맥의 대부분 런타임은 가중치론 어느 것도 못 하고 캐시론 하나를 해. 프롬프트당 멈춤이 2초 아래고 활성 바이트가 풀에 들어가면, 런타임이 라우팅하는 날 그 모델은 플래시에서 쓸 만할 거야. 그게 체크리스트의 요점이야.