09. 사양표와 시스템 구성도 읽기
이 장의 핵심 연결: 01~08장에서 기른 모든 태도(조건 명시·주장 유형·병목·메모리·통신·측정 계약)를 하나의 실천으로 종합합니다. 이 안내서의 정체성인 "증거를 등급으로 읽기"가 여기서 완성됩니다.
다음 질문: 공개된 사양표·구성도에서 무엇이 peak이고 무엇이 measured인가? 어떤 결론이 지지되고, 어떤 결론이 지지되지 않는가?
목표:
- 사양표의 수치를 peak·measured·calculated·inferred로 분류한다.
- 서로 다른 조건의 수치로 순위를 만들지 않는 습관을 굳힌다.
- 구성도에서 지지되지 않는 결론을 스스로 표시한다.
먼저: 사양표는 "사실의 목록"이 아니다
사양표를 보면 숫자들이 나란히 있어 마치 "객관적 사실"처럼 보입니다. 하지만 그 숫자들은 성격이 제각각입니다. 어떤 건 이론적 최댓값(peak), 어떤 건 특정 조건의 실측(measured), 어떤 건 식으로 계산한 값(calculated), 어떤 건 자료를 연결한 해석(inferred)입니다.
이것들을 같은 표에 나란히 놓고 순위를 매기는 것이 이 분야의 가장 흔한 오류입니다. 이 장은 그 오류를 막는 훈련입니다.
두 축을 다시: 출처 등급 × 주장 유형
이 안내서는 처음부터 두 개의 서로 다른 축을 써 왔습니다. 여기서 정식으로 종합합니다.
출처 등급 (누가 말했나)
| 등급 | 뜻 | 주의 |
|---|---|---|
| PRIMARY | 원 논문·공식 표준·제품 사양·공식 문서/저장소 | owner의 보고가 곧 독립 검증은 아님 |
| REPRODUCTION | 조건·코드·결과를 공개한 독립 재현 | 조건이 다르면 "같은 결과 확인"이 아니라 새 실험 |
| SECONDARY | 해설·맥락 | 핵심 원리·성능·비용 수치의 단독 근거로 쓰지 않음 |
주장 유형 (어떻게 얻었나)
| 유형 | 뜻 |
|---|---|
| measured | 공개된 조건에서의 관측값 |
| vendor-reported | owner·vendor의 기능·사양 보고 |
| calculated | 공개 입력과 식을 남긴 산술 |
| inferred | 자료를 연결한 해석 |
📌 핵심: 두 축은 독립입니다. 공식 제품 페이지는 PRIMARY(출처)이면서 동시에 vendor-reported(유형)일 수 있습니다. "PRIMARY니까 믿어도 된다"가 아니라, "PRIMARY이고 vendor-reported이며 아마 peak 수치다 → 실측과 구분해서 읽자"가 올바른 독해입니다.
peak vs measured vs calculated vs inferred
특히 사양표에서 이 넷을 섞지 않는 것이 핵심입니다.
CODE
peak(이론 최댓값): "이상적 조건에서 도달 가능한 상한". 실제로는 거의 그 값이 안 나옴. 예: peak FLOPS, peak 대역폭. → 실측 상한이지 실측값이 아님. measured(실측): 특정 조건에서 실제로 관측한 값. 조건이 붙어야 의미 있음. calculated(계산): 공개 입력 + 식. 예: storage 하한 P×w/8 (02장). 재현 가능. inferred(추론): 여러 자료를 연결한 해석. 전제가 무너지면 결론도 무너짐.
⚠️ 가장 흔한 함정: peak 수치 두 개를 비교해 "A가 B보다 빠르다"고 결론짓기. peak은 도달하기 어려운 상한이고, 실제 성능은 워크로드·병목(05장)·메모리(06장)·통신(07장)이 정합니다. peak 순위 ≠ 실제 순위.
실습: 가상의 스펙 표 읽기
아래는 가상의(架空) 조건 명시 예시 표입니다. 실제 제품이 아니며 추천도 아닙니다. 원리 훈련용입니다.
가상 가속기 스펙 표 (예시)
| 항목 | 가속기 A (가상) | 가속기 B (가상) | 이 수치의 성격 |
|---|---|---|---|
| peak 연산 (BF16) | 300 TFLOP/s | 350 TFLOP/s | peak / vendor-reported |
| 메모리 용량 | 40 GB | 32 GB | vendor-reported (용량은 비교적 명확) |
| peak 메모리 대역폭 | 1,200 GB/s | 1,600 GB/s | peak / vendor-reported |
| 가중치 storage 하한(7B×BF16) | 14 GB | 14 GB | calculated (02장 식, 하드웨어 무관) |
| "실제 추론 throughput" | (표에 없음) | (표에 없음) | measured 필요 — 여기 없음 |
이 표에서 지지되는 결론 / 지지되지 않는 결론
CODE
✅ 지지되는 결론:
- "가속기 A는 B보다 메모리 용량이 크다(40 vs 32 GB)."
→ 용량은 비교적 명확한 vendor-reported 값이며 같은 성격끼리 비교.
- "7B×BF16 가중치 storage 하한은 두 경우 모두 14 GB다."
→ calculated. 하드웨어와 무관한 산술(02장).
🚫 지지되지 않는 결론:
- "B가 peak 연산·대역폭이 높으니 실제 추론이 더 빠르다."
→ peak은 실측이 아님. 실제 성능은 워크로드·병목(05)·구현에 달림.
measured 없이 실제 속도 순위를 매길 수 없음.
- "A는 40 GB이니 7B 모델(하한 14 GB)을 넉넉히 돌린다."
→ 하한 ≠ 런타임 전체(02·06장). 활성값·KV 캐시 자리와
워크로드(요청 길이·동시성)를 모르면 단정 불가.
- "표의 숫자가 클수록 좋은 가속기다."
→ 워크로드가 없으면 우열 비교 자체가 성립 안 함(04장).
시각적 직관: 사양표를 읽는 판단 흐름
flowchart TB
NUM[표의 수치 하나]:::req --> Q1{이 값은 peak인가<br/>measured인가<br/>calculated인가?}:::req
Q1 -->|peak| P[상한일 뿐 → 실측과 구분<br/>순위 근거로 쓰지 말 것]:::warn
Q1 -->|measured| M{조건이 명시됐나?<br/>워크로드·분모·집계}:::req
Q1 -->|calculated| C[식·입력 확인 → 재현 가능하면 신뢰]:::compute
M -->|명시됨| OK[같은 성격·같은 조건끼리만 비교]:::result
M -->|없음| NG[비교 불가 — 조건을 물어라]:::warn
P --> NG
classDef req fill:#fef9c3,stroke:#ca8a04,color:#713f12
classDef warn fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
classDef compute fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
classDef result fill:#dcfce7,stroke:#16a34a,color:#14532d
구성도(시스템 다이어그램) 읽기
구성도도 같은 태도로 읽습니다. 상자와 선이 있다고 "그렇게 동작한다"는 보장은 아닙니다.
- 무엇이 어느 통로로 연결됐나(07장): 노드 내 링크인지 노드 간 네트워크인지에 따라 통신 비용이 다릅니다.
- 표시된 대역폭이 peak인가: 링크 옆 숫자가 peak면 실제 달성치와 다릅니다.
- 그림에 없는 것: 대기·스케줄링(control path, 01장), 오버헤드, 실제 워크로드는 그림에 잘 안 나옵니다. 없는 것을 있다고 읽지 않기.
🔬 증거 읽기: 구성도는 대개 inferred/교육적 모델이거나 vendor-reported 구조도입니다. "이 구조라서 빠르다"는 결론은 measured 없이는 지지되지 않습니다.
⚠️ 흔한 오해 (종합)
- "사양표 숫자가 크면 좋다." — 성격(peak/measured/calculated)이 다르고, 워크로드 없이는 우열이 성립 안 합니다.
- "공식 자료(PRIMARY)면 그대로 믿어도 된다." — PRIMARY라도 vendor-reported·peak일 수 있습니다. owner 보고는 독립 검증이 아닙니다.
- "재현했다니까 같은 결과다." — 조건이 다르면 REPRODUCTION이 아니라 새 실험입니다.
- "peak 대역폭으로 실제 속도를 계산하면 된다." — peak은 상한이라 실제와 벌어집니다.
조건 명시
| 내용 | |
|---|---|
| 성립하는 조건 | "수치를 성격별로 분류하고, 같은 성격·같은 조건끼리만 비교한다"는 태도는 모든 사양표·구성도에 일반적으로 적용됩니다. |
| 성립하지 않는 결론 | 이 장의 가상 표로 실제 제품의 우열을 말할 수 없습니다. 가상 수치이며 예시일 뿐입니다. 실제 비교는 대상 제품의 사양을 확인일·출처와 함께 확인하고, measured를 조건과 함께 봐야 합니다. |
이 장에서 배운 것
- 사양표 수치는 성격이 제각각(peak·measured·calculated·inferred)이다. 섞어 순위 매기지 않는다.
- 출처 등급(누가)과 주장 유형(어떻게)은 독립 축. PRIMARY이면서 vendor-reported·peak일 수 있다.
- peak ≠ measured. peak 순위는 실제 순위가 아니다. 실제는 병목·메모리·통신·워크로드가 정한다.
- 구성도는 없는 것(대기·오버헤드·워크로드)을 있다고 읽지 않는다.
- 같은 성격·같은 조건끼리만 비교하고, 조건이 없으면 비교 불가로 남긴다.
🔎 이 장의 '지지하지 않는 결론'
- 이 장의 가상 표로 어떤 실제 가속기의 우열도 말할 수 없다. 예시일 뿐이다.
- peak 수치만으로 실제 성능·순위를 결론지을 수 없다. measured와 조건이 필요하다.
✍️ 확인 문제
- 위 가상 표에서 "가속기 B가 실제 추론에서 A보다 빠르다"가 지지되지 않는 이유를 두 가지 드세요(어떤 값이 peak인지, 무엇이 표에 없는지).
- 어떤 자료가 "공식 제품 페이지(PRIMARY)"라고 합니다. 그런데도 그 성능 수치를 곧바로 믿으면 안 되는 이유는? (출처 등급과 주장 유형의 관계로 설명)
- [peak/measured/calculated/inferred 종합] 다음 각각을 분류하세요: (a)
P×w/8로 얻은 14 GB, (b) "peak 대역폭 1,600 GB/s", (c) "concurrency 32에서 측정한 TTFT 중앙값 0.4초", (d) "그러므로 이 시스템이 대화형에 더 적합하다". 그리고 이 넷 중 서로 순위 비교가 가능한 것과 불가능한 것을 나눠 설명하세요.
다음: 부록 — storage/메모리 워크시트, 정밀도 비교표, 측정 계약 템플릿, "이름 우열로 줄 세우지 않기" 체크리스트, 사양표 읽기 체크리스트, 주제 고유 용어집, 기초 시스템·수학 용어 사전, 단위·접두어 참조표.