Deoks

PUE·WUE 계산하기: Python CSV로 단위·기간·결측값 검증하기

2026-10-28T19:11:50.298+09:00

PUE는 시설 전체 에너지를 IT 장비 에너지로 나누고, WUE는 정해진 범위의 물 사용량을 IT 전력량으로 나눕니다. CSV를 계산할 때는 단위와 측정 기간부터 맞춰야 합니다. 월별 PUE·WUE를 단순평균하거나, 빈 물 사용량을 0으로 채우면 계산이 끝나도 의미가 달라질 수 있습니다. 이번에는 그런 입력을 확인하는 작은 Python 계산기를 만듭니다.

숫자가 이상하면, 분모부터 확인하세요

PUE가 1보다 작게 나오면 시설 총소비량 대신 순구매량·GPU 보드 사용량 등을 넣었는지 먼저 확인하세요. 원자료를 보존한 채 단위·기간·계량 범위를 대조합니다. 값을 1로 강제로 맞추거나 결측값을 0으로 바꾸지 않습니다.

기준일: 2026년 10월 28일. Windows·Python 3.14.3에서 표준 라이브러리만 사용해 행동 검사 24개와 아래 CSV의 명령행 실행을 검증했습니다. 예제는 모두 자체 제작한 가상 월별 집계입니다. 실제 데이터센터 계량·냉각 장비·GPU·LLM 실험은 하지 않았습니다.

목차 · 계산 전에 구분할 용어

시설 전체 에너지: IT 장비와 냉각·전원 손실 등 정해진 시설 경계의 합계입니다.
kW·kWh: kW는 전력, kWh는 기간에 걸쳐 사용한 전력량입니다. 같은 숫자가 아닙니다.
측정 범위: 어느 시설·계량기·물 용도를 포함했는지 정한 경계입니다.
가중 합계: 각 월의 분자·분모를 각각 더한 뒤 나누는 방식입니다.
결측값: 관측하지 못한 값입니다. 실제 0과 구분합니다.

1. 무엇을 나눌지 먼저 고정합니다

NREL·DOE 설계 가이드의 8장은 연간 시설 전체 에너지와 IT 장비 에너지로 PUE를 정의합니다. 냉각 전력량을 IT 전력량으로 나눈 값에 PUE라는 이름을 붙이면 안 됩니다. 시설 전체 에너지에는 IT 에너지도 포함되기 때문입니다. 또한 PUE는 지원 인프라의 효율 지표이며, 같은 전력량으로 유용한 답을 얼마나 만들었는지는 별도 문제입니다.

Microsoft의 WUE 설명은 냉각·가습에 쓰인 연간 물의 리터 수를 연간 IT 장비 전력량으로 나눕니다. 비교 자료가 취수량인지 소비량인지, 냉각만 포함하는지 다른 용도도 포함하는지 확인해야 합니다. 아래 프로그램은 그 정의를 자동으로 판별하지 않고, 입력한 water_basis를 결과에 남깁니다.

PUE = 시설 전체 에너지 / IT 장비 에너지
WUE = 정의한 물 사용량[L] / IT 전력량[kWh]
기간 비율 = 기간의 분자 합계 / 같은 기간의 분모 합계

이 실습은 시설 에너지가 모두 전기로 계량된 경우를 가정합니다. 다른 에너지원이 있거나 순구매 전력만 측정했다면 정식 PUE 보고에 필요한 전체 에너지 경계와 다를 수 있습니다. 그런 자료를 그대로 넣고 인증된 PUE라고 부르지 않습니다.

GPU 모니터링 값만 확보했다면 GPU 사용률·요청 성과·에너지 범위를 나눠 읽는 글을 먼저 확인하세요. GPU 보드 전력량은 시설 전체 전력량을 대신하지 않습니다.

2. kW를 kWh 칸에 넣지 않습니다

입력 단위	이 계산기의 처리
kWh	전력량 그대로 사용
MWh	1,000을 곱해 kWh로 통일
L	물 부피 그대로 사용
m3	1,000을 곱해 L로 통일
kW·MW	전력량이 아니므로 거부

kW에서 kWh를 구하려면 해당 구간의 시간과 전력 변화가 필요합니다. 한 시점의 100kW를 월간 100kWh로 옮기지 마세요. 이 계산기는 순간 전력을 적분하거나 누적 계량기 지침의 차이를 구하는 도구가 아닙니다. 먼저 신뢰할 수 있는 월간 전력량을 준비해야 합니다.

자체 계산 순서

① 원자료와 계량 범위 보존
↓ ② 같은 시설·같은 월·같은 물 기준 확인
↓ ③ kWh와 L로 변환
↓ ④ 분자 합계 ÷ IT 전력량 합계
↓ ⑤ 기간·미확인 항목을 결과와 함께 보관

직접 만든 텍스트 도식입니다. 숫자가 맞는지 확인하는 절차이며, 계량기 정확도나 실제 경계를 자동으로 검증한다는 뜻은 아닙니다.

3. 가상 월별 CSV를 준비합니다

아래를 example.csv로 저장하세요. 모든 행은 해당 월 전체 기간의 확정 집계라는 가정입니다. UTF-8 또는 UTF-8 BOM을 지원하며 구분자는 쉼표입니다. 필드 순서까지 아래 헤더와 같아야 합니다. 숫자에는 천 단위 쉼표를 넣지 않습니다.

month,scope_id,facility,facility_unit,it,it_unit,water,water_unit,water_basis
2026-01,demo-a,200,MWh,100,MWh,10,m3,consumption
2026-02,demo-a,1080000,kWh,900000,kWh,180000,L,consumption

scope_id는 같은 시설·계량기 경계·물 용도를 묶는 식별자입니다. 예제의 demo-a는 실제 사업장 이름이 아닙니다. water_basis의 consumption은 소비량, withdrawal은 취수량이라는 입력 선언입니다. 두 기준이 섞이면 합산하지 않습니다. 실제 자료의 정의를 확인하지 않고 문자열만 통일하는 방법은 올바른 수정이 아닙니다.

1월은 시설 200MWh·IT 100MWh·물 10m³, 2월은 시설 1,080,000kWh·IT 900,000kWh·물 180,000L를 가정했습니다. 서로 다른 단위를 의도적으로 섞었지만, 계산 전에 같은 단위로 바꿉니다. 두 행은 실측이나 특정 업체의 성능이 아닙니다.

4. 계산기를 저장하고 실행합니다

다음 전체 코드를 같은 폴더의 pue_wue.py로 저장하세요. Python 표준 라이브러리만 사용합니다. csv.DictReader 문서에 맞춰 헤더로 열을 읽고 newline=''로 엽니다. CSV에서 읽은 문자열을 Decimal로 바꾸며, NaN·Infinity도 입력으로 허용하지 않습니다. 연산 정밀도는 28자리이므로 반복소수가 무한히 정확한 문자열로 출력되는 것은 아닙니다.

import csv
import json
import sys
from datetime import datetime
from decimal import Decimal, DecimalException, localcontext

FIELDS = ['month', 'scope_id', 'facility', 'facility_unit', 'it',
          'it_unit', 'water', 'water_unit', 'water_basis']
ENERGY = {'kWh': Decimal(1), 'MWh': Decimal(1000)}
WATER = {'L': Decimal(1), 'm3': Decimal(1000)}


def quantity(row, name, factors, allow_zero=False):
    text = row[name].strip()
    if not text:
        raise ValueError(f'{name}: missing value is not zero')
    value = Decimal(text)
    if not value.is_finite() or value < 0 or (value == 0 and not allow_zero):
        raise ValueError(f'{name}: invalid finite quantity')
    unit = row[name + '_unit'].strip()
    if unit not in factors:
        raise ValueError(f'{name}: unsupported unit {unit!r}')
    return value * factors[unit]


def calculate(file):
    with open(file, encoding='utf-8-sig', newline='') as handle:
        reader = csv.DictReader(handle, strict=True)
        if reader.fieldnames != FIELDS:
            raise ValueError('header must match the documented schema')
        rows = list(reader)
    if not rows:
        raise ValueError('CSV has no data rows')
    months, scopes, bases = set(), set(), set()
    facility = it = water = Decimal(0)
    with localcontext() as context:
        context.prec = 28
        for row in rows:
            if set(row) != set(FIELDS) or any(v is None for v in row.values()):
                raise ValueError('row has missing or extra cells')
            month = row['month'].strip()
            date = datetime.strptime(month, '%Y-%m')
            if date.strftime('%Y-%m') != month or month in months:
                raise ValueError('month must be unique YYYY-MM')
            months.add(month)
            scope = row['scope_id'].strip()
            basis = row['water_basis'].strip()
            if not scope or basis not in {'consumption', 'withdrawal'}:
                raise ValueError('scope_id and explicit water_basis are required')
            scopes.add(scope)
            bases.add(basis)
            f = quantity(row, 'facility', ENERGY)
            i = quantity(row, 'it', ENERGY)
            w = quantity(row, 'water', WATER, allow_zero=True)
            if f < i:
                raise ValueError('facility energy below IT: check meter boundaries')
            facility, it, water = facility + f, it + i, water + w
        if len(scopes) != 1 or len(bases) != 1:
            raise ValueError('do not combine different scopes or water bases')
        ordered = sorted(months)
        indices = [int(m[:4]) * 12 + int(m[5:]) for m in ordered]
        if any(b - a != 1 for a, b in zip(indices, indices[1:])):
            raise ValueError('months must be consecutive; missing months are not zero')
        annual = (len(ordered) == 12 and ordered[0].endswith('-01')
                  and ordered[-1] == ordered[0][:4] + '-12')
        def text(value):
            result = format(value, 'f')
            return result.rstrip('0').rstrip('.') if '.' in result else result
        return {'months': ordered, 'scope_id': next(iter(scopes)),
                'water_basis': next(iter(bases)), 'complete_calendar_year': annual,
                'facility_kwh': text(facility), 'it_kwh': text(it),
                'water_l': text(water), 'period_pue': text(facility / it),
                'period_water_l_per_it_kwh': text(water / it)}


if __name__ == '__main__':
    try:
        if len(sys.argv) != 2:
            raise ValueError('usage: python pue_wue.py input.csv')
        result = calculate(sys.argv[1])
        print(json.dumps(result, ensure_ascii=False, indent=2))
    except (ValueError, OSError, csv.Error, DecimalException) as error:
        print(f'ERROR: {error}', file=sys.stderr)
        sys.exit(2)

Windows PowerShell에서 두 파일이 있는 폴더로 이동한 뒤 실행합니다.

python pue_wue.py example.csv

검증 환경에서 종료 코드는 0이었고, 출력 JSON의 주요 값은 다음과 같았습니다.

"facility_kwh": "1280000"
"it_kwh": "1000000"
"water_l": "190000"
"period_pue": "1.28"
"period_water_l_per_it_kwh": "0.19"
"complete_calendar_year": false

시설 합계는 1,280,000kWh, IT 합계는 1,000,000kWh이므로 기간 PUE는 1.28입니다. 물 190,000L를 IT 1,000,000kWh로 나눈 기간 물 비율은 0.19L/kWh입니다. 시설 전력량을 물 비율의 분모로 넣지 않습니다.

5. 월별 비율을 단순평균하면 왜 달라질까요

1월 PUE는 2.00, 2월 PUE는 1.20입니다. 이를 단순평균하면 1.60이지만, 두 달의 IT 전력량이 다르므로 전체 기간의 1.28과 일치하지 않습니다. 전체 기간의 답은 월별 분자·분모를 각각 합산한 뒤 나눠 구합니다. 분모가 모두 같으면 단순평균도 일치할 수 있지만, 일반 규칙으로 가정하면 안 됩니다.

물 비율도 같은 문제입니다. 1월은 0.10L/kWh, 2월은 0.20L/kWh로 단순평균 0.15가 나오지만 기간 합산값은 0.19입니다. 이번 숫자는 1월·2월 두 달이므로 연간 실적이라고 부르지 않습니다. 출력 키에도 period라는 이름을 붙였습니다.

complete_calendar_year는 같은 해 1~12월의 연속된 라벨 12개가 있는지만 확인합니다. 각 행이 월 전체를 빠짐없이 측정했는지, 누락된 계량기가 없는지, 공식 보고 범위에 맞는지는 사람이 별도로 확인해야 합니다. true라고 나왔다고 공식 연간 PUE·WUE가 인증되는 것은 아닙니다.

6. 오류를 건너뛰기보다 원자료로 돌아갑니다

거부하는 입력	먼저 확인할 것
빈 값·NaN·Infinity	미관측 원인과 집계 완료 여부
IT 0·음수, 물 음수	사용량인지 계량기 지침인지
시설 에너지 < IT	순구매량·부분 시설·기간 불일치
같은 월 중복·중간 월 누락	행 중복과 월별 집계 범위
범위·물 기준 혼용	같은 집계로 볼 근거가 있는지

입력이 거부되면 결과 JSON을 출력하지 않고 ERROR: 메시지와 종료 코드 2를 남깁니다. 검증하려고 빈 물 값을 0으로 채워 통과시키지 마세요. 반대로 실제로 계량된 물 사용량이 0이면 입력 0을 허용합니다. 이는 해당 물 범위의 0일 뿐, 발전·제조·건설·생활용수까지 전부 0이라는 뜻이 아닙니다.

데이터센터 여러 곳을 한 파일로 합산하거나 서로 다른 계량 범위를 섞는 기능은 넣지 않았습니다. 실무에서는 범위별로 분리한 뒤, 합칠 수 있는 자료인지 먼저 판단하세요. 이 계산기는 센서 수집기·이상 탐지기·공식 환경 보고 검증기가 아닙니다.

Appendix · 실행한 것과 남는 한계

Windows·Python 3.14.3에서 CLI 정상 출력, 단위 혼용, 가중 합계, BOM, 실제 0, 월 순서, 연간 라벨과 잘못된 입력 거부를 포함한 행동 검사 24개를 통과했습니다. Python 3.14 문서는 확인 시점에 3.14.10으로 표시됐습니다. 문서의 패치 버전과 실행 버전을 구분하며 다른 OS·버전에서 실행했다고 주장하지 않습니다.

가상 CSV만 실행했고 실제 시설 에너지·물·AI 요청을 측정하지 않았습니다. 두 달의 계산 결과를 연간 수치로 확대하거나, 계산된 비율만으로 냉각 설비의 우열·절감액·물 부족·AI 서비스 품질을 판단할 수 없습니다. 공백과 단위의 모순을 줄이는 작은 확인 도구로 사용하세요.

NREL·DOE: Best Practices Guide for Energy-Efficient Data Center Design — 표지 개정일2024-07; URL 경로의2025-07과 구분
Microsoft: 에너지·물 효율 측정 정의 — 게시일미표기;2026-10-28확인
Python 3.14: csv.DictReader와 파일 열기 — 확인시문서3.14.10;실행3.14.3과패치버전구분
Python 3.14: Decimal과 유한값·연산 정밀도 — 확인시문서3.14.10;실행3.14.3

Can Lower PUE Hide Higher Water Use in an AI Data Center?

2026-10-28T06:40:16.940+09:00

Yes. A lower PUE can accompany higher on-site water use, because PUE measures energy overhead, not water demand. Evaporative cooling can trade water for lower cooling electricity. Separately, a growing AI workload can increase total water use even when both PUE and WUE improve. Read the two ratios alongside absolute energy, water volumes, and the same measurement boundary.

The decision in 30 seconds

Ask for annual facility kWh, annual IT kWh, annual water liters, and the water numerator's definition. Then ask where and when the water is needed. A better efficiency ratio is useful evidence; it is not a complete answer to a site's resource constraints.

Checked October 28, 2026. This is an interpretation guide, not a measured cooling comparison. All A/B/C figures below are invented annual scenarios. Fifteen arithmetic assertions ran on Node.js v24.14.1 on Windows; no data-center meters, GPU workloads, cooling equipment, or LLMs were operated.

Contents and working definitions

PUE: total facility energy divided by IT equipment energy, over the same period; a dimensionless ratio.
WUE: water liters divided by IT energy in kWh. The water boundary and withdrawal/consumption convention must be stated.
Heat rejection: the step that ultimately moves heat from the cooling system to the outside environment.
Absolute demand: the actual kWh and liters, before dividing by IT activity.
Indirect water: water associated with electricity generation or other upstream activities, outside a site-only numerator.

1. PUE and WUE answer different questions

The DOE-sponsored NREL design guide, revised July 2024, defines annual PUE as total facility energy divided by IT equipment energy. It characterizes supporting infrastructure, rather than the usefulness or efficiency of the computation itself. A PUE of 1.20 means 1.20 kWh of facility energy per 1 kWh delivered to IT within the stated boundary.

Microsoft's efficiency page defines its WUE using annual water for cooling and humidification over annual IT electricity. Its disclosed global FY24/FY25 values are PUE 1.16/1.17 and WUE 0.30/0.27 L/kWh. FY25 covers July 1, 2024–June 30, 2025, for fully owned and controlled sites operational for 12 months. These are operator-reported fleet ratios, not a same-building experiment or proof that cooling caused the changes.

Notice that those two ratios moved in different directions. Neither establishes total liters without the corresponding IT-energy denominator. Nor should a fleet average be substituted for a specific AI campus.

PUE = facility energy [kWh] / IT energy [kWh]
WUE = stated water volume [L] / IT energy [kWh]
Facility energy [kWh] = PUE × IT energy [kWh]
Water volume [L] = WUE × IT energy [kWh]

The last identity reconstructs only the water volume defined in that WUE. It does not automatically yield drinking-water withdrawal, all site consumption, or a lifecycle footprint. Annual ratios should use sums over the period, rather than an unweighted average of hourly ratios.

2. A closed liquid loop does not tell you where the heat goes

A useful distinction is the liquid moving heat away from chips versus the equipment rejecting that heat outdoors. A recirculating chip loop does not, by itself, identify the external cooling method.

In its December 2024 design explanation, Microsoft explicitly said replacing evaporative systems with mechanical cooling would raise PUE, while warmer chip-level cooling and efficient chillers could mitigate the energy impact. It also distinguished cooling water from administrative uses. That is evidence of a possible design tradeoff, not a universal percentage penalty.

The company's June 24, 2026 update describes cooling towers that evaporate water, hybrid systems that switch modes, air-cooled chillers, and new closed-loop direct-to-chip AI designs without operational water evaporation. These descriptions concern different configurations; they do not establish that every existing Microsoft building has adopted the new design.

An original two-step reading aid

① Chip → recirculating coolant loop
Ask: what carries the heat away from the processor?

② Facility → outdoor environment
Ask: dry heat rejection, mechanical refrigeration, evaporation, or a hybrid?

Only after both answers: compare the measured energy and water boundaries.

Conceptual diagram, not a piping design or a universal system layout. All essential distinctions are also stated in the text.

3. Two counterexamples expose what a ratio can hide

Synthetic example, not vendor performance: A and B each use 10 million IT kWh in a full year. We assume comparable useful work, service quality, climate, and accounting boundaries solely to isolate the ratios. The numbers are stipulated; they were not derived from a cooling simulation.

Metric	A	B
IT energy	10 GWh	10 GWh
PUE	1.20	1.10
Facility energy	12 GWh	11 GWh
WUE	0.20 L/kWh	0.60 L/kWh
Stated site water	2 million L	6 million L

B uses about 8.3% less facility energy than A, but three times the water. There is no contradiction: PUE contains no water term. This demonstrates an accounting possibility; it does not prove a particular evaporative system will deliver these values.

C: both ratios improve, yet both totals rise

Now suppose annual IT energy doubles to 20 GWh, PUE becomes 1.10, and WUE falls to 0.15 L/kWh. Facility energy is 22 GWh and water is 3 million L. Compared with A, total energy rises about 83.3% and water rises 50%, despite better PUE and WUE.

C isolates expansion, not a failure of efficiency. The ratios still identify improvements per IT kWh. They simply do not say whether demand growth exceeds those gains. Since useful workload was not measured, these examples also cannot establish liters per successful request or per training run.

4. Check location, season, and the missing water boundary

A site-only WUE can omit water associated with producing the electricity it buys. A June 2025 research abstract hosted by Lawrence Berkeley National Laboratory identifies server efficiency, utilization, grid water factors, cooling, and climate among determinants of workload water use. The abstract supports considering multiple factors, not assigning a universal water footprint to every AI request.

For a broader operational estimate, a transparent starting point is stated site water plus electricity consumption multiplied by a relevant electricity-water factor. Use the electricity quantity that factor actually covers, align period and geography, and avoid double counting. This article does not supply a grid factor, calculate lifecycle water, or equate withdrawal with consumption.

An annual ratio also cannot reveal a hot week's peak water draw, the availability of reclaimed water, or pressure on a particular watershed. Treat those as separate evidence requests. Water replenishment elsewhere should be reported separately from physical demand at the campus; it does not remove the need to examine local timing and supply.

5. What this means for AI infrastructure growth

Our interpretation: energy and water constraints can coexist. A campus that fits an annual electricity budget may still need a different heat-rejection design or water supply arrangement. Conversely, reducing evaporation may shift more attention to electricity, equipment cost, and operating conditions. A PUE headline alone cannot identify the lowest-cost or most expandable option.

For an operator or infrastructure investor, request the site-specific cooling configuration, energy and water totals, seasonal peak requirements, and the scope of commissioned capacity. Those inputs matter more than assuming that a lower ratio guarantees an easier buildout. No supplier orders, revenue forecasts, stock-price effects, or investment recommendation follow from the synthetic examples here.

At the workload layer, our guide to aligning GPU telemetry with request timing explains another boundary problem: board-level measurements do not represent whole-facility electricity. Keep that distinction when connecting AI service activity to PUE and water demand.

Comparison checklist

Match the period: full year against full year; retain monthly and peak-season evidence separately.
Match the meters: facility electricity, IT electricity, and the explicitly defined water numerator.
Show the totals: report kWh and liters beside PUE and WUE.
Identify the system: chip heat transfer and outdoor heat rejection are separate questions.
Keep unknowns: grid water, local scarcity, useful work, and costs remain unknown until measured or sourced.

The stronger question is not simply “Which campus has the lowest PUE?” It is “Which configuration can deliver the required AI service within this site's energy, water, and operating constraints?”

Appendix · sources and reproducibility

Checked October 28, 2026. Official operator disclosures describe their own scope; they are not an independent comparative benchmark. Fifteen offline arithmetic assertions verified unit conversion, scenario totals, percentage changes, and one energy-weighted PUE calculation. No hardware, facility telemetry, cooling test, or paid API was used. The examples exclude electricity prices, embodied resources, water treatment, construction, and measured service output.

Revised July 2024; hosted in a 2025-07 directory — NREL/DOE guide, section 8: PUE is annual total facility energy divided by IT energy; infrastructure efficiency is not overall compute efficiency.
Undated live page; FY24/FY25 table — WUE annual cooling/humidification liters divided by annual IT kWh.
2024-12-09 — Evaporative-to-mechanical cooling can raise PUE; warmer chip cooling mitigates energy impact.
2026-06-24 — New AI direct-to-chip design recirculates coolant without operational evaporation; cooling tower, hybrid, air-cooled chiller and chip cooling distinctions.
June2025 journal abstract — Workload water use depends on server efficiency/utilization, electricity-grid water factors, cooling, climate and infrastructure.

Log GPU Power, Memory, and Request Latency on One Timeline

2026-10-27T19:11:51.594+09:00

Put GPU observations and request completion events on an explicit UTC timeline, then attach only an earlier sample from the correct GPU within a stated age limit. Keep missing, unsupported and stale values visible. This Python lab produces that joined CSV; it does not prove that GPU power or memory caused a slow response.

Start here when two dashboards disagree

Check the time zone, GPU identity and event boundary first. Run the offline fixture below before collecting anything. A one-second polling setting is not evidence of one-second sensor precision, and a blank power reading is not zero watts.

Checked October 27, 2026. Actually executed: CPython 3.14.3 on Windows, standard library only, seven fictional request rows and 26 offline alignment checks. The real collector was attempted once and stopped because nvidia-smi was unavailable on PATH. No GPU telemetry, model output, real TTFT/E2E benchmark or paid API call was collected. Other operating systems were not executed.

1. The terms and the measurement boundary

GPU observation: a row returned by a read-only device query. Our sample_utc is when that query finished, not a precise hardware event timestamp.
TTFT: elapsed time from your declared request start to the first output token. A text client may observe only the first nonempty text event; label that proxy.
E2E: elapsed time to the declared final-content boundary for a successful request. A later transport completion signal is a separate event.
Backward match: the most recent observation at or before a request's completion, for the same GPU.
Sample age: completion time minus query completion time, in milliseconds. Our example accepts at most 1,500 ms; that is a teaching choice.

This exercise assumes successful text requests with compatible TTFT/E2E boundaries and a known GPU assignment. It joins existing latency measurements; it does not infer latency from GPU counters. Keep failed or incomplete attempts in a separate outcome-aware log rather than inventing successful durations. The C# streaming measurement lab explains first text, last text and completion signals.

One timeline, two independent observations

GPU 0: 00.000 → 120 W
GPU 0: 01.000 → 180 W
GPU 0: 02.000 → power unavailable

Request r2 completes at 01.200
↓ Choose GPU 0 at 01.000
Sample age = 200 ms; attach 180 W

Do not choose 02.000: that observation is later.
Do not call 180 W “r2's energy”: the board may serve other work.

Original fictional diagram. Times are seconds within 10:00 UTC on October 27. The arrows describe a join rule, not an execution trace or a cause-and-effect result.

2. Collect a short GPU log, if the tool is already available

NVIDIA documents selective CSV queries and unsupported N/A values. The fields below are device index, GPU busy-time percentage, used device memory in MiB and board power in watts. Used memory is capacity, not memory-bandwidth utilization. Power may be averaged or instantaneous depending on the supported device/field; inspect your local help and driver documentation. It is not whole-server wall power. Device index is scoped to this capture: enumeration can change across reboots.

Save this as collect_gpu.py. It calls only the query command, uses no shell and changes no GPU setting. It records query duration as poll_ms. The delay follows each poll, so actual gaps exceed the requested interval. This is a small teaching collector, not a stable cross-driver monitoring API.

"""Read-only, short nvidia-smi polling example; no driver/settings changes."""
import argparse
import csv
import io
import subprocess
import time
from datetime import datetime, timezone


def poll():
    start = time.perf_counter()
    result = subprocess.run(
        ["nvidia-smi", "--query-gpu=index,utilization.gpu,memory.used,power.draw",
         "--format=csv,noheader,nounits"],
        capture_output=True, text=True, check=True, timeout=10,
    )
    # Query completion time, not an exact hardware sensor timestamp.
    stamp = datetime.now(timezone.utc).isoformat()
    elapsed_ms = round((time.perf_counter() - start) * 1000, 3)
    rows = []
    for values in csv.reader(io.StringIO(result.stdout), skipinitialspace=True):
        if len(values) != 4:
            raise ValueError("Unexpected nvidia-smi columns; inspect local --help-query-gpu")
        rows.append([stamp, *[v.strip() for v in values], elapsed_ms])
    if not rows:
        raise ValueError("No GPU rows returned")
    return rows


if __name__ == "__main__":
    p = argparse.ArgumentParser()
    p.add_argument("--samples", type=int, default=10)
    p.add_argument("--interval", type=float, default=1)
    p.add_argument("--out", default="gpu.csv")
    a = p.parse_args()
    if not 1 <= a.samples <= 60 or not 0.5 <= a.interval <= 60:
        p.error("Use 1..60 samples and an interval of 0.5..60 seconds")
    try:
        first = poll()  # A missing tool does not create an empty output file.
        with open(a.out, "x", newline="", encoding="utf-8") as f:
            w = csv.writer(f)
            w.writerow(["sample_utc", "gpu_index", "util_pct", "memory_mib", "power_w", "poll_ms"])
            w.writerows(first)
            f.flush()
            for _ in range(a.samples - 1):
                time.sleep(a.interval)  # Delay after a poll; not exact 1 Hz.
                w.writerows(poll())
                f.flush()
    except FileNotFoundError:
        raise SystemExit("nvidia-smi unavailable on PATH; no GPU telemetry collected")
    except (subprocess.SubprocessError, ValueError) as error:
        raise SystemExit(f"Collection stopped; inspect any partial file: {error}")

On a machine with the existing NVIDIA driver/tool, first inspect nvidia-smi --help-query-gpu. Then run a short capture alongside an already approved workload:

python collect_gpu.py --samples 10 --interval 1 --out gpu.csv

Actual outcome on this Windows environment:

python collect_gpu.py --samples 1 --out actual-gpu.csv
nvidia-smi unavailable on PATH; no GPU telemetry collected

The command exited with code 1 and created no actual-gpu.csv during our one-sample check. The GPU collection path did not succeed here. Do not solve that by copying random binaries, raising privileges or changing driver settings. Use an approved host that already exposes the tool, or continue with the offline fixtures. If a later poll fails, the collector stops and any partial file needs inspection. Output files use exclusive creation, so choose a new name instead of overwriting evidence.

3. Export request events with an explicit UTC offset

For real runs, record a timezone-aware UTC completion time separately from the elapsed TTFT and E2E durations measured by a monotonic timer. Python's datetime documentation distinguishes aware and naive timestamps; the parser below rejects a timestamp without an offset. perf_counter is suitable for elapsed intervals. A UTC label does not synchronize two computers: check clock offset and record an uncertainty bound when the client and GPU collector run on different hosts.

Do not set gpu_index to 0 just because there is one client. It must describe the observed serving device. This lab does not attribute a distributed request to multiple GPUs, pods or MIG instances. For that, retain the actual placement mapping and per-device streams. The join here uses the request's final-content time; it cannot explain the whole prefill/decode interval.

For a reproducible first run, save these invented observations as gpu-fixture.csv:

sample_utc,gpu_index,util_pct,memory_mib,power_w,poll_ms
2026-10-27T10:00:00Z,0,60,4096,120,20
2026-10-27T10:00:01Z,0,95,6144,180,20
2026-10-27T10:00:02Z,0,90,6144,N/A,20
2026-10-27T10:00:01Z,1,10,1024,50,20

Save these invented successful-request timings as requests-fixture.csv. r7 uses +09:00 intentionally; it represents 10:00:01.100 UTC. The dates are fixture labels, not when hardware was measured.

request_id,end_utc,ttft_ms,e2e_ms,gpu_index
r1,2026-10-27T10:00:00.250Z,80,200,0
r2,2026-10-27T10:00:01.200Z,120,700,0
r3,2026-10-27T10:00:02.100Z,900,1800,0
r4,2026-10-27T10:00:05Z,300,1200,0
r5,2026-10-27T09:59:59.900Z,20,50,0
r6,2026-10-27T10:00:01.100Z,100,200,2
r7,2026-10-27T19:00:01.100+09:00,100,200,1

4. Join without filling from the future

Save this as align_timeline.py in the same folder. It sorts each GPU stream, rejects ambiguous duplicate timestamps, validates nonnegative finite durations and keeps every request row. N/A stays unavailable. An older-than-limit sample keeps its age for diagnosis but leaves GPU values blank. This is our explicit matching policy, not a claim that these sensor values were constant between observations.

"""Join request completion times to prior GPU observations. Python 3.14, stdlib."""
import argparse
import csv
import math
from bisect import bisect_right
from datetime import datetime, timezone


def utc(text):
    value = datetime.fromisoformat(text.replace("Z", "+00:00"))
    if value.utcoffset() is None:
        raise ValueError("Timestamp needs Z or an explicit UTC offset")
    return value.astimezone(timezone.utc)


def number(text, optional=False):
    if optional and text.strip() in ("", "N/A", "[N/A]", "[Not Supported]"):
        return None
    value = float(text)
    if not math.isfinite(value) or value < 0:
        raise ValueError("Expected a finite, nonnegative number")
    return value


def align(gpu_rows, request_rows, max_age_ms=1500):
    if not math.isfinite(max_age_ms) or max_age_ms < 0:
        raise ValueError("max_age_ms must be finite and nonnegative")
    streams = {}
    for row in gpu_rows:
        key = str(int(row["gpu_index"]))
        stamp = utc(row["sample_utc"])
        values = [number(row[k], True) for k in ("util_pct", "memory_mib", "power_w")]
        if values[0] is not None and values[0] > 100:
            raise ValueError("util_pct must be at most 100")
        streams.setdefault(key, []).append((stamp, values))
    for stream in streams.values():
        stream.sort(key=lambda item: item[0])
        if len({item[0] for item in stream}) != len(stream):
            raise ValueError("Duplicate timestamp within a GPU stream")
    times = {key: [item[0] for item in stream] for key, stream in streams.items()}
    output = []
    seen = set()
    for request in request_rows:
        rid = request["request_id"]
        if not rid or rid in seen:
            raise ValueError("request_id must be nonempty and unique")
        seen.add(rid)
        end = utc(request["end_utc"])
        ttft, e2e = (number(request[k]) for k in ("ttft_ms", "e2e_ms"))
        if ttft > e2e:
            raise ValueError("TTFT exceeds E2E; check measurement boundaries")
        key = str(int(request["gpu_index"]))
        row = dict(request, end_utc=end.isoformat(), match="no_gpu", sample_utc="", age_ms="", util_pct="", memory_mib="", power_w="")
        if key in streams:
            pos = bisect_right(times[key], end) - 1
            row["match"] = "no_prior"
            if pos >= 0:
                stamp, values = streams[key][pos]
                age = (end - stamp).total_seconds() * 1000
                row.update(sample_utc=stamp.isoformat(), age_ms=round(age, 3), match="stale")
                if age <= max_age_ms:
                    row["match"] = "matched_partial" if None in values else "matched"
                    row.update(zip(("util_pct", "memory_mib", "power_w"), ("" if v is None else v for v in values)))
        output.append(row)
    return output


if __name__ == "__main__":
    parser = argparse.ArgumentParser()
    parser.add_argument("gpu_csv")
    parser.add_argument("requests_csv")
    parser.add_argument("output_csv")
    parser.add_argument("--max-age-ms", type=float, default=1500)
    args = parser.parse_args()
    with open(args.gpu_csv, newline="", encoding="utf-8") as f:
        gpu = list(csv.DictReader(f))
    with open(args.requests_csv, newline="", encoding="utf-8") as f:
        requests = list(csv.DictReader(f))
    rows = align(gpu, requests, args.max_age_ms)
    if not rows:
        raise SystemExit("No requests; no output written")
    with open(args.output_csv, "x", newline="", encoding="utf-8") as f:
        writer = csv.DictWriter(f, fieldnames=list(rows[0]))
        writer.writeheader()
        writer.writerows(rows)
    print(f"Wrote {len(rows)} requests to {args.output_csv}")

Run the offline example with Python 3.14:

python align_timeline.py gpu-fixture.csv requests-fixture.csv aligned-fixture.csv

Actual console output from the fixture run:

Wrote 7 requests to aligned-fixture.csv

The first two saved CSV rows were:

request_id,end_utc,ttft_ms,e2e_ms,gpu_index,match,sample_utc,age_ms,util_pct,memory_mib,power_w
r1,2026-10-27T10:00:00.250000+00:00,80,200,0,matched,2026-10-27T10:00:00+00:00,250.0,60.0,4096.0,120.0
r2,2026-10-27T10:00:01.200000+00:00,120,700,0,matched,2026-10-27T10:00:01+00:00,200.0,95.0,6144.0,180.0

5. Read the result before drawing a conclusion

ID	Result
r1	ok · 250ms 120W
r2	ok · 200ms 180W
r3	partial 100ms · N/A
r4	stale 3,000ms
r5	no prior
r6	no GPU
r7	GPU 1 100ms · 50W

r3 preserves 90% utilization and 6,144 MiB memory while leaving unsupported power blank. r4's prior observation is 3,000 ms old, beyond this example's 1,500 ms limit. r5 completes before the first GPU 0 sample, so there is no future fill. r6 names GPU 2, which has no stream. r7 correctly uses GPU 1 after offset conversion.

The result is useful for asking a narrower question: did a slow completion occur near rising memory use, a busy device or a collection gap? It cannot establish the bottleneck. A long request crosses many samples; inspect its start-to-final interval and the surrounding queue, batching and CPU/network signals before an experiment. Repeated completions may attach the same board sample, so these rows are not independent power observations.

Do not multiply the attached watts by request duration and call it per-request energy. The sample can cover unrelated work and a different averaging window. This script does not integrate energy, rank models, recommend power limits or calculate throughput. For a separate outcome-aware aggregation step, see p50, p95 and SLO Goodput from saved request logs.

6. Compare the timestamp choices

Closest sample in either direction: visually convenient, but can select an observation after the request finished.
Latest earlier sample, with an age limit: the reproducible rule used here. It still cannot reconstruct events between polls.
Full request-interval analysis: a better next step for long requests, requiring start/end boundaries, sampling-window knowledge and placement information. Not implemented or benchmarked in this lab.

Appendix · What passed, what did not run

26 offline checks passed on Python 3.14.3/Windows: per-GPU selection, UTC-offset equivalence, inclusive age boundary, stale and missing data, no future fill, unsupported values, sorting, duplicate IDs/timestamps, invalid durations, nonfinite numbers and out-of-range utilization. The seven-row CSV command really ran. The collector's missing-tool exit was also observed once. No real GPU/LLM collection or performance comparison ran; the successful GPU polling branch remains unverified on this host.

For your own measurements, retain raw files, script versions, model/runtime/driver versions, GPU placement, prompt/output lengths, warmup policy, request outcomes and collection intervals. Replace both fixtures with compatible real records, choose a justified age bound, and inspect unmatched rows before plotting. A smaller age limit exposes uncertainty; it does not improve the original clock or sensor.

Sources

NVIDIA System Management Interface documentation — query fields, support limits, units and power scope; local device/driver support must be checked.
Python 3.14 datetime — aware timestamps and UTC conversion.
Python 3.14 time — elapsed-time counters.
Python 3.14 subprocess — bounded, checked process execution with an argument list.

Original code, fixture data, text diagram and interpretation. Official documentation is linked and paraphrased; no third-party image, hardware trace, private prompt, credential or external font is included. Query/documentation behavior can vary by version; this is a learning lab.

GPU 사용률 95%가 효율적인 AI 서빙을 보장하지 않는 이유

2026-10-27T06:38:01.955+09:00

nvidia-smi의 GPU-Util 95%는 표본 기간의 대부분에 GPU 커널이 하나 이상 실행됐다는 뜻입니다. GPU의 최대 연산 성능을 95% 달성했다거나, 이용자가 빠른 답을 받았다는 뜻은 아닙니다. AI 서빙 효율을 판단하려면 같은 시간대의 요청 지연·대기열·처리량·전력과 작업 조건을 함께 봐야 합니다.

30초 확인 · ‘95%’가 무엇의 95%인지부터 보세요

대시보드의 지표 설명과 단위를 확인하세요. GPU-Util, SM Activity, 메모리 점유율은 서로 다른 값입니다. 다음으로 같은 관측 구간의 요청 지연과 대기 요청 수를 나란히 확인합니다. 이 숫자 하나만 보고 배치를 키우거나 GPU·전력 설정을 바꾸지 마세요.

기준일: 2026년 10월 27일. NVIDIA nvidia-smi·DCGM 공식 문서와 vLLM의 공개 지표 문서를 확인했습니다. 아래 A·B는 자체 제작한 가상 집계 예시이며 실제 GPU나 LLM 실험이 아닙니다. Node.js 24.14.1·Windows에서 산술·집계 관계 14개만 실행 검증했습니다.

목차 · 지표를 읽기 위한 여섯 용어

GPU-Util: 표본 기간 중 GPU에서 커널이 하나 이상 실행된 시간의 비율입니다.
SM: GPU에서 스레드 묶음을 실행하는 연산 단위인 Streaming Multiprocessor입니다.
TTFT: 요청을 보내고 첫 출력 토큰을 받기까지의 시간입니다. 측정 시작·종료 경계를 함께 적어야 합니다.
대기열: 도착했지만 아직 실행에 들어가지 못한 요청이 머무는 곳입니다.
SLO: 서비스가 정한 지연·성공률 등의 목표입니다. 조건을 충족한 완료 요청을 따로 세면 처리량의 질을 구분할 수 있습니다.
token/J: 정해진 범위에서 소비한 에너지 1줄(J)당 생성한 출력 토큰 수입니다.

1. ‘계속 바쁨’과 ‘최대 연산량에 가까움’은 다릅니다

NVIDIA의 nvidia-smi 설명에서 GPU 사용률은 표본 기간 중 하나 이상의 커널이 실행된 시간 비율입니다. 제품에 따라 표본 기간도 달라집니다. 이 값만으로 어떤 커널이 얼마나 많은 연산 유닛을 썼는지, 계산과 메모리 대기 중 무엇이 지배적인지 알 수는 없습니다.

예를 들어 작은 일을 하는 커널이 오래 실행되는 경우와 더 많은 일을 처리하는 커널이 오래 실행되는 경우 모두 높은 GPU-Util이 나올 수 있습니다. 이는 가능한 해석을 설명하는 예이며, ‘95%이면 메모리 병목’이라고 진단한 결과가 아닙니다.

확인할 표시	구분할 의미
GPU-Util	커널 실행 시간 비율
Memory Utilization	장치 메모리를 읽거나 쓴 시간 비율
Memory Used	사용 중인 장치 메모리 용량

따라서 메모리 점유가 높다는 말과 메모리 대역폭을 많이 쓴다는 말도 구분해야 합니다. CUDA의 allocated·reserved가 궁금하다면 메모리 부족 오류에서 할당·예약 로그를 읽는 글로 이어서 볼 수 있습니다.

2. SM·Tensor·DRAM 지표는 ‘왜 바쁜가’를 좁히는 단서입니다

NVIDIA DCGM의 프로파일링 문서는 SM Activity, SM Occupancy, Tensor Activity와 메모리 활동을 구분합니다. SM Activity는 SM들에 걸친 활동 시간의 평균이며, 메모리를 기다리는 warp도 active에 포함될 수 있습니다. SM Occupancy는 유지 중인 warp 수를 가능한 최대 동시 warp 수와 비교합니다. 두 값은 동의어가 아닙니다.

Tensor Activity와 DRAM 관련 활동도 각각 다른 하드웨어 측면을 봅니다. 활동 비율이 높다는 이유만으로 실제 FLOPS나 GB/s를 이론 최대값과 같은 비율로 달성했다고 읽으면 안 됩니다. 이 값들은 구간 평균이므로 어떤 소스 코드 줄이 원인인지 알려주는 추적 기록도 아닙니다.

사용 가능한 필드·이름·범위는 GPU, DCGM·드라이버·exporter 버전에 따라 확인해야 합니다. MIG나 가상화 환경에서 지원되지 않는 값은 0으로 바꾸지 말고 미지원으로 남깁니다. 이 글에서는 프로파일러 설치·권한 확대·모니터링 중단 명령을 실행하지 않았습니다.

3. 서빙에서는 GPU 옆에 요청 지표가 있어야 합니다

GPU가 높은 사용률로 일하는 동안에도 새 요청이 줄을 서면 이용자의 첫 응답은 늦어질 수 있습니다. 배치를 크게 하면 처리 효율이 좋아질 수 있지만, 요청이 모일 때까지 기다리는 시간이나 긴 요청의 영향을 함께 확인해야 합니다. 반대로 GPU-Util이 낮아도 수요가 적고 지연 목표를 만족한다면 당장 불량 운영이라고 볼 근거는 부족합니다.

vLLM의 공개 지표 설계도 서버 상태 지표와 요청 단위 지표를 구분합니다. 대기·실행 중인 요청 수, 큐 시간, TTFT와 전체 요청 지연을 함께 해석할 수 있습니다. 구체적인 지표 이름과 계산 경계는 설치 버전의 문서·실제 노출값을 확인해야 합니다.

자체 점검 흐름

① GPU가 바쁜 시간인가?
↓ 지표 이름·표본 기간 확인

② 무엇이 활동 중인가?
↓ SM·Tensor·DRAM·통신 단서 대조

③ 요청이 목표 안에 끝났는가?
↓ 대기열·TTFT·전체 지연·성공 확인

④ 같은 작업에 에너지를 얼마나 썼는가?
↓ 동일 구간·동일 측정 범위로 계산

자체 제작한 해석 순서입니다. 이 화살표는 인과관계나 실제 실행 추적을 나타내지 않습니다. 지표 정의가 낯설다면 LLM 추론 지연·처리량의 기본 개념부터 확인할 수 있습니다.

4. 같은 95%라도 결과는 달라질 수 있습니다

다음은 실측이 아닌 가상 반례입니다. 같은 모델·품질 기준·입력 길이·출력 길이 분포, 같은 GPU 한 장과 60초 구간을 가정합니다. 두 경우 모두 요청 100개가 도착하고 GPU-Util은 95%라고 놓았습니다. 끝난 요청은 각각 100토큰을 출력하며 미완료 요청의 부분 출력은 없다고 단순화했습니다.

예시의 요청 목표는 TTFT 1초 이하와 전체 요청 지연 10초 이하를 모두 만족하는 것입니다. 아래 ‘목표 충족’ 개수 역시 주어진 가정이며, GPU 사용률이나 출력 토큰 수로부터 계산해 낸 값이 아닙니다. 이 목표 수치가 모든 서비스의 권장값이라는 뜻도 아닙니다.

가정 A · GPU-Util 95%

완료 60개, 그중 목표 충족 30개
출력 6,000토큰 / 60초 = 100token/s
GPU 보드 평균 전력 400W × 60초 = 24,000J
6,000 ÷ 24,000 = 0.250token/J
목표 충족 요청 30 ÷ 60 = 0.5개/초

가정 B · GPU-Util 95%

완료 90개, 그중 목표 충족 72개
출력 9,000토큰 / 60초 = 150token/s
GPU 보드 평균 전력 350W × 60초 = 21,000J
9,000 ÷ 21,000 ≈ 0.429token/J
목표 충족 요청 72 ÷ 60 = 1.2개/초

이 숫자들은 GPU-Util만으로 나머지 결과가 정해지지 않는다는 점을 보여줍니다. B가 실제 시스템에서 재현됐다거나 특정 배치·소프트웨어가 원인이라는 증거는 아닙니다. 서로 다른 모델·정밀도·출력 품질·캐시 조건을 섞으면 token/J 비교 자체가 달라질 수 있습니다.

요청 목표를 만족한 처리량과 수요를 함께 읽는 방법은 Goodput이 높아도 충분한 용량인지 판단하는 글에서 이어집니다. 이번 글의 질문은 그보다 앞선 ‘장치 사용률이 요청 성과를 대신할 수 있는가’입니다.

5. 전력 수치 하나를 효율로 읽지 마세요

전력 W와 에너지 J는 다릅니다. 같은 구간에서 평균 전력에 시간을 곱하면 에너지가 됩니다. 위 예시는 한 GPU 보드의 가정한 평균 전력만 사용했습니다. 순간 전력 한 번을 구간 전체의 평균으로 대신하지 않았습니다.

실제 측정에서는 nvidia-smi의 전력 필드 설명에서 평균·순간값, 보드·모듈 범위와 지원 조건을 확인해야 합니다. GPU 보드 에너지에는 서버의 다른 부품과 데이터센터 냉각·배전 에너지가 전부 들어 있지 않습니다. 이를 곧바로 전기요금이나 전체 데이터센터 효율로 바꾸지 마세요.

일부 요청의 목표 충족률을 높이는 것이 목적이라면 단순 token/J 외에 같은 목표를 통과한 완료 요청과 에너지를 함께 볼 수 있습니다. 다만 품질 검사, 실패·취소 처리, 미완료 요청과 관측 구간의 경계를 동일하게 정해야 비교가 성립합니다.

6. 운영 판단 전에 맞춰 볼 다섯 가지

같은 대상: GPU 한 장, MIG 인스턴스, 프로세스, 서비스 전체 중 어느 범위인지 적습니다.
같은 구간: 표본 기간과 평균·순간값을 확인합니다. 다른 시각의 95%와 p95 지연을 한 원인처럼 묶지 않습니다.
같은 작업: 모델·정밀도·입출력 길이·동시성·캐시·요청 도착 패턴을 기록합니다.
같은 성과 기준: 처리량뿐 아니라 지연 분포·실패·대기열·목표 충족 완료 요청을 대조합니다.
검증할 가설: 배치, 메모리, 통신, CPU 준비 작업 등 후보를 나눈 뒤 조건을 통제해 확인합니다. 상관관계만으로 GPU 증설 효과나 비용 절감을 확정하지 않습니다.

GPU-Util은 버릴 지표가 아니라 출발점입니다. 높은 사용률의 의미를 확인하고 요청 결과와 에너지의 측정 범위를 연결해야, 바쁜 장비와 유용한 AI 서비스를 구분할 수 있습니다.

Appendix · 실행 범위와 1차 출처

2026년 10월 27일 확인한 공개 문서 기준입니다. nvidia-smi·DCGM latest 문서와 vLLM main 문서는 바뀔 수 있습니다. 특정 GPU 모델이나 설치 버전에서 지표 수집이 된다고 검증한 글은 아닙니다. Windows·Node.js 24.14.1에서 가상 집계 산술 14개만 통과했습니다. nvidia-smi·DCGM·프로파일러·LLM·GPU 부하 시험은 실행하지 않았고, 장비·권한·전력·서빙 설정을 바꾸지 않았습니다.

400Gb/s면 얼마나 빠를까? Python으로 분산 AI 통신 시간 계산하기

2026-10-26T19:14:03.559+09:00

분산 AI 통신의 이상적인 전송 시간은 ‘보낼 데이터량 ÷ 같은 경계의 대역폭’으로 계산합니다. 400Gb/s에서 64MiB를 한 번 보내는 직렬화 시간은 약 1.342ms이고, 아래 8-rank All-Reduce 모델의 하한은 약 2.349ms입니다. 두 값은 장비 실측이나 LLM 응답 시간 예측이 아닙니다. 데이터 단위, 참여자 수, 통신량과 병목 대역폭의 범위를 먼저 맞춰야 합니다.

30초 확인 · 계산이 8배쯤 다르면 b와 B부터 보세요

입력 크기가 MB인지 MiB인지, 속도가 Gb/s인지 GB/s인지 확인하세요. 다음 행동은 아래 계산기를 로컬에서 실행해 기준값을 만드는 것입니다. 네트워크 설정이나 권한을 바꿀 필요는 없습니다. 포트 속도를 전체 AI 작업의 처리량으로 읽지 마세요.

2026년 10월 26일 확인. Windows 11·Python 3.14.3에서 산술·단위·입력 검증 20개와 예제 프로그램 출력을 실제 실행했습니다. GPU·NCCL·네트워크 전송·LLM 벤치마크는 실행하지 않았습니다. 숫자와 효율 70%는 설명용 가정입니다.

목차 · 먼저 익힐 용어

payload: 전송 대상 데이터 본체. 헤더와 재전송 같은 부가 비용과 구분합니다.
직렬화 시간: 정해진 데이터 비트를 링크로 내보내는 데 필요한 시간입니다.
rank: 집단 통신에 참여하는 프로세스의 식별 단위입니다.
All-Reduce: 참여자들의 대응 원소를 합산 등으로 결합해 모두에게 결과를 주는 집단 통신입니다.
효율 η: 이 계산기에서 가정한 유효 대역폭과 명목 대역폭의 비율입니다.
하한: 정해진 모델과 가정 아래 가능한 가장 짧은 시간입니다. 모든 장비에 적용되는 보편적 보장은 아닙니다.

1. 단위를 맞추면 400Gb/s는 50GB/s가 됩니다

소문자 b는 bit, 대문자 B는 byte입니다. 1byte는 8bit이므로 400Gb/s ÷ 8 = 50GB/s입니다. 여기서 G는 10⁹, Mi는 2²⁰입니다. NIST의 단위 정의처럼 MB와 MiB를 구분해야 합니다.

표기	이 글의 뜻
1MB / 1MiB	10⁶B / 2²⁰B
64MiB	64 × 2²⁰B
400Gb/s	50GB/s （십진 단위）
ms	1초의 1/1,000

직접 따라가는 계산 흐름

64MiB → 67,108,864B → 536,870,912bit

÷ 400,000,000,000bit/s → 0.00134217728초

× 1,000 → 1.34217728ms

자체 제작한 산술 도식입니다. 한 방향 payload를 한 번 보내는 이상적 계산이며, 장비 배선도나 패킷 측정 화면이 아닙니다.

2. 분자는 클러스터 총량인가, rank 하나의 입력인가

같은 64MiB라도 의미가 다르면 답이 달라집니다. 아래에서는 8개 호스트에 rank 하나씩, rank마다 입력 64MiB, rank당 바깥으로 나가는 가용 대역폭을 명목 400Gb/s로 보는 균일한 모델을 가정합니다. 다른 작업과 링크를 공유하지 않고, 여러 NIC를 묶지 않으며, 압축도 하지 않습니다.

8개 입력을 합친 512MiB를 rank 하나의 400Gb/s로 나누면 다른 질문을 계산하게 됩니다. 반대로 전체 클러스터의 NIC 속도를 모두 더한 분모를 rank 하나의 데이터에 바로 쓰면 시간을 과도하게 줄일 수 있습니다. 분자와 분모가 가리키는 범위를 같은 문장에 적으세요.

송신과 수신이 동시에 진행되는 full-duplex 모델에서 송신량을 계산한 뒤 수신량까지 무조건 더해 시간을 2배로 만들지도 않습니다. 어떤 경계에서 몇 번 센 바이트인지가 중요합니다. GPU 간 경로 자체가 다르다면 nvidia-smi로 GPU·PCIe 토폴로지를 읽는 순서부터 확인할 수 있습니다.

3. 8-rank All-Reduce의 하한을 계산해 봅니다

NVIDIA nccl-tests 설명의 All-Reduce 대역폭 모델은 rank 수 n에 대해 2 × (n − 1) / n의 통신량 보정 계수를 사용합니다. n=8이면 1.75입니다. 이 예에서는 rank당 입력 크기 S를 byte로, 대역폭 B를 byte/s로 맞춘 뒤 T = (S / B) × 1.75로 계산합니다.

따라서 모델상 rank당 송신 payload는 64MiB × 1.75 = 112MiB, 시간은 112MiB ÷ 50GB/s = 2.34881024ms입니다. 단순한 1회 전송의 1.342ms와 달라지는 이유는 입력 크기만으로 집단 통신량이 정해지지 않기 때문입니다.

이는 충분한 병렬성·균일한 rank 대역폭을 둔 이상적 모델입니다. 실제 구현의 알고리즘, 계층 구조, 공유 링크와 동기화 비용에 따라 달라집니다. NCCL의 All-Reduce 정의는 결과의 의미를 정합니다. 이 계수를 모든 통신 연산이나 실제 MoE 라우팅에 그대로 대입할 수는 없습니다.

4. 복사해서 실행하는 Python 계산기

아래 전체 코드를 communication_time.py로 저장하세요. 표준 라이브러리만 사용하므로 패키지 설치·관리자 권한·API 키가 필요 없습니다. Python 3.14.3에서 실행했고, 다른 버전은 이번에 시험하지 않았습니다. 함수 입력에는 숫자를 넣으세요. 문자열 파서나 임의 입력을 처리하는 웹 서비스용 코드는 아닙니다.

"""Offline arithmetic only: not an NCCL, NIC, GPU, or LLM benchmark."""
import math


def serialization_ms(size_mib, gbps, factor=1.0, efficiency=1.0):
    values = (size_mib, gbps, factor, efficiency)
    if any(not math.isfinite(x) for x in values):
        raise ValueError("All inputs must be finite")
    if size_mib < 0 or gbps <= 0 or factor <= 0:
        raise ValueError("Size >= 0; bandwidth and factor > 0")
    if not 0 < efficiency <= 1:
        raise ValueError("Efficiency must be in (0, 1]")
    payload_bytes = size_mib * (2 ** 20)
    bits_to_send = payload_bytes * factor * 8
    bits_per_second = gbps * (10 ** 9) * efficiency
    return bits_to_send / bits_per_second * 1000


def allreduce_factor(ranks):
    if isinstance(ranks, bool) or not isinstance(ranks, int) or ranks < 2:
        raise ValueError("Ranks must be an integer >= 2")
    return 2 * (ranks - 1) / ranks


if __name__ == "__main__":
    size_mib, gbps, ranks = 64, 400, 8
    factor = allreduce_factor(ranks)
    print(f"payload_bytes={size_mib * 2 ** 20}")
    print(f"point_to_point_ms={serialization_ms(size_mib, gbps):.6f}")
    print(f"allreduce_factor={factor:.2f}")
    print(f"allreduce_ideal_ms={serialization_ms(size_mib, gbps, factor):.6f}")
    print("allreduce_70pct_ms="
          f"{serialization_ms(size_mib, gbps, factor, 0.7):.6f}")

파일을 저장한 폴더에서 실행합니다.

python communication_time.py

실제 로컬 실행 출력입니다. 측정한 실행 지연이 아니라 프로그램이 계산한 값입니다.

payload_bytes=67108864
point_to_point_ms=1.342177
allreduce_factor=1.75
allreduce_ideal_ms=2.348810
allreduce_70pct_ms=3.355443

efficiency=0.7은 유효 대역폭이 400 × 0.7 = 280Gb/s라는 가정입니다. 이때 대역폭 항은 약 3.355ms입니다. 70%는 실측치도 권장 기본값도 아닙니다. 추가 지연을 포함한 예상 완료 시간의 상한도 아닙니다.

0 또는 음수 대역폭, 음수 크기, 0 이하·1 초과 효율, NaN·무한대는 거부합니다. rank는 2 이상의 정수만 허용합니다. math.isfinite로 유효한 수인지 확인하며, 잘못된 입력을 조용히 정상 결과처럼 출력하지 않도록 했습니다.

5. 실측이 계산과 다를 때 확인할 순서

8배 차이: Gb/s와 GB/s를 섞었는지 확인합니다. MB와 MiB 차이는 약 4.86%이므로 두 문제를 구분합니다.
작은 메시지에서 차이가 큼: 호출·동기화·처리 지연을 확인합니다. payload가 0이면 계산기의 직렬화 항은 0이지만, 실제 호출 비용까지 0이라는 뜻은 아닙니다.
rank를 늘릴수록 급격히 느려짐: rank 배치, NIC 공유, 스위치 경로와 혼잡을 확인합니다. 이 모델은 대역폭 B가 고정된다고 가정합니다.
계산한 하한보다 실측이 짧음: 먼저 단위, 입력 크기 기준, 압축, 여러 NIC·경로의 병렬 사용, 통신 연산이 같은지 확인합니다. 비교 가정이 틀렸을 수 있으므로 곧바로 측정 오류라고 단정하지 않습니다.

nccl-tests의 algbw와 busbw도 구분하세요. 전자는 입력 크기/시간, 후자는 전자에 연산별 계수를 곱한 값입니다. 측정 보고서의 algbw로 시간을 역산하면 T = S / algbw입니다. busbw로 역산하면 T = (S / busbw) × 1.75이며, 여기서는 앞의 8-rank 조건을 적용합니다. 두 대역폭은 보고서에서 GB/s 단위이므로 S도 byte로 맞추면 초가 나옵니다. 명목 포트 속도·TCP 전송 속도·이 두 집단 통신 지표를 서로 같은 값으로 대입하지 마세요.

링크를 빠르게 바꾸면 위 계산의 대역폭 항은 줄어들 수 있습니다. 그러나 통신과 연산이 겹치거나 다른 병목이 지배하면 학습 step 시간이나 LLM의 TTFT·토큰 처리량이 같은 비율로 개선된다고 말할 수 없습니다. 네트워크 선택 관점은 Ethernet과 InfiniBand를 포트 속도 외의 조건으로 비교한 글에서 이어서 볼 수 있습니다.

6. 계산 결과를 이렇게 기록하세요

단순 전송: 64MiB·400Gb/s → 약 1.342ms. 1회 송신 직렬화 항입니다.
집단 통신 모델: rank마다 64MiB·8 rank·rank당 400Gb/s → 약 2.349ms. All-Reduce 보정 1.75를 적용한 하한입니다.
가정 변경: 같은 조건에 효율 70% → 대역폭 항 약 3.355ms. 실제 완료 시간을 보장하지 않습니다.
실측 보고: 별도 실험의 연산·크기·rank 수·배치·라이브러리 버전·평균/분위수·반복 조건을 함께 남깁니다. 이 글에는 그런 하드웨어 실측 결과가 없습니다.

Appendix · 검증 범위와 출처

실행 환경은 Windows 11 빌드 26200·CPython 3.14.3입니다. 이진/십진 단위 변환, 2·8 rank 계수, 400→800Gb/s 가정, 효율·잘못된 입력 거부, 표시한 전체 예제의 stdout 일치 등 20개 검증을 통과했습니다. GPU 접근, 프로세스 간 통신, NCCL 설치·실행, NIC 부하 시험, 유료 LLM 호출은 하지 않았습니다.

문서 확인일은 2026년 10월 26일입니다. NCCL 문서는 2.32.3, Python 공식 문서는 3.14 계열을 참고했습니다. nccl-tests의 master 문서는 변경될 수 있습니다. 코드·문장·계산 흐름은 자체 작성했고 외부 이미지를 복제하지 않았습니다.

All-Reduce vs. All-to-All: Why AI Network Traffic Patterns Differ

2026-10-26T06:37:32.582+09:00

All-Reduce combines corresponding values and gives the combined result to every participant. All-to-All redistributes different chunks to different participants without doing that reduction. They solve different problems. A network that handles one well can still struggle with the other because message sizes, destinations, synchronization and the physical routes differ.

Start with the operation, not the port speed

Before comparing AI cluster bandwidth numbers, identify the collective, group size, payload size, data type and rank placement. Keep the workload fixed. A faster All-Reduce score is not evidence of faster expert routing, and fewer bytes in an example do not make All-to-All a replacement for All-Reduce.

Evidence checked October 26, 2026, Korea time: NCCL 2.32.3 documentation, PyTorch 2.14 documentation and the public Megatron Core implementation. The diagrams and numbers are original synthetic examples. Fourteen local Node.js assertions checked their arithmetic and data layouts; no distributed, GPU, NCCL, network or LLM benchmark was executed.

Contents · six terms before the comparison

Rank: one participant in a communication group. This example maps one rank to one GPU on each of four hosts; a rank number is not inherently a physical GPU ordinal.
Collective: a group communication operation with a defined result and participation rules.
Chunk: a piece of a buffer assigned to a destination; not an LLM token by definition.
Data parallelism: replicas process different data and synchronize training information such as gradients.
Expert parallelism: different ranks hold different experts in a mixture-of-experts model.
Topology: how devices and links are connected; it determines which logical transfers share physical paths.

1. All-Reduce: combine values, then make the result available everywhere

In a sum All-Reduce, corresponding elements from each rank are added. Each rank receives the same resulting vector. NCCL also supports reductions such as minimum and maximum; the mathematical operation is part of the definition.

Inputs · one vector per rank
R0: [1, 2]
R1: [10, 20]
R2: [100, 200]
R3: [1000, 2000]

Result · on every rank
R0: [1111, 2222]
R1: [1111, 2222]
R2: [1111, 2222]
R3: [1111, 2222]

Original integer example, not a GPU trace. Addition changes the values. “Same result on all ranks” defines the outcome; the arrow does not prescribe a centralized server or a specific communication algorithm.

The NCCL collective definitions separate All-Reduce from Reduce, whose result is held at a selected root. They also explain that Reduce followed by Broadcast has the same collective outcome as All-Reduce. That does not mean an implementation must use that particular schedule.

Ring and tree algorithms can implement the same mathematical operation with different communication schedules. Real floating-point sums can also depend on accumulation order, so the exact integer illustration is not a promise of bitwise reproducibility across implementations.

2. All-to-All: route each chunk to its designated rank

For the equal-chunk All-to-All in the NCCL documentation, each rank starts with one chunk for each destination. Destination Rj receives the j-th chunk from every source. The operation exchanges data; it does not sum those chunks into one shared vector.

Before · source rows
R0: A0, A1, A2, A3
R1: B0, B1, B2, B3
R2: C0, C1, C2, C3
R3: D0, D1, D2, D3

After · destination groups
R0: A0, B0, C0, D0
R1: A1, B1, C1, D1
R2: A2, B2, C2, D2
R3: A3, B3, C3, D3

Original label-only example. Letters identify sources; digits identify destinations. All 16 labels are preserved exactly once. The self-destined chunks A0, B1, C2 and D3 stay local in this model. These labels are not measured token traffic.

This resembles rearranging rows into destination columns. It differs from All-Gather, where all participants receive the collection of everybody's input. The word “all” does not mean that every rank receives the same data in every collective.

Nor does All-to-All require every pair to transmit at the same instant. The logical exchange and the implementation's schedule are separate. Real routed workloads can have unequal destination sizes, packing, padding and metadata; they are not automatically the balanced four-by-four example above.

3. Why gradient synchronization and expert routing create different traffic

Data-parallel training: replicas need to coordinate their gradients. PyTorch DistributedDataParallel documents gradient synchronization and gradient All-Reduce. The communication group and tensor sizes matter; the operation does not mean every worker sends all its weights to a central machine for every step.

Expert-parallel MoE: a router assigns token activations to experts held by different ranks. Activations must reach the selected experts, and expert results must be returned and combined. That creates a dispatch-and-return problem. It is not the same operation as summing corresponding gradient entries across replicas.

The public Megatron Core token dispatcher includes an All-to-All-based path with an expert-parallel dispatch exchange and a later combine exchange. It also includes an All-Gather-based dispatcher. MoE therefore does not imply that every engine or configuration must use exactly the same All-to-All implementation. The observed source is a moving main branch, not a benchmark or a fixed release claim.

The DeepSpeed MoE tutorial similarly defines an expert-parallel group and shows how its ranks distribute the experts. Expert count, expert-parallel group size and the selected routing policy describe different aspects of the model.

For an All-to-All-based expert path, the communication burden depends on activation width, precision, token assignments, how many selected experts are remote, placement and return traffic. Skewed assignments can make some ranks receive more work than others. Transport performance and expert compute balance both matter; one global average can hide the rank that finishes last.

Moving activations to resident experts is also different from offloading expert weights between memory tiers. The earlier MoE memory and expert-offloading analysis covers that separate capacity-and-timing question. This article focuses on communication semantics and traffic accounting.

4. A four-rank traffic example: count what actually crosses a rank boundary

Assume four ranks on four different hosts. For each operation, every rank starts with a total input buffer of 64 MiB, where 1 MiB is 1,048,576 bytes. Count outbound payload at its source once. Exclude protocol headers, retries, padding, metadata, extra MoE exchanges and any replication beyond the stated algorithm.

Illustrative ring All-Reduce: a Reduce-Scatter phase followed by an All-Gather phase gives an outbound payload factor of 2 × (n − 1) ÷ n. With n = 4, that is 1.5 × 64 MiB = 96 MiB sent per rank. This is the stated ring accounting model, not an observed NIC counter.

Uniform one-way All-to-All exchange: divide 64 MiB into four 16 MiB chunks. Keep one chunk locally and send the other three to the other ranks. That gives 48 MiB sent per rank. The factor is (n − 1) ÷ n = 0.75 for this uniform model.

Measure	Value
Ranks / hosts	4 / 4
Input per rank	64 MiB
Equal chunk	16 MiB
Ring sends per rank	96 MiB
Exchange sends per rank	48 MiB
Local exchange chunk	16 MiB

Summing source-side sends across the four ranks gives 384 MiB for the ring example and 192 MiB for the single exchange. Do not add receiver copies again and call that the same measure. These are logical directed payload counts; they do not count every switch hop or the physical link bytes along a multi-hop route.

Why this does not predict a winner

The two operations have different outputs and cannot replace one another. The smaller byte count does not prove half the completion time. The MoE example also needs a later return/combine exchange, which the single All-to-All row does not include. Different placement, message sizes, routing imbalance and overlap change the actual job.

The nccl-tests performance notes use operation-dependent factors to derive bus bandwidth from algorithm bandwidth. That derived column is not a direct measurement of every physical link. Compare the collective, ranks, size definition and column definition before comparing two reported GB/s numbers.

5. Topology changes where the pressure lands

A logical rank pair does not uniquely identify a physical route. Two GPUs may communicate within a host, through host interconnects or across a network. In the example above, one rank per host deliberately makes every inter-rank transfer remote; grouping multiple ranks inside a host changes that accounting boundary.

A ring schedule can create relatively regular neighbor exchanges, while a destination exchange can spread traffic across many logical peers. Neither description proves how much traffic each physical uplink carries. Routes can share links, and limited capacity across a partition of the fabric can constrain traffic even when individual NIC ports have high advertised rates.

Both collectives can be affected by congestion and slow participants. With routed experts, look at per-destination counts and expert compute time as well as network averages. With gradient synchronization, look at message sizes, group membership, timing relative to compute and the final completion time. The operation name identifies the required result; it does not identify the bottleneck by itself.

6. What an AI infrastructure comparison should report

The workload: training gradient synchronization, expert dispatch, expert return or another communication stage; name the actual collective and reduction operation where relevant.
The group: ranks, GPUs per host and how data, tensor and expert parallel groups map to the machines. A job may use several types of collective.
The payload: total buffer size versus per-peer chunk size, data type, actual routed counts, padding and whether one or both MoE exchanges are included.
The measurement: completion time and a clearly defined bandwidth column; include repeated-run variation and the slow ranks rather than only a peak average.
The outcome: end-to-end training or serving behavior with compute and communication together. Do not translate a collective GB/s score directly into tokens per second, model quality or a supplier's revenue.

For a socket-level diagnostic, the related iperf3 bandwidth tutorial explains why TCP payload rate is a different measurement. A communication microbenchmark and an LLM serving test answer different questions too.

The practical infrastructure conclusion is to procure and tune against the traffic your workload produces. NIC rate alone cannot show whether GPUs will wait for a collective, whether expert assignments will be balanced or whether a different fabric pays for itself. Those decisions need measurements on the intended placement and workload.

Appendix · execution, limitations and sources

Actually executed: Node.js v24.14.1 on Windows; 14 local assertions checked integer elementwise sums, replicated outputs, the four-by-four chunk transpose, label conservation and the payload arithmetic. Not executed: distributed processes, NCCL, CUDA, RDMA, NIC tests, model training, inference or paid LLM calls. No hardware benchmark, system setting, authentication or cloud resource was changed.

The four-rank inputs, labels and 64 MiB assumption are educational choices. No real model, GPU, interconnect or vendor performance number is assigned to them. The examples do not determine memory orders, GPU shipments, a stock-price outlook or an investment recommendation.

NVIDIA NCCL 2.32.3: Collective Operations — All-Reduce, Reduce, All-Gather, Reduce-Scatter and equal-chunk All-to-All semantics.
PyTorch 2.14: DistributedDataParallel — replica gradient synchronization and gradient All-Reduce.
NVIDIA Megatron-LM: MoE token dispatcher implementation — All-to-All dispatch/combine path and an alternative All-Gather path; moving source checked October 26, 2026.
DeepSpeed: Mixture of Experts — expert-parallel group and expert distribution.
NVIDIA nccl-tests: Performance — algorithm and operation-adjusted bus bandwidth; moving source checked October 26, 2026.

iperf3 Tutorial: Network Bandwidth Is Not LLM Throughput

2026-10-25T19:10:43.079+09:00

iperf3 measures data transferred between two test endpoints. It does not measure LLM tokens per second. Start with one forward TCP stream, preserve the receiver result and its units, and record the path and test conditions. A fast socket test can help diagnose a network path; it cannot establish RDMA, GPU collective or model-serving performance.

Quick check before a test

If the number looks eight times too large, check Mb/s versus MB/s first. If the client cannot connect, confirm the agreed server address, listener and narrow network access with its owner; do not disable the firewall. Run a short, rate-limited test only between endpoints you control and are authorized to load.

Documentation checked October 25, 2026, Korea time. The network commands below were not executed: this Windows PC did not have iperf3 on PATH, and no remote test endpoints were approved. The Python parser was actually executed on a hand-written synthetic fixture using CPython 3.14.3. No network, GPU, NCCL or LLM benchmark was run.

Contents and the terms you need

Scope: bandwidth is a capacity or rate with a defined scope; throughput is work actually completed per unit time.
Endpoints: the client starts a test; the server accepts it. Their names do not fix the data direction.
Direction: forward sends client to server; reverse sends server to client; bidirectional loads both simultaneously.
Units: Mb/s means decimal megabits per second; MB/s means decimal megabytes per second. One byte is eight bits.
Receiver result: bytes received divided by the receiver's elapsed interval, converted to the chosen unit.
Next layer: RDMA is a different data-transfer path; NCCL implements GPU collectives; LLM throughput counts completed model work under a stated workload.

1. Choose the measurement that answers your question

A port's advertised line rate, a TCP application's payload rate and generated tokens per second describe different things. iperf3 sends generated traffic between hosts. Its TCP receiver result excludes the Ethernet framing overhead from the payload byte count and reflects the tested hosts, route, operating system and socket behavior.

1 · Socket path
iperf3 TCP payload
Mb/s or Gb/s, one stated direction

2 · GPU communication
RDMA or NCCL tests on the actual setup
Operation time and explicitly defined bandwidth

3 · LLM service
Model, prompts, concurrency and latency targets
Tokens/s, TTFT, E2EL and SLO attainment

Original explanatory diagram. These are separate tests, not a chain of unit conversions. A TCP test does not certify the two layers below it.

For a model-serving measurement, record model and engine versions, input/output lengths, concurrency, cache policy, errors and the measurement window. For definitions, use the existing LLM inference metrics guide. The question here is narrower: how do you obtain and read a controlled network result?

2. Run a short forward TCP test on approved Linux endpoints

The commands use the ESnet iperf3 manual, which identified itself as version 3.22 when checked. Use an organization-approved Linux installation on both machines, and record the output of iperf3 --version on each. Check local help for these options before a run. This tutorial does not install a package or change network settings.

192.0.2.20 is a documentation address, not a public test server. Replace it with the agreed IP address actually assigned to your server. Confirm the intended NIC, route, existing TCP 5201 access and an acceptable load window. A rate cap still consumes real network resources.

Server B — one test, then exit (not executed here):

iperf3 --version
iperf3 -s -1 -B 192.0.2.20 -p 5201 \
  --idle-timeout 30 --server-max-duration 10

-B binds the listener to that local address. -1 accepts at most one client test and exits. The idle timeout avoids leaving the one-off listener waiting indefinitely. The duration limit rejects tests exceeding the server's allowed duration; it is not an access-control mechanism. Keep existing host and network access controls in place.

Client A — five seconds, one stream, 100 Mb/s target (not executed here):

iperf3 --version
iperf3 -c 192.0.2.20 -p 5201 -P 1 -t 5 -b 100M \
  --connect-timeout 3000 -J --logfile forward.json

TCP is the default protocol. -P 1 selects one stream; -t 5 requests a five-second test; -b 100M requests a 100,000,000-bit/s target. The actual receiver result can be lower. --connect-timeout 3000 limits the initial control connection wait to 3,000 milliseconds. -J writes JSON, saved here with --logfile.

This is a restrained smoke test, not a maximum-capacity benchmark. A 100 Mb/s cap cannot establish whether a 100 Gb/s path reaches its capacity. Extend duration or raise load only within the endpoint owner's approved test plan. Save errors and failed attempts rather than presenting a partial run as a valid result.

3. Keep forward, reverse and simultaneous tests separate

Mode	Data flow
Default	Client → server
`-R`	Server → client
`--bidir`	Both at once

For a later approved reverse test, restart the one-off server, add -R to the client command and use a new output filename. A bidirectional run uses --bidir instead and creates simultaneous contention. Do not silently add its two rates and compare that sum with a one-direction line rate. The Python reader below intentionally rejects reverse and bidirectional inputs.

Parallel streams also change the experiment. ESnet notes that -b is a per-stream limit when -P exceeds one. Four streams capped at 100M each are not a 100M aggregate test. Version matters too: iperf3 added one thread per stream starting with 3.16. A higher multi-stream result does not prove that the network alone changed.

4. Convert bytes and seconds without mixing bits and bytes

Use the receiver's summary interval and byte count from the same completed run. Do not divide its bytes by the requested duration if the reported receiver interval differs. Decimal conversions are:

bits per second = received bytes × 8 ÷ receiver seconds
Mb/s = bits per second ÷ 1,000,000
MB/s = received bytes ÷ receiver seconds ÷ 1,000,000

In the synthetic exercise below, 50,000,000 bytes in 5.0 seconds gives 80 Mb/s = 10 MB/s. The conversion changes the unit, not the speed. For binary units, divide bytes/s by 1,048,576 to obtain MiB/s; label that separately.

5. Read a forward JSON result in Python

Save the following as read_forward.py. It reads the receiver's end.sum_received summary and accepts only forward, single-stream TCP JSON with the expected fields. The official iperf3 output source uses start.test_start.bidir for the bidirectional flag. Missing fields or another mode require inspection of that version's output, not silently substituting a different summary.

import json
import math
import sys
from pathlib import Path


def receiver_rate(data):
    if "error" in data:
        raise ValueError("iperf3 reported an error; do not report a rate")
    test = data["start"]["test_start"]
    if (test["protocol"] != "TCP" or test["num_streams"] != 1
            or test["reverse"] != 0 or test["bidir"] != 0):
        raise ValueError("Expected forward TCP, one stream, no bidirectional test")
    result = data["end"]["sum_received"]
    size = result["bytes"]
    seconds = result["seconds"]
    if type(size) is not int or size < 0:
        raise ValueError("bytes must be a nonnegative integer")
    if (type(seconds) not in (int, float) or not math.isfinite(seconds)
            or seconds <= 0):
        raise ValueError("seconds must be finite and positive")
    return size * 8 / seconds, size / seconds


if __name__ == "__main__":
    try:
        data = json.loads(Path(sys.argv[1]).read_text(encoding="utf-8-sig"))
        bits, bytes_per_sec = receiver_rate(data)
    except (IndexError, OSError, ValueError, KeyError, TypeError) as error:
        raise SystemExit(f"No result: {error}")
    print(f"Receiver: {bits / 1e6:.3f} Mb/s = {bytes_per_sec / 1e6:.3f} MB/s")
    print("Forward TCP payload only; not wire rate, RDMA, GPU or LLM throughput.")

The reader uses Python's standard library only. It is a deliberately narrow example, not a validator for every iperf3 version or JSON mode. Keep the original JSON and version alongside the number. --json-stream produces a different output shape and is outside this example.

Runnable synthetic input: save this as synthetic-forward.json. It is a hand-written subset for teaching the parser, not captured iperf3 output.

{
  "_notice": "HAND-WRITTEN SYNTHETIC SUBSET, not captured iperf3 output",
  "start": {
    "test_start": {"protocol": "TCP", "num_streams": 1, "reverse": 0, "bidir": 0}
  },
  "end": {"sum_received": {"bytes": 50000000, "seconds": 5.0}}
}

python read_forward.py synthetic-forward.json

Actually observed local output:

Receiver: 80.000 Mb/s = 10.000 MB/s
Forward TCP payload only; not wire rate, RDMA, GPU or LLM throughput.

Executed on Windows with CPython 3.14.3. Seven local test methods passed, covering the conversion, zero bytes, an explicit error, other modes, invalid time/byte fields and a missing summary. This checks parsing and arithmetic; it supplies no evidence of network speed. After an authorized real forward test completes, run python read_forward.py forward.json against its saved file.

6. Interpret a result before changing the system

Connection failure: confirm the correct server IP, that its one-off listener is still waiting, the matching port and the intended route. Ask the owner to check narrowly scoped access. Do not disable security controls or repeatedly hit an unapproved endpoint.
A low number: first inspect the target rate, direction, stream count, test version, CPU load, route, competing traffic and test duration. A cap or host limitation is not evidence of a defective link.
A high number but slow AI work: use the actual GPU/RDMA path and application test next. iperf3's TCP socket traffic does not establish RDMA health, collective communication time, token latency or inference capacity.
Comparing two runs: hold endpoints, direction, protocol, stream count, load cap, duration and background conditions constant. Preserve both sender and receiver summaries and failure records; state which rate you report.

NCCL tests distinguish algorithm bandwidth from a formula-derived bus bandwidth, with the formula depending on the collective. Those columns are not interchangeable with iperf3's socket payload rate. Likewise, LLM SLO Goodput needs actual request-level latency and success criteria. The related Python guide to p50, p95 and SLO Goodput from request logs shows that next step without pretending a network test generated tokens.

7. Keep a reproducible test record

Record date and time zone; both iperf3 versions and operating systems; approved endpoint names; NIC and route; TCP/UDP; direction; stream count; target bitrate; requested and observed durations; receiver bytes/rate; sender summary; errors; CPU load and competing traffic. Keep internal addresses and topology out of a public report unless cleared for disclosure.

The useful conclusion is precise: “This forward TCP test achieved X Mb/s of receiver payload under these conditions.” Claims about RDMA, GPU collectives or LLM serving need their own measurements.

Appendix · environment and sources

Executed: local Python JSON parsing and synthetic arithmetic, CPython 3.14.3 on Windows. Not executed: all iperf3 commands, Linux server setup, RDMA/NCCL/GPU/LLM tests. No packages, firewall rules, NIC settings or cloud resources were changed. ESnet's FAQ states that native Windows iperf3 is not officially supported; this guide therefore does not present an unverified Windows binary as an equivalent tested environment.

ESnet: Invoking iperf3 — command options, rate limits, directions and JSON output; page labeled 3.22 when checked.
ESnet: iperf3 FAQ — Windows support and the 3.16 threading change.
ESnet: iperf3 output implementation — JSON field names; moving master source checked October 25, 2026, not a promise about every installed build.
NVIDIA nccl-tests: Performance — algorithm and bus bandwidth definitions.
Python 3.14: JSON — standard-library decoding and invalid JSON errors.

AI 네트워크 Ethernet vs InfiniBand, 포트 속도만으로 고르면 안 되는 이유

2026-10-25T06:37:46.414+09:00

AI 네트워크에서 Ethernet과 InfiniBand의 우열은 포트 속도 하나로 정해지지 않습니다. 같은 GPU 수와 통신 패턴에서 RDMA 경로, 혼잡할 때의 지연, 소프트웨어·운영 조건을 함께 비교해야 합니다. Ethernet도 RoCE로 RDMA를 사용할 수 있으므로, ‘Ethernet은 TCP, InfiniBand만 RDMA’라는 구분부터 바로잡는 것이 출발점입니다.

먼저 확인할 질문 세 가지

시간을 잡아먹는 것이 큰 데이터의 집단 통신인가, 자주 반복되는 작은 메시지인가?
한 작업만 돌릴 때가 아니라 여러 작업이 겹쳐도 지연과 처리량이 유지되는가?
기존 NIC·스위치·드라이버·운영 인력으로 해당 구성을 검증하고 유지할 수 있는가?

확인일: 2026-10-25 KST. NCCL 2.32.3 문서, NVIDIA DOCA 3.4.0 보관 문서와 공식 네트워킹 자료를 기준으로 작성했습니다. 아래 수치는 모두 가상 조건의 산술 예시입니다. 실제 네트워크·GPU·LLM 벤치마크나 유료 API는 실행하지 않았습니다.

목차와 한 줄 정의

Ethernet·InfiniBand·RDMA: 네트워크와 메모리 전송 방식을 같은 층위로 섞지 않습니다.
통신 패턴과 혼잡: 평균 대역폭과 늦게 끝나는 작업을 나눠 봅니다.
Scale-up과 scale-out: 어느 장치 사이의 경로를 비교하는지 먼저 정합니다.
200→400Gb/s 가상 계산: 통신만 빨라진 경우 전체 작업 시간의 변화를 계산합니다.
선택 기준과 사업 해석: 실효 성능·운영 비용·검증 조건을 함께 묻습니다.
요약·Appendix·출처: 실제 실행 범위와 비교의 한계를 확인합니다.

1. Ethernet과 RDMA는 반대말이 아니다

Ethernet과 InfiniBand는 서로 다른 네트워크 기술·생태계입니다. RDMA(Remote Direct Memory Access)는 원격 시스템의 메모리를 이용하는 데이터 전송 방식으로, 적절한 하드웨어·소프트웨어 지원 아래 전송 과정의 CPU 부담을 줄일 수 있습니다. 그렇다고 애플리케이션의 CPU 작업이나 초기 연결 과정까지 모두 사라진다는 뜻은 아닙니다.

RoCE는 Ethernet에서 RDMA를 사용하는 방식입니다. RoCEv2는 RDMA 트래픽을 UDP/IP 패킷으로 감싸 IP 라우터를 지날 수 있게 합니다. TCP 소켓 전송과 같은 경로로 취급해서는 안 됩니다. 다만 Ethernet 포트가 있다는 사실만으로 RoCE 구성과 애플리케이션의 RDMA 사용까지 검증되는 것은 아닙니다. NIC·드라이버·경로·설정이 맞아야 합니다. NVIDIA DOCA 3.4.0 RoCE 설명

InfiniBand에도 운영 조건이 있습니다. NCCL의 문제 해결 문서는 InfiniBand 패브릭에서 Subnet Manager가 동작하는지, 포트의 링크 계층·속도·활성 상태가 기대한 구성과 맞는지 확인하도록 안내합니다. 따라서 ‘한쪽은 연결만 하면 되고 다른 쪽만 설정이 복잡하다’는 이분법도 실제 도입 판단에는 부족합니다.

2. 같은 Gb/s라도 작업이 보내는 메시지는 다르다

AllReduce는 여러 rank의 값을 합산하는 등의 연산을 수행하고 결과를 각 rank가 받는 집단 통신입니다. AllGather는 각 rank의 데이터를 모아 모두에게 전달하고, AlltoAll은 각 rank가 상대별로 다른 데이터를 교환합니다. 여기서 rank는 통신에 참여하는 논리적인 참여자 번호이지, 항상 물리 서버 한 대를 뜻하지는 않습니다. NCCL 2.32.3 집단 통신 정의

큰 메시지를 길게 보내는 구간과 작은 메시지를 자주 주고받는 구간은 대역폭·시작 지연의 영향을 다르게 받습니다. 통신 대상이 고르게 나뉘는지, 특정 링크나 목적지로 몰리는지도 비교 질문입니다. 모델명만 같다고 통신이 같은 것은 아닙니다. 병렬화 방식, GPU 수, 배치와 메시지 크기가 달라지면 네트워크가 담당하는 일이 바뀝니다.

혼잡 조건의 지연도 따로 봐야 합니다. 평균은 양호해도 일부 통신이 늦어지면, 해당 통신 결과를 기다리는 단계의 종료 시점에 영향을 줄 수 있습니다. p95는 관측값의 95번째 백분위수이며 ms 같은 시간 단위로 표시합니다. 무엇의 p95인지도 중요합니다. 포인트투포인트 전송 지연, 집단 통신 완료 시간, 전체 요청 지연은 서로 다른 측정 대상입니다.

NCCL 문서는 대역폭이 정상처럼 보여도 꼬리 지연이 나쁠 수 있다고 설명합니다. RoCE에서는 환경이 제공하는 PFC·ECN·CNP·큐 드롭 카운터 등을 지연 변화와 함께 살펴보도록 안내합니다. 각각 흐름 제어·혼잡 표시·혼잡 통지·큐 손실을 해석할 단서입니다. 이는 관측과 원인 확인의 순서이지, 모든 Ethernet에 같은 설정을 일괄 적용하라는 지침이 아닙니다. 이 글은 PFC·방화벽·운영 설정을 변경하지 않습니다. NCCL 네트워킹 문제 해결

3. Scale-up과 scale-out의 경계를 먼저 그린다

Scale-up은 긴밀하게 연결된 가속기 자원의 영역을 확장하는 맥락, scale-out은 여러 노드·시스템을 네트워크로 연결해 확장하는 맥락에서 쓰입니다. 단, 두 용어를 ‘무조건 서버 내부’와 ‘무조건 서버 외부’로만 고정하면 실제 제품 설계를 놓칠 수 있습니다. 비교할 때는 논리적 통신 영역과 물리 경로를 함께 적어야 합니다.

NVIDIA가 소개하는 네트워킹 구성에서는 NVLink를 scale-up, Quantum InfiniBand와 Spectrum-X Ethernet을 scale-out에 배치합니다. 이 설명은 해당 플랫폼의 역할 구분이지, 모든 업체의 Ethernet이 scale-out 전용이라는 증거는 아닙니다. 서버 간 NIC 포트 속도를 비교하면서 다른 GPU 연결 영역의 대역폭을 같은 분모에 넣지 않는 것이 핵심입니다. NVIDIA 공식 네트워킹 구성

제품 순위가 아닌 비교 순서

① 통신 영역을 지정

어느 GPU·rank·노드 사이인가?

실제 경로가 비교 대상인가?

↓ 같은 영역·조건을 고정

② 전송 경로와 부하를 지정

InfiniBand / Ethernet의 RoCE 또는 소켓 경로

메시지 크기 · 동시 작업 · 혼잡 조건

↓ 작업이 기다리는 구간을 측정

③ 애플리케이션 지표로 검증

학습 step 시간 또는 추론 요청 지연

평균뿐 아니라 p95 · 오류 · 재현 조건

자체 제작 판단 도식입니다. 실제 배선도·측정 결과·제품 간 성능 순위가 아닙니다. 네트워크 경로의 개선과 전체 애플리케이션의 개선을 따로 검증하는 순서를 나타냅니다.

현재 장비의 연결부터 읽고 싶다면 같은 언어의 GPU·PCIe 토폴로지와 SYS·PIX·NUMA를 해석하는 실습이 출발점입니다. 토폴로지를 확인한 것과 실제 RDMA 성능을 측정한 것은 여전히 다른 단계입니다.

4. 링크가 두 배 빨라져도 전체 작업은 두 배가 아니다

가상 조건을 정해 보겠습니다. 8개 rank가 하나의 균일한 링에서 AllReduce를 수행하고, rank마다 입력 메시지는 512MiB라고 가정합니다. 각 rank의 송신 링크를 200Gb/s 또는 400Gb/s로 놓습니다. 이는 Ethernet과 InfiniBand에 각각 붙인 수치가 아니며, 특정 NIC·스위치의 측정값도 아닙니다.

이 단순 링 모델의 rank당 송신량은 메시지 바이트 × 2 × (rank 수 − 1) ÷ rank 수로 계산합니다. 8개 rank이면 계수는 1.75이므로 512MiB × 1.75 = 896MiB입니다. rank 하나의 송신량이며 송신·수신을 더한 값이나 클러스터 전체 합계가 아닙니다. NCCL tests 문서도 AllReduce의 대역폭 해석에 같은 2(n−1)/n 계수를 사용하지만, 실제 알고리즘·토폴로지의 실행 결과를 이 식만으로 예측해서는 안 됩니다. NCCL tests 성능 지표 설명

단위는 1MiB = 1,048,576바이트, 1Gb/s = 10억 비트/초입니다. 8비트 = 1바이트이므로 200Gb/s는 25GB/s, 400Gb/s는 50GB/s입니다. 여기서는 명목 링크 속도를 전부 데이터 전송에 쓸 수 있다고 가정하며, 헤더·시작 지연·혼잡·재전송·다른 공유 부하는 모두 제외합니다. 현실보다 낙관적인 산술 모델입니다.

가상 조건	계산 결과
200Gb/s 896MiB 송신	통신 약 37.58ms 고정 계산 80ms와 직렬 합: 117.58ms
400Gb/s 동일한 송신량	통신 약 18.79ms 고정 계산 80ms와 직렬 합: 98.79ms
전체 작업 비교	시간 약 15.98% 감소 처리 속도 약 1.19배

두 경우 모두 계산 시간 80ms는 같고, 계산과 통신이 겹치지 않는다고 가정했습니다. 그래서 통신 시간이 절반이 되어도 전체 시간은 절반이 되지 않습니다. 실제 작업은 통신·계산 중첩이나 다른 병목이 있어 결과가 달라질 수 있습니다. 이 계산을 LLM의 토큰 처리량이나 제품 우위로 바꿔 말할 수는 없습니다.

5. 무엇이 유리한지는 이 조건으로 비교한다

우선순위	양쪽 구성에 같은 질문
집단 통신이 긴 작업	같은 rank 수·메시지 크기·연산에서 완료 시간과 확장 효율이 어떤가?
지연에 민감한 작업	같은 요청 조건과 동시성에서 p95·오류·목표 충족률이 유지되는가?
여러 작업이 공유	단독 시험뿐 아니라 동시 작업·혼잡·링크 장애 조건에서 얼마나 흔들리는가?
도입·운영 비용	NIC·스위치·광케이블·운영 소프트웨어·인력·전환 시간까지 포함하면 어떤가?

기존 Ethernet 운영 경험과 장비를 활용할 수 있다는 점은 검토할 조건입니다. 하지만 기존 장비가 목표한 RoCE·혼잡 제어·패브릭 구성을 지원하는지 확인하기 전에는 ‘재사용하니 무조건 저렴하다’고 결론 낼 수 없습니다. InfiniBand도 지원하는 집단 통신 기능과 운영 도구를 실제 워크로드에서 검증해야 합니다. 어느 쪽이든 포트 가격 하나가 총비용은 아닙니다.

사업 관점에서도 Ethernet의 확대를 곧바로 특정 회사의 패배로 읽으면 단순화가 지나칩니다. NVIDIA는 공식 자료에서 Spectrum-X Ethernet과 Quantum InfiniBand를 모두 제공합니다. 제품군의 존재는 확인된 사실이지만, 어느 구성이 더 팔리거나 더 높은 이익을 낼지는 별도의 출하·매출·비용 자료가 필요한 질문입니다. 이 글은 시장점유율·매출 전망이나 투자 추천을 제시하지 않습니다.

6. 요약: 네트워크 이름보다 같은 작업의 완료 시간을 본다

Ethernet도 RDMA를 사용할 수 있고, InfiniBand도 구성과 운영 검증이 필요합니다. 먼저 통신 영역과 작업 패턴을 고정한 뒤, 혼잡 조건을 포함한 실효 성능과 운영 비용을 비교하는 것이 순서입니다. 네트워크 대역폭 결과를 GPU 연산 성능·LLM 처리량으로 바로 치환하지 마세요.

추론 서비스를 평가한다면 평균 처리량과 목표를 지킨 요청의 비율도 구분해야 합니다. 관련 한글 분석인 LLM Goodput과 SLO 충족률을 함께 읽는 법에서 애플리케이션 쪽 판단 기준을 이어 볼 수 있습니다.

Appendix. 계산·실행 여부와 비교의 한계

실제 실행: Windows x64·Node.js 24.14.1에서 가상 데이터의 단위 변환·송신량·시간 계산과 8개 assertion을 실행했습니다.
미실행: NIC·스위치·네트워크 트래픽 생성, NCCL tests, GPU·LLM 벤치마크입니다. 실제 하드웨어의 전송 속도나 두 네트워크의 승자를 측정한 글이 아닙니다.
버전·범위: NCCL 2.32.3, DOCA 3.4.0 보관 문서, NCCL tests upstream master 확인본을 사용했습니다. 보관·master 문서가 사용자의 설치 버전과 같다는 보장은 없습니다.
중단·보류 조건: 링크 계층·RDMA 사용 여부·메시지 크기·rank 수·동시성·오류 조건을 알 수 없으면 비교 불가로 남깁니다. 허가되지 않은 원격 서버 테스트나 보안·방화벽·드라이버 변경은 하지 않습니다.

출처 · 2026-10-25 KST 확인

NCCL 2.32.3 Collective Operations — 집단 통신과 rank별 의미.
NCCL 2.32.3 Networking Troubleshooting — 링크·대역폭·꼬리 지연·RoCE 혼잡 관측.
NVIDIA DOCA 3.4.0 RoCE — Ethernet RDMA와 RoCEv2 UDP/IP 구분.
NVIDIA nccl-tests PERFORMANCE.md — algbw와 집단 통신 보정 busbw. busbw는 하드웨어 카운터로 직접 잰 총 트래픽이 아니라 계산된 지표입니다.
NVIDIA Networking — NVLink·Spectrum-X Ethernet·Quantum InfiniBand의 제시 역할. 업체의 배수 성능 광고를 양쪽의 공정한 실측 비교로 인용하지 않았습니다.

GPU·PCIe 토폴로지 읽는 법: nvidia-smi의 SYS·PIX와 NUMA를 해석하기

2026-10-24T19:14:07.658+09:00

GPU가 느릴 때는 설정을 바꾸기 전에 nvidia-smi topo -m으로 GPU·NIC 사이의 경로를 보고, lspci의 PCI 트리와 numactl의 NUMA 노드 정보를 함께 확인하세요. SYS·PIX·NV#는 연결 경로의 종류이지 실측 GB/s나 성능 점수가 아닙니다. 토폴로지는 병목의 후보를 좁히는 지도이고, 병목을 확정하는 벤치마크는 아닙니다.

30초 확인: 증상별로 무엇부터 볼까?

GPU끼리 통신할 때만 느리다 → 해당 GPU 쌍의 topo -m 경로를 확인합니다. SYS라고 즉시 불량으로 판정하지 않습니다.
GPU로 데이터를 넣을 때 느리다 → GPU의 CPU·NUMA 친화도와 데이터 준비 프로세스의 위치를 비교할 단서를 모읍니다. 아직 CPU 바인딩은 바꾸지 않습니다.
VM·컨테이너에서 장치가 덜 보인다 → 현재 화면이 호스트 전체가 아닌 게스트·컨테이너의 관측 범위인지 확인합니다. 권한 확대나 보안 설정 해제부터 하지 않습니다.

적용 범위: NVIDIA 드라이버와 관련 도구가 준비된 Linux 서버의 읽기 전용 점검입니다. 문서 확인일은 2026-10-24 KST입니다. 실제 장비의 드라이버·도구 버전과 지원 옵션은 현장에서 확인해야 합니다. 이 글의 Linux 하드웨어 명령은 미실행이며, 아래 행렬과 도식은 설명용 가상 예시입니다.

목차와 한 줄 정의

토폴로지·PCIe·NUMA: 장치가 어디에 연결돼 있고 어느 CPU·메모리 노드와 가까운지 읽는 개념입니다.
읽기 전용 명령: 버전, 연결 행렬, PCI 트리, 노드 목록을 구분해 봅니다.
SYS·PIX 행렬 해석: 경로 기호와 친화도를 별도로 읽습니다.
서로 대조하기: 장치 주소와 관측 환경을 맞춥니다.
VM·컨테이너와 실패 조건: 보이지 않는 정보를 없는 하드웨어로 단정하지 않습니다.
요약·비교와 Appendix: 실행 여부와 다음 측정의 경계를 확인합니다.

1. GPU 번호보다 연결 경로를 먼저 읽는다

토폴로지(topology)는 GPU, 네트워크 카드(NIC), CPU, PCIe 브리지·스위치의 연결 구조입니다. GPU0과 GPU1이라는 번호가 붙었다고 같은 스위치 아래에 있거나 서로 가까운 것은 아닙니다. NVIDIA 문서는 GPU 열거 순서가 재부팅 사이에 유지된다고 보장하지 않으므로, 서로 다른 기록을 대조할 때는 번호만 믿지 말고 PCI 버스 주소 같은 식별 기준도 맞춰야 합니다.

PCIe는 장치 입출력 연결이고, NUMA는 프로세서가 접근하는 메모리의 위치에 따라 접근 특성이 달라지는 구조입니다. NUMA 노드 번호 0·1은 용량이나 속도의 단위가 아닌 식별자입니다. CPU Affinity의 0–15도 GHz가 아니라 논리 CPU 번호 범위입니다. 친화도 정보만으로 현재 스레드가 그 CPU에서 실행 중이거나 메모리가 그 노드에 배치됐다고 판단하면 안 됩니다. NVIDIA SMI 공식 문서

2. 먼저 조회만 한다: 네 가지 명령 묶음

아래는 Linux 셸에서 직접 실행할 때 사용할 문서 기반 예제입니다. 이 글을 작성한 Windows x64 환경에서는 PATH 검색으로 nvidia-smi·lspci·numactl 실행 파일을 찾지 못했습니다. 따라서 이 명령들의 성공 출력이나 GPU 드라이버 버전을 검증했다고 주장하지 않습니다. PATH에서 찾지 못했다는 사실 자체가 GPU가 없다는 증거도 아닙니다.

# 1) 환경과 도구 버전: 출력은 본인 장비에서 기록
uname -r
nvidia-smi --version
lspci --version
numactl --version

# 2) 설치된 nvidia-smi가 지원하는 topo 옵션 확인
nvidia-smi topo -h

# 3) GPU/NIC 경로와 친화도; NVLink를 제외한 PCI 경로와 비교
nvidia-smi topo -m
nvidia-smi topo -mp

# 4) PCI 장치 식별, 연결 트리, 사용 가능한 NUMA 노드
lspci -Dnn
lspci -t
numactl --hardware

topo -m은 GPU·NIC 연결 및 GPU의 CPU·메모리 친화도를 보여줍니다. topo -mp는 NVLink 연결을 제외한 PCI 연결 행렬이므로, 두 결과가 다른 이유를 해석할 때 유용합니다. 장치·OS·드라이버별 지원 차이가 있으므로 로컬 도움말에 없는 옵션이나 Not Supported 결과를 억지로 우회하지 마세요.

lspci -Dnn은 도메인을 포함한 PCI 주소, 장치 이름과 숫자 ID를 함께 확인하는 용도입니다. lspci -t는 버스·브리지·장치의 연결 트리를 보여줍니다. 둘 다 전송 속도 테스트가 아닙니다. numactl --hardware는 시스템에서 사용 가능한 NUMA 노드 정보를 보는 옵션이며, --membind 같은 배치 정책 변경과는 다릅니다. pciutils 설명서, numactl 설명서

3. SYS·PIX·NV#를 속도 순위표로 읽지 않는다

기호	경로를 읽는 뜻
X	장치 자기 자신입니다.
PIX / PXB	단일 / 여러 PCIe 스위치를 지나는 경로입니다. 호스트 브리지를 통과하지 않는 PXB의 조건도 구분합니다.
PHB / NODE	PCIe 호스트 브리지를 지나거나, 같은 NUMA 노드 안의 호스트 브리지 사이 연결을 지납니다.
SYS	PCIe뿐 아니라 NUMA 노드 사이의 SMP 인터커넥트도 지나는 경로입니다.
NV#	#개의 NVLink를 묶은 연결을 뜻합니다. #는 GB/s나 전체 서버 GPU 개수가 아닙니다.

NVIDIA 문서의 topo -m 범례를 요약한 표입니다. 제품 세대별 링크 특성, 링크 공유, 실제 전송 방식과 부하가 다르므로 PIX는 항상 빠르고 SYS는 항상 느리다는 식의 절대 순위를 만들 수 없습니다. NV4가 보인다는 사실만으로 애플리케이션이 그 경로를 쓰거나 GPU 메모리가 자동으로 하나로 합쳐진다고도 결론 내리지 않습니다.

다음 행렬은 설명을 위해 만든 가상 예시이며 실제 nvidia-smi 출력이 아닙니다. 장치·열 일부를 줄였습니다. 가상의 GPU0은 NUMA 0, GPU1은 NUMA 1 쪽이며, NIC0은 GPU0과 단일 스위치 경로를 공유한다고 가정합니다.

# 설명용 가상 행렬 · 측정값 아님
       GPU0 GPU1 NIC0  CPU Affinity  NUMA Affinity
GPU0    X   SYS  PIX   0-15          0
GPU1   SYS   X   SYS   16-31         1
NIC0   PIX  SYS   X

가상 연결 지도 — 실행 결과 아님

NUMA 노드 0

논리 CPU 0–15 · 로컬 메모리

PCIe 스위치 아래 GPU0 ↔ NIC0

행렬에서 GPU0–NIC0: PIX

↕ 노드 사이 인터커넥트를 지나는 경로

NUMA 노드 1

논리 CPU 16–31 · 로컬 메모리

이 노드 쪽 PCIe에 연결된 GPU1

행렬에서 GPU0–GPU1: SYS

자체 제작 개념도. 가상의 경로를 단순화했으며 실제 서버 배선도·거리 비례 그림·대역폭 차트가 아닙니다. 모든 서버의 NUMA 구성이 이와 같다는 뜻도 아닙니다.

여기서 확실히 읽을 수 있는 것은 GPU0–GPU1과 GPU0–NIC0의 경로 분류가 다르다는 점입니다. 아직 알 수 없는 것은 몇 GB/s가 나오는지, 현재 통신량이 얼마인지, 지연의 원인이 그 경로인지입니다. NUMA 0이 표시돼도 데이터 로더의 실행 CPU와 실제 메모리 배치는 별도 관측 대상입니다.

4. 재현 기록은 장치·환경·구간을 맞춰 남긴다

환경을 먼저 적습니다. 호스트인지 VM인지 컨테이너인지, Linux 커널과 NVIDIA 드라이버·도구 버전을 기록합니다. 같은 모델의 GPU여도 관측 범위가 다르면 결과를 직접 비교하기 어렵습니다.
GPU와 PCI 주소를 대조합니다. nvidia-smi 기본 화면의 Bus-Id와 lspci -Dnn의 해당 장치 주소를 맞춥니다. 도메인 등의 0 채움 형식이 다를 수 있습니다. GPU 번호와 PCI 버스 번호를 같은 번호로 취급하지 않습니다.
문제가 생기는 장치 쌍만 골라 읽습니다. GPU 간 작업이면 GPU–GPU, 네트워크 데이터 이동이면 GPU–NIC 경로와 CPU·NUMA 친화도를 확인합니다. NIC가 행렬에 보인다고 애플리케이션의 RDMA 동작까지 검증된 것은 아닙니다.
그다음 측정 질문을 만듭니다. 같은 입력·동시성·전송 크기에서 시간이 어디에 쓰이는지 확인할 계획을 세웁니다. 이 글은 성능 측정이나 NUMA 바인딩 변경을 수행하지 않습니다.

공유할 때는 조직명·호스트명·GPU UUID·일련번호·네트워크 주소 등 식별 정보를 제거하세요. 비교에 필요한 장치 대응표는 내부에서 일관되게 익명화하면 됩니다. 전체 시스템 덤프를 공개 게시판에 그대로 올릴 필요는 없습니다.

5. VM에서 안 보인다고 연결이 없다고 단정하지 않는다

NCCL 2.32.3 문서는 GPU와 네트워크 카드의 PCI 토폴로지 탐색에 /sys를 사용하며, VM·컨테이너가 가상 PCI 토폴로지를 노출하면 성능에 영향을 줄 수 있다고 설명합니다. 게스트에서 보이는 트리를 호스트의 전체 물리 배선도라고 가정하지 마세요. 필요한 호스트 측 정보는 운영 담당자에게 읽기 전용으로 확인을 요청합니다. NVIDIA NCCL GPU 문제 해결 문서

관측 결과	안전한 다음 행동
command not found	현재 PATH·컨테이너 이미지·관리되는 도구 위치를 확인합니다. 드라이버부터 새로 설치하지 않습니다.
N/A / Not Supported	모델·드라이버·OS 지원과 관측 범위를 기록합니다. 0이나 미연결로 바꾸어 해석하지 않습니다.
NIC 누락 / access denied	권한 때문에 일부 sysfs 정보가 제한될 수 있습니다. 제한 자체를 기록하고 관리자에게 조회를 요청합니다.
SYS가 보임	장치 쌍과 작업의 실제 데이터 이동을 대조할 후보로 남깁니다. 설정 오류나 확정 병목으로 단정하지 않습니다.

하지 않는 것: 진단을 위해 ACS·IOMMU를 끄거나, 컨테이너에 광범위한 권한을 주거나, 드라이버·BIOS·CPU 바인딩을 변경하지 않습니다. 읽기 명령이라도 모든 옵션이 같은 위험도를 갖지는 않습니다. pciutils 설명서는 일부 장치가 전체 설정 공간 읽기에서 문제를 일으킬 수 있다고 경고하므로, 이 입문 절차에는 lspci -xxx·-xxxx 덤프를 넣지 않았습니다.

6. 요약: 지도 → 관측 질문 → 별도 성능 측정

topo -m은 경로와 친화도, lspci는 PCI 장치·트리, numactl --hardware는 NUMA 노드 정보를 보는 데 씁니다. 세 가지를 맞춰 보면 무엇을 측정해야 할지는 명확해지지만, 병목의 원인이나 처리량이 자동으로 확정되지는 않습니다.

GPU 메모리 사용량 문제와 연결 경로 문제도 구분해야 합니다. 메모리가 부족하다면 같은 언어의 실습 글인 CUDA allocated·reserved·peak 로그를 읽는 법에서 사용량 기준 구간부터 확인할 수 있습니다. 그 수치만으로 PCIe 통신 병목을 판단할 수는 없습니다.

Appendix. 실제로 확인한 것과 아직 확인하지 않은 것

실제 확인: Windows x64, Node.js 24.14.1 환경에서 where.exe로 세 실행 파일의 PATH 검색을 수행했습니다. 세 검색 모두 종료 코드 1이었으며 실행 파일 경로를 찾지 못했습니다.
문서 검증: NVIDIA SMI 옵션·범례, NCCL 2.32.3의 /sys·가상화 주의, pciutils·numactl upstream master 설명서를 2026-10-24에 확인했습니다. master 문서는 고정 릴리스의 실행 보증이 아닙니다.
미실행: Linux 명령 묶음, GPU·NIC 행렬 수집, P2P·PCIe·NUMA 성능 측정입니다. 가상 행렬·자체 도식은 실제 로그가 아닙니다.
실패·중단 조건: 명령 미설치, 지원되지 않는 옵션, 권한 제한, 가상화에 따른 정보 누락은 미확인으로 남깁니다. 해당 정보를 얻으려고 운영·보안 설정을 바꾸지 않습니다.

출처와 확인 기준

NVIDIA System Management Interface — topo -m/-mp, 범례, 버전·장치 식별과 지원 제한.
pciutils 공식 저장소의 lspci 설명서 — 트리·도메인·숫자 ID와 설정 공간 덤프 주의.
numactl 공식 저장소의 설명서 — --hardware 조회와 정책 설정의 구분.
NCCL 2.32.3 GPU troubleshooting — 토폴로지 탐색, VM·컨테이너 관측 범위.

작성·확인: 2026-10-24 KST. 도구 출력 형식은 버전에 따라 달라질 수 있습니다. 이 글은 읽기 전용 진단 입문이며, 실제 장비에서 실행한 벤치마크나 성능 개선 보장이 아닙니다.

PCIe, NVLink and CXL: Why More Memory Is Not Always More GPU Memory

2026-10-24T06:39:47.568+09:00

PCIe, NVLink and CXL are not interchangeable ways to add GPU memory. PCIe commonly carries device I/O; NVLink connects supported processors through product-specific paths; CXL adds memory and cache-coherency protocols over a PCIe-derived physical interface. More addressable capacity does not automatically become local HBM, or deliver HBM-like access time.

The useful question is not simply “Which connection is fastest?” It is which processor is accessing which memory, over what route, with what software support? A capacity number without that route can be misleading when planning AI infrastructure.

Quick check: before accepting “more AI memory,” label the requesting processor, the memory’s physical location, the link/protocol, and the supported access mechanism. If any field is missing, do not count the capacity as interchangeable GPU HBM.

Documentation checked October 24, 2026, KST. This is a source-based architecture explanation with original synthetic arithmetic—not a GPU, PCIe, CXL, CUDA or inference benchmark. Product examples are deliberately named and version-scoped.

For the performance context, see why more GPU FLOPS need not speed up LLM decoding. For the separate capacity accounting, see the GPU-side HBM4 versus CPU-side SOCAMM2 explanation.

1. Define the connection before comparing it

PCIe: PCI Express, a general-purpose high-speed interconnect commonly used for GPUs, network interfaces and NVMe storage.
NVLink / NVLink Switch: NVIDIA interconnect technology and switching for supported processor configurations; the GPU scale-up fabric is one important use.
NVLink-C2C: a distinct chip-to-chip connection; Grace Hopper is a concrete coherent CPU–GPU example.
CXL: Compute Express Link, an interconnect with I/O, caching and memory-access protocols; available features depend on generation and device type.
Coherence: rules that keep participating cached views of memory consistent. It is not a bandwidth guarantee or a promise that all memory is equally close.
Capacity / bandwidth / latency: respectively how much fits, how much data moves per second, and how long an operation takes. State GB or GiB, GB/s or GiB/s, and the latency endpoint.

2. PCIe connects devices; the slot does not define memory semantics

A server can use PCIe for several different jobs: communicating with an accelerator, reaching a network adapter, or accessing NVMe storage. That does not make the attached device’s memory or storage a single interchangeable pool.

For a concrete product boundary, NVIDIA’s DGX H100/H200 guide documents a system with PCIe-generation CPU I/O, GPUs, NVSwitch, network cards, SSDs and system DIMMs. It includes a product topology diagram precisely because the installed route matters; the components coexist rather than replacing one another.

A PCIe device can expose memory windows, perform transfers, or support peer access under the right conditions. But “it plugs into PCIe” alone does not establish coherent CPU–GPU shared memory, a direct GPU-to-device route, or the effective bandwidth of an application. A root complex, switch, CPU-socket boundary, permissions and software support can change the usable path.

3. GPU-to-GPU NVLink is a scale-up path, not new HBM chips

NVIDIA’s NVLink documentation describes GPU-to-GPU communication through links and NVLink Switch. Keep the platform generation attached to its claims: Hopper, Blackwell and Vera Rubin are not one identical topology or link configuration.

Peer access and communication can let software work with data held by another supported GPU. They do not physically enlarge the HBM attached to the requesting GPU. Nor does a connected multi-GPU system automatically make an application’s allocations, scheduling or communication costs disappear.

For infrastructure planning, separate local memory capacity, peer-access capability and the framework’s actual placement strategy. A workload may benefit greatly from the fabric and still spend time communicating or moving data between owners. This is why a rack-wide aggregate bandwidth headline is not a per-request memory-speed measurement.

4. NVLink-C2C connects a different pair of endpoints

The GH200 Grace Hopper Superchip combines a Grace CPU and Hopper GPU using NVLink-C2C. NVIDIA documents a coherent CPU–GPU memory model for that product. Its architecture explanation distinguishes CPU-attached LPDDR5X from GPU-attached HBM and describes access across the connection.

That is not a claim that every ordinary PCIe GPU supports the same coherent access. It also is not the same route as GPU A communicating with GPU B through NVLink Switch. Even within a coherent addressable system, CPU-resident and GPU-resident data occupy different physical memory tiers.

Practical reading rule: when a specification says “NVLink,” ask whether it means a GPU scale-up fabric or the CPU–GPU C2C connection, then name the exact product. The shared brand does not erase the endpoint distinction.

5. CXL reuses a physical foundation—not every PCIe capability

CXL is not simply a third unrelated cable competing with PCIe. It uses a PCIe-derived electrical foundation while introducing additional protocol behavior. A host port, device, firmware and software stack must support the required CXL mode; an ordinary PCIe connection is not sufficient evidence.

The foundational CXL 1.1 specification separates these roles:

CXL.io provides PCIe-based I/O functions, including device discovery and management.
CXL.cache supports a device coherently caching host memory.
CXL.mem provides access to device-attached memory.

Those are foundational protocol definitions, not a statement that 1.1 is the newest version. The Consortium’s CXL 3.1 technical Q&A identifies traditional Type-3 memory expanders as CXL.mem targets with CXL.io, and discusses direct peer-to-peer memory access by capable accelerators. Therefore, neither “every GPU can directly use any CXL pool” nor “CXL can never support accelerator-to-memory access” is a safe generalization.

A CPU-visible CXL memory region is not automatically an extension of a GPU’s local HBM. Establish the supported host/device/switch topology, mappings and runtime path before making that claim. More capacity can be valuable for a workload that tolerates the access path; it does not, by itself, demonstrate faster decoding.

6. Four routes that must stay separate

A · Local GPU memory
GPU cores ↔ local memory controller ↔ local HBM
No PCIe, NVLink or CXL hop is inserted into this local-memory arrow.

B · Supported GPU scale-up fabric
GPU A + its HBM ↔ NVLink / switch fabric ↔ GPU B + its HBM
Peer communication is not additional local HBM on GPU A.

C · Grace Hopper product example
CPU + LPDDR5X ↔ NVLink-C2C ↔ GPU + HBM
Coherent CPU–GPU access; different physical memory locations remain.

D · CXL memory-expansion example
CXL-capable CPU host ↔ supported CXL path ↔ Type-3 controller + DRAM
GPU access requires its own supported route; none is assumed here.

Original conceptual route cards, not a copied board diagram or one combined server configuration. Arrows identify endpoints and access paths, not equal speed, latency or universal compatibility. Sources: NVIDIA product/architecture documentation and the CXL Consortium references linked above.

Connection	First question
PCIe I/O	Which device and actual route?
GPU NVLink	Which peer GPUs and fabric?
NVLink-C2C	Which coherent processor pair?
CXL memory	Who can access the region, and how?

7. A transfer budget shows why capacity is not enough

Consider an entirely invented path that must move 256 MiB before a consumer can proceed. Assume an already established usable payload rate of 32 GiB/s. These are teaching inputs, not specifications or measurements of PCIe, NVLink, CXL or HBM.

Ideal transfer-only time = (256 / 1,024) GiB ÷ 32 GiB/s = 7.8125 ms. If the workload allows only 2 ms for that serialized movement, it cannot meet that budget under these assumptions—even if the source tier has abundant free capacity.

The corresponding ideal rate required for that deadline is 0.25 GiB ÷ 0.002 s = 125 GiB/s. Queueing, setup and protocol costs are excluded. This simple model assumes the entire transfer lies on the critical path; overlap, caching or transferring less data can change the workload. It does not rank the named interconnects or predict token latency.

8. What this changes for AI infrastructure decisions

Capacity expansion: a larger accessible tier may make a previously impossible working set feasible. Check where weights, KV state and other data actually reside, and whether movement fits the application’s latency target. Do not relabel all accessible bytes as HBM.

Scale-up: more capable GPU communication can support larger parallel jobs, but the useful gain depends on placement and collective traffic. “More connected GPUs” is not a measurement of achieved application throughput.

Commercial interpretation: technical capability, a qualified server configuration, a customer deployment, a component shipment and supplier revenue are separate evidence steps. NVIDIA’s product documentation establishes specific interconnect offerings; a CXL specification establishes protocol capabilities. Neither establishes an order forecast, a memory-supplier win or a stock-price outcome.

This is architecture and procurement context, not a buy/sell recommendation. The growth question is conditional: which memory tier and connection remove a real bottleneck at an acceptable cost and service target?

9. A six-field checklist for the next memory claim

Requester: CPU, local GPU, peer GPU or another accelerator?
Physical owner: local HBM, CPU DRAM, expansion-device DRAM or storage?
Route: exact ports, switches, sockets and protocol generation—not just a brand name.
Semantics: explicit copy, mapped access, cache coherence or storage I/O? Do not infer one from another.
Software support: which OS, driver, runtime and application placement policy actually use the route?
Measurement scope: per-lane/link/GPU/rack, one direction or aggregate, payload or line rate, and what workload/latency target?

If a headline supplies only capacity or aggregate bandwidth, those missing fields are the next questions—not permission to assume interchangeability.

Appendix. Coherence is not locality, and SSDs are not DRAM

Coherence addresses consistency among participating caches. Locality concerns where data physically lives and what route accesses it. A coherent remote or attached memory tier can still have different bandwidth and latency from a local tier.

Likewise, an NVMe SSD on PCIe remains storage with its own access model; a Type-3 DRAM expander is a different device. Software can explicitly stage or tier data between media, but sharing a physical interconnect family does not turn NAND into DRAM or HBM.

Sources, scope and verification

NVIDIA DGX H100/H200 system guide—named system components and topology reference.
NVIDIA NVLink / NVLink Switch—GPU scale-up paths and generation-specific scope.
GH200 product documentation and Grace Hopper architecture explanation—coherent C2C and distinct CPU/GPU memory locations; not a claim about every GPU.
CXL 1.1, June 2019, terminology and protocol overview—foundational definitions only. Specification copyright: © 2019-2020 COMPUTE EXPRESS LINK CONSORTIUM, INC. ALL RIGHTS RESERVED. No specification diagram reproduced.
CXL Consortium, CXL 3.1 webinar Q&A, March 19, 2024—device roles and direct peer-access qualification.

Checked October 24, 2026, KST. Original transfer-budget arithmetic executed locally with Node.js 24.14.1 on Windows; no actual server topology inspection, transfer benchmark, GPU/CXL hardware test or paid API call. No product throughput measurements or shipment forecasts are implied. The current Consortium site discusses CXL 4.0; its existence does not establish support in an installed system.

Calculate LLM p50, p95 and SLO Goodput from Request Logs in Python

2026-10-23T19:13:38.470+09:00

To calculate LLM latency percentiles and SLO Goodput from request logs, keep two views: compute p50 and p95 for successful responses, then count requests that meet every declared latency threshold over a stated time window. Keep errors and timeouts in the all-attempt attainment denominator—not in a made-up zero-latency bucket.

A dashboard can show a reasonable median while half the requests fail your definition of a useful response. This small Python exercise makes that difference visible, without a GPU, API key or paid LLM call.

Start here: if p95 differs between tools, first compare their percentile method and included requests. Save the two files below and run python analyze_logs.py requests.jsonl. These are synthetic logs; the analyzer really ran, but no model generated these timings.

Checked October 23, 2026. Executed on Windows with CPython 3.14.3, using only the standard library. Thresholds and the 60-second window are teaching choices, not recommended production targets.

New to the vocabulary? Start with the LLM inference metrics guide. For collecting streaming observations rather than analyzing saved logs, see the C# TTFT and E2EL measurement exercise.

1. The terms, in one minute

TTFT: time from sending a request to the first nonempty model content, in milliseconds (ms).
p50 / p95: positions in a latency distribution. This exercise uses R7 linear interpolation and successful requests only.
E2EL: time from sending the request to its final content, in ms; it is not the time of a later empty completion marker.
SLO Goodput: successful requests meeting both our TTFT and E2EL thresholds, divided by observation seconds; unit: requests/s.
Attainment: that same good-request count divided by all attempted requests, including errors and timeouts; unit: fraction or percent.

NVIDIA’s metric definitions distinguish first content, final content and aggregate throughput. A chunk may contain multiple tokens; this exercise never treats HTTP/SSE chunks as individual tokens or derives token-level ITL from them.

2. Create a fully resolved, anonymous log

Save this as requests.jsonl: one JSON object per line. The six attempts were invented for this tutorial. No prompts, account identifiers or customer data are included.

{"id":"r1","status":"ok","start_ms":0,"end_ms":1000,"ttft_ms":100}
{"id":"r2","status":"ok","start_ms":10000,"end_ms":11200,"ttft_ms":200}
{"id":"r3","status":"ok","start_ms":20000,"end_ms":21800,"ttft_ms":300}
{"id":"r4","status":"ok","start_ms":30000,"end_ms":35000,"ttft_ms":900}
{"id":"r5","status":"error","start_ms":40000,"end_ms":40400,"ttft_ms":null}
{"id":"r6","status":"timeout","start_ms":50000,"end_ms":56000,"ttft_ms":null}

All timestamps are elapsed milliseconds from the start of a declared [0, 60,000 ms] observation window. Each attempt starts before its end, and every outcome is known inside it. For an ok row, end_ms marks final content. For an error or timeout, it marks the terminal failure or deadline—not a successful response.

For example, r3 has E2EL = 21,800 − 20,000 = 1,800 ms. Its TTFT is 300 ms. Our teaching SLO accepts a request only when it succeeds, TTFT ≤ 500 ms, and E2EL ≤ 2,000 ms. Equality passes.

6 attempts in a declared 60-second window
Keep every outcome; reject invalid records.

↓

4 successful responses
Use their measured TTFT and E2EL for p50 and p95.
3 meet both thresholds; 1 is too slow.

↓

1 error + 1 timeout stay visible
Goodput = 3 / 60 = 0.05 requests/s.
Attainment = 3 / 6 = 50%.

Original schematic from the synthetic fixture, not a measured service benchmark. Failure durations do not become successful E2EL samples.

3. Declare how p50 and p95 are calculated

Sort n latency values in ascending order, indexed from zero. For percentile p, R7 uses h = (n − 1) × p / 100, then interpolates between the values at floor(h) and ceil(h). NIST’s percentile reference explains that software can use different estimators, particularly noticeable with small samples. This is a declared choice, not the only valid method.

The successful E2EL values are 1,000, 1,200, 1,800 and 5,000 ms. The p50 lies halfway between 1,200 and 1,800: 1,500 ms. For p95, h = 2.85, so the result is 1,800 + 0.85 × (5,000 − 1,800) = 4,520 ms. It is an interpolated value, not an actual request.

Only four successful samples support those numbers. They demonstrate the arithmetic; they cannot establish production tail reliability, confidence bounds or a maximum sustainable capacity.

4. Run the standard-library Python analyzer

Save this complete script as analyze_logs.py in the same folder. It stops on duplicate IDs, unknown outcomes, missing successful TTFT, nonfinite or impossible timings, and attempts outside the fully resolved window. It does not silently drop invalid rows to improve the result.

import json
import math
import sys


def percentile(values, p):
    """R7 linear interpolation; caller supplies validated finite values."""
    if not values:
        return None
    x = sorted(values)
    h = (len(x) - 1) * p / 100
    lo, hi = math.floor(h), math.ceil(h)
    return x[lo] + (h - lo) * (x[hi] - x[lo])


def analyze(rows, window_ms, ttft_slo_ms, e2el_slo_ms):
    for value in (window_ms, ttft_slo_ms, e2el_slo_ms):
        if type(value) not in (int, float) or not math.isfinite(value) or value < 0:
            raise ValueError('window/SLO must be finite nonnegative numbers')
    if window_ms == 0:
        raise ValueError('window must be positive')
    seen, ttfts, e2els = set(), [], []
    good = errors = timeouts = 0
    for r in rows:
        if not isinstance(r, dict):
            raise ValueError('each row must be an object')
        rid = r.get('id')
        if not isinstance(rid, str) or not rid or rid in seen:
            raise ValueError('id must be unique and nonempty')
        seen.add(rid)
        status = r.get('status')
        if status not in ('ok', 'error', 'timeout'):
            raise ValueError('unresolved/unknown status')
        start, end = r.get('start_ms'), r.get('end_ms')
        for value in (start, end):
            if type(value) not in (int, float) or not math.isfinite(value):
                raise ValueError('timestamps must be finite numbers')
        if not 0 <= start < window_ms or not start <= end <= window_ms:
            raise ValueError('attempt not fully resolved inside this window')
        first = r.get('ttft_ms')
        if first is not None:
            if type(first) not in (int, float) or not math.isfinite(first) or not 0 <= first <= end - start:
                raise ValueError('invalid first-token time')
        if status == 'ok':
            if first is None:
                raise ValueError('successful content response needs TTFT')
            elapsed = end - start
            ttfts.append(first)
            e2els.append(elapsed)
            good += first <= ttft_slo_ms and elapsed <= e2el_slo_ms
        else:
            errors += status == 'error'
            timeouts += status == 'timeout'
    return {
        'window_seconds': window_ms / 1000,
        'percentile_method': 'R7 linear interpolation; successful requests only',
        'attempts': len(rows), 'successful': len(e2els),
        'errors': errors, 'timeouts': timeouts, 'good': good,
        'attainment': good / len(rows) if rows else None,
        'goodput_req_s': good / (window_ms / 1000),
        'successful_ttft_ms': {f'p{p}': percentile(ttfts, p) for p in (50, 95)},
        'successful_e2el_ms': {f'p{p}': percentile(e2els, p) for p in (50, 95)},
    }


if __name__ == '__main__':
    with open(sys.argv[1], encoding='utf-8') as f:
        rows = [json.loads(line) for line in f if line.strip()]
    # This tutorial's fixed, fully resolved 60-second observation window.
    print(json.dumps(analyze(rows, 60000, 500, 2000), indent=2, allow_nan=False))

Open a terminal in that folder and run:

python --version
python analyze_logs.py requests.jsonl

No packages need installing. The script reads only the named local file and prints JSON; it sends no network requests. Use a trusted, bounded-size log export: this teaching script loads the file into memory and is not a hardened production ingestion service.

5. Read the actual execution result

The following output came from executing the script above against the six synthetic lines on CPython 3.14.3:

{
  "window_seconds": 60.0,
  "percentile_method": "R7 linear interpolation; successful requests only",
  "attempts": 6,
  "successful": 4,
  "errors": 1,
  "timeouts": 1,
  "good": 3,
  "attainment": 0.5,
  "goodput_req_s": 0.05,
  "successful_ttft_ms": {
    "p50": 250.0,
    "p95": 810.0
  },
  "successful_e2el_ms": {
    "p50": 1500.0,
    "p95": 4520.0
  }
}

Metric	Result
E2EL p50	1,500 ms
E2EL p95	4,520 ms
SLO pass	50%
Goodput	0.05 req/s

The median successful completion fits under 2 seconds, yet only half of all attempts qualify. Dividing 3 by 4 would answer a different question—“what fraction of successes meet the SLO?”—and hide the error and timeout. Dividing 3 by 60 seconds is a rate, not a success percentage.

The AIPerf Goodput tutorial similarly distinguishes good requests per second from the fraction meeting all configured thresholds. This script is independent of AIPerf: it does not run that tool or claim identical accounting.

6. What was tested—and what was not

The accompanying local test suite ran 8 unittest methods successfully. It checks R7 arithmetic, empty/singleton samples, the all-attempt denominator, threshold equality, empty logs, invalid windows or thresholds, malformed request records, and duplicate IDs. Empty latency samples return null, not 0 ms; an empty log has undefined attainment and zero counted Goodput for the declared window.

Executed: local Python parsing, validation and arithmetic on synthetic fixtures. Not executed: an LLM, GPU workload, paid endpoint, real streaming benchmark, AIPerf or load generator. The test result validates this calculation example, not the speed or capacity of any deployed model.

7. Before using real request logs

Match the measurement boundaries. Use one client-side clock for request submission, first content and final content. Keep tokenizer, model, input/output lengths and sampling settings with the run metadata. Do not mix server compute time with end-user elapsed time.
Choose the cohort and window explicitly. Here, the denominator is a fixed 60 seconds including idle time. NVIDIA’s referenced batch throughput uses first request to last response; that is a different interval. Do not expect the same rate from different boundaries.
Resolve boundary-crossing attempts deliberately. This example rejects attempts starting before or ending after the window. Do not simply filter those rows away. For real traffic, define an admission cohort with a declared drain policy, or a fixed completion window with outstanding/censored counts, and report its limitations. A timeout is not a completed response whose latency you know.
Keep unsuccessful outcomes. Define warmup, retries, cancellations and invalid-record handling before comparison. A retry is another attempt unless you explicitly compute a separate logical-request measure. Never remove slow failures after seeing the chart.
Validate tail conclusions with enough representative data. Report sample counts, duration and workload mix. Do not average p95 values from separate runs and call that the combined p95; pool comparable raw samples or use a suitable mergeable histogram with declared error.

If software claims a large efficiency gain, this kind of accounting is one part of the evidence—not proof by itself. Compare equivalent useful output, latency targets and failure handling before connecting benchmark throughput to hardware needs. See the Flapping Airplanes GPU-and-memory evidence checklist for that broader distinction.

Summary: publish the denominator beside the percentile

A useful result states the workload, n, percentile estimator, success/failure policy, observation window, latency thresholds, Goodput and all-attempt attainment together. “p95 = 4,520 ms” alone cannot tell you whether the service is acceptable.

For this tiny synthetic fixture: 6 attempts, 4 successes, 3 jointly good requests, R7 E2EL p50/p95 of 1,500/4,520 ms, 50% attainment and 0.05 good requests/s over 60 seconds. Those are reproducible arithmetic results—not a capacity recommendation.

Appendix. Why no tokens/s or ITL?

The schema has no output-token counts or token timestamps, so the script cannot honestly produce token throughput or token-level ITL. It also does not assess answer correctness. In a real application, “good” may require a separate task-quality or validity check; add that declared condition rather than assuming a fast HTTP success is useful.

Sources and reproducibility

NIST/SEMATECH handbook: percentiles and estimator differences—R7 choice and interpolation.
NVIDIA NIM Benchmarking metrics, visible documentation version 2.0.0—latency/content and batch interval definitions.
AIPerf: benchmark Goodput, visible documentation version 0.13.0—joint thresholds, rates and fractions.
Python 3.14 JSON documentation and math documentation—standard-library parsing, finite-value checks and interpolation helpers.

Sources checked October 23, 2026. Original synthetic data, Python example and schematic; no third-party figure reproduced. Python version actually executed: 3.14.3 on Windows. No API keys, package installation, model downloads or paid calls required.

Fewer NVIDIA GPUs, Less Memory? Flapping Airplanes’ $1B Challenge

2026-10-23T09:25:29.461+09:00

Flapping Airplanes could make AI cheaper per useful result, but the public material reviewed here does not establish that NVIDIA GPUs or large amounts of memory are no longer needed. Higher hardware efficiency can reduce resources for a fixed workload without reducing total demand for AI infrastructure.

The interesting challenge is not whether software can improve a chip. It is whether a better system changes the economics of buying the next rack. That deserves a harder test than either declaring the GPU boom over or assuming efficiency must create unlimited demand.

Checked October 23, 2026, KST. Company statements, earlier academic measurements and original hypothetical calculations are labeled separately. This is an infrastructure analysis, not a stock recommendation or a GPU benchmark performed by this blog.

Contents and working definitions

The announcement: financing is not a benchmark.
Megakernel: a GPU execution program, not a count of chips.
Memory efficiency: capacity, traffic and time are different quantities.
The demand test: workload growth divided by effective throughput growth.
The buyer’s checklist: compare useful output under the same constraints.

1. What did the billion dollars actually buy?

Index Ventures announced its leadership of a $1 billion Series A on October 21. That is funding for a research direction, not a measurement of cost savings available to a customer.

Flapping Airplanes describes a model-and-systems approach and a framework that can overlap memory-bound inference with compute-bound training. It lists NVIDIA among its backers and argues that its ideas could expand AI demand. These are company statements, not independent proof of fleet-wide savings. The announcement does not give this reader a reproducible percentage reduction in GPU count or HBM capacity.

The social post that prompted this article also discusses Recursive’s Flint. That is a different company and model. Its laptop-running claims should not become evidence about Flapping Airplanes. Nor does NVIDIA’s presence on an investor list prove a particular defensive investment motive.

2. One kernel is not one GPU

In NVIDIA’s programming model, a kernel is a function invoked to execute on the GPU. “One kernel” describes execution organization; it does not mean “one chip replaces a cluster.” This distinction is essential when reading the term megakernel.

An intuitive opportunity is to reduce gaps between operations and coordinate complementary work. A calculator that is busy while data moves can be more productive than one that waits for every movement to finish. But overlap has limits: dependencies, bandwidth and storage remain finite. Two tasks competing for the same resource can slow each other down.

The broader category is not new. A September 2025 Hazy Research prototype handled Llama-70B inference with eight GPUs. Its existence is a useful technical precedent, not a specification for the startup’s current framework or a demonstration of its learning algorithm.

3. Less waiting does not necessarily mean less memory

Ask what changed: peak resident capacity in GB, bytes transferred, bandwidth in GB/s, or elapsed time. They are related, but a result for one does not establish a result for the others. Fewer training examples also do not, by themselves, imply fewer model parameters or a smaller inference cache.

For intuition, 70 billion parameters stored at two bytes each require about 140 decimal GB for weights alone. That is arithmetic, not a particular model’s complete runtime footprint: cache, activations, metadata and other state are additional concerns. Changing a schedule without changing the stored representation does not erase that storage requirement.

A useful counterexample appears in the 2025 Hazy Research design: a communication optimization used an extra 9GB per GPU and reduced maximum batch size by about 15%. Its ShareGPT test used 65,536 prompts and reported total throughput of 19,170 versus 23,468 tokens/s for SGLang and the megakernel system. That is approximately 22.4% more throughput, or 18.3% less time for fixed work—not a 22.4% memory saving. These are earlier research results, not Flapping Airplanes’ current product benchmark.

4. Can a 25% throughput gain still require more GPU-hours?

Yes. In a deliberately simplified model with unchanged hardware and useful-work definition:

Total GPU-hour ratio = workload multiplier ÷ effective throughput multiplier.

The effective throughput must hold at the required quality and latency. A peak tokens/s number is not enough.

In the table, Work is the workload multiplier, Speed is useful throughput per GPU, and GPU·h is total GPU-hours relative to the baseline.

Work	Speed	GPU·h
1.00×	1.25×	0.80× −20%
1.50×	1.25×	1.20× +20%
2.00×	1.25×	1.60× +60%

Original hypothetical examples, not a forecast or a company measurement. GPU-hours measure work over time; they are not a direct forecast of chip shipments.

Efficiency improves
Less resource per equivalent useful result

↓

Two separate questions
How much does workload grow?
What hardware and memory remain necessary?

↓

Only then estimate the fleet
Include peak load, latency, headroom and deployment constraints.

Original conceptual diagram. It describes a decision process, not measured Flapping Airplanes performance.

A rebound in usage is possible, not guaranteed. Lower prices may unlock applications; buyers may also hold volume constant and pocket the savings. A hardware-demand thesis needs evidence about both effects. Converting GPU-hours into purchased GPUs then requires a capacity-planning horizon, utilization and reliability assumptions.

5. What should a cloud buyer demand before changing a purchase order?

Equivalent quality: compare the same task and output quality, not just a smaller or easier model.
Representative traffic: disclose input/output lengths, batch sizes, concurrency and whether prefill, decode or training is measured.
Service constraints: report tail latency, errors and useful throughput that meets the target—not utilization alone.
Full resource cost: record GPU type/count, precision, peak memory, energy and any extra CPU or networking costs.
Repeatability: provide versions, workload definitions and an independently reproducible baseline.
Mixed-workload isolation: if training and inference share a GPU, show that training does not break inference latency or reliability.

The next commercial question is portability. An impressive result on a particular hardware/software combination is not automatically economical to support across customers. If you need the mechanics behind this distinction, the existing GPU FLOPS and decoding roofline explanation separates compute from memory constraints. The inference metrics guide explains what to measure when the user experience matters.

6. The threat is real; the “no more GPUs” conclusion is not established

For infrastructure suppliers, efficiency is a genuine competitive variable: fixed workloads may need fewer GPU-hours, and buyers may change when or what they purchase. For customers, that can be good news. For NVIDIA, stronger usefulness of existing GPUs can also reinforce the value of its platform. Neither direction follows automatically from an investment announcement.

HBM demand needs its own bridge: how many accelerators are deployed, how much memory each carries and which workloads they serve. A faster software schedule is not itself a new memory bill of materials. The current evidence supports watching a serious efficiency effort—not declaring the disappearance of GPUs or memory.

Appendix. How this article was checked

The calculations were executed with Node.js 24.14.1 on Windows. No GPU, LLM or Flapping Airplanes framework was run. The throughput conversion is a recalculation of a published research table; the demand scenarios and 140GB example are labeled arithmetic. Definitions are checked against CUDA documentation. No copied news image, benchmark chart or AI-generated evidence is used.

Sources and scope

The October 22 X post: a starting point, not a technical benchmark.
Flapping Airplanes official website: current claims checked October 23.
Index Ventures financing announcement, October 21, 2026: an investor’s perspective.
Hazy Research’s published 2025 measurements and workload introduction: distinct from today’s company claims.
CUDA programming model: kernel and memory definitions.

엔비디아 GPU·메모리, 이제 덜 필요할까? 플래핑 에어플레인즈의 도전

2026-10-23T09:25:12.792+09:00

플래핑 에어플레인즈(Flapping Airplanes)가 AI 효율을 높이려는 것은 맞지만, 엔비디아 GPU와 메모리가 더는 많이 필요하지 않다고 입증한 것은 아닙니다. 같은 일을 더 적은 자원으로 처리하는 기술과, AI 산업 전체의 반도체 수요가 줄어드는 현상은 다른 문제입니다.

이 소식은 메모리 투자자에게 꽤 불편한 질문을 던집니다. 비싼 장비를 더 사는 대신 이미 산 장비를 더 잘 쓰면 되는 것 아닐까요? 저는 이 질문을 가볍게 넘길 필요도, 곧바로 ‘HBM 호황의 끝’으로 받아들일 필요도 없다고 봅니다.

확인일: 2026년 10월 23일 KST. 기업의 설명, 공개 연구 결과, 아래의 가상 계산을 구분합니다. 이 글은 산업을 읽기 위한 정보이며 매수·매도 추천이나 주가 예측이 아닙니다.

먼저 구분할 세 문장

적은 데이터로 학습한다 ≠ 모델 가중치가 작아졌다.
메모리에서 덜 기다린다 ≠ 장착한 HBM 용량이 줄었다.
커널 하나로 묶는다 ≠ GPU 한 개만 쓴다.

목차와 핵심 용어

공식 발표 — 회사가 공개한 목표와 아직 검증하지 못한 부분.
메가커널 — 여러 실행 단계를 하나의 GPU 프로그램으로 엮는 접근.
용량과 대역폭 — 저장할 수 있는 양과 초당 옮기는 양.
단위 효율과 총수요 — 절감률만으로 산업의 크기를 계산할 수 없는 이유.
메모리 산업 체크포인트 — 제품별 출하·가격·수익성으로 검증하기.

1. 10억 달러가 몰렸지만, 성능표를 산 것은 아니다

Index Ventures는 2026년 10월 21일 Flapping Airplanes의 10억 달러 Series A 투자를 이끈다고 발표했습니다. 투자 유치는 확인할 수 있는 사건이지만, 그 금액이 기술의 성능을 검증해 주지는 않습니다. 투자자 발표와 고객 환경의 재현 가능한 측정은 구분해야 합니다.

회사 공식 사이트는 모델과 시스템을 함께 개선하고, 메가커널에서 학습과 추론을 겹쳐 실행할 수 있다고 설명합니다. NVIDIA도 후원 투자자 명단에 있습니다. 회사는 자신의 접근이 AI 수요를 더 키울 수 있다고 봅니다. 이것은 회사의 주장과 전망이지, 독립 검증된 시장 수요 예측은 아닙니다.

검토한 발표 자료에는 비교 가능한 조건으로 ‘GPU 몇 % 감소, HBM 몇 % 감소’를 확정할 근거가 없습니다. 원문 SNS에 함께 등장한 Recursive의 Flint는 별개 회사의 모델입니다. 그 모델의 노트북 실행 설명을 Flapping Airplanes의 성과로 옮기지 않습니다. NVIDIA가 투자한 이유를 ‘칩이 안 팔릴까 봐 든 보험’으로 확정할 근거도 없습니다.

2. 메가커널은 칩을 없애는 기술일까?

아닙니다. NVIDIA의 CUDA 설명에서 커널은 GPU에서 실행하도록 호출하는 함수입니다. 칩 개수를 세는 단위가 아닙니다. 메가커널이라는 단어만 보고 데이터센터 전체가 GPU 한 개로 대체됐다고 읽으면 출발점부터 어긋납니다.

쉽게 말하면 작업 사이의 빈틈을 줄이는 문제입니다. 계산 장치가 일할 때 다음 데이터를 준비하고, 통신이 진행되는 동안 가능한 다른 일을 배치하는 식입니다. 단, 모든 작업을 동시에 돌릴 수는 없습니다. 같은 대역폭이나 메모리 공간을 두 작업이 함께 요구하면 서로 방해할 수도 있습니다. 자원을 공유한다는 사실과 자원이 무한해졌다는 말은 다릅니다.

학술적 선행 사례도 범위를 붙여 읽어야 합니다. 2025년 9월 Stanford Hazy Research의 공개 연구는 H100 기반 Llama-70B 추론을 다뤘습니다. 이는 2026년 회사의 학습 시스템 성능표가 아닙니다. 연구 소개는 8-GPU 구성도 명시합니다.

3. 메모리를 더 잘 쓴다면 HBM은 줄어야 하지 않을까?

경우에 따라 그럴 수 있지만 자동으로 성립하지는 않습니다. 용량은 GB, 대역폭은 GB/s, 데이터 이동량은 GB처럼 구분해야 합니다. 왕복 이동이나 대기 시간이 줄어도, 모델 가중치와 KV cache를 담을 공간이 그대로 필요할 수 있습니다.

반대 방향의 교환도 가능합니다. 같은 2025년 연구의 특정 설계는 통신을 줄이려고 일부 가중치를 복제하면서 GPU당 메모리 9GB를 추가로 쓰고 최대 배치 크기는 약 15% 줄었다고 설명합니다. 이 수치를 현재 회사의 제품에 적용할 수는 없지만, ‘더 빠르면 메모리도 반드시 덜 든다’는 등식이 성립하지 않는 사례입니다.

여기서 확인할 질문은 구체적입니다. 줄었다는 것이 최대 상주 메모리인가요, HBM을 오가는 바이트인가요, 작업 완료 시간인가요? 세 수치가 어떻게 달라졌는지 공개하지 않으면 메모리 업체의 출하량까지 계산할 수 없습니다.

4. 25% 빨라졌는데 총 GPU 사용량은 28% 늘 수도 있다

다음은 회사의 전망이 아니라 직접 검산한 가상 예제입니다. 같은 GPU·품질·작업 구성에서 처리량이 1.25배가 됐다고 가정해 봅시다. 이전에 100 GPU·시간이던 고정 작업은 80 GPU·시간으로 줄어듭니다. 그러나 요청량이 1.6배가 되면 필요한 시간은 128 GPU·시간입니다.

가정: 같은 조건에서 처리량 1.25배

↓

요청량 그대로: 100 ÷ 1.25 = 80 GPU·시간
자원 사용 20% 감소

요청량 1.6배: 100 × 1.6 ÷ 1.25 = 128 GPU·시간
총사용 28% 증가

작성자가 만든 조건부 산술 도식. 회사 실측·수요 전망·HBM 출하 예측이 아닙니다. GPU·시간은 GPU 대수와 같지 않습니다.

이 단순식은 ‘처리할 일의 증가율 ÷ 유효 처리량의 증가율’입니다. 실제 서비스에서는 지연 목표, 피크 시간, 가동률, 장애 여유분도 들어갑니다. 효율 향상으로 가격이 내려가도 이용량이 반드시 크게 늘어난다는 보장은 없습니다. 반대로, 신규 이용이 절감 효과를 넘어설 가능성도 열어둬야 합니다.

5. 삼성·SK하이닉스는 무엇을 확인해야 할까?

삼성전자의 HBM 제품 자료와 SK하이닉스의 HBM4 발표는 두 회사가 이 메모리 시장에 실제로 노출돼 있음을 보여줍니다. 그렇다고 새 소프트웨어 발표만으로 두 회사의 향후 출하량이나 영업이익 변화를 알 수는 없습니다.

고정 작업 절감: 같은 품질·지연 목표에서 실제 GPU 구매나 증설이 줄었는가?
장착 용량: 가속기당 HBM 용량과 패키지 구성이 바뀌었는가?
이용량: 싸진 비용 덕분에 새 서비스와 유료 사용량이 얼마나 늘었는가?
제품 믹스: HBM·서버 DRAM·스토리지 중 어느 수요가 이동했는가?
실적: 계약 조건, 비트 출하량, 실제 판매가격과 이익률이 어떤 순서로 바뀌는가?

메모리 매출을 읽는 기본은 여전히 제품·기간을 맞추는 것입니다. DRAM·NAND 가격·물량·제품 믹스 구분을 함께 보면 발표 한 줄에서 실적 결론으로 건너뛰는 실수를 줄일 수 있습니다. 서비스 성능은 최고 처리량보다 지연 조건을 통과한 Goodput으로 비교해야 합니다.

6. 결론: ‘덜 필요하다’보다 먼저 확인할 것

Flapping Airplanes의 도전이 성공하면 같은 결과를 내는 데 쓰는 GPU·전력·데이터가 줄어들 수 있습니다. 그 가능성은 인프라 투자 논리의 중요한 위험 요인입니다. 하지만 현재 확인된 내용은 GPU의 퇴장이 아니라 활용 방식을 바꾸려는 시도입니다.

저는 ‘메모리 수요가 끝났다’와 ‘효율이 오르면 수요는 무조건 폭발한다’ 둘 다 성급하다고 봅니다. 먼저 재현 가능한 성능과 최대 메모리 사용량을 확인하고, 그다음 실제 이용량·주문·가격 변화를 따라가야 합니다. 자극적인 제목 뒤에서 놓치지 말아야 할 답은 이 순서입니다.

Appendix. 검증할 때 받아야 할 최소 자료

비교할 모델·품질, GPU 종류와 대수, 정밀도, 입력·출력 길이, 배치·동시 요청, 지연 백분위수, 최대 메모리 사용량, 전력·완료 시간을 같은 표에 둡니다. 학습 데이터 효율은 같은 품질에 도달하는 학습 자원으로, 추론 효율은 실제 서비스 요청으로 따로 확인합니다. 위 계산은 Node.js 24.14.1·Windows에서 산술만 실행했으며 GPU나 회사 프레임워크는 실행하지 않았습니다.

출처와 확인 범위

계기가 된 10월 22일 X 게시물: 회사 두 곳을 구분해 확인했으며, 기술 근거는 위 공식 자료로 교차 확인했습니다.
Flapping Airplanes 공식 사이트: 회사 주장·투자자 명단, 10월 23일 확인.
Index Ventures의 10월 21일 투자 발표: 투자자의 관점임을 구분했습니다.
Hazy Research의 2025년 공개 연구: 현재 회사 성능과 구분했습니다.
CUDA·삼성 HBM·SK하이닉스 HBM4 자료는 각 관련 문단에 연결했습니다. 기사 사진·원문 차트는 재사용하지 않았습니다.

LLM Goodput이 높아도 충분한 용량일까? SLO 충족률로 가려보기

2026-10-23T06:37:57.955+09:00

LLM의 Goodput이 높아져도 서비스 용량이 충분하다고 단정할 수는 없습니다. 목표를 지킨 요청이 초당 몇 개였는지와, 전체 시도 중 몇 %가 목표를 지켰는지는 다른 질문입니다. 용량 후보를 고를 때는 요청별 조건을 동시에 통과했는지, 오류까지 포함한 충족률이 목표 이상인지를 함께 확인해야 합니다.

먼저 확인할 것은 “좋은 요청”의 분모입니다. 완료된 응답만 보고 있다면 실패·타임아웃을 포함한 전체 시도로 다시 나눠보세요. 그다음 통과율을 지킨 후보끼리 처리량을 비교하는 것이 안전한 순서입니다.

기준일: 2026년 10월 23일 KST. 공식 문서와 논문을 읽고 구성한 분석이며, 아래 요청 수·지연 기준·도식은 모두 가상입니다. Windows의 Node.js 24.14.1로 산술과 조건 판정만 실행했습니다. 실제 LLM·GPU·AIPerf 벤치마크나 유료 API는 실행하지 않았습니다.

목차 · 용어를 먼저 나눠 봅니다

요청별 허용 기준과 SLO — 한 요청의 합격선과 서비스가 지킬 목표.
Goodput과 충족률 — 초당 합격 요청 수와 전체 시도 중 합격 비율.
같은 60초의 두 후보 — 처리량이 더 높은 쪽이 목표에는 탈락하는 예.
공동 통과와 실패 분모 — 두 조건을 따로 보거나 오류를 빼면 생기는 착시.
부하별 용량 판단 — 한 번의 결과를 최대 용량으로 부르지 않는 방법.

1. 요청의 합격선과 서비스 목표는 다릅니다

요청별 허용 기준은 한 요청을 통과로 셀 조건입니다. 이 글에서는 “오류 없이 완료하고, TTFT 1초 이하이며, 요청별 평균 TPOT 80ms 이하”를 예로 들겠습니다. TTFT는 첫 내용 토큰까지의 기다림, TPOT는 첫 토큰 이후 출력 토큰당 평균 시간입니다. 둘 중 하나만 지켜서는 통과가 아닙니다.

SLO(Service Level Objective)는 서비스가 지키려는 목표입니다. 예를 들어 “정한 관측 구간의 전체 시도 중 위 조건을 모두 만족한 비율이 95% 이상”으로 정할 수 있습니다. 앞의 1초·80ms는 요청의 합격선이고, 95%는 집계 결과를 판단할 목표 비율입니다. 모두 설명을 위해 선택한 값이지 업계 공통 권장값은 아닙니다.

Google SRE의 SLO 설명은 좋은 사건 수를 전체 사건 수로 나누는 지표와 목표를 구분합니다. 무엇을 좋은 사건으로 셀지, 관측 지점과 기간은 무엇인지가 먼저 정해져야 숫자가 의사결정에 쓰입니다.

기본 용어가 낯설다면 기존 한국어 가이드 LLM 추론 성능 지표 이해하기를 먼저 보세요. 이번 글은 용어 사전을 반복하기보다 이미 계산한 숫자로 용량 후보를 걸러내는 과정에 집중합니다.

2. Goodput 하나만으로는 목표 달성을 알 수 없습니다

Goodput(유효 처리율)을 여기서는 정한 요청별 조건을 모두 만족한 요청의 초당 처리율로 사용합니다. 단위는 req/s입니다. SLO 충족률은 같은 통과 요청 수를 전체 시도 수로 나눈 비율이며 단위는 %입니다.

Goodput = 통과 요청 수 ÷ 관측 시간(초)

충족률 = 통과 요청 수 ÷ 전체 시도 수 × 100

이 글의 통과 요청은 오류 없이 완료하고 TTFT·평균 TPOT 조건을 모두 만족한 요청입니다. 모든 요청의 판정이 끝난 가상 집합을 사용합니다. 관측 경계에 남은 요청을 임의로 삭제하지 않습니다.

NVIDIA AIPerf의 Goodput 문서도 처리율과 목표 충족 비율을 구분합니다. Goodput은 조건을 지킨 요청이 초당 얼마나 나왔는지를 보여주지만, “전체의 95%가 조건을 지켰는가”에는 별도의 비율이 필요합니다.

주의할 점도 있습니다. 여기서 “좋다”는 뜻은 설정한 지연·완료 조건을 지켰다는 것입니다. 답변의 사실성·유용성·안전성까지 검증했다는 뜻은 아닙니다.

3. 가상 비교: Goodput은 늘었지만 목표에는 탈락합니다

각각 60초로 끝나는 가상 관측 A·B를 비교해보겠습니다. 모든 시도는 그 구간 안에 성공·오류·타임아웃 중 하나로 판정이 끝났다고 가정합니다. 성공 완료한 요청은 모두 200개 출력 토큰을 냈고, 요청별 합격선과 목표 비율은 같습니다. 실제 도착 시각이나 장기 정상 상태를 측정한 결과가 아닙니다.

항목	A	B
전체 시도	100건	200건
성공 완료	98건	190건
오류 등	2건	10건
조건 통과	96건	140건
출력 처리량*	326.67 token/s	633.33 token/s
유효 처리율	1.60 req/s	2.33 req/s
충족률	96%	70%
95% 목표	통과	미달

*이 예제의 출력 처리량은 성공 완료한 요청의 출력 토큰 합 ÷ 60초입니다. 오류 요청의 부분 출력은 제외했습니다. 실제 도구와 비교할 때는 토큰 집계 범위·워밍업·시간 경계를 맞춰야 합니다. 소수는 둘째 자리까지 반올림했습니다.

A · 96 / 100건 = 96%Goodput 1.60 req/s
설정한 95% 목표를 통과합니다.

B · 140 / 200건 = 70%Goodput 2.33 req/s
처리율은 높지만 95% 목표에는 미달합니다.

Deoks 자체 도식·가상 수치. 막대는 Goodput이 아니라 전체 시도 중 통과 비율입니다. 실제 모델이나 GPU 성능 비교가 아닙니다.

B는 토큰 처리량과 Goodput 모두 더 높습니다. 그런데 이 예제의 서비스 목표를 만족하는 후보는 A뿐입니다. “Goodput이 늘었다”와 “현재 부하를 목표 품질로 감당했다”는 같은 결론이 아닙니다.

반대로 A를 서비스의 최대 용량이라고 부를 수도 없습니다. 두 가상 집합만 비교했을 뿐, 그 사이 부하나 다른 구성에서 어디까지 목표를 지키는지 탐색하지 않았기 때문입니다.

4. 두 가지 착시: 조건을 따로 세거나, 실패를 분모에서 빼기

공동 통과는 같은 요청이 필요한 조건을 모두 지킨 상태입니다. 예를 들어 100건 중 5건은 TTFT만 늦고, 다른 5건은 TPOT만 느리며, 나머지 90건은 모두 통과했다고 가정해보세요. TTFT 통과율과 TPOT 통과율은 각각 95%지만, 두 조건을 동시에 지킨 비율은 90%입니다.

각 지표의 요약 수치가 합격처럼 보인다고, 같은 요청들이 함께 합격했다고 결론 내리지 마세요. 요청별 식별자를 기준으로 성공 여부와 두 지연 조건을 묶어 판정해야 합니다. 이 예시는 집합을 직접 센 산술이며 두 지표가 독립이라는 통계 가정은 쓰지 않았습니다.

분모에서 사라진 실패도 확인해야 합니다. 1,000번 시도해 200건만 성공했고 그 200건이 모두 빠른 경우, 성공 응답만 나누면 100%처럼 보입니다. 하지만 전체 시도 중 통과 비율은 20%입니다.

AIPerf 문서는 good_request_fraction의 분모에 정상 요청과 오류 요청을 함께 넣는 이유를 설명합니다. 이 글 역시 같은 취지로 오류·타임아웃을 전체 시도에 포함합니다. 다만 재시도·취소·수신되지 않은 요청을 어떻게 식별하는지는 실제 관측 지점과 운영 정책에 맞춰 별도로 정해야 합니다.

TTFT를 재기 전에 실패한 요청에는 유효한 TTFT 값이 없을 수 있습니다. 그런 요청을 지연 백분위 계산에서 다루는 방식과, 목표 충족률의 분모에 남겨두는 판단은 서로 다른 문제입니다.

5. 용량은 “목표를 지키는 부하”로 비교합니다

목표를 지키는 용량은 지정한 작업·구성·지연 목표 아래에서 감당할 수 있는 부하입니다. OSDI 2024 DistServe 연구는 TTFT와 TPOT 제약을 지키면서 처리할 수 있는 최대 요청률을 중요하게 봅니다. 논문의 특정 조건에서 얻은 수치를 지금의 모든 모델이나 GPU에 그대로 적용할 수는 없습니다.

실제 비교에서는 다음 순서를 권합니다. 아래는 이번 글에서 실행한 벤치마크가 아니라, 측정을 설계할 때 확인할 항목입니다.

같은 작업을 고릅니다. 모델·토크나이저·입출력 길이 분포·정밀도·캐시 상태·엔진 버전과 하드웨어 범위를 기록합니다.
부하를 한 단계씩 바꿉니다. 동시 요청 수와 요청 도착률을 구분하고 대기열·실패·타임아웃도 남깁니다. NVIDIA의 부하 설정 설명처럼 클라이언트 동시성과 엔진 배치 크기는 같지 않을 수 있습니다.
통과 후보를 먼저 가릅니다. 요청별 공동 조건, 전체 시도의 충족률, 오류율과 관측 기간을 함께 봅니다. 목표 미달을 높은 처리량으로 상쇄했다고 보지 않습니다.
그다음 비용과 변동을 비교합니다. 같은 목표를 지킨 후보 사이에서 지연 분포·자원·비용을 비교하고, 반복 측정과 여유 폭을 확인합니다. 짧은 표본의 통과가 운영 기간 전체의 보장은 아닙니다.

메모리 용량과 대역폭, 요청 배분, 네트워크도 결과에 영향을 줄 수 있습니다. 그러나 Goodput 하나로 어느 부품이 원인인지 역산할 수는 없습니다. 병목 진단에는 별도의 자원·실행 경로 관측이 필요합니다.

6. AI 데이터센터를 볼 때도 총량과 유효 용량을 나눠 봅니다

필자의 해석: 설치한 GPU 수나 총 토큰 수는 서비스가 목표를 지키면서 제공한 처리 능력과 다릅니다. 같은 설비에서도 작업 특성과 목표에 따라 사용할 수 있는 여유가 달라질 수 있으므로, 기술 효율을 기업 실적에 연결하기 전에 어떤 부하를 어떤 조건으로 처리했는지부터 확인하는 편이 낫습니다.

그렇다고 이 글의 가상 수치로 데이터센터 증설 필요량이나 메모리 매출을 계산할 수는 없습니다. 투자 논의와의 경계는 기존 한국어 분석 AI 인프라 투자 회의론을 계약·매출·추론 수요로 나눠 보는 글에서 이어 읽을 수 있습니다. 이 글은 기술·산업을 이해하기 위한 정보이며 매수·매도 추천이 아닙니다.

요약 · 다음에 확인할 숫자

질문	확인할 항목
목표를 지킨 요청이 초당 몇 개인가?	같은 시간 경계의 Goodput
전체 시도 중 몇 %가 함께 합격했나?	오류를 포함한 공동 충족률
더 큰 부하도 감당할 수 있나?	부하별 반복 측정과 목표 통과 여부
어떤 부품이 병목인가?	별도의 시스템·커널 관측

먼저 목표를 통과한 후보를 고르고, 그 안에서 처리량과 비용을 비교하세요. Goodput의 req/s, 충족률의 %, 그리고 목표를 지키는 최대 요청률을 같은 숫자로 읽지 않는 것이 이번 글의 핵심입니다.

Appendix · 계산 범위와 공식 출처

총 16개의 산술·조건 검증을 Node.js 24.14.1·Windows에서 실행했습니다. 가상 A·B 집계, 공동 통과 90%, 오류 포함 20%, 목표 판정과 반올림을 확인했습니다. AIPerf·vLLM·GPU·실제 LLM 서버는 설치하거나 실행하지 않았으며 다른 OS를 시험했다고 주장하지 않습니다.

도구 문서에서 Goodput이라는 이름을 보더라도 단위·분모·시간 구간·통과 조건을 먼저 읽어야 합니다. 여기서는 60초 안에 모든 요청의 판정이 끝난 집합을 사용했지만, 운영 로그는 구간 밖까지 이어질 수 있습니다. 워밍업·미완료 요청·재시도를 임의로 없애면 같은 비교가 되지 않습니다.

NVIDIA AIPerf — Benchmark Goodput: Goodput과 충족률·오류 분모. 확인 화면의 버전은 v0.13.0입니다.
USENIX OSDI 2024 — DistServe: 지연 제약을 지키는 요청률의 연구 맥락.
Google SRE Workbook — Implementing SLOs: 좋은 사건/전체 사건 지표와 서비스 목표.
NVIDIA NIM Benchmarking — Parameters and Best Practices: 부하·동시성·배치 비교 조건. 확인 화면의 버전은 2.0.0입니다.

공식 자료 확인일: 2026-10-23 KST. 문장·가상 계산·도식은 독립 제작했습니다. 공식 자료의 그림·코드·벤치마크 결과를 복제하지 않았습니다.

When More GPU FLOPS Do Not Mean Faster LLM Decoding

2026-10-22T06:37:56.367+09:00

More GPU FLOP/s does not necessarily make LLM decoding faster. If a decode workload is limited by moving data rather than doing arithmetic, raising its compute ceiling alone leaves the main constraint unchanged. Batch size, memory traffic and the actual execution path determine whether extra compute can help.

Start with one question: what limits the next decode step at the batch and context length you actually serve? A peak-compute comparison cannot answer that by itself.

Evidence checked October 22, 2026, Korea time. This is a documentation-based explanation with executed synthetic arithmetic—not a GPU, CUDA, inference-engine or paid-LLM benchmark. No real accelerator specifications or measured token rates are used in the worked example.

Contents · five terms before the comparison

FLOPs and FLOP/s: work performed versus a rate of doing work.
Decode and batch: generating continuations and grouping work in one engine step.
Arithmetic intensity and Roofline: work per byte and a conditional performance ceiling.
Memory bandwidth: bytes transferred per second, not bytes of storage.
ITL and throughput: output timing versus total completed token work.

1. FLOPs describe work; FLOP/s describes a rate

FLOPs is a count of floating-point operations. FLOP/s is operations per second; TFLOP/s means 10¹² operations per second. Product pages often abbreviate the rate as “FLOPS,” which is why the headline uses that familiar spelling.

Memory bandwidth measures bytes per second. Capacity answers whether data fits; bandwidth answers how quickly it can move. A larger memory allocation is not automatically a faster data path.

NVIDIA’s GPU performance guide distinguishes arithmetic, memory and latency limitations. Its arithmetic-intensity estimate assumes enough parallel work to use the machine. A tiny or poorly parallelized kernel can fall short of both headline ceilings.

Before comparing rates, align the numeric format and execution conditions. Do not treat different precision modes or a sparsity-qualified peak as interchangeable measurements of one unchanged workload.

2. Why decoding is not the same workload as prefill

Prefill processes the prompt; decode incrementally generates its continuation. A KV cache stores attention keys and values from earlier tokens. A decode batch groups work processed in an engine step; it is not necessarily every request waiting at the service.

The JAX scaling book’s inference analysis explains how weight reuse across a larger token batch raises the arithmetic intensity of linear operations. Ordinary autoregressive decoding has a sequential dependency within each sequence, so batching usually means working across multiple sequences.

That creates a trade-off: better weight reuse can increase total throughput, while memory for separate KV states and latency requirements limit the usable batch. Attention traffic also matters, particularly as context grows. “Decode is memory-bound” is therefore a useful hypothesis for some regimes—not a verdict on every kernel, model or batch size.

This article does not repeat the KV-reuse or speculative-decoding mechanisms. Its narrower question is how to compare the arithmetic and data-movement ceilings of a declared workload.

3. Roofline is a ceiling, not a token-speed prediction

Arithmetic intensity, I, is useful floating-point work divided by bytes transferred at a specified memory boundary. For an HBM-level estimate, use HBM traffic—not an unrelated cache or interconnect bandwidth.

Performance ceiling = min(P, W × I)

Ideal time floor = max(F / P, Q / W)

P: compute rate in FLOP/s · W: bandwidth in bytes/s · F: operation count · Q: bytes transferred · I = F/Q. These expressions assume an idealized overlap of arithmetic and transfer, with all other work omitted.

NVIDIA’s Nsight Compute Roofline documentation combines compute, bandwidth and intensity. The ridge point is I = P/W. Below it, the bandwidth ceiling is lower; above it, the compute ceiling is lower. The memory level and compute instruction path must match the analysis.

Use this to decide what to investigate. Do not label a service “bandwidth-bound” simply because its achieved performance sits far below a peak line: low utilization, dependencies and uncounted work can invalidate that shortcut.

4. A worked example: twice the compute, unchanged time floor

Every number below is invented. Assume one device with enough capacity, a synthetic workload containing 7 billion two-byte weights, and one multiply plus one addition per weight per token. All weights are read once per batch step. Ignore attention, KV traffic, activations, launches, scheduling and communication.

At batch 1, that is F = 14 billion operations and Q = 14 billion bytes, or 14 GB in decimal units. Give the imaginary device P = 500 TFLOP/s and W = 2 TB/s. Then I = 1 FLOP/byte and the ridge point is 250 FLOPs/byte.

A · Baseline

14 GB ÷ 2 TB/s = 7 ms transfer
14 billion FLOPs ÷ 500 TFLOP/s = 0.028 ms arithmetic

Ideal floor: max(7, 0.028) = 7 ms

B · Double compute only

Transfer stays 7 ms.
Arithmetic falls to 0.014 ms.
Ideal floor stays 7 ms.

C · Double bandwidth only

Transfer falls to 3.5 ms.
Arithmetic stays 0.028 ms.
Ideal floor becomes 3.5 ms.

Original diagram; synthetic arithmetic, not observed hardware performance. A lower ideal floor is not a guaranteed application speedup. All assumptions and values also appear in the text.

Now keep the baseline device and reuse the weights across larger batches. Under this deliberately weight-only model, Q remains 14 GB and transfer time remains 7 ms while F grows with batch size. All table times are milliseconds:

Batch	Math (ms)	Floor (ms)
1	0.028	7
64	1.792	7
512	14.336	14.336

Batch 512 crosses the toy ridge point, making compute the larger term. This is not a recommendation to batch 512 real users: the omitted KV state, attention, activation traffic and latency constraints could make that configuration impractical.

Calculation check: Node.js 24.14.1 on Windows, October 22, 2026; 12 arithmetic assertions executed. No GPU or LLM was run. The calculation validates the displayed numbers, not the realism of the simplified workload.

5. Check the service, then the kernel

Inter-token latency (ITL) describes spacing between output tokens; system throughput describes output across requests. NVIDIA’s NIM benchmarking metrics separates these from time to first token and total request latency. An improved total token rate does not by itself establish a smoother response for one person.

For the definitions and timing boundaries, follow the same-language guide LLM inference metrics: TTFT, TPOT, ITL and goodput. Here the next task is a controlled comparison, not another metric glossary.

Write down the workload. Keep the model revision, precision, input/output lengths, engine configuration and accelerator count comparable.
Separate load from batch. Sweep concurrency, record the batch actually scheduled and note waiting requests. NVIDIA’s benchmark parameters guide explains why concurrent clients and engine batch size can differ.
Keep timing distributions. Compare ITL and request-latency percentiles alongside throughput, under a stated service target. Do not hide a worse tail behind a better average.
Find the expensive stage. NVIDIA’s compute triage guide recommends timeline analysis when kernel priority is unclear, then targeted profiling. Change one limiting factor and remeasure absolute duration.

These are proposed checks, not tests performed for this article. A profiler’s collection overhead or changed clock/cache settings also deserves a note when comparing timings.

6. What this changes in AI-infrastructure analysis

Author’s interpretation: compare a system’s balance of resources against the workload it can economically serve, rather than reading peak compute as finished inference capacity. HBM capacity, HBM bandwidth and inter-device communication answer different design questions; one cannot substitute for the other in the calculation.

That does not mean “memory always wins” or that compute demand has peaked. A different batch, attention design, precision or execution path can move the bottleneck. Nor does a technical bottleneck prove any supplier’s sales, margin or share-price outlook.

For a separate capacity-and-platform question, see Vera Rubin NVL72 memory demand: HBM4 and SOCAMM2 scenarios. Rack memory arithmetic and measured decoding performance are complementary evidence—not interchangeable proof. This is technical and industry analysis, not a buy-or-sell recommendation.

Summary · which number answers which question?

Number	Useful question	Not enough to prove
Peak FLOP/s	What is the stated compute ceiling?	Actual decode speed
HBM bytes/s	How fast could data cross this boundary?	That the workload saturates it
Arithmetic intensity	Which ideal ceiling is lower?	The real end-to-end bottleneck
Measured ITL + throughput	What did this deployment deliver?	Performance at another load or configuration

The next check: state the memory boundary, calculate both ideal times, then measure the actual workload. Faster arithmetic matters when arithmetic is on the critical path; the headline alone cannot tell you whether it is.

Appendix · assumptions, limits and primary sources

GB and TB here are decimal, 10⁹ and 10¹² bytes. FLOP counts use two operations per multiply-add. The toy example assumes resident weights and complete ideal overlap; it omits all other traffic and overhead. Multi-device sharding, MoE routing, offload and speculative decoding require additional accounting. No particular CUDA, GPU or inference-engine version was installed or benchmarked for this post.

The NVIDIA performance-background guide contains older hardware examples; this article uses its general reasoning, not those devices as current product recommendations. NIM documentation identified itself as version 2.0.0 when checked. The JAX chapter is dated February 4, 2025; its TPU examples are not presented as GPU measurements.

Primary sources checked October 22, 2026 KST. Explanations, synthetic examples and the diagram are independently written. No source illustrations, screenshots or font files were copied.

Build a Memory-Earnings Comparison Sheet Without Mixing Units

2026-10-22T00:19:16.276+09:00

Build a memory-earnings comparison sheet by keeping the reported value, currency, scale, reporting period, business scope and accounting basis in separate columns. Normalize millions and billions only within the same currency. Leave undisclosed values missing, and block comparisons whose definitions do not match.

If two numbers look wildly different, first check the currency and the unit printed above the source table. The safe next step is to copy those labels alongside the original number—not to divide the larger number until it looks plausible. A unit conversion cannot repair a different fiscal period or turn company-wide sales into DRAM revenue.

This is an English-language, beginner-friendly data-cleaning exercise, checked on October 21, 2026. The Python example runs locally without packages, credentials, web scraping or paid APIs. All amounts in the execution example are fictional; they are not Samsung, Micron or SK hynix results, and the output is not an investment ranking.

Contents and working definitions

A source ledger: one traceable record for each reported figure.
Comparison gates: checks that keep unlike measurements apart.
Scale normalization: expressing an amount in another unit, without changing its currency.
Missing-value status: the reason a cell has no usable number.
A review-ready sheet: raw evidence beside derived values, with unresolved comparisons visibly held.

1. Start with a source ledger, not a ranking

A source ledger is a table that preserves where a value came from and what it actually measures. Give each figure its own row before arranging companies side by side. Keep the original wording and amount; put derived values in new columns.

Column group	Record explicitly
Identity and evidence	Company, metric, source URL, page or table, publication date and collection date
Period	Period start and end, duration, fiscal label, and whether the number is a quarter or year-to-date
Amount	Reported decimal text, currency and scale; normalized amount and target scale separately
Meaning and status	Consolidated or segment scope; revenue or profit; accounting/adjustment basis; actual, preliminary estimate or forecast; missing-value reason

For example, Samsung’s October 8 third-quarter guidance identifies consolidated estimates based on K-IFRS. That document is not a standalone DRAM revenue table. Micron’s September 30 prepared remarks identify fiscal Q4 2026 and state that financial discussion uses non-GAAP measures unless specified otherwise. Copy the basis attached to the particular figure; do not apply a single label blindly to every metric.

Those examples show why a column called simply “Q3 earnings” is inadequate. Record the actual dates from the relevant financial statements, and use the same named metric. A fiscal-quarter label alone does not establish matching calendar exposure. A 13-week quarter and a longer quarter also deserve an explicit duration note.

2. Use comparison gates before calculating

A comparison gate is a visible pass, warning or hold attached to a proposed comparison. “Hold” means the definition needs resolving; it does not mean the company is weak or the missing number is zero.

1 — Capture
Original amount + source + period + definition

↓

2 — Normalize scale
Billion → million, while preserving USD or KRW

↓

3 — Check comparability
Currency, dates, scope, metric, basis and status

↓

4 — Release or hold
Calculate only the comparison whose assumptions are documented

Original workflow diagram. Unit conversion is one step, not permission to rank unlike disclosures.

Currency: USD million and KRW million remain different units of account. Keep separate columns unless an explicit foreign-exchange method is documented.
Period: check actual start/end dates and duration. Do not compare a quarterly flow with a cumulative nine-month flow.
Scope and metric: consolidated revenue, a memory segment’s revenue, operating profit and gross margin answer different questions. Percentage margins are not currency amounts.
Basis and status: distinguish adjustments and preliminary estimates from reported actuals. Use reconciliations where available; “same scale” does not reconcile accounting definitions.

A different fiscal period need not make all discussion impossible. It makes a strict same-period comparison unavailable: show the dates and qualify the observation, rather than silently relabeling both rows as the same quarter.

3. Run a small, local scale-normalization example

Scale normalization changes the presentation unit of an amount. One billion equals 1,000 million. Thus 1.25 USD billion becomes 1,250 USD million; 1,800 KRW billion becomes 1,800,000 KRW million. Neither operation converts won to dollars.

The following complete script was executed on Windows with Python 3.14.3. Save it as normalize.py, then run python normalize.py in that folder. It prints CSV text to the terminal and does not create or overwrite files. Copy the output into a new scratch sheet using a CSV import operation with a comma delimiter; review imported column types instead of assuming the spreadsheet preserves them.

It is deliberately only the amount-normalization component. It does not extract filings, validate accounting definitions, check quarter dates, perform currency conversion or generate forecasts. Add the source-ledger columns from section 1 before using any output for real comparisons.

Python — complete, locally executed synthetic example

"""Synthetic amount-scale demo only: no FX conversion or investment ranking."""
import csv
import sys
from decimal import Decimal, InvalidOperation


def to_millions(value, scale):
    factors = {"million": Decimal("1"), "billion": Decimal("1000")}
    if scale not in factors:
        raise ValueError("scale must be million or billion")
    if value is None:
        return None
    if not isinstance(value, str) or not value.strip():
        raise ValueError("use a decimal string or None")
    try:
        amount = Decimal(value)
    except InvalidOperation as error:
        raise ValueError("invalid decimal string") from error
    if not amount.is_finite():
        raise ValueError("amount must be finite")
    return amount * factors[scale]


if __name__ == "__main__":
    # Fictional revenue amounts, not real company disclosures.
    samples = [
        ("Demo A", "USD", "1250", "million"),
        ("Demo B", "USD", "1.25", "billion"),
        ("Demo C", "KRW", "1800", "billion"),
        ("Demo D", "USD", None, "million"),
    ]
    writer = csv.writer(sys.stdout, lineterminator="\n")
    writer.writerow([
        "company", "currency", "raw_value", "raw_scale",
        "amount_million", "status",
    ])
    for company, currency, value, scale in samples:
        normalized = to_millions(value, scale)
        writer.writerow([
            company, currency, value, scale,
            "" if normalized is None else format(normalized, "f"),
            "not_disclosed" if normalized is None else "reported",
        ])

Why use decimal strings? Python’s Decimal documentation explains that constructing a decimal directly from a binary float can retain that float’s approximation. This example accepts strings, rejects floats, and rejects NaN and Infinity. It uses the default decimal context; it is not a general-purpose unlimited-precision financial engine.

Observed terminal output — fictional amounts

company,currency,raw_value,raw_scale,amount_million,status
Demo A,USD,1250,million,1250,reported
Demo B,USD,1.25,billion,1250.00,reported
Demo C,KRW,1800,billion,1800000,reported
Demo D,USD,,million,,not_disclosed

Demo A and Demo B now have equal numeric amounts expressed in USD million. That is a unit-equivalence check, not proof their fictional revenue definitions or periods match. Demo C is still denominated in KRW. Demo D has no reported amount and no normalized number.

Execution checks: the local test suite checked six valid cases and nine rejection cases: both scales, zero, missing, a negative amount, empty inputs, comma-formatted text, non-finite values, numeric floats/booleans and unsupported units. All 15 cases passed. These are synthetic-input checks—not an audit of company disclosures or a test of Excel/Google Sheets import behavior.

4. Preserve missing values and their reasons

A missing value is an absent measurement, not a measured zero. Keep a separate status such as not_disclosed, not_collected or not_applicable. In this narrow example, None specifically means “not disclosed”; an empty string is rejected so it cannot accidentally acquire that meaning.

Python’s CSV writer documentation notes that None is written as an empty field and that this transformation is not reversible by itself. The status column preserves the missingness meaning in our output. In a spreadsheet, visibly distinguish missing cells from zero, and do not rely on a blank cell’s default arithmetic behavior.

If a total requires three components and one is undisclosed, label the result incomplete rather than presenting the sum of the other two as the total. Likewise, do not subtract an undisclosed HBM value from a broader revenue line to invent a “conventional DRAM” result. Derivation needs compatible, disclosed components and a documented definition.

5. Review the sheet before sharing it

What changed?	What did not?
Billion → million	Currency, business scope and accounting basis remain unchanged.
A date label was copied	Actual period alignment still needs checking.
Missing became an empty CSV cell	The status must still distinguish absence from a measured zero.
Numbers now fit one table	Comparability and investment conclusions have not been established.

Before calculating growth or margins, check the source again, confirm the denominator, and label the comparison period. Round only for display; preserve the source’s stated precision. If a figure is approximate or given as a qualitative range, retain that qualification rather than filling in an exact point estimate.

In short: preserve raw evidence, normalize scale in a separate column, then pass the comparison gates. Leave unresolved rows on hold. The next useful step is to populate one company’s comparable periods before expanding across companies—not to force a ranking from the first four numbers you find.

Appendix. Reading the memory-industry thread

For the business question behind the data, continue with what memory prices do—and do not—show about Samsung’s profit estimate. For a different unit trap in hardware specifications, see SOCAMM2 capacity, bandwidth and module counts. These are related English articles, not translations of this exercise.

If you later add foreign-exchange conversion, retain the reported currency and value, the exchange-rate source, rate date or averaging window, and the method used. A convenience conversion is not automatically a company’s reported constant-currency measure. This guide is for reading disclosures and cleaning data, not a buy/sell recommendation.

Primary sources and scope

Samsung Electronics, third-quarter 2026 guidance — October 8, 2026; used for document scope, estimates and K-IFRS labeling, not synthetic amounts.
Micron, fiscal Q4 2026 prepared remarks — September 30, 2026; fiscal-period and accounting-basis wording, not a cross-company ranking.
Python, decimal — decimal construction, precision and non-finite values.
Python, csv — CSV output and missing-value behavior. The unversioned documentation currently resolves to Python 3.15; the actual example was run with Python 3.14.3.

Sources checked October 21, 2026. Code and workflow are original. All demo amounts are hypothetical. No external package installation, live financial-data collection or paid API call was performed.

DRAM·NAND 실적, 가격·비트 출하량·제품 믹스를 나눠 읽는 법

2026-10-21T06:45:02.443+09:00

메모리 매출이 늘었다고 해서 판매가격만 그만큼 오른 것은 아닙니다. DRAM·NAND 실적은 가격, 판매한 메모리 용량인 비트 출하량, 어떤 제품을 더 팔았는지를 뜻하는 제품 믹스를 나눠 읽어야 합니다. 특히 기업 전체 잠정실적이나 시장 가격지수만으로 특정 회사의 DRAM·NAND 가격 효과를 역산하면 판단이 어긋날 수 있습니다.

같은 ‘메모리 호황’이라도 매출이 늘어난 경로는 다릅니다. 가격이 더 올랐는지, 더 많은 용량을 팔았는지, HBM이나 서버용 제품의 비중이 바뀌었는지에 따라 다음 분기에 확인할 숫자도 달라집니다. 아래는 2026년 10월 21일 KST에 확인한 공식 자료와 직접 검산한 가상 예제로 실적을 읽는 방법입니다. 개별 종목의 매수·매도 추천이나 주가 전망을 보장하는 글은 아닙니다.

먼저 확인할 세 가지

범위: 연결 전체 매출인가, DRAM·NAND 제품군 매출인가?
분모: 전분기 대비인가, 전년 동기 대비인가? 가격과 물량의 제품·기간 기준은 같은가?
정밀도: 실제 수치인가, 반올림·범위 표현인가? 모르는 값을 억지로 채우지 않았는가?

목차와 핵심 용어

ASP와 비트 출하량: 평균 판매단가와 판매한 메모리 용량입니다.
가격·물량의 곱셈: 증가율은 같은 기준에서 곱으로 결합합니다.
제품 믹스: 제품별 판매 비중이 바뀌는 효과입니다.
마이크론 공시 읽기: 근삿값으로 만든 검산과 회사 보고값을 구분합니다.
삼성·SK하이닉스 자료 범위: 잠정 연결 실적과 제품별 설명을 섞지 않습니다.
매출과 이익: 매출총이익률·영업이익률은 다른 항목입니다.
요약·비교와 출처: 다음 실적에서 확인할 순서를 정리합니다.

1. ASP와 비트 출하량은 같은 단위부터 맞춘다

ASP(Average Selling Price)는 평균 판매단가입니다. 다만 ‘무엇 하나당’ 가격인지가 중요합니다. 같은 제품 범위에서 용량당 가격을 볼 때와 칩·모듈·완제품 한 개당 가격을 볼 때는 분모가 다릅니다. 회사가 단순히 가격 변화라고 발표했다면 그 표현과 설명 범위를 먼저 보존하고, 이를 임의로 정확한 비트당 ASP 수치로 바꾸지 않는 편이 안전합니다.

비트 출하량은 메모리를 몇 개 팔았는지가 아니라 판매 용량이 얼마나 늘었는지 보는 기준입니다. 예를 들어 두 배 용량의 칩을 같은 개수만큼 팔면 칩 개수는 같아도 판매 용량은 달라집니다. 출하와 매출 인식이 같은 범위를 가리키는지도 확인해야 합니다.

단순 모형은 매출 = 용량당 평균단가 × 판매 용량입니다. 하지만 실제 공시와 맞추려면 제품군, 회계기간, 통화, 매출 인식 기준이 일치해야 합니다. 현물 가격지수나 특정 규격의 계약가격은 회사 전체 평균 판매가격과 같지 않으며, 서로 다른 지표를 곱해 회사 매출을 계산해서는 안 됩니다.

2. 가격 20%·물량 10% 증가면 매출은 30%가 아니라 32%

같은 제품·기간·통화 기준이라면 가격과 물량 증가율은 더하지 않고 곱합니다. 아래는 수수료·환율·매출 인식 차이 등을 제외한 가상 계산이며 실제 회사의 실적 전망이 아닙니다.

매출 증가율 = (1 + 가격 증가율) × (1 + 물량 증가율) − 1

1.20 × 1.10 − 1 = 0.32, 즉 32%입니다. 가격 20%와 물량 10%를 더한 30%에는 두 변화가 함께 작용하는 2%포인트가 빠져 있습니다.

가격 요인 · 1.20배

같은 제품 범위의 용량당 평균단가 +20%

물량 요인 · 1.10배

같은 기준의 판매 비트 용량 +10%

↓

매출 요인 · 1.32배

가상 매출지수 100 → 132
단순 합계 30%가 아닌 32% 증가

자체 제작 가상 도식. 같은 제품·기간·통화·단위라는 가정 아래의 산술이며 실제 DRAM·NAND 가격지수나 기업 전망이 아닙니다. 가격과 비트 출하량의 공시 기준이 다르면 그대로 적용할 수 없습니다.

반대로 가격이 20% 올라도 물량이 15% 줄면 1.20 × 0.85 − 1 = 2% 증가입니다. 가격 강세만 보고 매출 성장률을 고정해 놓으면 이런 반대 요인을 놓칩니다.

3. 제품 가격이 그대로여도 평균단가는 오를 수 있다

제품 믹스는 전체 판매에서 제품별 비중이 바뀌는 것을 말합니다. 같은 용량 기준으로 값을 셀 수 있는 가상 DRAM 제품 A와 B를 생각해 보겠습니다. A의 단가는 1, B의 단가는 3이며 두 제품의 단가는 다음 기간에도 그대로라고 가정합니다. 이는 실제 DDR·HBM 가격표가 아닙니다.

가상 상황	용량 구성·매출
이전	A 90 + B 10 총용량 100 매출 90×1 + 10×3 = 120
이후	A 80 + B 20 총용량 100 매출 80×1 + 20×3 = 140

전체 용량은 100으로 같지만 매출은 약 16.7% 늘고, 용량당 평균단가는 1.2에서 1.4로 높아집니다. 각 제품의 가격을 올린 것은 아닙니다. 비중 변화가 평균에 영향을 준 것입니다. 따라서 이미 믹스가 반영된 평균단가에 별도의 믹스 증가율을 다시 곱하면 같은 효과를 두 번 셀 수 있습니다.

HBM은 DRAM 제품군 안에서 분류를 확인해야 합니다. 삼성의 공식 제품 분류도 HBM을 DRAM 아래에 둡니다. 회사가 DRAM에 HBM을 포함해 발표한 매출이라면 DRAM 매출과 HBM 매출을 독립 항목처럼 더하지 않습니다. NAND와 기업용 SSD 역시 회사가 제시한 제품·사업부 범위부터 확인해야 합니다. 삼성 HBM 공식 제품 분류

4. 마이크론의 ‘약 30%·약 10%’를 정확한 원시값으로 바꾸지 않는다

공시의 근삿값으로 계산한 결과와 회사가 보고한 실제 매출 증가율은 구분해야 합니다. 마이크론은 2026년 9월 30일 발표한 회계연도 2026년 4분기 준비 발언문에서 NAND의 전분기 대비 매출 증가율을 42%, 비트 출하량 증가를 약 10%, 가격 증가를 약 30%로 설명했습니다. Micron 공식 준비 발언문, 인쇄 페이지 7

공개된 근삿값만 넣으면 1.30 × 1.10 − 1 = 43%입니다. 이 계산은 42%라는 보고값을 틀렸다고 판정하는 도구가 아닙니다. 근사·반올림, 항목의 정의와 범위가 일치하는지 먼저 확인해야 합니다. 남는 차이를 곧바로 ‘믹스 효과 −1%포인트’라고 이름 붙이지 않습니다. 정확한 원자료와 기업의 조정 설명 없이 원인을 분해할 수는 없습니다.

DRAM 비트·가격 증가도 각각 한 자릿수 중반·10%대 후반이라는 원문의 범위를 보존합니다. 임의의 정확한 숫자를 골라 공식을 맞추거나 미공개 ASP를 추정하지 않습니다.

5. 삼성·SK하이닉스·마이크론의 자료 범위는 같지 않다

기업 비교는 발표일과 실적 기간, 연결·제품·사업부 범위를 맞추는 작업에서 시작합니다. 아래는 읽는 법을 보여주기 위해 선택한 자료이며, 같은 분기 실적 순위를 매기는 표가 아닙니다. 회계연도 분기와 달력 분기를 같은 이름이라고 자동으로 맞추지도 않습니다.

삼성전자 · 2026년 10월 8일 발표 · 2026년 3분기 잠정실적

이 발표문은 연결 매출과 영업이익 추정치가 중심입니다. 이 문서만으로 DRAM·NAND의 ASP·비트 출하량·가격만의 이익 기여도를 분리할 수는 없습니다. 연결 전체의 이익 증가율을 메모리 가격 상승률로 옮겨 적지 않습니다. 삼성 공식 잠정실적

SK하이닉스 · 2026년 7월 29일 발표 · 2026년 2분기 실적 설명

회사는 가격 상승과 HBM·AI 서버용 DRAM·기업용 SSD 등 고부가 제품 판매 확대를 함께 설명했습니다. 방향에 대한 설명과 가격·물량·믹스의 정확한 수치 분해는 다른 자료입니다. 이 발표문이 제공하지 않는 기여도는 미확인으로 남깁니다. SK하이닉스 공식 2분기 발표

또한 같은 회사의 제품별·사업부별·지역별 표는 서로 다른 분류 축일 수 있습니다. 각 표의 매출을 독립적인 매출처럼 더하지 말고 어떤 기준으로 나눈 표인지 먼저 확인하세요.

미공개 값은 0이 아닙니다. 비교 메모에 ‘이 문서에 없음’, ‘범위 표현만 제공’, ‘기간이 다름’이라고 적어 두는 편이, 숫자를 채운 뒤 그럴듯한 비교를 만드는 것보다 유용합니다.

6. 고부가 제품 비중과 이익률도 자동으로 같은 방향은 아니다

매출총이익률은 매출에서 매출원가를 뺀 이익의 비율이고, 영업이익률은 영업비용까지 반영한 영업이익의 비율입니다. 매출 증가, 매출총이익 증가, 영업이익 증가를 같은 수치로 대체하지 않습니다. 원가·제품별 수익성·생산 및 판매 시점에 따라 결과가 달라질 수 있습니다.

마이크론은 이 분기 CMBU(Cloud Memory Business Unit)의 가격 개선 효과가 높아진 HBM 믹스로 상쇄됐다고 설명했습니다. 이는 해당 사업부·분기의 매출총이익률 설명이며 HBM 전체의 수익성에 대한 일반법칙이 아닙니다. Micron CMBU 설명, 인쇄 페이지 7

독자가 다음 실적에서 확인할 것은 가격의 지속성뿐 아니라 출하량, 믹스, 원가와 이익률의 연결입니다. 가격만 먼저 움직이고 물량·제품 수익성이 따라오지 않는 경우도 열어 두세요. 장기 수요 전망과 이번 분기에 인식한 매출·이익은 서로 다른 판단입니다.

7. 요약: 매출 성장의 원인을 세 칸으로 나눠 적는다

가격: 같은 제품·용량 기준 가격이 얼마나 바뀌었나? 회사의 평균인가, 시장 지표인가?
비트 출하량: 칩 개수가 아닌 용량 기준인가? 가격과 같은 기간·제품 범위인가?
제품 믹스: 무엇을 더 팔았나? 평균단가에 이미 반영된 효과를 다시 더하고 있지는 않나?
이익: 제품·사업부 원가와 비용을 반영한 뒤에도 개선되는가?

기본 순서는 범위·단위 맞추기 → 공개된 수치와 범위 표현 보존 → 곱셈 검산 → 미확인 값 구분 → 이익률 설명 확인입니다. 매출 증가율에서 설명이 남는다고 바로 믹스나 특정 기업의 경쟁력으로 이름 붙이지 않는 것이 중요합니다.

관련 글타래로는 마이크론 실적에서 메모리 호황의 지속성을 살펴본 글을 이어 읽을 수 있습니다. 수요 전망과 계약의 질을 분리하려면 AI 인프라 투자 회의론과 공급계약의 확실성을 다룬 분석이 연결됩니다. 이 글의 가격·물량·믹스 분해와는 다른 질문이므로 함께 보되 같은 지표처럼 섞지 마세요.

Appendix · 계산·확인 범위와 1차 출처

자료 확인일은 2026-10-21 KST입니다. 예제의 가격 20%·물량 10% 및 −15%, 제품 A·B의 단가 1·3과 용량 구성 90·10 및 80·20은 모두 가상입니다. 실제 기업 가격·시장지수·이익 예측으로 사용하지 않습니다. 계산은 로컬 Node.js로 검산했으며 기업의 미공개 원자료나 실험·주가 성과를 검증한 것은 아닙니다.

Micron의 ‘약 30%·약 10%’를 이용한 43%는 공개된 근사율을 넣은 검산값입니다. 회사의 보고값 42%와 혼동하지 않습니다. 삼성 잠정실적과 SK하이닉스의 해당 발표 역시 각 문서의 발표일·분기·잠정성 범위에서 인용했습니다. 주가·목표가·수익 보장은 제시하지 않았습니다.

CUDA 메모리 부족 오류, allocated·reserved·peak 로그는 어떻게 읽을까

2026-10-20T22:56:25.315+09:00

CUDA 메모리 부족 오류를 읽을 때는 현재 텐서 사용량인 allocated, 할당기가 관리하는 reserved, 측정 구간의 최대 텐서 사용량인 peak를 같은 측정 구간·장치 기준으로 기록해야 합니다. 먼저 작업 전후 로그와 peak 초기화 위치를 확인하세요. reserved와 allocated를 더하거나, 둘의 차이를 곧바로 단편화로 해석하면 진단이 어긋납니다.

30초 진단 순서

종료 로그는 낮은데 OOM이 난다: 한 작업 직전 peak를 초기화하고, 작업 후 현재값과 peak를 함께 기록합니다.
반복할수록 allocated가 오른다: 같은 입력 크기에서 기준선을 비교하고 결과 텐서·참조가 남는 위치를 확인합니다. 이 패턴만으로 누수라고 확정하지 않습니다.
reserved만 높아 보인다: 먼저 allocator backend와 로그 범위를 확인합니다. 무작정 empty_cache나 allocator 설정 변경부터 하지 않습니다.

적용 범위: PyTorch 2.14 공식 CUDA 문서, NVIDIA CUDA GPU를 쓰는 단일 프로세스의 단일 장치 진단입니다. 확인일은 2026-10-20 KST입니다. 아래 GPU 계측 코드는 문서 기반 미실행 예제이며, 실제로 실행한 부분은 GPU가 필요 없는 가상 로그 계산과 Python 문법 검사입니다. 다중 GPU·다중 프로세스·CUDA Graph 캡처 중인 서비스에 그대로 넣는 예제가 아닙니다.

목차와 한 줄 정의

allocated·reserved: 현재 텐서 사용량과 캐싱 할당기의 관리량입니다.
peak와 기준 구간: 마지막 초기화 이후 기록한 최대 텐서 사용량입니다.
작업 전후 계측: 같은 GPU에서 한 작업의 전후와 피크를 기록합니다.
가상 로그 해석: 종료 4 GiB와 구간 최대 9 GiB를 구분합니다.
증상별 다음 행동: 원인을 단정하지 않고 확인 범위를 좁힙니다.
요약·비교와 Appendix: 실행 여부와 제약을 다시 확인합니다.

1. allocated와 reserved는 더하는 숫자가 아니다

allocated는 해당 장치의 텐서가 현재 차지하는 메모리 바이트 수입니다. 이 값은 GPU 전체 사용량이 아닙니다. 공식 문서는 캐싱 할당기의 미사용 보유 메모리와 GPU 컨텍스트 때문에 nvidia-smi 표시와 다를 수 있다고 설명합니다. memory_allocated 공식 정의

reserved는 해당 장치에서 PyTorch 캐싱 할당기가 관리하는 메모리 바이트 수입니다. 일반적인 native backend의 그림에서는 allocated가 reserved 안에 들어갑니다. 예를 들어 reserved 10 GiB, allocated 4 GiB를 보고 총 14 GiB를 쓴다고 계산하면 안 됩니다. memory_reserved 공식 정의

단위도 맞춰야 합니다. API의 바이트 값을 1024²로 나누면 MiB, 1024³으로 나누면 GiB입니다. 이 글의 1 GiB는 1024 MiB입니다. 아래 가상 로그에서는 MiB를 사용하며, 제조사가 십진 GB로 표시하는 용량과 섞어 계산하지 않습니다.

2. peak는 ‘이번 작업의 추가 필요량’과 다르다

peak allocated는 측정 시작 이후 텐서가 가장 많이 차지했던 메모리입니다. 기본적으로 프로그램 시작 이후의 최댓값이므로 한 작업을 비교하려면 시작점을 다시 정해야 합니다. max_memory_allocated와 reset_peak_memory_stats가 이 용도로 쓰입니다.

모델을 올린 뒤 allocated가 이미 2 GiB이고 작업 중 peak가 9 GiB였다면, 관측한 최대 텐서 사용량은 9 GiB입니다. 그 차이 7 GiB는 시작값 대비 증가 폭이지, 어떤 입력에서도 보장되는 추가 용량이나 GPU 전체 필요량이 아닙니다. 실패한 할당 요청 크기까지 peak에 더해 기록된다고 가정해서도 안 됩니다.

초기화는 메모리를 비우는 동작이 아닙니다. peak 추적의 기준을 바꾸는 동작입니다. 다른 계측 코드가 같은 프로세스·장치의 peak를 보고 있다면 측정 구간에 간섭할 수 있으므로 독립된 재현 환경에서 사용하세요.

3. 한 작업의 전후 로그를 남기는 Python 예제

계측은 같은 장치·같은 조건에서 전후를 비교하는 절차입니다. 아래 코드는 작업 전에 동기화하고 peak를 초기화한 뒤 before·after를 출력합니다. OOM은 기록을 시도한 뒤 다시 전달하며 자동 재시도하지 않습니다. 이 코드를 실제 GPU에서 실행한 결과라고 주장하지 않습니다.

전제: 독자가 관리하는 CUDA 지원 PyTorch 환경, GPU 0 한 개, 동시에 같은 프로세스에서 GPU 작업을 추가하지 않는 진단 구간입니다. 아래 작은 텐서 예제를 실행하려면 gpu_memory_probe.py로 저장해 python gpu_memory_probe.py를 실행합니다. PyTorch 설치·드라이버 변경·유료 클라우드 작업은 이 글의 실행 검증 범위가 아닙니다.

Python · GPU 계측 예제 · 문법 검사만 수행, CUDA 실행 미검증

"""PyTorch 2.14 documentation-based CUDA example. GPU execution NOT tested here."""
import json
import torch

MIB = 1024 ** 2


def read_stats(tag, device=0):
    free_bytes, total_bytes = torch.cuda.memory.mem_get_info(device)
    return {
        "tag": tag,
        "device": device,
        "allocated_mib": round(torch.cuda.memory.memory_allocated(device) / MIB, 2),
        "reserved_mib": round(torch.cuda.memory.memory_reserved(device) / MIB, 2),
        "peak_allocated_mib": round(torch.cuda.memory.max_memory_allocated(device) / MIB, 2),
        "driver_free_mib": round(free_bytes / MIB, 2),
        "driver_total_mib": round(total_bytes / MIB, 2),
    }


def measure_step(step, device=0):
    if not torch.cuda.is_available():
        raise RuntimeError("CUDA GPU와 CUDA 지원 PyTorch가 필요합니다.")
    torch.cuda.synchronize(device)
    torch.cuda.memory.reset_peak_memory_stats(device)
    print(json.dumps(read_stats("before", device), ensure_ascii=False))
    try:
        result = step()
        torch.cuda.synchronize(device)
    except torch.OutOfMemoryError:
        try:
            print(json.dumps(read_stats("oom", device), ensure_ascii=False))
        except Exception as log_error:
            print("OOM 로그 수집 실패:", type(log_error).__name__)
        raise
    print(json.dumps(read_stats("after", device), ensure_ascii=False))
    return result


if __name__ == "__main__":
    print(json.dumps({"torch": torch.__version__, "cuda_runtime": torch.version.cuda}))
    if not torch.cuda.is_available():
        raise SystemExit("CUDA 사용 불가: GPU 예제는 여기서 종료합니다.")
    print("allocator:", torch.cuda.memory.get_allocator_backend())
    value = measure_step(lambda: torch.empty((256, 1024), device="cuda:0", dtype=torch.float32))

기본 예제의 텐서 원소 크기는 256 × 1024 × 4 bytes = 1 MiB입니다. 이는 텐서 데이터 크기의 계산이지 CUDA 컨텍스트·allocator의 전체 증가량을 예측한 값이 아닙니다. 자신의 코드에서는 measure_step에 한 번의 학습·추론 단계를 수행하는 함수를 전달하되 입력·출력 텐서의 수명을 기록해야 합니다. 반환값을 보유한 채 after를 찍기 때문에 그 결과 텐서도 현재 allocated에 남을 수 있습니다.

synchronize는 장치의 모든 stream에 있는 커널 완료를 기다립니다. 진단 구간을 구분하기 위한 것이며 평소 처리량을 측정하는 벤치마크 루프에 무심코 넣으면 동작과 성능을 바꿉니다. 여러 stream의 실제 서비스나 Graph 캡처 중에는 그대로 쓰지 마세요. synchronize 공식 문서

추가로 기록한 driver_free_mib는 cudaMemGetInfo가 반환하는 장치 전체 free/total 범위입니다. 이 프로세스의 allocated·reserved와 같은 범위가 아니며, 차례로 읽은 값은 원자적인 한 장면도 아닙니다. 다음 할당 성공 여부를 이 값 하나로 보장할 수 없습니다. mem_get_info

4. 종료 4 GiB, peak 9 GiB인 로그를 읽어 보자

가상 로그는 계산법을 설명하기 위해 만든 입력입니다. 실제 장치 출력이나 위 작은 텐서 예제의 예상 출력이 아닙니다. native backend의 단순화한 예로 시작 allocated 2 GiB, 종료 allocated 4 GiB, 종료 reserved 10 GiB, 구간 peak allocated 9 GiB를 사용합니다.

시작 · allocated 2 GiB

기존 텐서를 보유한 상태에서 peak 기준 설정

↓

구간 최대 · peak allocated 9 GiB

중간 텐서가 많아진 시점의 기록값

↓

종료 · allocated 4 GiB

중간 피크가 지나간 뒤의 현재값

종료 reserved 10 GiB 안에 allocated 4 GiB 포함

차이 6 GiB ≠ 확정 단편화 크기
차이 6 GiB ≠ 다음 요청에 보장된 가용량

자체 제작 가상 도식. 중간 최대값과 종료값을 더하지 않습니다. 단순화한 텐서 사용량 흐름이며 GPU 전체 메모리 지도나 실제 측정 차트가 아닙니다.

아래 계산 예제는 PyTorch를 import하지 않는 순수 Python입니다. Windows x64의 Python 실행 결과를 제시하며 가상 입력의 산술만 검증했습니다.

Python · analyze_demo.py · 가상 입력 산술 검증

"""CPU-only arithmetic on explicitly synthetic CUDA-style logs. No torch import."""
before = {"allocated_mib": 2048, "reserved_mib": 4096, "peak_allocated_mib": 2048}
after = {"allocated_mib": 4096, "reserved_mib": 10240, "peak_allocated_mib": 9216}

allocated_growth = after["allocated_mib"] - before["allocated_mib"]
peak_above_start = after["peak_allocated_mib"] - before["allocated_mib"]
peak_above_end = after["peak_allocated_mib"] - after["allocated_mib"]
reserved_gap = after["reserved_mib"] - after["allocated_mib"]

assert allocated_growth == 2048
assert peak_above_start == 7168
assert peak_above_end == 5120
assert reserved_gap == 6144
assert after["peak_allocated_mib"] / 1024 == 9
assert 1024 ** 3 / (1024 ** 2) == 1024
assert after["reserved_mib"] >= after["allocated_mib"]

print("입력: 가상 로그, GPU 실측 아님")
print(f"allocated 증가: {allocated_growth} MiB ({allocated_growth / 1024:.2f} GiB)")
print(f"구간 peak: {after['peak_allocated_mib']} MiB ({after['peak_allocated_mib'] / 1024:.2f} GiB)")
print(f"peak - 시작 allocated: {peak_above_start} MiB ({peak_above_start / 1024:.2f} GiB)")
print(f"끝 reserved - allocated: {reserved_gap} MiB ({reserved_gap / 1024:.2f} GiB)")
print("판정: 단편화·다음 할당 성공 여부는 이 로그만으로 미확인")

실제로 실행한 계산 출력 · GPU 실측 아님

입력: 가상 로그, GPU 실측 아님
allocated 증가: 2048 MiB (2.00 GiB)
구간 peak: 9216 MiB (9.00 GiB)
peak - 시작 allocated: 7168 MiB (7.00 GiB)
끝 reserved - allocated: 6144 MiB (6.00 GiB)
판정: 단편화·다음 할당 성공 여부는 이 로그만으로 미확인

이 예에서는 종료값만 보면 4 GiB지만 구간 최대는 9 GiB입니다. peak와 종료값의 차이는 5 GiB입니다. 따라서 종료 시 스냅샷만 보고 여유가 충분했다고 결론내릴 수 없습니다. 반대로 reserved−allocated가 6 GiB라는 사실만으로 그 공간이 모두 즉시 반환 가능하다거나 그만큼 단편화됐다고 결론내리지도 않습니다.

5. 패턴별로 한 가지씩 확인한다

allocated 기준선이 계속 오른다: 입력 크기와 반복 조건을 고정해 로그를 비교하고, 보관 중인 출력·참조를 확인합니다. 의도한 캐시나 워밍업일 수도 있으므로 증가만으로 누수 판정은 하지 않습니다.
현재값은 비슷한데 peak만 크다: 입력 길이·배치·작업 단계를 기록합니다. 한 변수를 바꿔 피크가 어떻게 달라지는지 다시 확인합니다. 성능·정확도까지 함께 검수해야 하며 배치 축소가 모든 문제의 정답은 아닙니다.
reserved와 allocated 차이가 크다: backend를 확인하고 필요할 때 torch.cuda.memory_summary(device=0) 또는 allocator snapshot으로 블록 상태를 더 봅니다. 단편화는 후보이지 이 차이만으로 확정된 원인이 아닙니다.
PyTorch 로그와 전체 장치 사용량이 크게 다르다: 장치·프로세스 범위와 PyTorch 밖의 할당을 확인합니다. 다른 사용자의 프로세스를 임의로 종료하지 않습니다.

empty_cache는 살아 있는 텐서를 지우지 않습니다. 공식 문서는 미사용 캐시를 반환하는 동작과 텐서가 점유한 메모리를 구분합니다. allocator 옵션도 첫 조치가 아닙니다. 특히 max_split_size_mb는 native backend의 inactive split 블록 근거가 있는 경계 사례에서 검토하는 마지막 수단으로 안내되며, 성능 비용이 생길 수 있습니다. 이 글은 해당 설정을 자동 변경하거나 고정 값을 권하지 않습니다. PyTorch 메모리 관리

고급 snapshot도 모든 CUDA 할당을 보여주는 것은 아닙니다. 공식 메모리 시각화 문서는 PyTorch allocator를 통하지 않는 할당이 보이지 않을 수 있음을 설명합니다. 기록 파일에는 모델·코드 경로 같은 운영 정보가 포함될 수 있으므로 승인 없이 외부에 업로드하지 마세요. Understanding CUDA Memory Usage

6. 요약·비교: 현재값, 관리량, 구간 최대를 분리한다

로그 항목	먼저 답할 질문
allocated	지금 텐서가 얼마를 차지하나?
reserved	할당기가 얼마를 관리하나?
peak allocated	기준 구간 중 얼마나 높아졌나?
driver free	장치 전체 free 범위는 어떤가?

안전한 순서는 환경·backend 기록 → 같은 장치에서 시작점 설정 → 한 작업의 before·after·peak 기록 → 한 변수씩 바꿔 재확인입니다. 로그가 알려주는 범위보다 더 큰 결론을 내리지 않는 것이 핵심입니다. peak를 줄였더라도 처리량과 응답 지연이 좋아졌다고 자동으로 결론내릴 수는 없습니다.

관련 개념은 같은 언어 글타래로 이어 볼 수 있습니다. 브라우저 메모리와 서버 KV Cache를 나누어 보는 글은 측정 위치를 구분하는 데, TTFT·TPOT·ITL과 처리량 설명은 메모리 변경 후 응답 품질을 무엇으로 검증할지 정하는 데 도움이 됩니다. 서로 다른 자원·성능 지표를 한 숫자로 대체하지 마세요.

Appendix · 실행 환경, 실패 조건과 출처

확인일 2026-10-20 KST. 문서 기준은 PyTorch 2.14입니다. GPU 계측 코드는 CUDA 지원 환경이 필요하고, CUDA 미지원·잘못된 장치·OOM·동시 작업·서로 다른 allocator backend에서는 실행 또는 해석에 제약이 생깁니다. 특히 일부 allocator 통계는 backend에 따라 의미가 달라집니다. 현재 allocator backend 확인

실행 여부: 가상 로그 계산은 Windows x64의 Python 3.14.3으로 실행하고 일곱 산술 조건을 확인했습니다. GPU 코드는 Python 문법만 검사했으며 PyTorch import·CUDA 실행·실제 LLM·처리량·메모리 누수 재현은 수행하지 않았습니다. 실제 GPU 출력이나 OOM 해결을 보장하는 글이 아닙니다. 설치 패키지·드라이버·전역 설정은 변경하지 않았습니다.

Aside vs ego lite, AI 브라우저는 무엇이 다를까? 기능·비용·보안 비교

2026-10-20T17:16:47.273+09:00

Aside와 ego lite의 차이는 AI가 있느냐보다, 내가 쓰는 에이전트와 브라우저를 어떤 방식으로 연결하느냐에 있습니다. 브라우저 안에서 작업·기억·반복 실행을 묶어 시작하려면 Aside를, 기존 AI 에이전트가 웹을 조작하는 작업 공간을 붙이려면 ego lite를 먼저 살펴볼 만합니다. 다만 Aside도 CLI·MCP·REPL을 지원하므로 ‘Aside는 내장형만, ego lite는 외부 연결만’이라는 이분법은 정확하지 않습니다.

이 글에서 Aside는 aside.com의 AI 브라우저, ego lite는 egolite.app의 브라우저를 뜻합니다. 기준일은 2026년 10월 20일이며, 공식 문서·다운로드 안내·공개 요금 화면을 비교했습니다. 두 제품을 같은 PC에서 설치해 속도·메모리·성공률을 겨룬 실측 리뷰는 아닙니다. 아래 선택 기준은 문서에 대한 해석이며 성능 우열이나 보안 인증을 뜻하지 않습니다.

30초 선택: 이미 쓰는 에이전트부터 확인하세요.

“브라우저에서 요청하고 반복 작업까지 한곳에서 관리하고 싶다” → Aside의 기본 작업 흐름과 루틴을 확인합니다.
“쓰던 코딩 에이전트에 로그인된 웹 작업을 연결하고 싶다” → ego lite의 연결 방식과 Space를 확인합니다. Aside의 MCP 연결도 비교 후보입니다.
회사·고객 정보를 다룬다 → 무료 여부보다 조직의 사용 승인과 모델 전송 범위를 먼저 확인합니다. ‘로컬’이라는 표현만으로 안전하다고 판단하지 않습니다.

목차와 핵심 용어

AI 브라우저와 에이전트: 화면을 여는 프로그램과 다음 행동을 결정하는 AI는 서로 다른 역할입니다.
Aside: 브라우저와 AI 작업 기능을 묶은 제품이며 외부 도구 연결도 제공합니다.
ego lite: 기존 에이전트에 브라우저 조작 환경을 연결하는 데 초점을 둡니다.
작업 흐름: 요청이 모델과 웹사이트까지 이동하는 경로입니다.
비용: 브라우저 요금과 에이전트·모델 요금을 분리해서 봅니다.
데이터와 권한: 로컬 저장과 외부 모델의 처리는 별개의 문제입니다.
안전한 비교 방법: 같은 공개 자료를 같은 완료 조건으로 확인합니다.

1. AI 브라우저와 AI 에이전트는 같은 것이 아니다

AI 브라우저는 웹을 열고 조작하는 환경이고, 에이전트는 목표에 맞춰 읽기·클릭·입력 같은 행동을 결정하는 소프트웨어입니다. 이를 한 제품에 묶을 수도 있고, 별도의 에이전트와 연결할 수도 있습니다. 웹사이트 로그인 상태, 도구의 권한, 연결된 모델에 따라 가능한 작업이 달라집니다.

MCP(Model Context Protocol)는 여기서 외부 에이전트가 도구에 연결하는 인터페이스를, CLI는 터미널 명령 인터페이스를, REPL은 명령을 입력하고 결과를 확인하는 대화식 실행 환경을 뜻합니다. 이 이름이 보인다고 해서 설치·연결 없이 곧바로 모든 에이전트에서 작동하는 것은 아닙니다. 지원 버전과 설정을 따로 확인해야 합니다.

2. Aside: 브라우저 안의 작업 묶음에서 출발한다

Aside의 특징은 브라우저 작업과 Memory·Routines 같은 기능을 제품 안에서 함께 안내한다는 점입니다. 공식 문서의 Routines는 정해진 시각이나 주기로 작업을 실행하는 기능입니다. 새 작업으로 실행하는 cron 방식과 기존 대화를 이어가는 heartbeat 방식을 구분합니다. 반복 실행이 필요하다면 단순히 예약 유무뿐 아니라 실패·겹침·중단 조건도 확인하는 편이 좋습니다. Aside Routines 공식 문서

외부 에이전트와 연결하는 길도 있습니다. 개발자 문서는 CLI로 작업을 시작하거나, MCP 서버로 다른 도구와 연결하거나, REPL로 페이지 확인·스크린샷 같은 세부 조작을 수행하는 경로를 설명합니다. 따라서 기존 개발 환경과 연결하려는 사람도 Aside를 비교 대상에 넣을 수 있습니다. Aside CLI·MCP·REPL 문서

이 글의 판단은 ‘통합된 기본 경험을 원하는가’입니다. 기능이 한곳에 있다는 이유만으로 복잡한 업무를 더 정확히 끝낸다고 단정할 수는 없습니다. 실제 업무에서 어느 단계에 사람 확인이 필요한지가 더 중요합니다.

3. ego lite: 기존 에이전트에 작업 공간을 붙인다

ego lite는 기존 AI 에이전트가 브라우저를 다룰 수 있도록 연결하는 Chromium 기반 브라우저입니다. 공식 Windows 문서는 ego-browser 도구를 통한 연결과 페이지의 조작 대상을 간결하게 전달하는 Snapshot을 설명합니다. 에이전트의 모델 선택·지시·도구 사용 능력이 결과에 영향을 줍니다. ego lite Windows 제품 소개

Space는 에이전트 작업을 나누는 브라우저 작업 공간입니다. 공식 설명상 작업마다 별도 BrowserContext를 두어 쿠키·저장소를 분리하며, 사용자는 작업 탭을 보고 개입할 수 있습니다. 그렇다고 모든 사이트에서 재로그인이 필요 없거나 회사 자료의 외부 전송이 차단된다고 보장하는 기능은 아닙니다. 작업 공간 분리와 정보 접근 권한은 다른 층위입니다. ego lite Space 문서

운영체제도 오래된 소개 글이 아닌 현재 다운로드 안내로 확인해야 합니다. 확인일 기준 Aside는 macOS·Windows를 안내하고, ego lite도 macOS와 Windows 베타를 제공합니다. ego lite의 일부 macOS 소개에는 Windows가 향후 계획처럼 남아 있지만 현재 Windows 문서·다운로드 페이지가 존재합니다. 베타의 안정성이나 기능 동등성은 이 글에서 검증하지 않았습니다. Aside 다운로드 안내, ego lite 다운로드 안내

4. 같은 웹 작업도 요청 경로가 다르다

작업 흐름은 ‘누가 판단하고, 어떤 도구가 화면을 조작하는가’를 보여주는 경로입니다. 아래는 제품의 대표적인 시작 방식을 단순화한 개념도입니다. 실제 네트워크 구성이나 모든 지원 모드를 그린 아키텍처는 아닙니다.

Aside에서 시작하는 경우

사용자 요청

↓

Aside의 AI 작업 기능 + 선택한 모델

↓

브라우저 조작 → 대상 웹사이트

외부 에이전트도 CLI·MCP·REPL로 연결 가능

ego lite에 연결하는 경우

사용자 요청 → 기존 AI 에이전트와 모델

↓

ego-browser 도구

↓

ego lite의 Space → 대상 웹사이트

사용자는 작업 공간을 보며 확인·개입

공식 개발자·제품 문서를 바탕으로 직접 구성한 개념도. 실제 UI 캡처나 속도 측정 결과가 아닙니다. 두 흐름 모두 모델·웹사이트로 전달되는 정보를 별도로 확인해야 합니다.

예를 들어 공개 제품 문서 세 개의 지원 OS를 표로 정리하는 작업이라면, 최종 표가 정확한지와 원문 링크가 맞는지를 확인해야 합니다. 첫 답변이 빨리 나왔다고 전체 작업이 빠른 것도 아닙니다. 모델 응답 지연과 작업 완료 시간을 구분하려면 TTFT·TPOT·ITL 등 LLM 추론 성능 지표를 함께 보면 이해에 도움이 됩니다.

5. 무료 브라우저와 무료 AI 작업은 다르다

총비용은 브라우저·도구 요금, 에이전트·모델 요금, 재시도와 사람 검수 부담을 나눠 보는 것이 좋습니다. 이는 비용을 비교하는 틀이며 실제 과금 산식이나 측정값은 아닙니다.

제품·플랜	표시 요금
Aside Free	US$0
Aside Pro	US$20/월
Aside Max	US$200/월
ego lite	브라우저 무료

Aside는 Monthly 선택 기준이며 무료 플랜은 월 500 credits를 안내합니다. 확인일 기준 표시 가격이므로 실제 결제 조건은 공식 화면에서 다시 확인하세요. ego lite의 무료 안내는 브라우저에 대한 것이며 연결하는 AI 에이전트·모델의 구독이나 API 사용료까지 무료라는 뜻은 아닙니다.

Aside 문서는 자체 credits와 외부 AI 구독·API 사용을 구분합니다. credits를 모델 토큰이나 ‘완료할 수 있는 작업 수’로 임의 환산하면 안 됩니다. 자신이 연결할 모델에서 어떤 요금이 별도로 발생하는지 확인해야 합니다. 이 글은 유료 결제나 작업당 비용 측정을 수행하지 않았습니다. Aside 공식 요금, Aside 구독·credits 문서, ego lite 비용 안내

6. ‘로컬 실행’은 ‘모델에 아무것도 보내지 않음’이 아니다

로컬 저장은 데이터가 내 컴퓨터에 보관되는 위치에 관한 말이고, 모델 처리는 어떤 내용이 AI 제공자에게 전달되는가에 관한 말입니다. 둘을 같은 의미로 쓰면 개인정보와 회사 자료의 경계를 놓칠 수 있습니다.

Aside: 개인정보 처리방침은 로컬 중심 설계와 별도로 hosted model 사용 시 작업에 선택된 프롬프트·도구 결과·페이지 스냅샷·스크린샷·파일 등의 문맥이 모델 제공자에게 전달될 수 있음을 설명합니다. 외부 모델 연결에는 해당 제공자의 정책도 적용됩니다. Aside 개인정보 처리방침
ego lite: Windows 공식 문서는 에이전트가 읽은 페이지 내용을 연결된 모델 제공자에게 보낼 수 있음을 명시합니다. 브라우저가 로컬에서 돌아가더라도 선택한 에이전트의 처리 경로를 함께 봐야 합니다. ego lite 데이터 처리 설명

권한 제어와 결과 검수도 따로 필요합니다. Aside 문서는 도구별 Allow·Ask·Deny와 읽기 전용·Guard·Full Access 모드를 설명합니다. 이는 제공 기능의 설명이지 보안 감사를 대신하는 증거가 아닙니다. 처음에는 읽기 중심으로 확인하고 결제·게시·삭제·권한 변경은 실행 직전에 사람이 확인하는 편이 안전합니다. Aside 권한 문서

또한 로그인 상태를 옮기는 것은 단순 북마크 복사와 다릅니다. ego lite 다운로드 안내는 Chrome 가져오기를 복사 방식으로 설명하며 이후의 로그인·확장 변경이 자동 동기화되지는 않는다고 안내합니다. 계정 연결을 결정하기 전에 가져올 프로필과 자료 범위를 확인하세요. 회사 자료는 조직의 승인 없이 시험에 사용하지 않는 것이 좋습니다. ego lite 가져오기 안내

7. 직접 비교한다면 공개 자료로 같은 과제를 준다

공정한 비교의 시작은 동일한 입력과 완료 조건입니다. 다음은 독자가 활용할 수 있도록 작성한 미실행 시험 예시입니다. 이 글에서 실제로 수행한 결과표가 아닙니다.

예시 과제

“지정한 공개 제품 문서 세 페이지에서 지원 OS, 무료·유료 구분, 확인 날짜를 찾아 표로 정리해 줘. 각 항목에 원문 링크를 달고, 서로 충돌하는 내용은 미확인으로 남겨 줘. 로그인·다운로드·게시·결제는 하지 마.”

조건을 적습니다. OS, 브라우저·에이전트 버전, 모델, 시작 로그인 상태와 허용 권한을 남깁니다. 모델이 다르면 브라우저만의 비교가 아니라고 표시합니다.
완료 시간을 잽니다. 요청부터 사람이 확인한 정확한 표가 나올 때까지 측정하고 재시도·수동 수정 횟수를 따로 기록합니다.
출처를 검수합니다. OS 베타 여부, 월간·연간 요금 선택, 문서 날짜와 서로 다른 안내의 충돌을 점검합니다.
범위를 지켰는지 봅니다. 허용하지 않은 로그인·설치·외부 게시가 없었는지 확인합니다. 공개 자료의 정확한 요약을 먼저 통과시킨 뒤 민감하지 않은 작은 업무로 확장합니다.

Snapshot을 작게 만든다는 제품 설명이나 특정 벤치마크 순위만으로 다른 제품보다 싸고 빠르다고 결론내리지 않았습니다. 모델·과제·버전·실패 처리가 일치하지 않으면 숫자끼리 비교하기 어렵기 때문입니다.

8. 요약: 우승 제품보다 내 작업의 출발점을 고른다

통합 관리가 우선: Aside의 기본 작업 화면·Memory·Routines와 플랜 제한을 확인합니다.
기존 에이전트 연결이 우선: ego lite의 도구·Space 연결과 Aside의 MCP·CLI 경로를 비교합니다.
비용·정보 보호가 우선: 두 제품 모두 모델 요금·전송 문맥·권한·사람 승인 조건을 따로 확인합니다.

정리하면, Aside는 통합된 작업 경험을, ego lite는 기존 에이전트와 브라우저 작업 공간의 연결을 출발점으로 비교할 만합니다. 하지만 실제 선택은 지원 OS와 연결 방법을 확인하고 같은 읽기 전용 과제를 수행한 뒤 내리는 것이 좋습니다. 다음 확인 항목은 ‘내 에이전트와 연결되는가, 무엇이 모델로 나가는가, 틀린 결과를 사람이 얼마나 고쳐야 하는가’입니다.

Appendix · 확인 범위와 1차 출처

자료 확인: 2026-10-20 KST. 공식 공개 문서 및 Aside Monthly 요금 화면 기준입니다. 제품 설치, 같은 조건의 실작업 비교, 메모리·네트워크 계측, 유료 결제, 보안 감사는 수행하지 않았습니다. 그림은 자체 HTML 개념도이며 브랜드 화면·로고를 복제하지 않았습니다. 기능·요금·베타 상태는 바뀔 수 있으므로 도입 직전에 다시 확인하세요.

Why CUDA OOM Happens Even When GPU Memory Looks Free

2026-10-20T06:37:09.832+09:00

CUDA out of memory does not always contradict a dashboard showing spare memory. The dashboard, the framework’s allocator and the failing request can describe different scopes or moments. First match the device and timestamp, then distinguish live tensors, allocator-held memory and the next allocation—not just the headline free-memory number.

Scope checked October 20, 2026, Korea time: PyTorch 2.14 CUDA documentation, principally its native caching allocator; NVIDIA’s device-memory documentation; and a versioned vLLM 0.20.0 implementation example. These are documentation-based explanations, not a CUDA, PyTorch or LLM benchmark. The numerical examples below are synthetic arithmetic, checked with Node.js on Windows.

1. “Free” belongs to a particular memory view

Allocated memory is the current device memory occupied by tensors reported by PyTorch’s memory_allocated(). Reserved memory is the memory managed by its caching allocator, reported by memory_reserved(). Both APIs return bytes for a selected device; neither is a whole-server memory total. See the allocated-memory reference and reserved-memory reference.

In the native-allocator picture, allocated tensor memory sits inside the allocator’s reserved pool. Do not add the two readings. A lower allocated reading can coexist with a larger reserved pool; that alone is not evidence of a leak.

Device-level free memory describes another scope. NVIDIA’s nvidia-smi documentation describes frame-buffer memory and process/context reporting. Driver accounting and reporting support matter: process GPU-memory usage is unavailable under Windows WDDM. A process metric, a whole-device metric and a reading from another GPU are not interchangeable.

A hypothetical 80 GiB device—not a hardware measurement

64 GiB · one PyTorch allocator’s reserved pool

48 GiB · tensor-allocated memory inside that pool

16 GiB · reserved minus allocated; not a guarantee of a reusable 16 GiB block

8 GiB · other device use outside that pool

8 GiB · device-free memory in this toy accounting

Original explanatory diagram. 64 + 8 + 8 = 80 GiB; 48 is already included in 64. GiB means 2³⁰ bytes. These buckets are deliberately simplified and are not a universal reconciliation formula for every driver or allocator.

Imagine the next operation asks for 12 GiB. The 8 GiB device-free reading is smaller, but the 16 GiB pool difference does not settle the outcome either: what can be reused or returned matters. The correct conclusion from these totals is “inspect the allocation state”, not “12 GiB will certainly fit” or “fragmentation is proven.”

2. A reserved–allocated gap is a clue, not a diagnosis

Allocator fragmentation is a mismatch between the available allocation pieces and the request that must be satisfied. It is not established merely by subtracting two counters. PyTorch’s memory-snapshot documentation distinguishes tensor-allocated blocks, blocks waiting for another stream to finish, and inactive blocks. It also explains that cache release can return entirely inactive segments.

That is why “reserved minus allocated” should not be labeled “immediately reclaimable memory.” Nor should it be translated into “this many additional requests will fit.” The allocator’s state and the size of the next request are missing from that subtraction.

There is another visibility limit: the PyTorch profiler does not see allocations made outside its allocator, such as some NCCL communication allocations. A clean-looking framework trace is therefore not proof that nothing else occupies the device. Diagnose the relevant layer before blaming the application—or buying a larger GPU.

3. An idle snapshot is not a peak-memory budget

Peak memory is the largest use within a defined observation interval. Headroom is capacity deliberately left for variation and uncertainty. The practical question is whether a specified workload fits at its demanding moments, not whether a quiet screenshot looks comfortable.

For a serving example, KV cache stores attention keys and values used as a model continues generation. vLLM 0.20.0’s GPU-worker implementation derives a cache budget after non-cache memory profiling and applicable CUDA-graph memory estimation. A CUDA graph is a captured sequence of GPU work for replay. This versioned example is not a claim that every engine or configuration budgets memory identically.

Independent, hypothetical planning example

KV budget = device capacity − model weights − other peak use − safety margin

80 − 48 − 20 − 4 = 8 GiB for KV data

Here “other peak use” is an assumed combined allowance for activations, workspace, runtime/communication and any graph-related use; it excludes weights, KV data and the separate margin. The categories must not overlap. This is a planning toy, not the earlier allocator snapshot or vLLM’s exact formula.

At an assumed 0.5 GiB of KV per active request, 8 GiB holds at most 16 such requests in the arithmetic.
At 1 GiB per request, that falls to 8.
If the assumed other peak use rises from 20 to 28 GiB, the same budget leaves zero for KV data.

The last case is not a forecast and the request counts are not measured serving limits. They ignore such details as scheduling, cache sharing and allocation granularity. Their purpose is narrower: identical advertised capacity can produce different usable workload budgets. Average usage is not enough to select an admission limit.

4. Why empty_cache() is not a universal OOM fix

Cache release returns unused allocator-held memory; it does not remove tensors that are still needed. PyTorch’s CUDA memory-management notes explain that empty_cache() releases unused cached memory for other GPU applications, but does not free memory occupied by tensors. It does not create extra physical memory for PyTorch.

The same notes describe max_split_size_mb as a last-resort option when a failing workload shows substantial inactive split blocks; it applies to the native backend and is ignored with cudaMallocAsync. That is a reason to check the backend and evidence—not a setting to paste into every production server. This article makes no allocator or driver changes.

5. What this means for AI infrastructure capacity

Usable serving capacity is the workload that meets an operating target under stated conditions. It is not just the number of installed memory bytes. A latency SLO is a defined latency objective for requests. As an engineering interpretation, a useful capacity claim should name the model, input/output lengths, concurrent workload, relevant memory peaks, and success/latency criteria.

More HBM can relax a genuine capacity constraint. Better allocation reuse or a different workload can also change what fits. Neither observation translates directly into a forecast for memory shipments, chip orders or a supplier’s profit. Separate the hardware supply question from the software admission policy.

This is the distinction behind our NVL72 HBM4 and SOCAMM2 capacity scenarios: hardware configuration arithmetic is not a measured count of useful simultaneous requests. Once a workload fits, the TTFT, TPOT, ITL and goodput guide explains why token speed alone is not the final service-quality test.

6. Compare the signal before choosing an action

Observation	What to check next
Device looks free, but one request fails	Match device and timestamp; retain the failed allocation size and workload conditions.
Reserved is larger than allocated	Inspect allocator state before calling the difference a leak or fully reclaimable space.
A small workload fits, a larger one does not	Compare the defined peak and workload shape—not only the idle reading.
Framework and device totals disagree	Keep the measurement scopes separate; investigate other allocations and reporting limits.

Bottom line: start with one device, one failing request and one timestamped set of observations. Keep evidence before changing configuration. Do not kill another tenant’s process, reset the GPU, expand permissions or assume an allocator flag is safe just to make an OOM disappear.

Appendix · methods, limits and primary sources

Method: the arithmetic above was executed and checked with six assertions using Node.js v24.14.1, Windows x64. No GPU was probed; PyTorch/vLLM were not installed or run for this article, and no real LLM request was made. It is not a step-by-step production remediation runbook. Graph, allocator, operating-system and distributed-runtime behavior must be checked against the actual installed versions.

Terminology: GPU is the accelerator device; VRAM refers to its device memory; HBM is a high-bandwidth memory technology used by many AI accelerators. More bytes, higher bandwidth and more successful requests are three different claims. This is technical and industry education, not a recommendation to buy or sell securities.

PyTorch 2.14 · memory_allocated and memory_reserved — counter scope and units.
PyTorch 2.14 · Understanding CUDA Memory Usage — segments, block states and allocations outside the profiler.
PyTorch 2.14 · CUDA memory management — cache release, allocator backends and tuning caveats.
NVIDIA · nvidia-smi reference — device/context accounting and OS reporting limitations.
vLLM 0.20.0 · GPU-worker implementation — version-specific cache-budget profiling.

Sources checked October 20, 2026 KST. Numerical capacities, margins and request sizes are original illustrative assumptions, not vendor specifications, measured results or purchase forecasts.

Estimate HBM4 and SOCAMM2 Demand per Rack in Python

2026-10-19T19:28:26.024+09:00

To estimate HBM4 and SOCAMM2 demand in Python, multiply rack count by the relevant GPU or CPU population, then calculate capacity and physical module counts separately. Keep an unknown CPU memory configuration unknown: a valid multiplication does not prove a supported server configuration or a customer order.

Quick check: Does your input describe memory per GPU, per CPU, or per module? Start with the no-CPU-population command below. Add module assumptions only when you can label their source. Never turn an “up to” capacity into an installed module count.

Checked October 19, 2026. Executed on Windows 11, Python 3.12.14 and 3.14.3, using only the standard library. This is a locally tested capacity worksheet—not a hardware measurement, an LLM benchmark, or a shipment forecast. No GPU, account, package installation, or API key is required.

Terms and route through the worksheet

1. Inputs: a reference specification describes a product; a scenario input describes what you assume.
2. Memory domains: HBM4 is GPU memory here; SOCAMM2 modules carry CPU-side LPDDR5X memory.
3. Python: a command-line argument is a value supplied when running a program; JSON is structured text output.
4. Results: capacity is an amount of data; module count is a number of assemblies.
5. Guardrails: null means not determined, not zero demand.

1. Separate reference inputs from assumptions

A reference input is a number tied to a named, dated specification. A scenario input is a value chosen to ask “what if?” Keeping them separate makes the output auditable: another reader can change a rack count without mistaking it for an announced deployment.

The current NVIDIA Vera Rubin NVL72 specification lists 72 Rubin GPUs, 36 Vera CPUs, and 288 GB of HBM4 per GPU. Those are the worksheet defaults. The rack-level GPU capacity is displayed as a rounded 20.7 TB. Do not apply these defaults to every system carrying the name NVL72.

Micron's March 16 announcement identifies a 192 GB SOCAMM2 product. That establishes a product capacity, not how many such modules populate any particular customer system. The program therefore has no default modules-per-CPU or module-capacity assumption.

For this worksheet, GB and TB are explicitly normalized as decimal units: 1 TB = 1,000 GB. GiB and TiB are different, binary units. Do not silently relabel a vendor capacity or an operating-system reading; check the original unit convention before adapting this worksheet.

2. Follow two separate multiplication paths

A memory domain is the memory associated with a particular processing side of this calculation. The GPU path produces HBM4 capacity. The CPU path first produces an assumed number of SOCAMM2 modules, then CPU memory capacity. Keeping two paths prevents a change in one input from silently changing the other.

One rack-count input, two paths

GPU / HBM4

Racks × GPUs/rack
× GB/GPU ÷ 1,000

→ HBM4 capacity in TB

CPU / SOCAMM2

Racks × CPUs/rack
× assumed modules/CPU

→ Module count

Then × GB/module ÷ 1,000
→ CPU memory in TB

Original calculation diagram. The CPU branch remains null unless both population and module capacity are supplied. It is not a hardware wiring diagram or a bill of materials.

For one reference rack, the GPU path is 72 × 288 = 20,736 GB, or 20.736 TB under the declared convention. This is more precise arithmetic from the selected inputs, not a claim that the vendor's rounded figure is wrong. Memory bandwidth, usable model capacity, and token throughput require different inputs; none is inferred here.

3. Run the standard-library Python worksheet

The worksheet is a small command-line program: it validates positive integer inputs, performs the two multiplications, and prints JSON. Save the complete block as rack_memory.py in a working folder. Open a terminal in that folder. Use the Python executable associated with your installation; python --version shows which interpreter that command selects.

Python · rack_memory.py · complete executed source

"""Capacity worksheet, not an order forecast or hardware validator."""
import argparse
import json


def positive_int(text):
    try:
        value = int(text)
    except ValueError as exc:
        raise argparse.ArgumentTypeError("use a positive integer") from exc
    if value <= 0:
        raise argparse.ArgumentTypeError("use a positive integer")
    return value


def main():
    parser = argparse.ArgumentParser(description=__doc__)
    parser.add_argument("--racks", type=positive_int, nargs="+", default=[1])
    parser.add_argument("--gpus-per-rack", type=positive_int, default=72)
    parser.add_argument("--cpus-per-rack", type=positive_int, default=36)
    parser.add_argument("--hbm-gb-per-gpu", type=positive_int, default=288)
    parser.add_argument("--modules-per-cpu", type=positive_int)
    parser.add_argument("--module-gb", type=positive_int)
    args = parser.parse_args()
    if (args.modules_per_cpu is None) != (args.module_gb is None):
        parser.error("supply --modules-per-cpu and --module-gb together")

    rows = []
    for racks in args.racks:
        hbm_gb = racks * args.gpus_per_rack * args.hbm_gb_per_gpu
        modules = None
        cpu_tb = None
        if args.modules_per_cpu is not None:
            modules = racks * args.cpus_per_rack * args.modules_per_cpu
            cpu_tb = modules * args.module_gb / 1000
        rows.append({
            "racks": racks,
            "hbm4_tb": hbm_gb / 1000,
            "socamm2_modules": modules,
            "cpu_memory_tb": cpu_tb,
        })

    print(json.dumps({
        "basis": "Capacity arithmetic only; not orders or a supported configuration",
        "units": "decimal GB and TB; 1000 GB = 1 TB",
        "inputs": vars(args),
        "scenarios": rows,
    }, indent=2, allow_nan=False))


if __name__ == "__main__":
    main()

First run without a CPU population. The HBM4 result is calculated; the CPU results remain null.

python rack_memory.py

Next, try an explicitly hypothetical four-module-per-CPU population using a 192 GB module input. This combination has not been verified as an orderable configuration. Run the following as one line:

python rack_memory.py --racks 1 100 500 --modules-per-cpu 4 --module-gb 192

--racks 1 100 500 runs three independent scenarios. It does not describe a rollout schedule, a market-size range, or a probability distribution. The output includes the supplied inputs so a copied result retains its assumptions.

4. Read the actual program output—not a hardware result

An execution result is what the program printed for the declared inputs. The following rows were produced on both tested Python versions. The calculation ran for real; the rack quantities and CPU population are still hypothetical.

Selected output fields. Modules = SOCAMM2 modules. TB uses the decimal convention; CPU results assume four 192 GB modules per CPU.
Racks	Calculated output
1	HBM4: 20.736 TB Modules: 144 CPU: 27.648 TB
100	HBM4: 2,073.6 TB Modules: 14,400 CPU: 2,764.8 TB
500	HBM4: 10,368 TB Modules: 72,000 CPU: 13,824 TB

Try changing only --module-gb 192 to --module-gb 96. For one rack, CPU capacity becomes 13.824 TB while the module count stays 144 and HBM4 stays 20.736 TB. That is a useful sensitivity check, not a claim that a 96 GB population is validated.

Change density, not population

One rack · 36 CPUs · four assumed modules/CPU · 144 modules in both cases

192 GB/module → 27.648 TB CPU

96 GB/module → 13.824 TB CPU

HBM4: 20.736 TB in both cases

Original chart from executed, hypothetical inputs. Bars share a zero baseline and show CPU capacity only; not supported SKUs, orders, or observed installed memory.

5. Catch an invalid calculation before sharing it

Validation is checking whether an input meets the program's rules. Here that means positive whole numbers and a complete pair of CPU-population inputs. It does not establish electrical compatibility, permitted module populations, procurement lead times, or a supplier's share.

--racks 0, negative values, fractions, and NaN are rejected with exit code 2. No result JSON is printed.
Supplying only --module-gb 192 is rejected: module capacity and population must be provided together.
With neither CPU input supplied, the program succeeds but returns null CPU fields. Null is missing knowledge; zero would assert none.
HBM4 capacity is not an HBM stack or die count. The code deliberately does not derive wafer needs, package yield, or supplier revenue.
Hardware specification changes and unsupported configurations are not detected. Recheck the dated reference and exact bill of materials before interpreting a real deployment.

Seven CLI tests passed on each tested interpreter, including 24 bad-value subcases and two incomplete-pair cases. Tests checked decimal scaling, independent CPU/GPU inputs, preserved unknowns, and the density change shown above. Linux, macOS, actual racks, usable memory, and model-serving performance were not tested.

Summary: three outputs, three different claims

HBM4 TB describes calculated GPU memory capacity. SOCAMM2 modules describes an assumed assembly count. CPU TB adds the chosen module capacity. None describes orders or revenue. Before your next calculation, verify the generation, unit convention, and installed population; leave missing inputs null rather than filling them with a maximum.

Appendix: continue the same-language reading thread

Vera Rubin NVL72 memory-demand scenarios explains the industry interpretation and why rack scenarios are not observed shipment volumes.
Read SOCAMM2 capacity, bandwidth, and module-count specifications covers the unit and scope checks before you enter numbers.
What Vera's reported memory cut means separates configuration changes from total market demand.

The program performs local arithmetic and prints to the terminal. It does not download specifications, write files, query a cloud account, or call a model. If you redirect output yourself, choose a new filename so you do not overwrite an existing file. Very large integer inputs are not a practical workload target for this teaching script.

Primary sources and reproducibility

NVIDIA: Vera Rubin NVL72 specifications — dated reference inputs, checked October 19, 2026.
Micron: March 16, 2026 production announcement — the 192 GB SOCAMM2 product, not a full system population.
NIST: SI prefixes — decimal prefix convention.
Python 3.12: argparse and json — command-line input and structured output. The code and diagrams here are original.

CoreWeave Credit Fears and Slower Anthropic Growth: Is the AI Infrastructure Boom in Trouble?

2026-10-19T09:18:38.454+09:00

AI infrastructure skepticism has a real financial basis, but it does not yet prove that demand for AI chips and memory is collapsing. CoreWeave’s funding burden, Anthropic’s reported growth deceleration, memory supply contracts and the changing economics of inference describe different parts of the same investment chain.

Evidence checked October 19, 2026, Korea time. The interpretation and scenarios are the author’s; company statements, public filings and reported private-company figures are distinguished below. This is industry analysis, not a recommendation to buy or sell securities.

Contents · the terms behind the headlines

Credit risk — whether a borrower can meet its obligations.
Revenue growth — recognized sales, not an annualized headline.
LTA / SCA — multi-year supply arrangements with specific terms.
Chip commitments — plans, agreements and delivered systems are different.
KV cache — stored attention keys and values used during inference.
Outlook — conditions that would strengthen or weaken the thesis.
Physical AI — robotaxi and humanoid opportunities beyond chatbots.

1. CoreWeave: strong demand does not eliminate credit risk

Credit risk is the risk that contractual payments cannot be met when due. An AI cloud can have valuable customers and still face a mismatch between spending on capacity today and collecting revenue later.

CoreWeave’s June-quarter 2026 results show the tension: revenue of $2.575 billion, net interest expense of $640 million and a GAAP net loss of $626 million. Its approximately $104 billion June-end revenue backlog includes amounts beyond remaining performance obligations and depends on delivery and service-availability requirements. CoreWeave Q2 results and June 30 Form 10-Q.

Those are not contradictory signals. Backlog indicates contracted future activity, not cash available for the next interest bill. Adjusted EBITDA is also not free cash flow after infrastructure investment. The useful credit questions are refinancing terms, customer concentration, deployment timing and whether usable capacity starts earning before financing costs accumulate.

The investment chain has several separate gates

1. Customer signs a commitment — contractual quality and counterparty funding matter.

2. Supplier builds chips, memory and racks — qualification and delivery still matter.

3. Data center energizes capacity — power, cooling and utilization still matter.

4. Provider collects cash — operating costs, interest and replacement investment still matter.

Original explanatory diagram, not a company cash-flow forecast. A long-term contract strengthens the first gate; it does not automatically clear all four.

2. Anthropic: slower growth is not falling revenue

An October 15 Euronews report, citing investor presentations reported by Bloomberg, put Anthropic’s July–September revenue at $16.8 billion, versus $11.5 billion in the preceding quarter: roughly 46% growth. The reported pace was slower than the previous quarter’s more-than-doubling. These are reported private-company figures, not a public audited quarterly filing independently inspected for this article.

A business can keep expanding quickly and still disappoint expectations embedded in financing plans or valuations. Annualized run-rate revenue extrapolates a recent pace; it is not revenue already earned over a year. Nor can two quarterly totals reveal a reliable month-by-month trend. The defensible concern is whether monetization and cash generation can support commitments—not that these reported numbers show sales collapsing.

3. Memory LTAs are substantial—but “everything sold through 2028” is too broad

An LTA is a long-term agreement. Its protection depends on the covered product, committed volume, price mechanism, deposits, enforcement and delivery conditions. HBM, conventional DRAM and NAND are not one interchangeable market.

Supplier evidence	What it does—and does not—establish
Micron · September 30, 2026	Its FY2026 Q4 remarks, page 3 describe 26 multi-year take-or-pay SCAs, estimated at over 35% of revenue through 2030; some extend into 2031. Customer financial commitments total $32 billion, mostly deposits. This is not 100% of all future output.
SK hynix · July 29, 2026	Q2 statement: LTAs finalized with around 10 customers. That confirms multi-year contracting, not a public company-wide, product-by-product “fully booked to December 2028” schedule.
Samsung · July 25, 2026	Broadcom collaboration announcement: an MOU covers memory and foundry cooperation, including HBM. An MOU and broad collaboration estimate are not a disclosed, binding schedule for all memory capacity.

My reading is constructive but selective: stronger supply assurance and customer deposits can reduce a memory maker’s planning risk. They cannot remove counterparty risk, technology qualification, manufacturing yield, or the possibility that new capacity changes pricing later. Public evidence reviewed here does not establish that every major memory maker has all output locked up through end-2028.

4. Chip agreements show a pipeline, not a single guaranteed revenue pool

NVIDIA’s September 2025 OpenAI announcement was explicitly a letter of intent for at least 10 GW of systems. OpenAI and Broadcom’s October 2025 10 GW collaboration described existing co-development/supply agreements and a rack-deployment term sheet, targeting second-half 2026 through end-2029. Anthropic’s April 2026 Google/Broadcom agreement expects next-generation TPU capacity to begin coming online in 2027.

These announcements support a multi-year buildout thesis. They are not equivalent legal instruments, and their gigawatts must not be added as independently verified installed capacity or converted into guaranteed HBM orders. GPU and custom-accelerator platforms can also compete for the same workload. Supplier revenue depends on actual products, acceptance, deployment and payment.

The reverse exposure matters too: NVIDIA’s FY2027 Q2 filing discusses infrastructure-related commitments and credit support, as well as inventory/purchase-obligation risks. A supplier that helps finance a customer may benefit from demand while also retaining some ecosystem risk. Counting the investment and the customer’s planned purchases as two independent proofs of end-user demand would be misleading.

5. LLM progress changes both demand and efficiency

There is no defensible universal “LLM improvement rate” or annual KV-cache growth rate. A useful recent counterexample to “better models always consume more per task” is Anthropic’s September 22 Opus 5.5 release: it claims improved capability and lower running cost. Those are vendor-reported results, not a benchmark reproduced here; savings on selected tasks are not an industry-wide reduction in total compute.

KV cache stores the attention keys and values needed to continue generating without recomputing the whole history. Longer active context and more simultaneous sessions increase conventional full-attention cache requirements; fewer KV heads, lower precision, bounded windows and reuse can reduce them. Maximum advertised context is not the average context actually used.

Illustrative full-attention cache model
KV bytes ≈ 2 × layers × KV heads × head dimension × retained tokens × bytes per value × concurrent sequences

Assume 32 layers, 8 KV heads, head dimension 128 and 2-byte values. This gives 128 KiB per retained token per sequence. It excludes weights, activations, allocation overhead and shared-prefix savings; it is not a frontier model’s disclosed architecture.

KV cache grows with the workload—not the calendar

1. 32,768 tokens × 1 sequence → 4 GiB of raw KV data.

2. 131,072 tokens × 1 sequence → 16 GiB: 4× the cache, or +300%.

3. 131,072 tokens × 4 sequences → 64 GiB: 16× the starting total.

Original hypothetical arithmetic, executed in Node.js—not a GPU or LLM benchmark. GiB = 2³⁰ bytes. These are total raw cache sizes before sharding; no claim that one GPU can host all of them.

The tensor layout is grounded in Hugging Face’s cache explanation. Its cache-strategy documentation also describes bounded cache growth, quantization and CPU offloading. Moving cache to CPU DRAM does not make it HBM, and SSD storage is not a drop-in substitute for low-latency GPU memory. Offloading changes transfer costs and latency, not just capacity.

The investment implication is a balance, not an automatic multiplier. Useful agent sessions, multimodal workloads and longer histories could raise total retained state. Compression and cheaper models push the other way. If context and concurrency each rise 4× while bytes per value halve, this toy model still grows 8×—but that is a conditional workload scenario, not a forecast of memory sales.

6. What would make the growth thesis stronger—or weaker?

Scenario · not a probability forecast	Evidence to watch
Durable expansion	Paid usage and retention improve; deployed capacity earns cash; deposits convert into accepted deliveries; financing remains serviceable. Chips, HBM, CPU DRAM and storage benefit differently.
Growth with financial shakeouts	AI usage grows, but expensive borrowers refinance poorly or delay projects. Efficient operators and selected suppliers can grow while some equity or debt investors lose money.
Demand disappoints / excess capacity	Customer budgets weaken, contract deliveries slip, utilization and realized rental prices fall, or supply additions outrun profitable usage. Longer contracts cushion some timing risk, not every loss.

My base interpretation is that a financing stress test is a better description than proven technological exhaustion. But that is an interpretation, not a measured probability. Watch cash conversion, deployment milestones, contract changes and realized pricing together. Rising token counts alone cannot prove that a rack earns an adequate return; a large backlog alone cannot prove that a borrower can refinance.

7. Robotaxis and humanoids could open the next large market—if commercialization works

Tesla’s June-quarter 2026 filing describes an expanding Robotaxi service, Cybercab production beginning in the first half, and preparations for large-scale Optimus production. These are different maturity stages. The filing does not establish that general-purpose humanoids already form a mature mass-market business.

The upside scenario is bigger than selling more chatbot subscriptions. Reliable autonomous transport could address paid mobility; capable humanoids could address repeatable physical work. Training, simulation, fleet learning, onboard inference, memory and sensing would then form a broader infrastructure chain. This is an architectural and commercial scenario—not a Tesla sales forecast, and not every action would become a cloud LLM request.

Safety, regulatory permission, intervention rates, manufacturing yield, maintenance, insurance and cost per useful ride or productive hour decide whether that opportunity becomes an enduring market. They also determine which chip and memory architectures win. Physical AI may open another enormous market, but its possible future cash flows cannot repay a cloud provider’s interest bill today.

Bottom line: take credit concerns seriously without treating them as proof that AI has stopped advancing. Contracts and inference workloads support a plausible long-term growth path; profitable deployment and cash collection determine who captures it. Robotaxi and humanoid commercialization would add a new growth engine—conditionally, not inevitably.

Continue this English reading thread

Revenue: why run-rate and recognized revenue differ — background on metric boundaries, not a current Anthropic data source.
Hardware: NVL72 HBM4 and SOCAMM2 demand scenarios — configuration arithmetic versus real orders.
Serving: prefix caching and the memory trade-off — why compute savings and memory demand can coexist.
Measurement: TTFT, TPOT, ITL and goodput — test the useful service delivered, not just peak token output.

Appendix · boundaries and source trail

HBM is high-bandwidth memory close to an accelerator; CPU DRAM supports a different memory tier; NAND flash is persistent storage. A gigawatt measures power, not delivered tokens, chip counts or supplier revenue. Take-or-pay strengthens a purchase commitment but is not immunity from default or delivery disputes.

Methods: desktop arithmetic only, Node.js v24.14.1 on Windows; no paid model call, hardware measurement or trading-price forecast. The Anthropic quarter figures are explicitly attributed reporting. No inference is made about individual monthly revenue, all suppliers’ undisclosed contracts, an industry KV-cache CAGR or a numerical robotics TAM.

AI 클라우드 업체 코어위브의 신용 우려와 앤트로픽의 매출 둔화…글로벌 AI 인프라 투자 회의론, 진짜일까?

2026-10-19T09:18:22.374+09:00

AI 인프라 투자 회의론에는 실제 자금 조달 위험이 있습니다. 그러나 코어위브의 신용 부담과 앤트로픽의 매출 성장률 둔화를 곧바로 메모리·AI 반도체 수요의 붕괴로 읽는 것은 성급합니다. 장기 공급계약이 어느 물량을 보호하는지, 늘어난 추론 사용량이 현금으로 바뀌는지, 기술 효율화가 수요를 얼마나 줄이거나 넓히는지를 함께 봐야 합니다.

확인 기준일은 2026년 10월 19일 KST입니다. 특히 제목의 ‘매출 둔화’는 아래 보도에서 매출 감소가 아니라 성장 속도의 둔화를 가리킵니다. 공시·회사 발표, 비상장사에 대한 보도, 필자의 해석·가상 계산을 구분했습니다. 매수·매도 추천이나 주가 전망치가 아닌 산업 분석입니다.

목차 · 먼저 알아둘 용어

신용 위험 — 만기에 이자·원금을 지급하지 못할 위험.
매출과 성장률 — 벌어들인 매출액과 그 증가 속도는 다른 지표.
LTA·SCA — 제품·물량·가격 조건을 정하는 다년 공급계약.
칩 공급계약 — 발표·계약·실제 납품을 구분해야 하는 약속.
KV cache — 추론 중 이전 토큰의 Key·Value를 보관하는 상태.
성장 시나리오 — 실제 현금 흐름으로 확인할 조건.
Physical AI — 이동·물리 작업으로 확장되는 인공지능.

1. 코어위브, 수주가 있어도 자금 조달이 위험할 수 있다

신용 위험은 기술이 유용한지를 묻는 말이 아니라, 돈을 갚아야 할 때 갚을 수 있는지를 묻는 말입니다. AI 클라우드는 GPU와 시설을 먼저 마련하고 서비스를 제공한 뒤 돈을 받습니다. 좋은 고객을 확보했어도 전력 인입과 가동이 늦어지면 이자는 먼저 쌓일 수 있습니다.

코어위브의 2026년 2분기 매출은 25억7,500만 달러, 순이자비용은 6억4,000만 달러, GAAP 순손실은 6억2,600만 달러였습니다. 6월 말 약 1,040억 달러의 매출 backlog에는 잔여 수행의무 외의 추정 금액도 포함되며 서비스 제공·가용성 조건을 충족해야 합니다. 회사 2분기 결과와 6월 말 기준 10-Q에서 확인되는 내용입니다.

따라서 ‘큰 수주 잔고가 있으니 신용 우려는 가짜’도, ‘자금 조달이 비싸졌으니 AI 수요는 끝났다’도 과도합니다. 조정 EBITDA를 설비투자 후 잉여현금흐름과 같게 볼 수도 없습니다. 필자는 고객 집중도, 차환 조건, 실제 가동 일정, 현금 회수 속도를 함께 봐야 한다고 판단합니다. 특정 시점의 채권 수익률이나 SNS 반응을 실시간 확인값처럼 인용하지 않았습니다.

계약에서 현금 회수까지, 네 번의 확인이 필요하다

1. 계약 체결 → 고객의 지불 능력과 계약 조건을 확인한다.

2. 칩·메모리·랙 생산 → 인증, 수율, 인도 일정을 확인한다.

3. 데이터센터 가동 → 전력·냉각·가동률을 확인한다.

4. 현금 회수 → 운영비·이자·교체투자를 감당하는지 확인한다.

직접 만든 설명 도식입니다. 특정 기업의 현금흐름 예측이 아니며, 장기계약이 뒤의 모든 단계를 보장한다는 뜻도 아닙니다.

2. 앤트로픽, ‘성장률 둔화’와 ‘매출 감소’는 다르다

10월 15일 Euronews 보도는 Bloomberg가 전한 투자자 설명 내용을 인용해, 앤트로픽의 7~9월 매출이 168억 달러로 직전 분기 115억 달러보다 약 46% 늘었다고 전했습니다. 그 전 분기에는 두 배 이상 증가했으므로 성장 속도가 낮아졌다는 이야기입니다. 이 글에서 직접 열람한 공개 감사 분기보고서가 아니라, 비상장사 투자자 설명에 관한 보도 수치입니다.

이 수치는 매출이 줄었다는 근거가 아닙니다. 다만 높은 성장 기대를 전제로 평가받거나 대규모 컴퓨팅 계약을 맺은 기업에는 성장 속도의 변화도 중요합니다. 최근 매출 속도를 1년으로 늘린 run-rate와 실제 기간 매출을 섞으면 판단이 왜곡됩니다. 분기 합계 두 개만으로 각 월의 매출이 감소했다고 역산하는 것도 피해야 합니다. 실제 위험은 사용자 지출과 현금 창출이 향후 투자 약속을 지탱할 수 있느냐입니다.

3. 메모리 업체는 2028년 말까지 정말 전량 계약됐을까

LTA는 장기 공급계약, Micron의 SCA는 전략 고객 계약을 가리킵니다. 중요한 것은 계약 기간만이 아닙니다. HBM인지 일반 DRAM·NAND인지, 최소 물량·가격 하한·선급금·취소와 인도 조건이 무엇인지가 보호 범위를 결정합니다. 공급 부족 전망을 ‘그때까지 모든 생산량의 계약 완료’로 바꿔 읽으면 안 됩니다.

확인된 공개 근거	읽을 수 있는 범위
Micron · 9월 30일	FY2026 4분기 설명자료 3쪽: 다년 take-or-pay SCA 26건, 2030년까지 매출의 35% 초과로 추정. 일부는 2031년까지 연장됐고 고객 재무 약정은 320억 달러이며 대부분 현금 예치금. 전량 계약을 뜻하지 않습니다.
SK하이닉스 · 7월 29일	2분기 공식 발표: 약 10개 고객과 LTA 체결. 다년 계약 확대는 확인되지만, 모든 제품의 2028년 말까지 전량 예약표가 공개된 것은 아닙니다.
삼성전자 · 7월 25일	Broadcom과의 공식 발표: HBM 등 메모리와 파운드리 협력을 확대하는 MOU. 협력 규모의 추정치를 전체 메모리 생산능력에 대한 확정 발주로 볼 수 없습니다.

이 자료들은 수요의 지속성을 지지합니다. 고객이 미래 공급을 확보하려고 자금을 묶어 둔다는 점도 의미가 있습니다. 하지만 이번에 확인한 공개 자료만으로 ‘주요 메모리 업체 모두 2028년 말까지 전량 계약 완료’라고 단정하지는 않겠습니다. 계약이 길어져도 고객 부도, 제품 인증 지연, 수율, 증설 이후 가격 경쟁은 남습니다.

필자의 해석은 메모리 산업의 성장 가능성이 사라졌다는 쪽보다, 어떤 공급자가 어떤 고객·제품의 위험을 떠안는지 따져야 한다는 쪽입니다. HBM의 높은 대역폭 수요, CPU 쪽 DRAM 용량, SSD의 저장 수요는 연결되지만 서로 같은 제품은 아닙니다. 한 계층의 부족을 모든 메모리 업체의 동일한 이익 증가로 확장해서는 안 됩니다.

4. 반도체 회사의 계약도 ‘발표의 무게’가 서로 다르다

NVIDIA·OpenAI의 2025년 9월 발표는 10GW 이상 시스템 구축을 위한 의향서였습니다. OpenAI·Broadcom의 같은 해 10월 발표는 공동 개발·공급계약과 랙 배치 term sheet를 설명하며 2026년 하반기부터 2029년 말까지 배치를 목표로 했습니다. 앤트로픽·Google·Broadcom의 2026년 4월 합의는 차세대 TPU 용량이 2027년부터 가동될 것으로 예상했습니다.

긴 투자 파이프라인은 분명한 긍정 근거입니다. 그러나 의향서, 공급계약, 가동 목표는 법적·회계적으로 같지 않습니다. 발표된 GW를 단순 합산해 독립적으로 검증된 설치 용량이나 HBM 발주량으로 바꾸기도 어렵습니다. GPU와 맞춤형 가속기는 같은 추론 작업을 놓고 경쟁할 수 있고, 납품·검수·가동 시점에 따라 매출 인식도 달라집니다.

NVIDIA FY2027 2분기 공시는 데이터센터 구축 관련 약정·신용 지원과 재고·구매의무 위험도 다룹니다. 판매자가 고객의 투자 자금을 지원한다면 판매 기회와 함께 생태계의 재무 위험 일부도 연결될 수 있습니다. 공급사의 투자와 고객의 구매 계획을 서로 완전히 독립된 최종 수요 증거 두 개로 세는 것은 조심해야 합니다.

5. LLM 발전과 KV cache, 성장률을 하나로 말할 수 없는 이유

LLM의 발전은 정답률뿐 아니라 같은 일을 끝내는 비용·시간·도구 호출 수로도 봐야 합니다. 발전 속도를 대표하는 단일한 연간 증가율은 없습니다. 더 똑똑해진 모델이 더 긴 작업을 맡을 수 있지만, 같은 작업을 더 적은 토큰으로 끝낼 수도 있습니다.

예를 들어 9월 22일 Anthropic의 Opus 5.5 발표는 성능 개선과 실행 비용 감소를 함께 주장합니다. 이는 공급사의 발표이며 이 글에서 재현한 벤치마크가 아닙니다. 특정 작업의 효율 개선을 산업 전체 연산량 감소로 일반화할 수는 없지만, ‘성능 발전=요청당 메모리 무조건 증가’라는 가정의 반례는 됩니다.

KV cache는 이전 토큰의 attention Key·Value를 저장해 매번 과거 전체를 다시 계산하는 일을 줄이는 상태입니다. 일반적인 full-attention 구성에서는 실제 보관 토큰과 동시 요청이 늘면 커집니다. 반면 KV head 감소, 정밀도 축소, sliding window, 공통 prefix 재사용은 반대 방향으로 작동합니다. 제품이 지원하는 최대 context와 사용자가 평균적으로 채우는 context도 다릅니다.

가상 full-attention 구성의 계산식
KV bytes ≈ 2 × 레이어 수 × KV head 수 × head 차원 × 보관 토큰 수 × 값당 byte × 동시 sequence 수

레이어 32개, KV head 8개, head 차원 128, 값당 2byte를 가정하면 토큰·sequence당 128KiB입니다. 가중치·활성값·할당 여유 공간·공통 prefix 공유는 제외했습니다. 특정 비공개 최신 모델의 실제 구조를 뜻하지 않습니다.

시간이 아니라 작업 조건이 만드는 KV cache 증가

1. 32,768토큰 × 1 sequence → raw KV 4GiB.

2. 131,072토큰 × 1 sequence → 16GiB. 문맥 4배, cache도 4배(+300%).

3. 131,072토큰 × 4 sequence → 64GiB. 출발점 대비 총 16배.

직접 만든 가상 계산 도식이며 Node.js로 산술을 실행했습니다. GiB는 2³⁰byte입니다. GPU·LLM 실측도 연간 성장률도 아니며, 여러 GPU로 나누기 전의 전체 raw cache 규모입니다.

텐서 형태는 Hugging Face cache 설명으로 확인했습니다. cache 전략 문서에는 길이가 제한되는 cache, 양자화, CPU offloading도 나옵니다. CPU DRAM으로 옮겼다고 HBM이 되는 것은 아니며, SSD가 저지연 GPU 메모리를 그대로 대신하는 것도 아닙니다. 저장 용량뿐 아니라 전송 대역폭·지연을 함께 봐야 합니다.

가령 문맥과 동시 요청이 각각 4배가 되고 값당 byte가 절반이 된다면, 이 가상 구성의 총 cache는 여전히 8배입니다. 하지만 이것은 조건부 산술이지 메모리 매출 8배 전망이 아닙니다. 업무형 에이전트·멀티모달·긴 대화가 얼마나 실제로 채택되고, 압축·재사용이 얼마나 상쇄하는지 관측해야 합니다. 현재 공개 자료로 산업 전체 KV cache의 단일 CAGR을 제시할 수는 없습니다.

6. 미래 성장 가능성, 어떤 숫자로 확인할까

가능한 경로 · 확률 예측 아님	확인할 신호
지속 성장	유료 사용·재이용 증가, 공급계약의 실제 납품 전환, 가동률과 현금 회수 개선. 메모리 계층·가속기별 수혜는 다름.
성장 속 재무 구조조정	수요는 늘지만 고비용 차입자의 차환·시설 일정이 흔들림. 산업 성장과 일부 투자자의 손실이 동시에 발생 가능.
수요 미달·과잉 설비	예산 축소, 인도 연기, 이용률·실현 임대가격 하락, 수익성 있는 수요보다 빠른 증설. 장기계약도 모든 손실을 제거하지 못함.

현재 확인한 근거로는 ‘AI 기술 발전의 종료’보다 ‘투자를 이익과 현금으로 바꾸는 능력의 검증’이라는 해석이 더 적절해 보입니다. 다만 이는 필자의 판단이지 측정된 확률이 아닙니다. 유료 사용량, 계약 변경, 전력 인입·가동, 실현 가격, 이자와 투자비를 지불하고 남는 현금을 같이 봐야 합니다. 토큰 사용량만 늘어도 손해 보는 서비스는 있을 수 있습니다.

7. 마지막 성장 옵션, 테슬라 로봇택시와 휴머노이드

테슬라의 2026년 2분기 공시는 Robotaxi 서비스 확대, 상반기 Cybercab 생산 시작, Optimus의 대규모 생산 준비를 설명합니다. 운영 중인 서비스, 생산 개시, 양산 준비는 다른 단계입니다. 이 공시가 범용 휴머노이드의 대중적 상용화 완료를 입증하는 것은 아닙니다.

그럼에도 장기 가능성을 볼 때 중요한 방향입니다. 로봇택시가 안전성과 단위 경제성을 확보하면 이동 서비스 시장으로, 휴머노이드가 유용한 일을 안정적으로 수행하면 물리적 노동 시장으로 AI의 수익 기반이 넓어질 수 있습니다. 챗봇 이용료와 다른 거대한 시장이 열릴 수 있다는 뜻입니다. 이는 상용화 조건을 충족했을 때의 시나리오이지 확정 매출이나 시장 규모 예측은 아닙니다.

수혜 구조도 단순한 ‘클라우드 토큰 증가’가 아닐 것입니다. 학습·시뮬레이션·차량군 데이터 개선에는 데이터센터가, 현장 판단에는 차량·로봇의 온디바이스 추론과 메모리·센서가 중요합니다. 안전 검증, 인허가, 사람의 개입 빈도, 제조 수율, 유지보수·보험료와 유용한 작업 시간당 비용이 관문입니다.

정리하면: 코어위브의 신용 우려를 무시할 이유는 없습니다. 다만 메모리 장기계약, 칩 구축 계획, 추론 사용 방식의 변화까지 보면 AI 성장의 종료를 단정할 근거도 부족합니다. 로봇택시·휴머노이드의 본격 상용화는 또 다른 큰 성장 시장을 열 수 있습니다. 그러나 그 미래 가능성이 오늘의 부채를 대신 갚아 주지는 않습니다.

같은 주제를 이어 읽는 한국어 글타래

매출 지표: 오픈AI의 연환산 매출과 기간 매출은 어떻게 다른가 — 숫자를 읽는 배경이며 현재 앤트로픽 수치의 출처는 아닙니다.
산업 구조: HBM에서 전력·냉각·기판까지 — 투자가 실제 설비로 바뀌는 연결.
추론 메모리: KV cache 재사용과 HBM 수요 — 연산 절약과 메모리 계층의 차이.
서비스 측정: TTFT·TPOT·ITL과 처리량 — 단순 토큰 수가 아닌 응답 품질을 확인하는 방법.

Appendix · 수치와 확인 범위

HBM은 가속기 가까이의 고대역폭 메모리, CPU DRAM은 별도 메모리 계층, NAND flash는 비휘발성 저장장치입니다. GW는 전력 단위이지 GPU 대수·토큰 수·메모리 발주액 단위가 아닙니다. Take-or-pay는 구매 의무를 강화하는 조건이지 채무 불이행이나 인도 분쟁을 없애는 조건은 아닙니다.

계산 환경은 Windows의 Node.js v24.14.1이며 산술 검증만 실행했습니다. 유료 LLM 호출·GPU 실험·실시간 주가 분석은 하지 않았습니다. 앤트로픽의 분기 매출은 보도치, 공개되지 않은 전체 LTA 잔고·업계 KV 성장률·로봇 시장의 숫자 전망은 미확인입니다.

Vera Rubin NVL72 Memory Demand: HBM4 and SOCAMM2 Scenarios

2026-10-19T06:38:24.898+09:00

Vera Rubin NVL72 creates two different memory requirements: HBM4 attached to Rubin GPUs and LPDDR5X in SOCAMM2 modules on the Vera CPU side. To estimate demand, multiply a stated rack count by the installed configuration—not by an unlabeled headline maximum. The scenarios below are arithmetic exercises, not disclosed NVIDIA orders or supplier shipment forecasts.

Evidence checked October 19, 2026, Korea time. Published platform specifications, dated production statements and hypothetical calculations are labeled separately. No rack hardware, supplier purchase order, wafer requirement or inference benchmark was measured.

1. NVL72 is a configuration name, not a memory-generation guarantee

NVL72 identifies a rack-scale GPU configuration; the full product name matters. NVIDIA’s GB200 page lists Blackwell GPUs with HBM3E, while its Vera Rubin page lists Rubin GPUs with HBM4. A report about “NVL72 shipments” cannot automatically be counted as Rubin HBM4 demand. See the GB200 specification and Vera Rubin specification.

Production also needs a boundary: components being manufactured, completed systems shipping and customer installations becoming usable are different events. NVIDIA’s May 31 release described a production ramp but placed production shipments in the fall. Its later FY2027 Q2 filing says Vera Rubin production shipments began in fiscal Q3. The current product page displays availability. Those statements support a transition into shipments; they do not give us an NVL72 rack-count series.

Sources: May 31 company announcement; 10-Q for the quarter ended July 26, 2026. Fiscal Q3 of FY2027 is not calendar Q3 of 2027. The filing also says Blackwell and Rubin will both ship.

Use: identify the exact architecture before attaching a memory assumption to a shipment headline. Caution: a production announcement is not a bill of materials, an installed-memory average or a purchase commitment for a specific memory supplier.

2. Count two memory paths, not one interchangeable pool

HBM4 is the high-bandwidth memory generation on the GPU side. An HBM stack combines multiple memory dies in a stacked assembly. A stack count is not a die count. SOCAMM2 is a compression-attached module format carrying LPDDR5X on the CPU side; a module is not an HBM stack.

One reference rack · two memory paths

72 Rubin GPUs
GPU count × memory per GPU
HBM4 capacity
Stack count additionally needs capacity per stack.

36 Vera CPUs
CPU count × installed modules per CPU × module capacity
CPU LPDDR5X capacity
SOCAMM2 module count omits the last capacity factor.

Original scope diagram based on NVIDIA’s reference counts. It shows accounting paths, not a physical wiring diagram. CPU and GPU capacities are not interchangeable performance or bandwidth budgets.

The official datasheet, pages 8–10, separates these memory domains. For a broader introduction to the module format and the reported configuration change, our SOCAMM2 and Vera capacity explanation addresses that earlier question. Here we move to rack-level quantity accounting.

Capacity is the amount of stored data, expressed here in nominal GB, TB or PB. Bandwidth is a rate, such as TB/s. More capacity does not alone establish faster inference. Our worksheet normalizes 1 TB = 1,000 GB and 1 PB = 1,000 TB; it does not silently relabel manufacturer GB as GiB.

3. Start with one rack, then expose the missing inputs

A reference specification is a published configuration description, not a measured installed average. The current NVIDIA table lists 288 GB HBM4 per Rubin GPU, 20.7 TB HBM4 per rack, and up to 54 TB CPU LPDDR5X per rack. The CPU ceiling is not our assumption for every shipped system.

GPU-side capacity calculation
72 GPUs × 288 GB = 20,736 GB
20,736 ÷ 1,000 = 20.736 TB per rack

The last number is the decimal-normalized product of the listed inputs; it rounds to the published 20.7 TB. Preserve the reference’s nominal labels rather than treating this as a measurement of exact physical bytes.

A component-density assumption is needed to convert capacity into stack count. Micron’s March 16 release identifies a 36 GB HBM4 12H product and 192 GB SOCAMM2 in high-volume production. “12H” describes stack height, not twelve stacks per GPU. These are useful example densities—not evidence that Micron supplies every stack or module in every rack. Read the dated supplier announcement.

Conditional HBM stack arithmetic
If each stack is 36 GB: 288 ÷ 36 = 8 stacks per GPU.
72 × 8 = 576 stacks per rack.
This is a density-conditioned result, not an independently verified supplier-specific bill of materials.

For the CPU side, let M be populated SOCAMM2 modules per CPU and D be nominal GB per module. Then modules per rack = 36 × M, and CPU capacity per rack = 36 × M × D. We deliberately do not solve M by dividing a rounded CPU maximum by a module label.

Use: calculate capacity and physical component counts in separate columns. Caution: module population rules, exact SKUs and supported densities require a validated configuration. A numerically neat ratio does not supply that validation.

4. What would 100, 500 or 1,000 racks imply?

A scenario is an explicitly chosen input set, not a forecast with an implied probability. We use three invented completed-rack counts to show linear scaling. There is no target quarter, delivery commitment or evidence-based “base case” behind these counts.

Hold the GPU assumption above fixed. For a separate CPU arithmetic exercise, choose M = 4 and D = 192 GB: 768 GB per CPU, 144 modules and 27.648 TB per rack. Four modules per CPU is a worksheet assumption only; this article does not establish that population as an orderable or validated Vera configuration.

Hypothetical capacity · not an order forecast

100 assumed racks

HBM4: 2.0736 PB

CPU LPDDR5X: 2.7648 PB

500 assumed racks

HBM4: 10.368 PB

CPU LPDDR5X: 13.824 PB

1,000 assumed racks

HBM4: 20.736 PB

CPU LPDDR5X: 27.648 PB

Original calculated chart. Every bar starts at zero and uses the same 27.648 PB maximum. Fixed assumptions: 288 GB/GPU; hypothetical four 192 GB CPU modules per CPU. HBM4 and CPU memory remain separate categories even when their capacity bars share a scale.

Invented rack count	Conditional physical component counts
100	57,600 HBM stacks 14,400 SOCAMM2 modules
500	288,000 HBM stacks 72,000 SOCAMM2 modules
1,000	576,000 HBM stacks 144,000 SOCAMM2 modules

Assumes 36 GB per HBM stack and four CPU modules per CPU, as stated above. Counts exclude spares, other platform types, manufacturing losses and inventory timing. They are not observed orders, die starts or supplier allocations.

One-input sensitivity: at the same 1,000 racks, changing only hypothetical M from 4 to 2 halves the CPU result to 72,000 modules and 13.824 PB. HBM4 stays 20.736 PB. Changing only module density would instead change capacity without changing module count. Neither sensitivity asserts a supported hardware configuration.

For a bit-based planning worksheet, nominal bits = nominal bytes × 8. The 1,000-rack HBM result would be 165.888 petabits under the same decimal convention. That conversion does not tell us how many wafers must be started: packaging, die size, redundancy and yield information are still missing.

5. Why calculated capacity is not supplier revenue

Installed demand is the memory embodied in the systems being counted. Procurement demand is what a buyer orders over a period, which can include inventory and spares. Recognized revenue is another boundary again. The three do not have to peak in the same quarter.

Platform mix: a Blackwell shipment is not a Rubin shipment. The fiscal filing supports coexistence, not a one-for-one replacement schedule.
Memory mix: capacity per module and modules per CPU can move independently. A richer module mix can change bits per module without the same change in module units.
Qualification and share: a supplier’s compatible product establishes business exposure, not its share of all racks. Micron’s announcement is evidence of participation; it is not an allocation table for Micron or competitors.
Manufacturing yield: usable stacks are not wafer starts. Without yield and packaging assumptions, multiplying demand into gross production would add false precision.
Deployment timing: power, cooling, networking, financing and customer readiness can delay system acceptance or use. Strong component capacity does not remove those gates.

Our interpretation is therefore conditional: a ramp in completed, similarly configured Rubin racks would increase both memory categories, but at different component counts and price/mix sensitivities. A lighter CPU configuration can moderate LPDDR5X capacity per rack while the GPU-side assumption stays unchanged. Conversely, delays or a different product mix can weaken the same demand case. This is industry analysis, not a buy/sell recommendation or a stock-price forecast.

6. Keep the answer in four separate columns

Quantity	What it does not establish
Memory capacity GB/TB/PB	Bandwidth, latency or actual orders
Stacks / modules physical assemblies	Die count, wafer starts or supplier share
Completed racks units in a period	All Vera platforms or all AI data centers
Supplier revenue currency in a period	Profit, stock return or bits shipped without more data

Next checks: obtain a dated rack-count source, the installed SKU/population rules, the accounting period and supplier-specific shipment evidence. Until then, keep the model as a sensitivity worksheet rather than a forecast. Our SOCAMM2 specification-reading worksheet explains how to check unit and configuration mismatches before replacing these assumptions.

Appendix. Reproduction boundaries and primary sources

The scenario arithmetic was executed locally with Node.js on Windows. It uses no live shipment database, memory hardware, paid API or model benchmark. All rack counts and the four-module CPU example are invented. Replace them only with compatible, dated inputs; do not use NVIDIA’s maximum CPU memory as an installed average. No supply-share, pricing or yield model is included.

NVIDIA Vera Rubin NVL72 specifications — current GPU/CPU memory rows and product availability, checked October 19.
NVIDIA Vera Rubin datasheet — pages 8–10, reference topology and memory domains; not a customer-specific bill of materials.
NVIDIA GB200 NVL72 — distinguishes Blackwell/HBM3E from the Rubin scenario.
NVIDIA production-ramp announcement — May 31, 2026; announcement and shipment timing are separate.
NVIDIA FY2027 Q2 Form 10-Q — quarter ended July 26; shipment-transition and supply/deployment risks.
Micron HBM4/SOCAMM2 production release — March 16, 2026; example component densities and supplier participation.

Both figures and the scenario calculations are original educational material. Vendor specifications are dated source inputs, not independently tested performance. Actual rack shipments, populated configurations, purchase quantities and supplier shares remain unavailable in this worksheet.

LLM Inference Metrics Explained: TTFT, TPOT, ITL and Goodput

2026-10-19T00:03:18.661+09:00

LLM inference performance is not one speed number. TTFT describes the wait for the first output, TPOT and ITL describe how output continues, and E2EL describes the whole request. TPS and RPS measure processing capacity; SLO and goodput tell you whether that capacity meets a stated service goal.

Start with the symptom: a slow start suggests checking TTFT; pauses after the start suggest checking output gaps; an overloaded service needs throughput and SLO checks together. These are directions for investigation, not proof of a root cause.

Documentation checked October 18, 2026. All numerical examples and both diagrams are hypothetical. The short Python arithmetic was actually executed; no LLM, paid API, GPU or inference-engine benchmark was run.

1. TTFT — how long until the answer starts?

Definition: Time to First Token is elapsed time from a defined request start to the first generated output token received at the measurement point. Its unit is milliseconds or seconds; lower means a shorter initial wait under comparable conditions.

A token is a model’s processing unit, not necessarily a word or character. Prefill processes the input; decode generates output. Client-observed TTFT can also include queueing and transport, so it is not simply GPU prefill time. Initial empty messages and HTTP headers are not generated text. NVIDIA NIM’s metric definitions.

Figure 1 · One hypothetical request

Request sent
0 ms

First output token
500 ms · TTFT = 500 ms

Last output token
1,300 ms · E2EL = 1,300 ms

After-first output span: 800 ms. Six output tokens mean five intervening gaps.

Original conceptual timeline, not a hardware trace. Box heights are not proportional to elapsed time. Assume exactly one token per delivery and use the last token as the endpoint.

Use: compare initial responsiveness at the same input size and load. Caution: receiving a first chunk of text is only a proxy when you do not have actual token events. Keep the measurement boundary explicit.

2. TPOT — how fast does the answer continue on average?

Definition: Time Per Output Token describes average elapsed generation time per output token after the first. Here the unit is ms/token, and the calculation assumes one delivered token per event, N greater than one, and a last-token completion boundary.

TPOT = (E2EL − TTFT) ÷ (N − 1)
(1,300 − 500) ÷ (6 − 1) = 160 ms/token

Subtracting one matters: six tokens create five gaps. With zero or one output token, this interval-based formula is undefined. A shorter average interval means faster continuation, but it does not guarantee that every individual gap is short.

Use: compare continuation speed without hiding the initial wait inside the average. Caution: do not assume every tool’s “time per token” has the same numerator or denominator. Some metric names overlap, so read the tool’s definition before comparing results.

3. ITL — where are the pauses hidden?

Definition: in this guide, individual Inter-Token Latency values are successive token-arrival gaps. Their unit is milliseconds. Our six-token example arrives at 500, 600, 700, 1,000, 1,100 and 1,300 ms, giving gaps of 100, 100, 300, 100 and 200 ms.

Figure 2 · Same average does not mean evenly spaced output

Gap 1: 100 ms

Gap 2: 100 ms

Gap 3: 300 ms

Gap 4: 100 ms

Gap 5: 200 ms

Average: 160 ms. Longest gap: 300 ms.

Original hypothetical interval chart. Bars start at zero and use a common 300 ms scale. Five uniform 160 ms gaps would have the same mean but a different delivery pattern.

Important naming difference: NIM/AIPerf also uses ITL for an average interval and treats it as TPOT. Therefore “ITL” on a dashboard does not by itself tell you whether you are seeing an individual gap, a request average or an aggregated distribution. See the tool-specific ITL formula.

Use: inspect uneven streaming instead of relying only on a mean. A chunk is a delivery bundle and may contain several tokens; inter-chunk latency measures gaps between bundles. Network chunks and SSE events are not automatically tokens. Client gap measurements cannot, by themselves, identify server compute or memory as the cause.

4. E2EL — when is the complete result available?

Definition: End-to-End Latency measures elapsed time from request start to the stated completion boundary. Here that boundary is receipt of the last output token, giving 1,300 ms. Lower is better for the same task and comparable output length.

Under our interval assumptions, E2EL = TTFT + TPOT × (N − 1), or 500 + 160 × 5 = 1,300 ms. This is an accounting identity for this example, not a universal substitute for measuring completion.

Use: judge when a generated report, summary or code answer is ready. Caution: an application may continue waiting for a completion signal or perform extra work after the final text. Name that endpoint separately. NIM’s documented AIPerf definition excludes a trailing done/empty signal. End-to-end latency boundary.

5. TPS — how much token work gets through?

Definition: Tokens Per Second is a rate whose scope must be stated. It may mean total server output throughput or the output rate of one request. Both use tok/s, but answer different questions.

For an invented closed benchmark run with 9,000 output tokens over 12 seconds, aggregate output throughput is 750 tok/s. For our one six-token request, including its initial wait gives 6 ÷ 1.3 ≈ 4.62 tok/s. Excluding that wait and using five post-first intervals gives 5 ÷ 0.8 = 6.25 tok/s. State which calculation you mean.

Use: evaluate capacity, then inspect request latency alongside it. Caution: output-only throughput is not input-plus-output throughput. A higher aggregate TPS does not establish a faster individual experience. Record the benchmark window and request inclusion rules. NVIDIA’s benchmarking discussion.

6. RPS — how many requests finish?

Definition: Requests Per Second here means successful completed requests divided by the declared measurement duration. Our invented run completes 120 requests in 12 seconds: 10 req/s. This is not the same as the rate of newly arriving requests.

Concurrency is the number of requests active at once. Batching processes work from multiple requests together. These are load and scheduling conditions, not synonyms for RPS. If arrivals exceed sustainable completion capacity, outstanding work can grow. Load-control distinctions.

Use: size a service for a defined request mix. Caution: ten short answers and ten long answers can have the same RPS but very different token work. Report failed requests, timeouts, warmup and sequence lengths rather than comparing isolated headline rates.

7. SLO — what counts as an acceptable response?

Definition: a Service Level Objective states the performance target. For this lesson, a request passes only if TTFT ≤ 800 ms and TPOT ≤ 200 ms/token. These are invented teaching thresholds, not recommended targets for every application.

P50 is the median. P95 and P99 summarize the high-latency tail: roughly 95% or 99% of observations are at or below the corresponding value, subject to the estimator. Specify the metric, sample count and percentile method. A P95 of request-average TPOT does not describe the distribution of every individual token gap.

Use: make the tolerated wait explicit instead of saying “fast enough.” Caution: a mean can hide slow users, and a small sample gives unstable tail estimates. Latency objectives also do not prove answer correctness. Track quality separately. vLLM’s benchmark CLI exposes percentile reporting and request-level goodput objectives. vLLM benchmark options.

8. Goodput — how much useful capacity meets that target?

Definition: in this guide, goodput is successful completed requests meeting all stated latency objectives divided by the same run duration. Its unit is req/s, not a percentage. The throughput-with-latency-constraints perspective is central to the DistServe research paper.

Invented run: 120 completed requests / 12 s = 10 req/s
72 requests meet both objectives / 12 s = 6 req/s goodput
72 / 120 = 60% attainment among completed requests.

Use: compare throughput at an acceptable latency, not maximum throughput alone. Caution: qualifying criteria, error treatment, workload and time window must match. These counts are declared examples, not measured service capacity. vLLM supports per-request TTFT, TPOT and E2EL constraints for its goodput calculation; always verify the installed version. Goodput configuration.

9. Reproduce the arithmetic, then choose the right next test

The following complete example was executed locally with Python 3.12.14 on Windows. It only calculates the invented timestamps and counters above. It makes no network request, sleeps for no simulated delay and measures no real inference system.

Python · synthetic arithmetic only

# Synthetic arithmetic only: no network, model or GPU benchmark.
arrivals_ms = [500, 600, 700, 1000, 1100, 1300]
gaps_ms = [b - a for a, b in zip(arrivals_ms, arrivals_ms[1:])]
ttft_ms = arrivals_ms[0]
e2el_ms = arrivals_ms[-1]
tpot_ms = (e2el_ms - ttft_ms) / (len(arrivals_ms) - 1)

assert gaps_ms == [100, 100, 300, 100, 200]
assert tpot_ms == 160
print(f"TTFT={ttft_ms} ms")
print(f"TPOT={tpot_ms:.0f} ms/token")
print(f"Individual gaps={gaps_ms} ms")
print(f"E2EL={e2el_ms} ms")
print(f"Request output rate={len(arrivals_ms)/(e2el_ms/1000):.2f} tok/s")
print(f"System output throughput={9000/12:.0f} tok/s")
print(f"Completed-request rate={120/12:.0f} req/s")
print(f"SLO-qualified goodput={72/12:.0f} req/s")
print(f"SLO attainment={72/120:.0%}")

Observed local output · not a model benchmark

TTFT=500 ms
TPOT=160 ms/token
Individual gaps=[100, 100, 300, 100, 200] ms
E2EL=1300 ms
Request output rate=4.62 tok/s
System output throughput=750 tok/s
Completed-request rate=10 req/s
SLO-qualified goodput=6 req/s
SLO attainment=60%

For an actual streaming client, continue with our runnable C# TTFT and E2EL timing lab. That lab uses a simulated SSE server over real local HTTP; it is not a paid-provider or GPU result. It answers the instrumentation question, while this guide explains the metrics.

Question	Start with
Why does the answer start late?	TTFT and queue/input/cache conditions
Why does it pause after starting?	Individual token or chunk gaps, with scope verified
When is the whole answer usable?	E2EL and its endpoint
How much can the service handle?	TPS, completed RPS and matching workload
How much meets the promised latency?	SLO attainment and goodput, plus errors

Takeaway: choose one user question, a measurement boundary and a workload before comparing numbers. Keep first response, continuation, total completion and system capacity separate. A big tok/s value is only informative when you know whose tokens, over which window, at what latency and quality.

Appendix. Benchmark conditions and primary sources

Before a real comparison, record model and tokenizer versions, input sequence length (ISL), output sequence length (OSL), language, hardware, inference engine and precision. Also record cache state, concurrency or arrival process, warmup, request errors and measurement location. Client and server timestamps describe different boundaries; elapsed durations should use an appropriate monotonic clock.

NVIDIA NIM Benchmarking 2.0.0: metrics — tool-specific TTFT, average ITL, endpoint and throughput definitions.
NVIDIA: LLM inference benchmarking fundamentals — rate scope, workload and load-control context.
vLLM bench serve reference — percentile and goodput options; latest documentation checked October 18, not a locally installed/tested vLLM version.
DistServe, OSDI 2024 — serving under TTFT/TPOT latency constraints; no paper benchmark result is presented as our measurement.

Both diagrams and all example values are original educational material. Only local arithmetic was executed. No model quality, tokenization behavior, provider performance, investment return or search-traffic improvement was measured or promised.