대역폭 없는 용량은 죽은 무게야

"같은 버스 위의 풀에 더하는 모든 기가바이트는 버스가 덜 자주 들르는 기가바이트야. 더 큰 풀이 받아들이는 모델은 정확히 가장 느리게 디코드하는 모델이야."

나눗셈은 안 움직여

물리 트랙의 공식엔 위에 풀의 대역폭, 아래에 모델의 토큰당 바이트가 있고, 풀의 용량은 어디에도 없어. 코드 블록은 저장소의 파일들을 M3 Ultra의 819 GB/s 위 가상 풀 셋에 걸쳐 돌려. 512 GiB에선 여섯 중 다섯이 들어가고, 1 TiB에서도 같은 다섯, 2 TiB에선 여섯 전부. 그리고 모든 행에서 모든 상한이 같아. GLM-5.3은 초당 34토큰, Qwen3.8-Flash-Next는 228, 밀집 405B는 3. 상한의 무엇도 풀이 얼마나 큰지 모르니까. 더해진 용량이 받아들이는 건 초당 13토큰의 Kimi K3와 어떤 집도 기다리지 않을 밀집 405B야. 용량은 로드할 권리를 사고, 대역폭은 로드된 모든 것의 속도를 정하고, 버스 없이 자라는 풀은 자기 표의 느린 끝으로 자라.

이 집의 벤치마크

이 집의 독트린은 로컬 모델이 여기서 의미 있으려면 통과해야 할 시험의 이름을 대. 금고 전체를 읽고(M3 Ultra에서 기억 10만 토큰 넘게), 그 위에 저장소 하나를 로드하고, 실용적인 속도로 답하기. 두 번 대역폭 시험이야. 10만 토큰 컨텍스트의 프리필은 곡선 레슨의 벽이고, 그 길이의 3분의 1에서 27B로 90초. 그리고 뒤따르는 디코드는 벽이 세운 캐시를 실험실이 잰 기울기로 읽어. 어떤 용량도 어느 쪽도 줄이지 못해. 1 TB 풀은 금고와 리포지토리와 Kimi K3만 빼고 저장소의 모든 모델을 담고, 512 GB 풀보다 빨리 답하지 않아. 독트린의 표현: 차선을 더한다고 길이 뚫리지 않는다. 클라우드는 엣지에 없는 둘, 프롬프트 캐시와 배칭으로 같은 시험을 통과하고, 이 트랙 끝의 체크리스트는 그걸 실리콘이 아니라 소프트웨어 숙제로 나열해.

용량이 가질 가치가 있으려면

둘이고, 둘 다 이 트랙의 나머지야. 풀이 자라도 기가바이트당 대역폭이 유지되도록 하는 더 넓은 버스. 오늘 가족의 사다리는 M5 Max가 GB당 4.8 GB/s, M5 Ultra 2.4, M3 Ultra 1.6이고, 1 TB 풀이면 M5 Ultra 버스에서 1.2, M3 Ultra 버스에서 0.8이 돼. 배선 레슨이 패키지 가장자리로 값 매겨. 아니면 아예 풀 하나가 아닌 메모리. 오늘 크기의 빠른 계층과 그 뒤의 느린 계층, 뭐가 어디 살지 운영체제가 정하는. 두 계층 레슨이고, 라이벌이 랙에서 출하하고 애플이 폰에서 출하하는 모양이야. 둘 중 하나가 없으면 더 큰 풀의 정직한 읽기는 위의 표야. 더 많은 모델이 받아들여지고, 각각은 같은 버스가 허락하는 속도로, 그중 가장 빠른 건 이미 들어가던 것들. 이 집이 1테라바이트를 안 산 건 저장소에 버스가 줄 속도로 로드할 가치가 있는 게 없어서야. 더 빨리 돌리고 싶은 체크포인트는 이미 로드할 수 있어.

Code

capacity.py — 버스 하나 위의 풀 셋에 저장소의 파일들·python

#!/usr/bin/env python3
"""Capacity without bandwidth is dead weight. The store's files on three hypothetical pools
with the same 819 GB/s bus: what fits, and how fast it would decode -- the active-bytes
division from the big-models track, unchanged by the pool's size."""
BW = 819.0
files = [("GLM-5.3", 452, 24.0), ("GLM-5.3-Flash", 192, 10.8), ("DeepSeek-V4.1-Flash (quantized FP8 parts)", 470, 9.6),
         ("Kimi K3", 1680, 62.4), ("Qwen3.8-Flash-Next", 108, 3.6), ("a 405B dense at 4 bits", 243, 243.0)]
for pool_gib in (512, 1024, 2048):
    ws = pool_gib * 2**30 / 1e9 * 0.906
    fits = [f"{n} ({BW/a:.0f} tok/s)" for n, gb, a in files if gb + 16 <= ws]
    print(f"{pool_gib:5d} GiB / {BW:.0f} GB/s -> {len(fits)} of {len(files)} fit: " + "; ".join(fits))
print("\nthe ceilings never change with the pool; the dense 405B decodes at 3 tok/s on any of them, and the extra gigabytes only admit models this slow or slower.")
print("the household's own benchmark for a local model: read the whole vault, load a repository, answer at a practical speed -- a bandwidth test that no capacity passes for it.")

Exercise

네 버스와 작업 집합으로 capacity.py를 돌려. 그다음 이 집의 벤치마크를 네 것으로 써. 네가 실제로 들고 다니는 컨텍스트, 실제로 로드하는 저장소. 그리고 쓸 모델로 네 맥에서 그 컨텍스트의 프리필 벽과 디코드를 계산해. 어떤 용량이든 두 숫자 중 하나라도 바꿀지 카드에 올려.

Hint

프리필 벽 ≈ 컨텍스트 토큰 ÷ 네 프리필 속도. 컨텍스트에서의 디코드는 곡선 레슨의 기울기에서. 어느 쪽에도 풀의 크기는 없어. 더 빠른 버스는 도움이 되고 더 많은 메모리는 안 된다는 게 답이면 이 트랙의 첫 두 레슨을 이해한 거야.