Deoks

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.

Build a DRAM Price-Change Calculator in Python

2026-10-18T19:10:31.008+09:00

To combine consecutive DRAM price changes, multiply their growth factors instead of adding percentages. This Python calculator reads a CSV, starts a hypothetical index at 100, and creates a local HTML chart. The sample is invented; its output is not observed DRAM pricing, Samsung’s realized ASP, or a profit forecast.

Quick diagnosis: if +20% followed by −20% gives you “back to zero,” check the denominator. The second change applies to the new level. Run the supplied CSV first and compare the output before using any permitted real dataset. No API key, package install, or paid service is needed.

Executed October 18, 2026 on Windows 11 with Python 3.12.14 and 3.14.3. Standard library only. Other operating systems were not executed. The script reads your chosen CSV and exclusively creates a new chart file; it refuses to overwrite an existing output.

Key terms, defined first

QoQ percentage change: change from the immediately preceding quarter, not from a fixed base year.
Growth factor: 1 + percentage ÷ 100. For example, +20% becomes 1.20.
Index: a relative level rebased to 100 here—not a currency price per chip or per gigabit.
Cumulative change: the final level divided by the initial level, minus one.
CSV: comma-separated tabular text. Our two columns are period and qoq_pct.
Decimal: Python’s decimal arithmetic type. The code constructs values from text; it does not make market assumptions correct.
ASP: a company’s average realized selling price across a defined basket of actual sales.

1. Understand the compounding rule

Definition: each quarter’s rate changes the preceding level. The calculation is next index = previous index × (1 + QoQ rate ÷ 100). Cumulative change is (final index ÷ starting index − 1) × 100. Rates are in percent; index levels have no currency unit.

Example: start at 100. A 20% rise gives 120. A 20% fall then gives 96, because the fall is 20% of 120. A further 10% rise gives 105.60. The combined change is +5.60%; adding 20 − 20 + 10 would incorrectly give +10%.

Use: chain adjacent changes for one consistently defined series. Do not chain year-over-year rates as if they were sequential quarter-over-quarter rates: overlapping comparison windows would answer a different question.

2. Create the hypothetical CSV

Save the following as sample.csv in a small working folder. These numbers are deliberately invented. Enter 20 for +20%, not 0.20 and not the text “20%.” BASE in the output means the level immediately before the first listed quarter.

sample.csv · hypothetical data

period,qoq_pct
2026Q1,20
2026Q2,-20
2026Q3,10

The code requires exactly these two headers, chronological consecutive quarters and one rate per row. It does not sort rows, fill missing quarters, or quietly treat a blank rate as zero. Before adapting it, keep the source, date, product basket, contract-versus-spot basis and permitted usage of your data in a separate note.

3. Copy the calculator and chart code

Save this complete script as price_change.py. The central calculation is the line beginning level =; the other sections validate inputs, build the chart and handle files. D is simply an alias for Decimal.

Python’s CSV documentation describes DictReader and opening files with newline="". The Decimal documentation explains decimal representation and precision. We keep intermediate values unrounded explicitly and format the display to two decimal places; normal Decimal context precision still applies, so this is not arbitrary-precision financial software.

price_change.py · complete tested source

import csv
import re
import sys
from decimal import Decimal, InvalidOperation
from html import escape

D = Decimal


def calculate(stream):
    reader = csv.DictReader(stream, strict=True)
    if reader.fieldnames != ["period", "qoq_pct"]:
        raise ValueError("header must be period,qoq_pct")
    points = [("BASE", D("0"), D("100"))]
    previous = None
    for row in reader:
        period = (row.get("period") or "").strip()
        if None in row or not re.fullmatch(r"[1-9][0-9]{3}Q[1-4]", period):
            raise ValueError("use exactly two fields and period YYYYQ1..YYYYQ4")
        ordinal = int(period[:4]) * 4 + int(period[-1]) - 1
        if previous is not None and ordinal != previous + 1:
            raise ValueError("quarters must be consecutive, ordered and unique")
        try:
            rate = D((row.get("qoq_pct") or "").strip())
        except InvalidOperation as exc:
            raise ValueError("qoq_pct must be a decimal percentage") from exc
        if not rate.is_finite() or not D("-100") < rate <= D("1000"):
            raise ValueError("qoq_pct must be finite, above -100 and at most 1000")
        if len(points) > 40:
            raise ValueError("this teaching example supports at most 40 quarters")
        level = points[-1][2] * (D("1") + rate / D("100"))
        points.append((period, rate, level))
        previous = ordinal
    if len(points) == 1:
        raise ValueError("CSV must contain at least one data row")
    return points


def chart_html(points):
    peak = max(level for _, _, level in points)
    bars = []
    for period, _, level in points:
        width = level / peak * D("100")
        bars.append(
            f'<p style="margin:18px 0 6px;">{escape(period)}: '
            f'<strong>{level:.2f}</strong></p>'
            f'<div style="height:24px;background:#303238;">'
            f'<div style="width:{width:.2f}%;height:24px;'
            f'background:#8ab4f8;"></div></div>'
        )
    figure = (
        '<figure id="index-chart" aria-label="Hypothetical chained price index" '
        'style="margin:0;padding:16px;background:#27282c;'
        'border:1px solid #414247;border-radius:12px;">'
        '<strong>Hypothetical index - base 100</strong>'
        + "".join(bars)
        + '<figcaption style="font-size:16px;color:#c4c7cf;margin-top:18px;">'
        'Invented data, not observed DRAM prices. Bars start at zero; '
        'the largest displayed index fills the width.</figcaption></figure>'
    )
    return (
        '<!doctype html><html lang="en"><meta charset="utf-8">'
        '<meta name="viewport" content="width=device-width,initial-scale=1">'
        '<title>Hypothetical price index</title>'
        '<body style="margin:0;padding:18px;max-width:760px;'
        'background:#1e1f21;color:#e6e6e9;'
        'font:20px/1.9 system-ui,sans-serif;overflow-wrap:anywhere;">'
        + figure + '</body></html>'
    )


def main():
    if len(sys.argv) != 3:
        raise ValueError("usage: python price_change.py sample.csv chart.html")
    with open(sys.argv[1], encoding="utf-8-sig", newline="") as stream:
        points = calculate(stream)
    # Exclusive creation: never overwrite an existing output file.
    with open(sys.argv[2], "x", encoding="utf-8") as output:
        output.write(chart_html(points))
    print("HYPOTHETICAL DATA ONLY - not observed DRAM prices")
    print("period,qoq_pct,index,cumulative_pct")
    for period, rate, level in points:
        print(f"{period},{rate:.2f},{level:.2f},{level - D('100'):.2f}")
    print(f"sum_of_rates_only={sum(p[1] for p in points):.2f}%")
    print(f"chart_written={sys.argv[2]}")


if __name__ == "__main__":
    try:
        main()
    except (OSError, ValueError, InvalidOperation, csv.Error) as exc:
        print(f"ERROR: {exc}", file=sys.stderr)
        sys.exit(2)

The chart uses only local HTML and inline presentation, with text labels and zero-based bars. Its largest index fills the available width; it does not pretend that 100 is a monetary quote. The rate bounds and 40-quarter cap are teaching-program guardrails, not claims about the possible behavior of a market.

4. Run it and compare the actual output

From that folder, first check python --version. Then run the command below. If your installation uses python3 instead, substitute that command. Avoid running unreviewed downloads or changing security settings to make this example work.

Terminal command

python price_change.py sample.csv chart.html

Observed execution output: the table below was produced locally from the supplied CSV. Both tested Python versions produced the same index values and identical chart HTML; only the deliberately different second output filename changed.

Actual local output · hypothetical input

HYPOTHETICAL DATA ONLY - not observed DRAM prices
period,qoq_pct,index,cumulative_pct
BASE,0.00,100.00,0.00
2026Q1,20.00,120.00,20.00
2026Q2,-20.00,96.00,-4.00
2026Q3,10.00,105.60,5.60
sum_of_rates_only=10.00%
chart_written=chart.html

Open the newly created chart.html in your browser. The following is the same generated figure embedded in this article, not a screenshot of real market data:

Hypothetical index - base 100

BASE: 100.00

2026Q1: 120.00

2026Q2: 96.00

2026Q3: 105.60

Invented data, not observed DRAM prices. Bars start at zero; the largest displayed index fills the width.

Read the columns: qoq_pct is that row’s input rate, index is the chained level, and cumulative_pct is the change from BASE. Because BASE is exactly 100, the last column is numerically index minus 100 in this example. With another starting level, use the general ratio formula instead.

5. Recognize bad inputs and file errors

Symptom	Safe next step
File exists	Choose a new output name, such as chart2.html. The old file was not overwritten.
Quarter-order error	Check for duplicates, gaps or reversed rows. Do not invent a missing rate.
Rate error	Use a finite decimal number above −100 and at most 1000, without a percent sign.
Header or CSV error	Keep period,qoq_pct exactly, with two fields per row and valid quoting.
File not found	Check your working folder and the input filename. No permission escalation is required.

Verification: five test methods passed on both Python versions, including 12 invalid-input subcases, year rollover, the 40-quarter limit and malformed quoting. A second attempt to create the existing chart file was also checked: Python returned error exit code 2 and left the existing output intact. A shell wrapper may expose a different outer status, so use the printed error message as well.

The strict rate lower bound excludes a zero-price collapse, where a subsequent ordinary percentage change would need different treatment. The program supports up to 40 quarters, reads UTF-8 with an optional BOM, and ignores entirely blank CSV lines through the CSV reader. It is not a production data-cleaning or index-construction service.

6. Know what the index cannot tell you

Definition: rebasing a series changes its scale, not its meaning. A correctly compounded index still needs a consistent product definition and source methodology. It does not reveal an absolute DRAM price without a matching starting quote and unit.

Do not splice different products or mix spot quotes with contract prices just because each number is called “DRAM.” Nor can a basket’s percentage change be substituted for Samsung’s realized ASP or operating-profit growth. Actual sales mix, volume and costs are separate inputs. Our related English analysis explains the boundary between memory prices and Samsung’s profit estimate; the calculator does not estimate that relationship.

Takeaway: validate the period and units, multiply growth factors, keep calculations separate from display rounding, and label every illustrative result. Your next exercise is to change one invented rate, choose a new output filename, and explain the result before considering any licensed real data.

Appendix. Reproduction and sources

Test environment: Windows 11, CPython 3.12.14 and 3.14.3; no third-party packages, network calls or paid APIs in the example.
Official Python 3.12 CSV reference — parsing, headers, file newline handling.
Official Python 3.12 Decimal reference — decimal values, arithmetic and finite precision.
Checked October 18, 2026. Local tests are not a DRAM-market observation, hardware benchmark, investment model or traffic-performance claim.

Memory Prices and Samsung’s Record Profit Estimate: What the Data Shows

2026-10-18T06:34:40.793+09:00

Higher memory selling prices can lift Samsung’s profit, and the company identified rising prices as one contributor to its Q2 2026 memory results. Its Q3 guidance is a consolidated estimate—not a memory-profit breakdown. That supports a pricing tailwind, not an exact price-to-profit attribution.

Evidence checked October 18, 2026, Korea time. Q3 figures below are preliminary guidance issued October 8; the detailed business discussion is explicitly Q2. No share-price move or investment return is inferred.

The terms to know first

ASP: average selling price; the average realized price across a defined set of sales. Changing the product mix can change it.
Bit shipments: memory quantity sold, measured in bits—not the number of modules or the amount of revenue.
Product mix: the proportions of different products sold, such as server memory and other memory products.
Gross profit / operating profit: revenue after cost of sales / profit after operating expenses as well. Neither is automatically cash flow.
Consolidated / DS / Memory: the company-wide reporting scope / Device Solutions semiconductor division / the Memory Business within DS. These are not interchangeable.
Guidance: a preliminary company estimate, not the same disclosure as finalized detailed quarterly results.

1. What is the record-profit number?

Definition: consolidated operating profit covers the whole company. Samsung’s October 8 guidance estimates Q3 sales at KRW 195 trillion and operating profit at KRW 107.40 trillion. Its comparison table gives Q2 sales of KRW 171.5 trillion and operating profit of KRW 89.49 trillion. These are not memory-only figures.

Figure 1 · Same scope, different disclosure status

Q2 2026 · reported
KRW 89.49 trillion

Q3 2026 · preliminary estimate
KRW 107.40 trillion

Original chart from Samsung’s October 8 comparison table. Both bars start at zero; widths use Q3 = 100%. Q3 is an estimate, not finalized divisional earnings. Data source.

Using those inputs, estimated operating profit rises 20.0% quarter on quarter, compared with a 13.7% sales increase. Calculated operating margin is approximately 55.1%, versus 52.2%: about 2.9 percentage points, not a 2.9% relative increase.

Samsung called Q2 an all-time quarterly operating-profit high in its July 30 results release. Q3 guidance exceeds that prior record; the careful description is therefore a record-profit estimate. The July release rounds Q2 operating profit to 89.5; calculations here consistently use 89.49 from the October comparison table.

2. What actually links memory prices to profit?

Purpose: distinguish an explained mechanism from a quantified contribution. For Q2, Samsung attributed record Memory Business performance partly to industry-wide price increases and a server-focused sales mix. It also reported DS revenue of KRW 127.5 trillion and DS operating profit of KRW 89.2 trillion. DS is broader than Memory. Company’s Q2 discussion.

Do not carry one quarter’s explanation into another quarter as a completed profit bridge.
The short Q3 guidance gives no allocation of the profit change to memory prices, bit shipments, product mix, costs, currency, or individual divisions.

A profit bridge reconciles a starting profit with an ending profit by identifying contributions and offsets. Without that breakdown, “memory prices helped” and “memory prices explain all the increase” are very different statements. Subtracting a DS number from company profit is not a substitute for one: scope, rounding and consolidation effects must also be reconciled.

3. Why can profit grow faster than price?

Definition: a selling-price change affects revenue, while costs may move by a different amount. Consider one imaginary product, unchanged sales volume and unchanged cost per item. All numbers below are teaching units, not KRW, Samsung prices, or an earnings forecast.

Figure 2 · A 20% price rise is not a 20% profit rise

Before: revenue 100
Cost of sales 70 · gross profit 30

After: revenue 120
Cost of sales 70 · gross profit 50

Blue segment: cost of sales.
Green segment: gross profit.

Original hypothetical illustration on a common revenue scale. At flat volume, revenue increases 20%; gross profit rises from 30 to 50, or 66.7%. Operating expenses, tax, financing, currency and changing costs are omitted. This does not estimate Samsung’s sensitivity.

Use: understand why the direction of a pricing effect can be convincing while its magnitude remains uncertain. If cost per item rises, the benefit shrinks. If shipment volume falls, total revenue need not track the price increase. In another hypothetical case, price +20% and volume −15% produce 1.20 × 0.85 − 1 = +2% revenue—not +5%, and not +20%.

The simple model stops at gross profit. To reach operating profit, also account for operating expenses and other business effects. To judge cash generation, examine working capital and investment spending separately. A profitable quarter and an affordable expansion program are related questions, not identical ones.

4. Why ASP and an industry price index differ

Definition: an industry price index summarizes a specified market basket; a company’s realized ASP reflects what it actually sold. A spot quote covers a different transaction setting from a negotiated contract. Neither should silently replace the company’s realized price.

There is a second trap: a higher average price can reflect more expensive products in the sales mix, not just a price rise for an unchanged product. HBM—high-bandwidth memory—and other server-memory products need separate product, shipment and cost assumptions. Do not apply one DRAM percentage to all memory revenue, much less to consolidated profit.

Application: ask whether two numbers share a product family, sales period, price basis and unit. Compare like with like before calculating. For the hardware side of this boundary, our English SOCAMM2 analysis separates system capacity from supplier shipment demand. A larger specification is not itself a realized sale.

5. Three conditional paths to watch

Purpose: turn a broad “memory boom” claim into checks that could disprove it. These are analytical scenarios, not assigned probabilities, company guidance or share-price targets.

Pricing benefit persists. Realized selling prices and the product mix remain favorable while saleable shipments and unit-cost execution hold up. Look for detailed business commentary, shipment measures and margins—not just another industry price headline.
Higher revenue, weaker conversion into profit. Costs, product ramps, lower volume or weakness elsewhere offset part of the pricing benefit. Test revenue growth against operating margin and cash generation.
The cycle normalizes. Demand softens or supply expands enough to reduce pricing power. Watch inventory, utilization, customer purchasing and realized prices together; no one indicator establishes a turning point.

For AI infrastructure, my interpretation is two-sided: a higher memory selling price may help a supplier’s revenue per unit but increase a buyer’s component budget. Whether that slows deployments depends on the buyer’s configuration, total project cost and workload economics. It is not evidence that every AI supplier benefits equally or every data center must cut spending.

Samsung also described component-cost pressure in its Q2 mobile discussion. That is a useful reminder that the same company can contain sellers and users of expensive components. It does not quantify the net Q3 effect. Q2 business commentary.

6. A checklist for the next earnings release

Check	Why it matters
Disclosure status	Replace preliminary guidance only when finalized results appear.
Business scope	Separate Memory, DS and consolidated figures.
Price and mix	Ask whether ASP moved within products or because the basket changed.
Volume and cost	Check bit shipments and production economics before attributing profit.
Cash and investment	Do not treat operating profit as free cash available for expansion.

The takeaway: the pricing link has a credible economic mechanism and explicit Q2 company support. The Q3 consolidated estimate is stronger than Q2, but its price-only contribution remains undisclosed. The next useful step is a same-period, same-scope profit bridge—not a more confident extrapolation from a memory-price headline.

Appendix. Sources, calculations and limits

Samsung Electronics’ common shares are listed on KRX as 005930, as verified in its listing information. This article is industry and company analysis, not a buy/sell recommendation. It contains no share-price quotation, return prediction or hardware test.

Samsung: Q3 2026 earnings guidance — October 8, 2026; consolidated preliminary inputs.
Samsung: Q2 2026 results — July 30, 2026; detailed business discussion.
Samsung IR: earnings releases — checked October 18; no Q3 detailed-results PDF was listed on the observed page.

Arithmetic was executed locally: change = new ÷ old − 1; operating margin = operating profit ÷ revenue. Rounded calculations are not additional company guidance. The two original diagrams use disclosed inputs or explicitly hypothetical values; no company chart or photograph was copied. No numerical memory-price index or Samsung-specific ASP growth rate is asserted.

Read SOCAMM2 Specifications: Capacity, Bandwidth, and Module Counts

2026-10-17T19:08:09.197+09:00

To read a SOCAMM2 specification, label every number with its unit, hardware scope, and qualification before calculating anything. Capacity is not bandwidth, a maximum is not installed memory, and dividing two differently defined capacity labels does not prove a module count.

Quick check: if your module-count calculation produces a fraction, do not round it into a hardware claim. First check GB versus GiB, per-module versus per-CPU scope, and whether the number is a rounded maximum. If a field is missing, write “not determined” and request the exact configuration.

Documentation checked October 17, 2026. Worked exercises below use explicitly declared assumptions; they are not a Vera bill of materials or a hardware benchmark.

Key terms, defined first

SOCAMM2: a memory-module format; do not confuse the physical module with the CPU or the entire server.
Capacity: how much data can be held, expressed in bytes and a stated prefix.
GB / GiB: decimal gigabyte / binary gibibyte. The letters are not interchangeable.
Bandwidth: a data-transfer rate, such as GB/s; not an amount of stored data.
Gb/s / GB/s: gigabits per second / gigabytes per second. One byte is eight bits.
Scope: the object a number describes—one module, one CPU, a Superchip, or a rack.
Populated capacity: memory actually fitted in a specific configuration, rather than the largest supported option.

1. Attach numbers to the right hardware level

Purpose: prevent a perfectly correct calculation from answering the wrong question. A module capacity describes one physical assembly. A CPU-memory figure describes a larger memory subsystem. A rack figure describes an even wider scope.

For a real reading exercise, NVIDIA’s Vera CPU page states up to 1.5 TB of memory and up to 1.2 TB/s of LPDDR5X memory bandwidth. The first is capacity; the second is a rate. Neither number, on its own, states how many SOCAMM2 modules are installed.

Figure 1 · Put each number in its own box

MODULE
Part number · capacity per module · supported operation

CPU MEMORY SUBSYSTEM
Populated modules · total CPU-attached capacity · aggregate memory bandwidth

SYSTEM / SUPERCHIP
CPU and GPU counts · separate memory pools · exact configuration

Original reading diagram, not a wiring diagram. A number may move between levels only when a documented mapping and matching units support the calculation.

NVIDIA’s Vera Rubin table gives one Vera CPU and two Rubin GPUs per Superchip, with separate CPU-memory and GPU-memory rows. That does not mean two GPU memory quantities can be added to the CPU’s LPDDR5X and treated as directly interchangeable capacity.

2. Normalize GB, GiB, TB, and TiB

Definition: decimal prefixes use powers of ten; binary prefixes use powers of two. For the exercises here, 1 GB = 10⁹ bytes, 1 TB = 10¹² bytes, 1 GiB = 2³⁰ bytes, and 1 TiB = 2⁴⁰ bytes. See the NIST SI-prefix table and binary-prefix definitions.

Figure 2 · Same printed number, different byte counts

Exercise A: exactly 192 GB
192,000,000,000 bytes
÷ 1,073,741,824
≈ 178.814 GiB

Exercise B: exactly 192 GiB
206,158,430,208 bytes
÷ 1,000,000,000
≈ 206.158 GB

Original unit-conversion exercises. These are different starting byte counts, not memory lost during conversion and not a relabelling of Micron’s product. A hardware vendor’s printed convention must be checked separately.

Use: convert both inputs into the same byte-based unit before dividing. Caution: a memory datasheet may use a legacy convention or rounded labels. If its byte definition is not explicit, preserve the vendor’s label and mark the conversion assumption; do not silently rename GB as GiB.

3. Read bandwidth without multiplying twice

Definition: a rate has a time denominator. TB and TB/s cannot be compared as if they measure the same thing. Also check whether the quoted rate is per data pin, per module, per CPU, or a link’s aggregate rate.

Hypothetical raw-bandwidth exercise
9.6 gigabits/s per data pin
× 128 active data pins
÷ 8 bits per byte
= 153.6 decimal GB/s

The inputs above are declared teaching assumptions—not a verified SOCAMM2 data width or measured Vera result. They describe an ideal parallel-transfer calculation. A supported module, controller, and operating configuration must actually satisfy those assumptions before the result can describe hardware.

If the input is already a transfer rate, do not apply another “double data rate” multiplier. If it is already an aggregate GB/s figure, do not multiply it by bus width again. Likewise, a CPU’s memory-bandwidth number and its CPU–GPU link-bandwidth number describe different interfaces; adding them does not create a useful memory-throughput specification.

4. Calculate a module count only when inputs match

Purpose: estimate physical modules only from a specified, compatible population—not from unrelated maximum-capacity headlines.

Declared hypothetical configuration
CPU populated memory: exactly 1.5 TiB
Identical compatible modules: 192 GiB each
1.5 × 1,024 = 1,536 GiB
1,536 ÷ 192 = 8 modules

This answer is valid only under those assumptions. It does not establish Vera’s populated module count. By contrast, blindly dividing decimal 1.5 TB by decimal 192 GB gives 7.8125. Rounding that to eight would conceal a mismatch; eight such decimal modules would total 1.536 TB, not exactly 1.5 TB.

Confirm the supported densities, population rules, and installed option with the system vendor. Do not assume one physical module equals one independently active memory channel; check the actual mapping in the controller and module documentation.

5. Use a dated specification worksheet

Definition: a specification worksheet is a small record of what the source actually says. Fill these fields before comparing products:

Object: exact product, configuration, and revision.
Metric: capacity, transfer rate, physical count, or another quantity.
Unit and scope: retain the printed unit; note per module, CPU, or system.
Qualification: “up to,” maximum supported, populated, or measured.
Source and date: the original statement’s date plus your check date.
Unknowns: byte convention, populated module count, or other missing conditions.

For example, Micron’s March 16, 2026 announcement describes 192 GB SOCAMM2 production and a platform capability of up to 2 TB per CPU. The current NVIDIA Superchip table lists up to 1.5 TB CPU memory. Record them as separately dated statements, not as one automatically compatible set of module-count inputs. Neither tells you what a particular customer bought.

For the industry implication rather than the arithmetic, our related English analysis explains why Vera’s reported memory-capacity cut is not an order-volume total. This tutorial answers the narrower task of checking a specification sheet.

6. Compare the common mistakes

Mistake	Safer check
GB = GiB	Normalize the declared byte convention.
Gb/s = GB/s	Convert bits to bytes and verify the scope.
Maximum = installed	Ask for the populated configuration.
Fractional ratio → round up	Stop; check units, rounding, and compatibility.
Mixed dates → one BOM	Keep source revisions separate. BOM means bill of materials.

Your next action: annotate one real specification using the six worksheet fields. If its byte convention or populated configuration is missing, the correct module-count answer is “not determined”—not a more confident multiplication.

Appendix. Verification and sources

All exercise arithmetic was checked locally. No SOCAMM2 module, Vera CPU, Rubin GPU, or memory benchmark was run. The exercise does not establish supported bus width, installed module counts, effective application bandwidth, shipments, or investment outcomes. No credentials or paid service are needed to repeat the arithmetic.

NIST: binary prefixes and byte examples.
NIST: decimal SI prefixes.
NVIDIA: Vera CPU memory specifications, checked October 17, 2026.
NVIDIA: Vera Rubin configuration table, checked October 17, 2026.
Micron: March 16, 2026 production statement.

Original learning diagrams and worked examples by Deoks. Definitions, assumptions, and vendor specifications are kept separate; no search-volume or future-traffic claim is made.

SOCAMM2 Explained: What Vera’s Reported Memory Cut Really Means

2026-10-17T06:38:09.467+09:00

SOCAMM2 is a compact, replaceable module that brings low-power LPDDR5X memory to the CPU side of an AI system. It is not the Rubin GPU’s HBM4. The reported Vera memory cut concerns capacity per configuration; that alone does not establish fewer module orders or falling total memory demand.

Evidence checked October 17, 2026, Korea time. This is an explanation of dated public reports and product specifications—not a new NVIDIA order announcement, a hardware benchmark, or a stock-price forecast.

Definitions before the headlines

SOCAMM2: the second-generation small-outline compression-attached memory module format discussed here; a module is the physical assembly, not a new type of memory cell.
LPDDR5X / LPDRAM: a low-power DRAM technology / the broader low-power DRAM category. These describe the memory, not the module’s shape.
Vera: NVIDIA’s CPU, which runs host-side and standalone computing workloads.
Rubin and HBM4: the GPU and its high-bandwidth memory in the Vera Rubin platform. They are distinct from Vera’s CPU-attached LPDDR5X.
Capacity versus bandwidth: how much memory can hold versus how quickly data can move. More capacity does not automatically mean more bandwidth.
Bit demand versus module shipments: total memory quantity versus the number of physical modules shipped. Module density and populated slots connect the two.

1. Where SOCAMM2 fits—and why use it?

Definition: think of SOCAMM2 as the replaceable carrier for low-power server memory. Micron’s October 2025 introduction identifies LPDDR5X as the technology inside it and describes serviceability as a benefit of the modular design. That is a packaging and system-design choice, not a claim that every memory tier has become interchangeable. Micron’s introductory announcement.

Purpose: combine low-power memory with the ability to replace modules in a server. NVIDIA’s Vera documentation describes detachable SOCAMM memory and CPU work such as data processing, orchestration, and KV-cache management. A KV cache is saved attention state used during model generation. Its placement depends on the serving software and workload; this article does not claim that all KV state sits in CPU memory. NVIDIA’s Vera architecture page.

Figure 1 · Two memory pools, different attachment points

Vera CPU ↔ SOCAMM2 / LPDDR5X
CPU-attached working memory. Module capacity and populated modules matter here.

NVLink-C2C connects CPU and GPU
Connectivity does not make their physical memory interfaces identical.

Rubin GPU ↔ HBM4
GPU-side high-bandwidth memory. A SOCAMM2 module is not an HBM4 replacement.

Original conceptual diagram, not a board layout or scale drawing. Based on NVIDIA’s Vera and Vera Rubin specifications, checked October 17, 2026.

Use this distinction when reading an “AI memory” headline: first identify the processor and memory tier. A shortage or configuration change on one side is not automatically the same event on the other.

2. What was reportedly cut?

The reported change was a capacity adjustment, not a disclosed aggregate order cancellation. On June 10, 2026, TrendForce said NVIDIA had halved SOCAMM memory capacity in its next-generation Vera Rubin configuration because preliminary 2027 LPDRAM allocations were insufficient. The researcher described a strategy of putting less memory into each configuration to enable more units, rather than reducing NVIDIA’s overall memory requirement. This is TrendForce’s supply-chain finding—not an NVIDIA-confirmed purchase-order total. Read the dated research statement.

A later, publicly visible September 24 bulletin summary still describes a Vera capacity trim intended to support more shipments. Only that public summary was reviewed; the paid report was not accessed. Neither page is a real-time shipment ledger.

Three different questions:
How much memory is fitted per CPU or system?
How many physical modules are ordered?
How many memory bits are bought in total?

A percentage attached to one question cannot answer the other two without additional data.

Caution: the reviewed evidence does not give an audited, current total of SOCAMM2 orders by supplier. Describing the story simply as “NVIDIA cut SOCAMM2 volume” would erase the denominator that makes the claim meaningful.

3. Why the specification date matters

A maximum specification is a ceiling for a documented configuration, not a shipment average. The two public records below should remain separate:

March 16, 2026—Micron: its production announcement says SOCAMM2 supports up to 2 TB per CPU for the platforms discussed there. It also announces 192 GB SOCAMM2 in high-volume production. Product availability is not a disclosure of NVIDIA’s purchased quantity. Micron’s production announcement.
Checked October 17, 2026—NVIDIA: the live Vera Rubin specification lists up to 1.5 TB LPDDR5X per Superchip, whose configuration includes one Vera CPU and two Rubin GPUs. It separately lists HBM4 GPU memory. Current platform specification.

The numerical difference is visible. Its full cause and configuration history are not established by comparing those two maxima. In particular, 1.5 versus 2 is a 25% difference—not evidence that TrendForce’s separately reported halving describes the same baseline. Do not join a dated supplier capability statement, a current system maximum, and an analyst’s configuration report into a single invented bill of materials.

For a deployment decision, ask the vendor for the exact system SKU, populated memory, supported module density, and specification revision. A SKU is the identifier for a particular sellable configuration.

4. Less per system does not settle total demand

Definition: aggregate capacity is the sum installed across systems. For an identical-configuration teaching example:

Total installed capacity
= systems shipped × populated modules per system × capacity per module

Module shipments instead equal systems shipped × populated modules per system. This is why “capacity cut,” “module-count cut,” and “bit-demand cut” are not synonyms.

Figure 2 · The missing shipment denominator

Invented capacity units, not GB or a NVIDIA forecast. Baseline: 100 systems × 100 units = 10,000 units.

Same system count; half the capacity
100 × 50 = 5,000 units
Total = 50% of baseline

Twice the systems; half the capacity
200 × 50 = 10,000 units
Total = 100% of baseline

1.5× the systems; half the capacity
150 × 50 = 7,500 units
Total = 75% of baseline

Original arithmetic scenarios. Bars share the same 10,000-unit baseline. All values are illustrative; actual modules per system and supplier shipments are not assumed.

Interpretation: doubling system count exactly offsets a halving of capacity per system in this simplified example. If shipments grow less, aggregate capacity falls; if configurations vary, calculate each group separately. Constant total capacity also does not guarantee constant revenue: prices, product mix, qualification, and delivery timing still matter.

5. What changes for suppliers and data centers?

Memory suppliers: Micron’s own announcement establishes a SOCAMM2 production role. TrendForce’s allocation discussion names Samsung, SK hynix, and Micron, but does not disclose a verified supplier-by-supplier order book. The relevant business question is which qualified products ship, at what capacity and price—not which company appears most often in a headline.

Our interpretation for data-center buyers: a smaller supported CPU-memory configuration can force trade-offs between how many systems can be deployed and how much working data each can retain. Whether that hurts a workload depends on its actual memory footprint, concurrency, software placement, and service target. It is not possible to infer a universal tokens-per-second penalty from capacity alone.

Counter-cases matter: allocation could improve; customers could choose other configurations; deployment timing could slip; or workload demand could weaken. Any of those could change the result. HBM packaging, CPU-attached LPDRAM, networking, power, and cooling also have different constraints. Our related English analysis, where AI data-center spending goes beyond HBM, explains why a rack is not a single memory purchase.

This is an industry-reading framework, not a recommendation to buy or sell a stock. No supplier revenue, profit, market share, target price, or stock reaction is forecast here.

6. The practical conclusion

Headline term	What to verify
Capacity cut	Per module, CPU, or entire system? Which configuration and date?
Order cut	Physical modules or memory bits? Confirm the actual order evidence.
Demand outlook	System shipments, populated memory, prices, and delivery period.

Bottom line: identify the memory tier and the denominator before drawing a demand conclusion. The next useful evidence would be a dated configuration change, confirmed shipment quantities, or supplier delivery guidance—not another multiplication of unrelated maximum specifications.

Appendix. What this analysis did—and did not—test

The scenario arithmetic and percentages were calculated locally. No Vera or Rubin hardware was tested. No customer order database, paid market report, or confidential company information was used. Specifications are vendor-stated maxima, not observed fleet configurations. The analysis uses no stock-price data and makes no assertion about an October 16 trading-session reaction.

Sources and dates

Micron, October 22, 2025: SOCAMM2 introduction—module definition, LPDDR5X, and serviceability.
NVIDIA: Vera CPU—CPU-side memory and architecture; live page checked October 17, 2026.
TrendForce, June 10, 2026: reported configuration adjustment—researcher’s findings, not a NVIDIA order filing.
TrendForce, September 24, 2026: public bulletin summary—paid full report not accessed.
Micron, March 16, 2026: production and platform-capability statement—retain its original date and scope.
NVIDIA: Vera Rubin NVL72 specifications—live configuration table checked October 17, 2026.

Original diagrams and analysis by Deoks. Document review: October 17, 2026 KST. Search-volume and future-traffic claims are not made.

Measure LLM Streaming TTFT and E2EL in C#: A Beginner’s Hands-On Guide

2026-10-16T19:06:06.057+09:00

Start a monotonic timer just before sending the request, record the first non-empty generated-text event, and keep the last-text timestamp separate from the completion signal. This guide shows the distinction in a runnable C# streaming lab.

What was actually tested?
C# code over real loopback HTTP, using a simulated SSE generator. No actual LLM was called. No model, provider, GPU, token count or paid inference performance was measured.

Environment checked: 2026-10-16 · Windows build 10.0.26200 x64 · .NET SDK 10.0.400 · .NET runtime 10.0.11. Other operating systems and .NET versions were not executed for this article.

1. Definitions first: what will we measure?

Token: a model’s processing unit. It is not necessarily a word, character, HTTP chunk or SSE event.
TTFT — Time to First Token: wait from a defined request start to the first generated output token at the measurement point. This text client uses the first non-empty generated-text event as a proxy, not a token-generation timestamp.
E2EL — End-to-End Latency: total latency for a request. In our successful-text result, e2elLastTextMs ends at the last non-empty text event. An incomplete request has no successful E2EL result.
Application-completion latency: wait to a documented success signal. Our completionMs ends at the simulator’s [DONE] event. Do not silently compare it with last-token benchmark latency.
SSE — Server-Sent Events: UTF-8 text events sent over HTTP. A blank line finishes an event; multiple data: lines are joined with newlines.
Delta / metadata / chunk: a delta is an incremental text update; metadata describes the response; a transport chunk is a delivery unit. None is guaranteed to equal one token.

Contents

2. Follow one request on the timeline
3. Run the C# example locally
4. Read the actual execution results
5. Check failures before trusting a number
6. Adapt the measurement to a real LLM
7. Quick comparison and next checks
Appendix: full runnable Program.cs and sources

2. Follow one request on the timeline

The server can send headers immediately and still make you wait for text. Timing headers would miss that wait. The first metadata frame can also arrive before any generated text.

Figure 1 · One measured local request

REAL C# EXECUTION · SIMULATED GENERATOR · NOT AN LLM BENCHMARK

0.000 ms · Start request
Start the monotonic clock immediately before GetAsync.

30.131 ms · HTTP headers
Connection ready. Metadata and an empty delta are not generated text.

382.680 ms · First non-empty text
“Hello” arrives. This is our client-side TTFT proxy.

627.875 ms · Last text event
Final text is received. Successful last-text E2EL ends here.

734.832 ms · [DONE] event
Application completion is observed later. It is a different endpoint.

TTFT proxy = first text − start
Last-text E2EL = last text − start
Completion latency = done event − start

Original Deoks diagram using the first recorded local run on 2026-10-16. The server contains deliberate delays. The event order is shown vertically for mobile readability; distances are not a time scale.

The last text and the final success signal can arrive at different times. NVIDIA’s GenAI-Perf discussion explicitly excludes a trailing done/empty response from its end-to-end token latency. Our output therefore exposes both endpoints, rather than calling every stop time the same E2EL. See NVIDIA’s explanation of metric boundaries.

Figure 2 · What does this client actually measure?

CLIENT · timer starts
HTTP request → response headers → SSE event parsing.

THIS LAB · loopback simulator
Artificial delays → JSON text events → [DONE]. Real local HTTP; no model, GPU or paid API.

CLIENT · observations
First text, last text, successful completion and failure status.

REAL LLM SERVICE · NOT RUN
Network / gateway → queue → prefill → decode → streamed output.

A client timer alone cannot separate these internal stages. Server instrumentation is needed for that attribution.

Original conceptual boundary diagram. No server-stage duration, model speed or GPU performance was measured in this lab.

3. Run the C# example locally

Purpose: learn the measurement code without buying inference credits or configuring credentials. The mock emits {"delta":"…"} events and a final [DONE]. This is a deliberately narrow teaching protocol, not a provider-compatible LLM client.

Install a .NET 10 SDK if it is not already available. Confirm the SDK with dotnet --version.
Create a console project using the commands below.
Replace the generated Program.cs with the complete program in the Appendix. There are no third-party package dependencies.
Run normal, then try the failure scenarios. Each run starts and stops its own loopback server; it is not left running in the background.

dotnet --version
dotnet new console -n StreamingTimingLab -f net10.0
# Replace StreamingTimingLab/Program.cs with the full code below.
dotnet run --project StreamingTimingLab -c Release -- normal

The key client setting: use ResponseHeadersRead so the HTTP operation returns before the entire body has been buffered. Pass an overall cancellation token into body reads as well: the usual HttpClient timeout does not automatically cover the later body-reading phase in this mode. Microsoft documents this timeout boundary.

// Excerpt only. The Appendix contains the complete runnable program.
using var response = await http.GetAsync(
    url, HttpCompletionOption.ResponseHeadersRead, cancel.Token);

// After parsing a non-empty text delta:
result.FirstTextMs ??= receivedAt;
result.LastTextMs = receivedAt;

// On the simulator's successful [DONE] event:
result.CompletionMs = NowMs();
result.Status = "completed";

Why Stopwatch? It measures elapsed time using the platform’s timer rather than subtracting two wall-clock display times. UTC is recorded separately for the audit trail. Microsoft Stopwatch reference.

4. Read the actual execution results

These are real C# executions of an artificial streaming workload. The mock deliberately waits 350 ms before its first text, adds later delays, splits a UTF-8 character across writes, and sends completion after the final text. Runtime, scheduling, local transport and parser overhead explain why the observations are not exactly the requested delays.

Run	TTFT proxy (ms)	Last-text E2EL (ms)
1	382.680	627.875
2	387.058	630.852
3	390.237	635.672

In run 1, headers were observed at 30.131 ms, the first text at 382.680 ms, the final text at 627.875 ms, and completion at 734.832 ms. The trailing completion interval was 106.957 ms. It is observable overhead in this mock, not evidence about a real model.

One recorded stdout object from the final compiled program:

{
  "measurementMode": "local_mock_no_llm",
  "actualLlmMeasured": false,
  "scenario": "normal",
  "startedAtUtc": "2026-10-16T02:33:18.4012743+00:00",
  "status": "completed",
  "headersMs": 30.131,
  "firstTextMs": 382.68,
  "lastTextMs": 627.875,
  "e2elLastTextMs": 627.875,
  "completionMs": 734.832,
  "textEvents": 3,
  "text": "Hello, 世界!"
}

All three runs assembled Hello, 世界! from three text events. That is an event count, not a measured token count. Each observation came from a fresh program invocation, without a warm-up phase. Three samples are useful for checking the example—not for a reliable p95, a provider ranking, or a GPU-capacity claim.

5. Check failures before trusting a number

The local behavior suite passed 8 of 8 tests. Failure scenarios intentionally return process exit code 2; their successful E2EL field remains null, not zero.

dotnet run --project StreamingTimingLab -c Release -- empty
dotnet run --project StreamingTimingLab -c Release -- eof
dotnet run --project StreamingTimingLab -c Release -- timeout
dotnet run --project StreamingTimingLab -c Release -- error
dotnet run --project StreamingTimingLab -c Release -- malformed
dotnet run --project StreamingTimingLab -c Release -- http-error
dotnet run --project StreamingTimingLab -c Release -- unterminated

normal: metadata and an empty delta do not start TTFT; multiline data and split UTF-8 preserve the output.
empty: a valid completion with no generated text has firstTextMs = null and e2elLastTextMs = null, but a measured completion time.
eof: partial text followed by a closed connection is incomplete. A partial first-text time may still exist; successful E2EL does not.
timeout: the client enforces a 250 ms deadline while the mock stalls the body. No first text or successful completion is reported.
error / malformed / http-error: a stream error, invalid JSON or HTTP 503 is recorded as failure—not a fast successful response.
unterminated: a done line without the following blank line is not a complete SSE event. The client must not silently claim success.

This sample limits event and accumulated text size. It does not implement automatic retries, reconnection, tool-call aggregation, provider-specific event types, or production load generation. A malformed schema outside its narrow protocol may require additional validation before reuse.

6. What changes when you measure a real LLM?

Actual LLM measurement status: NOT RUN.
No approved target endpoint, model or inference budget was used for this draft. Provider, model, prompt length, output-token count, GPU, server-stage durations, real ITL and real-model E2EL are unmeasured.

Adapt the request and parser. A real service may require POST, different payloads, approved authentication and a different completion convention. Do not point this custom GET/delta demo at an arbitrary API and call it compatible.
Choose the timestamp contract before testing. Define request start, which event carries generated text, what successful completion means, and whether UI rendering or tool execution is in scope.
Fix comparable conditions. Record model/version, prompt and output-token lengths, reasoning settings, concurrency, request rate, cache state, region and failures. Keep client and server measurements separate.
Use server instrumentation for attribution. A slow first-text event alone cannot tell you whether network, queueing or prefill caused the delay.
Report token metrics only with valid token accounting. Multiple tokens can arrive in one text event. Event gaps do not establish token-by-token ITL; this program does not calculate TPOT, TPS or token-level ITL.

For serving-side context, vLLM documents distinct request and streaming-output metrics. Check the exact deployed version and collector definitions before comparing them with this client. No vLLM server was run here.

For the infrastructure question behind latency changes, read why prefix caching saves compute without removing the memory trade-off. That related English analysis is not a benchmark result from this lab.

7. Quick comparison: do not mix these clocks

headersMs: headers observed by the client; not the first generated token and not a directly instrumented first-byte timestamp.
firstTextMs: request-to-first non-empty text event; a clearly labelled client TTFT proxy.
lastTextMs: last text seen so far, even if the request later fails.
e2elLastTextMs: the last-text latency exposed only after successful completion; null for failed or empty-text responses.
completionMs: latency to this protocol’s success signal; may be later than the final text.

Next check: first reproduce the normal and failure cases locally. Only then adapt one approved real service and collect enough comparable requests. Keep failures in the report; do not replace missing measurements with zero.

Appendix. Full runnable Program.cs

Copy the entire program into the .NET 10 console project. The first half measures the stream; the second half is the deliberately delayed local simulator. The sample makes no external network request.

Expand the complete C# program

using System.Diagnostics;
using System.Net;
using System.Net.Sockets;
using System.Text;
using System.Text.Json;

// Local teaching simulator only: no model, API key, GPU or external request.
string scenario = args.Length == 0 ? "normal" : args[0];
string[] allowed = ["normal", "empty", "eof", "timeout",
    "error", "malformed", "http-error", "unterminated"];
if (!allowed.Contains(scenario))
    throw new ArgumentException("Unknown scenario: " + scenario);

var listener = new TcpListener(IPAddress.Loopback, 0);
listener.Start();
int port = ((IPEndPoint)listener.LocalEndpoint).Port;
Task server = ServeMockAsync(listener, scenario);
Measurement result;
try
{
    // The short deadline deliberately tests a stalled body in timeout mode.
    TimeSpan deadline = TimeSpan.FromMilliseconds(scenario == "timeout" ? 250 : 5000);
    result = await MeasureAsync(new Uri($"http://127.0.0.1:{port}/stream"), deadline);
}
finally
{
    listener.Stop();
    await server;
}
Console.WriteLine(JsonSerializer.Serialize(new
{
    measurementMode = "local_mock_no_llm",
    actualLlmMeasured = false,
    scenario,
    startedAtUtc = result.StartedAtUtc,
    status = result.Status,
    headersMs = result.HeadersMs,
    firstTextMs = result.FirstTextMs, // Client TTFT proxy, not a token timestamp.
    lastTextMs = result.LastTextMs,
    e2elLastTextMs = result.Status == "completed" ? result.LastTextMs : null,
    completionMs = result.CompletionMs, // Application completion; includes the done trailer.
    textEvents = result.TextEvents, // Event count, NEVER token count.
    text = result.Text
}));
Environment.ExitCode = result.Status == "completed" ? 0 : 2;

static async Task<Measurement> MeasureAsync(Uri url, TimeSpan deadline)
{
    var result = new Measurement { StartedAtUtc = DateTimeOffset.UtcNow };
    using var cancel = new CancellationTokenSource(deadline);
    using var http = new HttpClient(new SocketsHttpHandler { UseProxy = false });
    var clock = Stopwatch.StartNew();
    double NowMs() => Math.Round(clock.Elapsed.TotalMilliseconds, 3);
    try
    {
        using var response = await http.GetAsync(
            url, HttpCompletionOption.ResponseHeadersRead, cancel.Token);
        result.HeadersMs = NowMs();
        if (!response.IsSuccessStatusCode)
        {
            result.Status = "http_error";
            return result;
        }
        if (response.Content.Headers.ContentType?.MediaType != "text/event-stream")
        {
            result.Status = "invalid_content_type";
            return result;
        }
        await using var body = await response.Content.ReadAsStreamAsync(cancel.Token);
        // StreamReader preserves UTF-8 characters split across transport reads.
        using var reader = new StreamReader(body, Encoding.UTF8);
        var data = new StringBuilder();
        var output = new StringBuilder();
        while (await reader.ReadLineAsync(cancel.Token) is { } line)
        {
            if (line.Length != 0)
            {
                // Comments, event names and other fields are not generated text.
                if (line.StartsWith("data:") || line == "data")
                {
                    string value = line == "data" ? "" : line[5..];
                    if (value.StartsWith(' ')) value = value[1..];
                    data.Append(value).Append('\n');
                    if (data.Length > 1_048_576) throw new IOException("Event too large.");
                }
                continue;
            }
            // A blank line dispatches one SSE event, not one model token.
            if (data.Length == 0) continue;
            string payload = data.ToString(0, data.Length - 1);
            data.Clear();
            if (payload.Length == 0) continue;
            if (payload == "[DONE]") // A convention in THIS simulator, not the SSE standard.
            {
                result.CompletionMs = NowMs();
                result.Status = "completed";
                break;
            }
            using JsonDocument json = JsonDocument.Parse(payload);
            if (json.RootElement.TryGetProperty("error", out _))
            {
                result.Status = "stream_error";
                break;
            }
            if (json.RootElement.TryGetProperty("delta", out var delta)
                && delta.ValueKind == JsonValueKind.String)
            {
                string text = delta.GetString()!;
                if (text.Length == 0) continue;
                double receivedAt = NowMs();
                result.FirstTextMs ??= receivedAt;
                result.LastTextMs = receivedAt;
                result.TextEvents++;
                output.Append(text);
                if (output.Length > 1_048_576) throw new IOException("Output too large.");
                result.Text = output.ToString();
            }
        }
        // EOF is not proof of successful application completion.
        return result;
    }
    catch (OperationCanceledException) { result.Status = "timeout"; }
    catch (JsonException) { result.Status = "invalid_json"; }
    catch (HttpRequestException) { result.Status = "network_error"; }
    catch (IOException) { result.Status = "network_error"; }
    return result;
}

static async Task ServeMockAsync(TcpListener listener, string scenario)
{
    try
    {
        using TcpClient peer = await listener.AcceptTcpClientAsync();
        await using NetworkStream stream = peer.GetStream();
        using var request = new StreamReader(stream, Encoding.UTF8, leaveOpen: true);
        while (await request.ReadLineAsync() is { Length: > 0 }) { }
        async Task Send(string text)
        {
            await stream.WriteAsync(Encoding.UTF8.GetBytes(text));
            await stream.FlushAsync();
        }
        if (scenario == "http-error")
        {
            await Send("HTTP/1.1 503 Unavailable\r\nContent-Length: 0\r\nConnection: close\r\n\r\n");
            return;
        }
        await Send("HTTP/1.1 200 OK\r\nContent-Type: text/event-stream\r\nCache-Control: no-cache\r\nConnection: close\r\n\r\n");
        await Send(": heartbeat\n\ndata: {\"role\":\"assistant\"}\n\ndata: {\"delta\":\"\"}\n\n");
        if (scenario == "timeout") { await Task.Delay(1000); return; }
        if (scenario == "empty")
        {
            await Task.Delay(100);
            await Send("data: [DONE]\n\n");
            return;
        }
        await Task.Delay(350);
        if (scenario == "malformed") { await Send("data: {broken-json}\n\n"); return; }
        if (scenario == "error") { await Send("data: {\"error\":\"simulated\"}\n\n"); return; }
        // Valid multi-line SSE data: the joined JSON contains a newline.
        await Send("data: {\"delta\":\ndata: \"Hello\"}\n\n");
        if (scenario == "eof") return;
        await Task.Delay(100);
        await Send("data: {\"delta\":\", \"}\n\n");
        await Task.Delay(100);
        byte[] tail = Encoding.UTF8.GetBytes("data: {\"delta\":\"世界!\"}\n\n");
        int split = Array.IndexOf(tail, (byte)0xE4) + 1;
        await stream.WriteAsync(tail.AsMemory(0, split));
        await stream.FlushAsync();
        await Task.Delay(20);
        await stream.WriteAsync(tail.AsMemory(split));
        await stream.FlushAsync();
        await Task.Delay(100);
        if (scenario == "unterminated")
        {
            await Send("data: [DONE]\n"); // No blank line: not a complete SSE event.
            return;
        }
        await Send("data: [DONE]\n\n");
        await Task.Delay(150); // Connection closes later; client need not wait for it.
    }
    catch (IOException) { /* Client may cancel/dispose the local connection. */ }
    catch (SocketException) { /* Local listener can be stopped during cleanup. */ }
}
sealed class Measurement
{
    public DateTimeOffset StartedAtUtc { get; init; }
    public string Status { get; set; } = "incomplete";
    public double? HeadersMs { get; set; }
    public double? FirstTextMs { get; set; }
    public double? LastTextMs { get; set; }
    public double? CompletionMs { get; set; }
    public int TextEvents { get; set; }
    public string Text { get; set; } = "";
}

Primary sources and verification

Documentation checked 2026-10-16. Code and original diagrams by Deoks. Local execution, not real-model benchmarking; no third-party figures were copied.

메모리주, 마이크론 반등·샌디스크 약세…AI주 불안은 끝났을까

2026-10-16T08:36:39.973+09:00

어젯밤 메모리주는 장중 급락을 상당 부분 되돌렸지만, 추세 회복을 확인한 것은 아닙니다. 마이크론은 반등했고 샌디스크는 소폭 하락으로 마쳤습니다. 반면 최근 여러 거래일의 손실은 남아 있어, 하루 반등과 메모리 업황에 대한 신뢰 회복을 구분해야 합니다.

기준은 미국 2026년 10월 15일 16:00 EDT 정규장 마감, 한국시간으로는 10월 16일 05:00입니다. 장전 기사·장중 저가·시간외 가격을 종가와 섞지 않았으며, 한국 10월 16일 장중 시세는 반영하지 않았습니다.

1. 메모리주, 장중 공포와 마감 결과는 달랐다

마이크론(MU)은 931.24달러, 전일 대비 +1.87%로 마감했습니다. 샌디스크(SNDK)는 1,394.83달러, −0.61%였습니다. 두 종목이 나란히 큰 폭으로 하락 마감했다는 설명은 그날의 최종 결과와 맞지 않습니다.

메모리주	10/15 저가 → 종가
마이크론 MU	858.00 → 931.24달러
샌디스크 SNDK	1,276.00 → 1,394.83달러

MU 일별 가격와 SNDK 일별 가격 기준입니다. 저가는 하루 중 한때의 거래 가격이지, 그 가격에 누구나 매수할 수 있었다는 뜻은 아닙니다.

최근 흐름까지 보면 이야기가 달라집니다. 10월 8일 종가에서 15일 종가까지 5거래일의 주가 변화는 MU 약 −10.10%, SNDK 약 −13.34%입니다. 배당을 포함한 총수익률이 아니라 종가끼리 계산한 가격 변화입니다. 마이크론의 하루 상승만 보고 최근 조정을 모두 회복했다고 읽기는 어렵습니다.

2. 좋은 실적과 불안한 주가는 함께 나타날 수 있다

마이크론은 9월 30일 공식 실적 발표에서 회계연도 2026년 4분기 매출 542억 2,900만 달러를 보고했습니다. 다음 회계분기인 FY2027 1분기 매출 전망은 615억 달러 ±15억 달러입니다. 이미 발표한 실적과 앞으로의 회사 전망은 서로 다른 성격의 숫자입니다.

이 자료는 당장 메모리 수요가 모두 사라졌다는 주장과는 거리가 있습니다. 그렇다고 현재의 높은 수익성이 오래 지속된다는 보장도 아닙니다. 주가는 최근 실적뿐 아니라 앞으로의 판매가격, 공급 확대, 고객 주문, 그 이익에 적용할 평가 수준까지 미리 반영하려고 움직입니다.

이 때문에 이번 메모리주 전망에서는 ‘AI가 계속 성장하나’보다 질문을 더 나눌 필요가 있습니다. AI 수요가 늘더라도 경쟁과 공급 증가로 가격이 약해지면 업체 이익이 덜 늘 수 있고, 사업이 좋아도 시장이 높은 주가를 정당화할 때 요구하는 기준은 더 엄격해질 수 있습니다. 이는 가능한 경로에 대한 해석이지, 그날 매도의 단일 원인을 입증한 설명은 아닙니다.

HBM·범용 DRAM·NAND를 같은 상품으로 보면 안 된다

HBM: AI 연산 등에 필요한 높은 대역폭을 제공하는 메모리입니다. 고객 채택과 제품 경쟁력을 봐야 합니다.
DRAM: 서버·PC 등에서 사용하는 작업용 메모리입니다. 제품군과 수급 조건에 따라 가격 흐름이 다를 수 있습니다.
NAND: 데이터를 저장하는 플래시 메모리입니다. SSD 등 저장장치 수요와 공급을 따로 봐야 합니다.

마이크론은 DRAM·NAND 제품을 모두 다루며 HBM 사업도 갖고 있습니다. 샌디스크의 공식 사업 설명은 NAND 플래시를 중심에 둡니다. DRAM 경쟁 우려를 샌디스크의 NAND 사업 악화와 곧바로 같은 사건으로 놓으면 설명이 거칠어집니다. 반대로 서로 다른 제품이라는 이유만으로 공통의 투자심리·AI 지출 부담에서 완전히 분리된다고 보기도 어렵습니다.

3. AI·테크주와 전체 미국 증시의 온도도 달랐다

종목·지수	정규장 등락률
마이크론 MU	+1.87%
샌디스크 SNDK	−0.61%
엔비디아 NVDA	−1.84%
나스닥 종합	+0.08%
S&P 500	+0.33%
다우 산업평균	+1.08%

주식은 Stock Analysis의 일별 정규장 자료, 지수 등락률은 eOption에 실린 Hammerstone 마감 브리핑을 사용했습니다. 모두 미국 10월 15일의 전일 종가 대비 변화입니다. 나스닥 종합과 나스닥100·이를 추종하는 ETF는 같은 지표가 아닙니다.

마감 결과는 전체 시장의 반등과 AI 하드웨어 일부의 약세가 공존한 장에 가깝습니다. 같은 브리핑은 반도체 부문의 연속 약세와 헬스케어·필수소비재 등 방어 업종의 상대적인 강세를 함께 전했습니다. 지수가 플러스라는 이유만으로 AI주와 메모리주 전체의 불안이 해소됐다고 볼 수는 없습니다.

배경에는 물가와 자금조달 부담도 있습니다. 10월 14일 발표된 미국 9월 CPI는 전년 동월 대비 3.7%, 식품·에너지를 제외한 근원은 2.6% 상승했습니다. 물가 지표가 곧바로 다음 금리 결정을 확정하는 것은 아니지만, 미래 투자가 큰 기업을 평가할 때 금리와 자금 비용을 계속 확인해야 하는 이유입니다.

4. Reddit에서 보인 낙관·불안·피로감

아래는 미국 10월 14~15일 관련 공개 스레드에서 확인한 개별 의견의 요약입니다. 통계적으로 뽑은 표본도, 투자자 전체의 여론조사도 아닙니다. 게시판 이용자는 해당 종목 보유자에 치우칠 수 있고, 장중 댓글은 최종 종가를 반영하지 않을 수 있습니다.

실적과 AI 수요를 믿는 시각: r/MU_Stock의 조정 논의에서는 큰 변동에도 실적과 전망의 가치를 믿는 의견이 보였습니다. 동시에 AI 투자 수익성에 대한 걱정과 반복되는 하락에 지쳤다는 반응도 있었습니다.
제품 구분과 업황 순환을 놓고 나뉜 시각: r/SNDK_Stock의 DRAM·NAND 논의에서는 다른 메모리 제품의 악재가 과도하게 번졌다는 해석과, 결국 공급 경쟁·가격 순환을 경계해야 한다는 반론이 함께 나왔습니다. 댓글의 경쟁사 생산·계약 관련 주장은 이 글의 확인된 사실로 채택하지 않았습니다.
빠른 반등을 기대하면서도 상대적 약세에 답답해하는 반응: 같은 날의 장중 반등 논의에는 AI 거래가 끝난 것은 아니라는 의견과 다른 종목보다 회복이 더디다는 불만이 함께 있었습니다.

제가 이 의견들에서 읽은 핵심은 낙관론의 소멸보다는 ‘수요는 믿지만, 주가와 이익의 변동을 얼마나 감당할 수 있나’라는 갈등입니다. 다만 이것도 제한된 스레드를 읽은 해석이며, 긍정·부정 의견의 비율을 계산한 결과는 아닙니다.

5. 메모리주 전망, 세 가지 경로를 나눠 보자

① 반등이 이어지는 경우

다음 거래일에도 장중 회복이 유지되고, 메모리주뿐 아니라 반도체·AI 관련 종목의 참여 범위가 넓어지는지 봅니다. 이때도 기술적 반등과 주문·가격 전망의 개선은 별도로 확인해야 합니다. 하루 플러스는 공급·수요 문제가 해결됐다는 증거가 아닙니다.

② 지수는 버티고 메모리주는 흔들리는 경우

전체 지수가 안정돼도 메모리 업체의 가격 전망과 공급 경쟁에 대한 의심이 남으면 업종별 차별화가 이어질 수 있습니다. 이 경로에서는 시장 지수보다 업체별 판매가격·출하·이익 전망이 더 중요한 확인 자료가 됩니다.

③ 실적 전망까지 약해지는 경우

고객 주문 지연, 공급 확대에 따른 가격 압박, 회사의 전망 하향이 실제 공시와 실적에서 확인된다면 단순한 심리 조정이라는 해석을 다시 검토해야 합니다. 반대로 기존 전망을 지키고 현금 창출이 이어진다면 불안론을 반박할 근거도 쌓입니다.

다음 확인 일정 중 하나는 샌디스크의 10월 29일 FY2027 1분기 실적 발표입니다. 이는 미국 현지 발표일이며, 현재 실적이 이미 발표됐다는 의미는 아닙니다.

국내 메모리주에는 어떻게 연결해서 볼까

미국 메모리주가 반등했다고 삼성전자·SK하이닉스도 같은 비율로 움직인다고 예상할 수는 없습니다. 국내 종목은 각자의 제품 구성, 고객 채택, 환율과 수급을 따로 확인해야 합니다. 특히 HBM 경쟁력과 범용 DRAM·NAND 업황을 한 숫자로 합치지 않는 것이 중요합니다.

사업 실적을 더 자세히 읽으려면 마이크론 실적과 메모리 호황의 지속성을 다룬 글을, 국내 시장 충격의 배경은 코스피 급락과 조건부 증시 전망을 함께 참고할 수 있습니다. 이번 글은 그 이후 확정된 미국 정규장 결과와 투자자 의견을 추가로 다룹니다.

정리 · 반등은 확인했고, 추세 회복은 더 봐야 한다

메모리주 분위기는 장중 공포에서 일부 안정을 되찾았지만, 업황과 주가 평가를 둘러싼 논쟁은 남은 상태로 읽는 편이 맞습니다. 마이크론 반등, 샌디스크의 남은 약세, AI주와 전체 지수의 차이를 따로 봐야 합니다.

확인 순서는 가격 회복의 지속성 → 메모리 가격·주문·이익 전망 → AI 고객의 투자·자금 여건입니다. 위 시나리오는 확률·목표가나 매매 시점 추천이 아니라 이후 자료를 해석하기 위한 조건입니다. 이 글은 매수·매도 추천이 아닌 산업·기업을 읽기 위한 정보입니다.

Appendix · 계산과 출처 기준

당일 등락률은 정규장 전일 종가 대비, 최근 5거래일 변화는 10월 8일 종가와 15일 종가로 계산했습니다. MU: 1,035.84 → 931.24달러, SNDK: 1,609.46 → 1,394.83달러입니다. 산식은 (종료 종가 ÷ 시작 종가 − 1) × 100이며, Node로 계산했습니다. 배당 재투자 수익률은 아닙니다.

가격 자료의 정규장·시간외를 구분했고, 서로 다른 공급자의 장중 가격·전일 대비 값이 충돌할 때는 위에 연결한 일별 종가 자료를 기준으로 통일했습니다. SNS 의견은 기업 공시나 가격 데이터의 대체 근거로 쓰지 않았습니다. 자료 확인일: 2026년 10월 16일 KST.

Micron 공식 FY2026 4분기·연간 실적과 FY2027 1분기 전망
Micron 공식 HBM 제품 설명 · Sandisk 공식 사업 설명·발표 일정
MU · SNDK · NVDA 일별 가격 자료 — 제공처 표기: S&P Global Market Intelligence
eOption 게재 Hammerstone 10월 15일 마감 브리핑 — 지수 등락률·시장 해설
미국 BLS 9월 CPI 공식 발표

찰스슈왑(SCHW) 실적, 거래 44% 늘어도 수익은 왜 16%만 늘었나

2026-10-16T06:39:32.890+09:00

찰스슈왑의 거래 수익이 거래 건수만큼 늘지 않은 이유는 거래당 평균 수익이 낮아졌기 때문입니다. 2026년 3분기 실적은 ‘얼마나 많이 거래했나’와 ‘한 건에서 얼마나 벌었나’를 나눠 봐야 이해하기 쉽습니다.

미국 금융주 실적을 읽을 때 거래량 증가율을 곧바로 매출 증가율로 옮겨 적으면 판단이 어긋납니다. 이번 글은 10월 15일 발표된 찰스슈왑(NYSE: SCHW)의 자료로 그 차이를 짚습니다.

1. 먼저 구분할 세 가지 숫자

DATs(Daily Average Trades): 고객의 하루 평균 거래 건수입니다. 거래 금액과는 다릅니다.
Revenue Per Trade: 회사가 집계한 거래 수익을 총 거래 건수로 나눈 평균입니다. 모든 고객에게 똑같이 청구되는 수수료가 아닙니다.
Trading Revenue: 분기 동안 회사가 인식한 거래 관련 수익입니다. 전체 순수익(Net Revenues)의 일부입니다.

회사의 실적표에서 하루 평균 거래는 전년 동기보다 44% 증가했지만, 거래당 수익은 2.11달러에서 1.69달러로 약 20% 하락했습니다. 거래 수익은 9억 9,500만 달러에서 11억 5,800만 달러로 약 16% 증가했습니다. 공식 3분기 실적표 4쪽에 실린 수치입니다.

2. ‘건수 × 거래당 수익’으로 계산하면

회사가 제시한 정의를 뒤집으면 다음 관계가 됩니다.

분기 거래 수익 = 하루 평균 거래 건수 × 회사 집계 거래일 수 × 거래당 평균 수익

공시된 반올림 수치로 전년 대비 배수를 계산하면 1.440 × (64 ÷ 63.5) × (1.69 ÷ 2.11) ≈ 1.163입니다. 약 16% 증가라는 결과와 맞아떨어집니다. 반올림 때문에 실적표의 정확한 증가율과 소수점 차이는 납니다.

이를 ‘수수료를 일괄 인하해서 수익이 덜 늘었다’고 단정하면 안 됩니다. 평균은 거래 구성에 따라 달라질 수도 있기 때문입니다. 이 계산은 성장률의 관계를 설명할 뿐, 거래당 수익 하락의 원인을 따로 입증하지는 않습니다.

예를 들어 수익이 적게 발생하는 거래의 비중이 커지면 전체 거래 건수는 빠르게 늘어도 평균 수익은 낮아질 수 있습니다. 이는 평균값을 이해하기 위한 일반적인 예시이며, 이번 분기의 상품별 기여도를 재현한 분석은 아닙니다.

3. 슈왑은 거래 수익만으로 움직이는 회사가 아닙니다

같은 날 공개한 Fall Business Update 20쪽은 전체 순수익이 전년 동기 대비 17% 늘었다고 설명합니다. 순이자수익과 자산관리·관리 수수료도 각각 14% 증가했습니다.

회사는 순이자수익 증가를 대출 잔액과 롱·쇼트 전략의 성장으로, 자산관리 수수료 증가를 주식시장과 운용 서비스 순유입으로 설명했습니다. 이는 회사의 설명이며, 같은 요인이 다음 분기에도 같은 강도로 이어진다는 뜻은 아닙니다.

따라서 거래 건수 하나만으로 전체 실적을 예측하기 어렵습니다. 고객이 자금을 맡기고, 어떤 서비스를 이용하며, 그 활동이 어떤 수익으로 이어지는지를 함께 봐야 합니다. 거래 지표는 활발한 이용을 보여 주지만 전체 사업의 성적표를 대신하지는 못합니다.

고객자금 유입도 마찬가지입니다. 발표 자료가 강조한 분기 핵심 순유입 약 1,900억 달러는 회사 매출이 아닙니다. 회사는 일회성 대규모 흐름 등을 제외한 지표로 정의합니다. 고객이 맡긴 돈과 회사가 벌어들인 돈은 분리해서 읽어야 합니다. 정의와 추이는 발표 자료 12쪽에서 확인할 수 있습니다.

4. 다음 실적에서 확인할 조건

활동의 지속성: 거래가 일시적으로 몰린 것인지, 이후에도 이용이 이어지는지 확인합니다.
수익 전환: 거래당 수익이 더 낮아지는지, 거래 증가가 이를 상쇄하는지 따로 봅니다.
사업의 균형: 거래 부문의 둔화를 이자·자산관리 부문이 보완하는지 확인합니다.

제 해석으로는 활동과 수익 전환이 함께 개선되는 쪽이 더 탄탄한 신호입니다. 반대로 고객 활동은 늘어도 평균 수익이 계속 낮아지거나 다른 부문이 약해지면, 거래량만으로는 이익 성장을 낙관하기 어렵습니다.

시장 변동성이 커지면 거래가 활발해질 수 있지만, 고객자산 가치나 투자 심리는 약해질 수도 있습니다. 금리 변화도 자산 수익률과 조달 비용에 서로 다른 속도로 작용합니다. ‘변동성 확대 = 슈왑 실적 개선’이라는 한 줄 공식은 피하는 편이 좋습니다. 이 문단은 조건부 해석이지 회사 전망이나 주가 예측이 아닙니다.

요약: 큰 증가율보다 분모를 확인하세요

이번 질문의 답은 단순합니다. 거래 건수가 늘어도 한 건당 평균 수익이 낮아지면 거래 수익은 그보다 덜 늘어납니다. 다음 확인 항목은 거래 건수·거래당 수익·다른 수익 부문이 함께 좋아지는가입니다.

은행 실적에서 이자수익 증가와 최종 이익을 구분하는 방법은 뱅크오브아메리카 실적: 이자이익이 늘어도 순익은 줄 수 있는 이유와 함께 읽어 보세요. 서로 다른 금융사의 성장률을 한 숫자로 비교하지 않는 데 도움이 됩니다.

Appendix · 기준과 출처

기준: 미국 현지 2026년 10월 15일 공개 자료, 2026년 3분기(9월 30일 종료)와 전년 동기 비교입니다. 회사 보고서의 거래일 수를 그대로 사용했습니다. 숫자 관계는 Node로 계산했으며, 거래 실행이나 실적 설명회 청취를 했다는 의미는 아닙니다.

이 글은 사업 지표 해설입니다. SCHW의 정규장·시간외 주가나 시장 예상치 대비 실적을 인용하지 않았으며, 목표가·매수·매도 의견을 제시하지 않습니다.

코스피 7.57% 급락, 하락 배경과 증시 전망을 가를 세 가지 조건

2026-10-16T01:20:11.880+09:00

코스피 급락을 미국 물가나 AI 악재 하나로 설명하기는 어렵습니다. 10월 15일 국내 증시에서는 큰 폭의 하락과 거래 중단이 확인됐고, 시장에서는 미국 물가 상승과 AI 투자 수익성 우려가 함께 거론됐습니다. 앞으로의 증시 전망은 금리 부담, 기업이 실제로 버는 돈, 상승·하락 종목의 분포가 함께 개선되는지로 나눠 보는 편이 낫습니다.

기준: 2026년 10월 16일 01:15 KST 자료 확인 · 국내 지수는 10월 15일 15:30 KST 정규장 종가입니다. 이 시각 미국은 10월 15일 정규장이 아직 진행 중이므로, 미국의 그날 종가나 한국 10월 16일 장 결과를 미리 반영하지 않았습니다. 이 글은 시장 이해를 위한 해설이며 투자 권유나 매매 시점 추천이 아닙니다.

크게 떨어졌다는 사실과 앞으로도 계속 떨어진다는 전망은 다른 말입니다. 먼저 확정된 숫자를 보고, 그다음 원인에 대한 해석과 조건부 전망을 분리해 보겠습니다.

핵심 요약

10월 15일 코스피는 5,554.22, 전일 대비 −7.57%, 코스닥은 760.82, −7.65%로 마감했습니다.
미국 9월 CPI는 전년 대비 3.7% 올랐지만, 근원 CPI는 2.6%였습니다. 휘발유가 월간 전체 물가 상승의 절반 이상을 설명해, 물가의 구성도 봐야 합니다.
AI 공급망의 실적 성장과 AI 서비스 기업의 투자금 회수 문제는 다릅니다. TSMC 실적은 산업 전체의 수요가 사라졌다고 단정하기 어렵게 하는 반대 근거입니다.
하루 반등, 서킷브레이커 해제, 낮아진 주가만으로 바닥을 확인할 수는 없습니다. 전망은 아래 세 가지 조건을 함께 점검하는 방식으로 다룹니다.

국내 마감·거래 중단: YTN 마감 보도 · 지수 소수점 수치 교차 확인: OCI홀딩스 IR 시세 화면. 물가와 기업 실적의 원자료는 해당 절에 연결했습니다.

CPI: 소비자가 구입하는 상품·서비스 가격의 변화를 나타내는 소비자물가지수입니다.
근원 CPI: 식품과 에너지를 제외한 CPI입니다. 일시적인 가격 충격과 다른 품목의 흐름을 구분할 때 참고합니다.
할인율: 미래에 받을 돈을 오늘의 가치로 환산할 때 쓰는 비율입니다. 높아질수록 다른 조건이 같다면 현재가치는 낮아집니다.
현금흐름: 기업으로 실제 현금이 들어오고 나가는 흐름입니다. 매출 증가와 투자비를 낸 뒤 남는 현금은 다릅니다.
서킷브레이커: 시장이 급변할 때 거래를 일시 중단하는 제도입니다. 반등을 보장하는 장치는 아닙니다.

1. 코스피·코스닥은 얼마나 하락했나?

2026년 10월 15일 한국 정규장 마감 · 전일 종가 대비
지수	종가 · 변화
코스피	5,554.22 −454.59포인트 / −7.57%
코스닥	760.82 −63.06포인트 / −7.65%

같은 눈금으로 보면: 코스피 −7.57%, 코스닥 −7.65%로 낙폭 차이는 0.08%포인트입니다. 두 지수의 포인트 하락 폭이 아니라 전일 종가 대비 하락률을 비교한 자체 차트입니다.

하락률 비교: 코스피 −7.57%, 코스닥 −7.65%. 코스닥의 낙폭이 0.08%포인트 더 큽니다. 정규장 종가 기준.

Deoks 자체 제작. 수치 출처·기준 시각은 아래 링크에 명시. 기사·기업 이미지 복제 없음.

차트 자료: YTN 국내 증시 마감 보도와 OCI홀딩스 IR 시세 화면에서 교차 확인한 2026년 10월 15일 15:30 KST 종가 기준입니다. 두 수치는 소수 둘째 자리 반올림 값입니다.

두 시장 모두 장중 서킷브레이커가 발동됐습니다. 장중의 거래 중단 조건과 마감 하락률은 다릅니다. 거래가 멈췄다가 재개된 뒤 낙폭이 달라질 수 있으므로, 종가 하락률이 8%보다 작다는 이유로 거래 중단 보도가 틀렸다고 볼 수는 없습니다. 당일 거래 중단·마감 보도

하락과 회복의 퍼센트도 대칭이 아닙니다. 설명을 위해 100이 7.57% 내려 92.43이 됐다고 가정하면, 다시 100으로 돌아가려면 약 8.19% 올라야 합니다. 실제 지수의 목표가가 아니라 (100 ÷ 92.43 − 1) × 100이라는 산술 예시입니다. 큰 하락 다음 날 올랐다는 것과 이전 수준을 회복했다는 것을 구분하는 데 쓰입니다.

2. 미국 CPI와 금리는 왜 증시에 부담이 되나?

확인된 사실: 미국 노동통계국(BLS)이 10월 14일 발표한 9월 전체 CPI는 전월 대비 0.6%, 전년 대비 3.7% 상승했습니다. 식품·에너지를 뺀 근원 CPI는 각각 0.3%, 2.6%였습니다. 전월 대비는 계절조정, 전년 대비는 비조정 수치입니다. BLS 9월 CPI 원자료

특히 휘발유 가격이 전월보다 9.1% 올라 월간 전체 CPI 상승의 절반 이상을 설명했습니다. 따라서 전체 물가가 다시 높아졌다는 점과 모든 품목의 물가가 같은 속도로 뛰었다는 주장을 섞으면 안 됩니다. 근원 물가가 상대적으로 낮다고 부담이 사라지는 것도 아니지만, 에너지 충격의 지속 여부에 따라 이후 해석은 달라질 수 있습니다.

해석: 물가가 높으면 시장은 높은 금리가 더 오래 이어질 가능성을 따집니다. 금리가 기업의 자금 조달 비용과 주식 가치 평가에 부담을 줄 수 있다는 경로입니다. 다만 이 글에서는 시장 예상 CPI나 금리 선물 확률을 검증하지 않았으므로, ‘예상을 얼마나 웃돌았고 그것이 하락의 몇 %를 설명했다’고 계산하지 않습니다.

연준의 9월 16일 실제 결정은 정책금리 목표 범위를 0.25%포인트 올려 3.75~4.00%로 조정한 것입니다. 이는 한 달 전의 정책 배경이지 10월 15일에 새로 나온 결정이 아닙니다. 추가 금리 인상은 확정 사실로 쓰지 않습니다. 9월 FOMC 성명

쉬운 예를 들어 보겠습니다. 5년 뒤 받을 100을 할인율 8%로 환산하면 현재가치는 약 68.06, 9%이면 약 64.99입니다. 받을 돈이 같아도 가치가 약 4.50% 낮아집니다. 고정 현금 한 번만 가정한 교육용 계산이며, 정책금리가 1%포인트 오르면 모든 주가가 4.50% 떨어진다는 뜻은 아닙니다. 실제 기업에는 성장률·위험·여러 해의 현금흐름이 함께 작용합니다.

3. 반도체주 하락은 AI 수요 붕괴를 뜻할까?

보도된 시장 설명: 연합뉴스는 이번 하락 배경으로 AI 투자 수익성 논란과 미국 물가 부담 등을 제시했습니다. 이는 시장을 설명하는 보도이지, 각 요인의 기여도를 분해한 실험 결과는 아닙니다. 미확인 사기업 매출 수치나 채무불이행 소문으로 금융위기를 확정하지 않겠습니다. 연합뉴스의 배경 분석

반대 근거도 있습니다. TSMC가 10월 15일 발표한 3분기 실적에서 매출은 1조4,942억4,000만 대만달러로 전년 대비 50.9%, 순이익은 7,630억6,000만 대만달러로 68.7% 늘었습니다. 같은 매출을 미국 달러로 표시하면 467억2,000만 달러, 전년 대비 41.2% 증가입니다. 통화가 달라지면 환율 영향으로 증가율도 달라집니다. TSMC 3분기 공식 실적

이 글의 해석: 이 숫자는 ‘반도체 공급망의 매출이 이미 모두 무너졌다’는 주장과는 맞지 않습니다. 그렇다고 TSMC 한 회사의 좋은 실적이 모든 AI 기업의 수익성이나 한국 반도체주의 적정 가치를 증명하지도 않습니다. 칩을 파는 기업의 매출과, 칩을 사서 서비스를 운영하는 기업이 투자금을 회수하는 속도는 서로 다른 문제이기 때문입니다.

그래서 삼성전자·SK하이닉스 같은 메모리 기업은 주가만 보지 말고 공식 실적의 제품별 수익성, 공급 계획, 고객 수요 설명을 확인해야 합니다. 서비스 기업은 매출 성장뿐 아니라 설비 투자 후 현금 부담도 봐야 합니다. 사업 연결을 더 살펴보려면 메타 Muse 모델과 매출·추론 비용·메모리 산업을 나눠 본 글을 함께 참고할 수 있습니다.

이번 글은 업종별 시가총액 비중과 지수 하락 기여도를 직접 산출하지 않았습니다. 따라서 ‘반도체 두 종목이 지수 하락의 대부분을 만들었다’거나, 외국인 매도만으로 모든 하락을 설명하는 수치는 제시하지 않습니다.

4. 증시 전망: 반등·횡보·추가 하락을 가를 조건

아래는 앞으로 수 거래일~다음 주요 실적·물가 발표를 읽기 위한 조건부 관찰 틀입니다. 가격 목표나 시나리오별 확률이 아니며, 현재 모든 조건을 측정해 어느 하나로 판정한 것도 아닙니다.

조건부 전망 도식: 세 갈래는 시간 순서·목표가·발생 확률이 아닙니다. 관찰 조건과 판단을 약하게 만드는 반대 증거를 나눴습니다.

Deoks 자체 제작 개념도. 관측된 시장 예측값이나 투자 추천이 아닙니다.

위 도식의 세 갈래는 시간 순서나 발생 확률이 아닙니다. 금리 부담·기업 실적과 현금·종목 분포의 조합에 따라 확인할 조건을 나눈 자체 개념도입니다. ‘반대’는 각 시나리오 판단을 약하게 만드는 증거를 뜻합니다. 세부 확인 방법은 바로 아래 본문에 이어집니다.

① 반등이 이어지는 경우

확인 조건: 금리 부담이 진정되고, 기업 실적·현금 전망이 유지되며, 일부 대형주를 넘어 상승 종목이 늘어나는지 확인합니다.

반대 증거: 지수만 오르고 다수 종목은 하락하거나, 회사의 실적 전망이 계속 낮아지면 이 판단은 약해집니다.

② 높은 변동성 속에 횡보하는 경우

확인 조건: 좋은 실적과 물가·금리 부담이 엇갈리고, 업종별 방향이 갈리는 경우입니다.

반대 증거: 개선 또는 악화가 여러 업종과 실적에 같은 방향으로 이어지면 횡보 판단은 약해집니다. 횡보가 곧 안전하다는 뜻은 아닙니다.

③ 추가 하락하는 경우

확인 조건: 자금 조달 부담과 이익 전망 악화가 함께 나타나고, 하락이 더 많은 종목·업종으로 번지는지 확인합니다.

반대 증거: 공식 실적·현금 전망이 개선되고 상승 종목의 증가가 이어지면 추가 하락 판단은 약해집니다.

여기서 종목의 분포란 같은 시장의 같은 거래일 종가 기준 상승·하락 종목 수를 말합니다. 장중 숫자와 종가를 섞거나, 코스피와 코스닥을 임의로 합쳐 비교하지 않습니다. 하루의 강한 반등만으로 추세 전환을 확정하지 않는 이유도 여기에 있습니다.

금리가 내려가도 경기·기업 실적이 더 나빠지면 주식에 좋은 신호가 아닐 수 있습니다. 반대로 금리가 높아도 기업 이익이 예상보다 강하면 하락 논리가 약해질 수 있습니다. 지표 하나의 방향보다 서로 다른 지표가 같은 이야기를 하는지가 중요합니다.

5. 다음 장에서 무엇을 확인하면 좋을까?

장과 시각: 먼저 미국 10월 15일의 확정 종가와 한국 10월 16일의 실제 장을 구분합니다. 지금 읽는 글은 한국 10월 15일 마감 분석입니다.
물가와 금리: 전체 CPI뿐 아니라 근원·에너지 구성을 보고, 새로운 연준 발표가 실제로 있었는지 확인합니다. CPI와 연준의 물가 목표 판단에 쓰이는 PCE 물가지수도 같은 지표로 취급하지 않습니다. 연준의 물가 지표 설명
기업의 돈: 공시·IR에서 실적과 다음 분기 설명, 투자비와 현금흐름을 함께 확인합니다. 좋은 매출 뉴스만으로 높은 투자비가 회수됐다고 판단하지 않습니다.
반등의 범위: 지수 상승과 함께 같은 시장의 상승 종목 수가 늘어나는지 봅니다. 거래 중단 해제 자체는 바닥 확인 신호가 아닙니다.

기업별 공시는 금융감독원 DART, 국내 지수·종목 분포는 KRX 정보데이터시스템, 미국 정책 결정은 연준 FOMC 발표 목록에서 확인할 수 있습니다. 이 링크들은 다음 확인 경로이며, 이 글이 해당 지표의 최신 값까지 모두 수집했다는 뜻은 아닙니다.

정리하면: 급락은 이미 일어난 가격 변화이고, 전망은 아직 확인해야 할 조건입니다. ‘얼마나 떨어졌나’ 다음에는 ‘금리 부담이 풀리는가, 기업이 돈을 버는가, 회복이 여러 종목으로 넓어지는가’를 차례로 확인해 보세요.

Appendix · 계산과 자료의 한계

등락률은 (당일 종가 ÷ 전일 종가 − 1) × 100으로 검산했습니다. 코스피 전일 종가는 6,008.81, 코스닥은 823.88이며, 소수 둘째 자리 반올림 값이 각각 −7.57%, −7.65%입니다. 할인 예시는 100 ÷ (1 + 할인율)^5로 계산했습니다. 거래나 투자 성과를 시험한 결과가 아닙니다.

국내 종가는 IR 시세 화면과 언론 마감 보도로 교차 확인했습니다. 01:15 KST 확인 시점에 KRX 원자료를 직접 추출하지 못했으므로 거래소 원장을 직접 대조했다고 주장하지 않습니다. 외국인 순매매의 확정 집계, 업종별 하락 기여도, 현재 신용 스프레드는 이 글에서 검증하지 않았습니다. 세 가지 전망은 이 미확인 값이 이미 악화됐다는 주장이 아닙니다.

YTN: 10월 15일 국내 증시 마감·거래 중단 — 2026-10-15 17:30 KST 보도.
OCI홀딩스 IR 현재가의 시장 지수 — 화면 표시 기준 2026-10-15 15:30 KST. 기업 IR에 표시된 시세이며 KRX 직접 원자료는 아닙니다.
BLS: September 2026 CPI — 2026-10-14 08:30 EDT 발표.
Federal Reserve: 9월 16일 FOMC 성명 — 실제 정책 결정과 미래 전망을 구분하기 위한 원자료.
TSMC: 2026년 3분기 실적 — 2026-10-15 발표, 9월 30일 종료 분기. 대만달러와 미국 달러 기준을 구분했습니다.
연합뉴스: 급락 배경 분석 — 2026-10-15 17:24 KST 보도. 시장 설명의 출처로 한정하며 보도 문장·사진을 복제하지 않았습니다.

뱅크오브아메리카(BAC), 이자이익 늘었는데 순익은 왜 줄었나

2026-10-15T07:39:58.966+09:00

뱅크오브아메리카(BAC)의 2026년 3분기는 이자이익이 늘어도 순이익은 줄 수 있다는 사례입니다. 규제 합의 비용 12억 달러와 다른 비용 증가가 함께 반영됐습니다. 합의 비용을 뺀 조정 순이익도 전년보다 약 2.4% 낮아, 이를 모두 일회성 비용 탓으로 돌리면 설명이 부족합니다.

보고 EPS는 0.91달러, 회사가 제시한 조정 EPS는 1.08달러입니다. 두 숫자 중 좋은 것만 고르기보다, 비용을 얼마나 뺐는지와 무엇이 남았는지를 함께 보겠습니다. 실적 공시 · 회사의 조정 내역

기준: 2026-10-15 KST · 대상: NYSE 상장 Bank of America Corporation(BAC)의 2026년 3분기, 9월 30일 종료 분기. 미국장 기준 거래일은 뉴욕 현지 10월 14일입니다. 실적 발표는 10월 14일 06:45 미국 동부시간(EDT), 한국시간 같은 날 19:45였습니다. 주가·등락률은 이 글에서 인용하지 않습니다.

핵심 요약

영업의 한 축은 성장: GAAP 순이자이익은 164.49억 달러로 전년보다 약 8% 늘었습니다.
보고 이익은 감소: GAAP 순이익은 69.33억 달러로 전년의 83.32억 달러보다 약 16.8% 낮았습니다.
조정 후에도 남는 부담: 12억 달러 비용을 제외한 순이익은 81.33억 달러로 계산됩니다. 전년 보고 순이익에는 여전히 못 미칩니다.

금액은 회사 공시의 백만 달러 단위를 억 달러로 바꿨고, 증감률은 원자료로 계산했습니다. 조정 값은 비GAAP이며 보고 실적의 대체물이 아닙니다. 분기 실적표·비GAAP 조정표

1. 이자이익보다 비용이 더 빨리 늘었다

항목	3분기 결과 · 전년 대비
매출	299.58억 달러 · +3.2%
순이자이익	164.49억 달러 · +8.0%
비이자비용	197.22억 달러 · +13.8%
순이익	69.33억 달러 · −16.8%

모두 GAAP, 단위는 미 달러이며 같은 분기의 전년 대비입니다. 매출은 이자비용 차감 후 매출입니다. Selected Financial Data

은행은 이자를 더 벌었다고 그 금액이 전부 이익으로 남지는 않습니다. 회사는 대출·예금 잔액 증가와 고정금리 자산의 금리 재조정 등이 순이자이익을 도왔다고 설명합니다. 하지만 비용도 늘었습니다. 회사의 수익·비용 설명

직접 계산: 비이자비용 증가분은 23.85억 달러입니다. 여기서 규제 합의 비용 12억 달러를 제외해도 약 11.85억 달러가 남습니다. 조정 비이자비용은 전년보다 약 6.8% 높습니다. 따라서 “벌금만 없었으면 비용 문제가 전부 사라졌다”는 해석은 맞지 않습니다.

2. 12억 달러는 무엇이며, 왜 더해서 세면 안 될까?

OCC는 10월 13일 Bank of America, N.A.의 은행비밀법·자금세탁방지 준수 문제에 대해 7.5억 달러의 민사 제재금을 발표했습니다. 같은 발표에서 FinCEN의 12억 달러 제재금은 OCC 제재금을 공제한다고 설명합니다. 두 발표 금액을 단순히 더해 19.5억 달러라고 쓰면 중복 계산입니다. OCC 공식 발표

회사는 이 규제 합의와 관련해 3분기에 세금 공제되지 않는 비용 12억 달러를 계상했고, EPS 영향은 0.17달러라고 밝혔습니다. 이는 해당 분기에 반영한 회계 비용이지, 이 자료만으로 현금 지급일을 확정할 수 있다는 뜻은 아닙니다. 실적자료 Endnote B

해석: 특정 합의 비용을 조정해 영업을 살펴볼 수는 있습니다. 그러나 규제기관이 개선을 요구했다는 사실까지 없어지는 것은 아닙니다. 앞으로 필요한 통제·준법 개선과 그 비용은 별도로 확인해야 합니다. 이번 분기의 12억 달러가 반복되지 않는다고 모든 관련 부담도 끝났다고 단정하지 않겠습니다.

3. 조정 EPS는 늘어도 총이익은 줄 수 있다

읽는 순서	같은 분기에서 보는 숫자
보고 실적	순이익 69.33억 달러 · EPS 0.91달러
회사 조정	규제 합의 비용 12억 달러를 제외 · 조정 EPS 1.08달러
남는 차이	조정 순이익 81.33억 달러 · 전년 보고 순이익보다 약 2.4% 낮음

조정 순이익의 계산은 69.33 + 12 = 81.33억 달러입니다. 회사의 요약 자료에서는 반올림해 81억 달러로 표시합니다. 조정 EPS는 회사가 제시한 1.08달러이며, 조정 항목과 비교 기준을 숨기지 않고 함께 읽어야 합니다. 회사의 보고·조정 실적 연결표

EPS는 보통주에 귀속되는 이익을 희석 가중평균 주식수로 나눈 값입니다. 전체 순이익과 동일한 지표는 아닙니다. 이번 분기의 희석 가중평균 주식수는 전년보다 약 5.3% 줄었습니다. 분모가 달라지면 전체 이익 감소와 조정 주당이익 증가가 동시에 나타날 수 있습니다. 보통주 귀속 이익·희석 주식수

관련해서 JP모건 실적에서 ‘순익 증가’와 ‘예상 하회’를 나눠 읽는 법도 참고할 수 있습니다. 그 글은 시장 예상과 실제 EPS의 차이, 이번 글은 보고·조정 이익과 남는 비용의 차이를 다룹니다.

앞으로 확인할 것은 비용과 규제 개선이다

영업의 지속성: 이자이익 증가가 다음 분기에도 이어지는지, 예금 조달비용이나 금리 변화가 이를 얼마나 상쇄하는지 봅니다.
잔여 비용: 규제 합의 비용을 제외한 비용 증가가 매출 성장 안으로 들어오는지 확인합니다.
반대 요인: 준법 개선 부담, 비이자 수익·신용비용 변화가 영업의 성장 효과를 약화시킬 수 있습니다. 규모와 시점은 후속 공시가 필요합니다.

좋은 EPS 하나만으로 사업 전체가 좋아졌다고 결론내리기보다는, 보고 이익 → 조정 내역 → 여전히 남는 비용 순서로 읽는 게 유용합니다. 이 글은 기업 실적을 이해하기 위한 정보이며 매수·매도 추천이나 주가 방향의 예측이 아닙니다.

Appendix. 숫자를 읽을 때의 기준

NII(순이자이익): 이자수익에서 이자비용을 뺀 값입니다. 비이자비용까지 뺀 최종 순이익은 아닙니다.
GAAP와 비GAAP: 보고 회계 실적과 회사가 특정 항목을 제외한 조정 수치를 구분합니다. 조정 실적은 제외한 항목을 함께 확인해야 합니다.
단위: 원표의 $MM는 백만 달러입니다. 1 billion 달러는 10억 달러이며, EPS 단위는 달러/주입니다.
계산 기준: 증감률은 (당기 ÷ 전년 동기 − 1) × 100입니다. 반올림한 요약 수치로 계산한 결과와 차이가 날 수 있습니다.

1차 출처와 확인일

자료 확인: 2026-10-15 KST. 규제 발표는 10월 13일, 분기 실적 발표는 10월 14일 미국 현지 기준입니다. 이 글은 공개 원자료의 해설이며 컨퍼런스콜을 직접 청취했다거나 금융 거래를 실행했다는 주장이 아닙니다.

메타 Muse Wonder·Full, 모델 차이와 주가·메모리 산업 영향

2026-10-14T13:41:11.187+09:00

Meta의 Muse Wonder·Full은 긴 작업을 수행하는 AI 에이전트용 모델입니다. 장기 코딩에는 강점이 있지만, Meta 주가와 메모리 산업의 영향은 실제 사용량·매출·작업당 비용에 달려 있습니다.

기준일: 2026-10-14 KST · 발표일: 2026-10-12 · 공식 명칭은 ‘Wonder Full’이며 ‘Wonderful’이라는 별도 모델이 아닙니다. 이 글의 비교는 공개 자료 분석이며 직접 실행한 모델 테스트가 아닙니다.

목차 — 먼저 정의, 그다음 차이와 영향

Wonder와 Full: 무엇이 공개됐나
Active Memory·Active Focus: 무엇에 쓰나
다른 모델과의 차이: 잘하는 일과 평가 조건
Meta 주가: 매출 기회와 비용 부담
AI·메모리·데이터센터 산업의 변화
요약과 앞으로 확인할 지표

핵심 용어의 한 줄 정의

AI 에이전트: 목표를 받고 도구를 사용해 여러 단계의 일을 수행하는 시스템입니다.
Active Memory: Meta가 부르는, 대화를 넘어 중요한 사용자 정보를 기억하고 필요한 때 찾아 쓰는 능력입니다.
Active Focus: Meta가 부르는, 장애물이나 새 조건을 만나도 목표를 향해 작업을 이어가는 능력입니다.
컨텍스트 윈도: 모델이 한 번의 추론에서 다룰 수 있는 입력·대화 문맥의 범위입니다.
HBM: AI 가속기 등에서 쓰는 고대역폭 메모리입니다. KV 캐시는 토큰 생성 때 이전 문맥 계산을 재사용하는 데이터이며, 둘은 기능과 장치를 가리키는 서로 다른 말입니다.
CapEx: 서버·설비 등에 쓰는 자본적 지출입니다. 지출 시점의 현금 부담과 이후 감가상각 비용을 함께 봅니다.

1. Wonder와 Full, 무엇이 공개됐나

Wonder는 API와 Muse Code로 제공되는 모델이고, Full은 Muse Code에서 제공되는 더 높은 성능 지향의 모델입니다. Meta의 발표는 Full을 일반 API로도 사용할 수 있다고 설명하지 않습니다. 모델 이름, 이를 쓰는 코딩 제품, 개인 에이전트 서비스를 구분하면 혼동이 줄어듭니다. [1]

2026-10-14 확인한 제공 경로
구분	확인된 위치·역할
Muse Wonder	Meta Model API·Muse Code. 외부 서비스에 연결하는 API 경로가 있습니다.
Muse Wonder Full	Muse Code의 해당 구독 플랜. 이용 가능한 플랜·지역·한도는 실제 서비스에서 확인해야 합니다.
Muse Spark 1.3	기존 모델 계열. Meta는 Wonder 계열의 더 강한 기반 모델과 비교합니다.
Muse / Muse Code	각각 개인 에이전트 서비스 / 코딩 제품입니다. 모델 자체와 같은 말이 아닙니다.

Full이 항상 더 경제적이라는 뜻은 아닙니다. 어려운 일을 더 적은 재시도로 끝낸다면 유리할 수 있지만, 쉬운 일에서는 추가 비용·시간이 불필요할 수 있습니다. 구독료와 API의 토큰 단가는 서로 다른 과금 단위라 그대로 나란히 놓고 싼 모델을 결정하면 안 됩니다. 공개 개발자 안내도 Wonder의 API 경로와 Full의 구독 경로를 구분합니다. [2]

2. Active Memory와 Active Focus는 무엇에 쓰나

Active Memory는 맥락을 이어 쓰는 능력, Active Focus는 일을 이어 끝내는 능력입니다. 예를 들어 지난 대화의 프로젝트 조건을 다시 찾아 쓰는 일과, 오류를 고친 뒤 테스트 결과까지 확인하는 일은 다른 문제입니다. Meta는 이 두 능력을 개인·업무 에이전트의 핵심으로 내세웠습니다. [1]

① 목표 받기
새 요구와 성공 조건을 파악

② 필요한 기억 찾기
이전 조건 중 관련 정보 사용

③ 도구로 작업하기
코드·문서·앱에서 단계 수행

④ 결과 확인하기
실패를 고치고 중요한 행동은 승인 확인

직접 구성한 개념도입니다. 기능을 이해하기 위한 흐름이며 Meta 내부 구현도나 실제 실행 화면이 아닙니다.

이 이름들이 다른 회사에는 없는 독점적인 기능 종류라는 뜻은 아닙니다. 모델 비교에서 중요한 것은 기억·도구 사용이라는 간판보다, 조건을 얼마나 정확하게 유지하고 실제 일을 얼마나 끝내는지입니다. 모델이 좋은 답을 내더라도 검색·파일·권한·검증 도구를 연결한 전체 시스템이 실패하면 작업은 끝나지 않습니다.

특히 Active Memory를 ‘HBM을 더 넣어 구현한 기억’으로 읽으면 안 됩니다. 사용자 정보를 저장·검색하는 서비스 기능과, 현재 추론의 중간 데이터를 빠르게 읽는 KV 캐시·GPU 메모리는 다른 층입니다. 이번 발표만으로 Meta의 기억 저장 방식이나 모델별 HBM 용량을 계산할 수는 없습니다.

3. 다른 모델보다 잘하는 일은 무엇인가

공개표에서는 긴 코드 수정 과제에 강점이 있지만, 터미널 작업과 일반 지능 지수의 순서는 다릅니다. 아래는 Meta가 공개한 평가표의 일부입니다. DeepSWE는 긴 소프트웨어 수정 과제의 1회 시도 성공률(pass@1), Terminal-Bench는 터미널 환경의 과제 정확도이며 두 열 모두 높은 값이 좋습니다. [2]

코드 수정: DeepSWE 1.1 · 터미널 작업: Terminal-Bench 4.0-AA · Meta 공개표의 max 추론 설정 · 단위: %
모델	코드 수정	터미널 작업
Muse Wonder Full	79.0	57.1
Muse Wonder	78.8	52.0
Claude Fable 5.1	67.4	52.0
GPT-6 Astra	74.1	59.1
Claude Opus 5.5	74.2	59.6

같은 표의 Artificial Analysis 지수는 Full 56, Wonder 52, Claude Opus 5.5 58입니다. 따라서 ‘모든 모델을 이겼다’는 결론은 맞지 않습니다. DeepSWE에서 Full과 Wonder의 차이도 0.2%포인트라, 그 항목 하나만 보고 Full을 고를 근거는 약합니다.

평가 조건을 함께 보세요. 모델 카드는 외부 평가와 제공사 보고 결과가 섞여 있고, 일부 비교는 도구·실행 환경을 완전히 같게 통제한 실험이 아니라고 설명합니다. 이 표는 동일 하드웨어의 응답 속도·API 비용·한국어 정확도를 비교하지 않습니다. 실제 선택은 자신의 과제로 확인해야 합니다. [3]

4. Meta 주가에는 어떤 경로로 영향을 줄까

긍정적인 경로는 사용과 수익의 확대, 부담 요인은 이를 서비스하는 비용과 투자 회수입니다. Meta Platforms(Nasdaq: META)가 모델 경쟁력을 높였다는 소식은 성장 기대를 바꿀 수 있습니다. 하지만 새 모델의 점수가 오늘의 매출이나 주가 상승률로 곧바로 변환되지는 않습니다. 다음은 발표로 확정된 결과가 아니라 앞으로 확인할 시나리오입니다.

상방 시나리오: 코딩·업무 고객이 반복 사용하고 유료 전환한다면 API·구독 사업 기회가 커질 수 있습니다. 기존 광고·기업 도구에도 실제 생산성 향상이 연결되는지 봐야 합니다.
중립 시나리오: 좋은 벤치마크가 나와도 이용자의 작업에 맞지 않거나 가격·전환 비용이 높으면, 도입은 느리고 실적 기여는 제한적일 수 있습니다.
부담 시나리오: 긴 추론과 재시도가 늘어 수익보다 추론비·설비 감가·운영비가 빠르게 증가하면 현금흐름에 부담을 줄 수 있습니다. 개인정보 사고나 실행 오류도 도입을 늦출 수 있습니다.

비용의 기준점도 중요합니다. Meta의 7월 29일 발표에서 2026년 CapEx 전망은 1,300억~1,450억 달러, 2분기 CapEx는 310억8천만 달러였습니다. 이는 금융리스 원금 지급을 포함한 회사 전체 전망·실적이며, 10월 Muse 발표로 새로 추가된 예산이 아닙니다. 발표 뒤 이 전망과 수익성 지표가 어떻게 바뀌는지를 확인해야 합니다. [4]

확인한 공개 자료만으로 Muse Wonder의 매출·수익성을 분리해 산출할 수는 없습니다. Meta의 기업용 배포 경로는 앞서 쓴 메타 기업용 AI 플랫폼과 고객 도입의 관전 포인트와 이어 읽으면 이해하기 쉽습니다. 이 글은 매수·매도 추천이 아니라 산업과 기업을 읽기 위한 정보입니다.

5. AI·메모리·데이터센터 산업에는 무엇이 달라지나

긴 작업을 수행하는 서비스가 실제로 늘면 추론·문맥 저장·전력 인프라에 새로운 부담이 생길 수 있습니다. 다만 수요의 크기는 ‘모델이 똑똑해졌다’보다 사용자 수, 작업 길이, 동시 실행 수, 성공률에 달려 있습니다. 더 적은 재시도로 일을 끝내는 개선은 작업당 자원 사용을 줄일 수도 있습니다.

산업별 가능한 경로와 확인 항목 — 전망이며 수주·매출 확정이 아닙니다
영역	가능한 변화 / 확인할 것
AI 서비스·가속기	반복 실행·도구 호출 증가가 추론 수요를 키울 수 있습니다. 이용량·재시도·성공 작업당 비용을 확인합니다.
HBM·DRAM·SSD	긴 문맥과 동시 사용자가 메모리·저장 계층에 부담을 줄 수 있습니다. 실제 구성·캐시 적중·이동 비용을 확인합니다.
데이터센터	전력·냉각·네트워크가 함께 필요합니다. 계약 용량과 실제 통전·가동률·투자 집행을 구분합니다.

메모리 수요를 HBM 하나로만 보면 놓치는 것이 있습니다. NVIDIA의 Dynamo 설명은 사용 중인 KV 캐시와 대기 중인 캐시를 구분해 GPU 밖의 CPU RAM·SSD·네트워크 저장소로 옮기는 방법을 소개합니다. 이런 계층화는 메모리의 구성과 재계산 비용을 바꿉니다. 이것은 일반적인 추론 설계의 사례이며 Muse가 Dynamo를 쓴다는 증거는 아닙니다. [5]

Meta는 Wonder 계열을 기가와트급 Prometheus에서 학습했다고 밝혔습니다. 이전 인프라 설명도 패키징·열 관리·전력 공급·메모리 분리·광 네트워크를 함께 과제로 들었습니다. 전력 용량은 GPU 개수나 메모리 업체의 매출 금액과 같지 않습니다. [1] [6]

공식적으로 확인된 공급망 사례는 AMD와 Meta의 최대 6GW, 다년·다세대 GPU 협력입니다. 2월 발표는 첫 1GW 배치를 지원할 출하를 2026년 하반기로 계획했습니다. 이는 이미 공개된 인프라 계약이지, Muse 발표 당일의 새 발주나 Wonder 학습용 GPU를 특정하는 자료가 아닙니다. [7]

국내 메모리 업계의 영향도 실제 고객 계약·제품 구성·가격·출하에서 확인해야 합니다. 발표만으로 특정 업체의 수혜를 확정하지 않습니다. 계층화의 기본 원리는 KV 캐시 재사용과 HBM 수요를 구분하는 글에서 더 살펴볼 수 있습니다.

6. 요약, 좋은 모델이 좋은 사업이 되려면

모델: Wonder는 API·코딩 제품, Full은 해당 코딩 구독 경로로 구분합니다. 장기 코딩의 강점과 과제별 약점을 함께 봅니다.
서비스: 장기 기억·집중이라는 설명보다 실제 작업 성공률, 중요한 행동의 승인, 반복 사용을 확인합니다.
Meta 주가: 유료 도입·매출·작업당 비용·CapEx 회수라는 연결이 확인되는지가 중요합니다.
메모리·데이터센터: 실제 처리량·캐시 구성·전력 가동을 봅니다. 발표와 공급사 실적 사이에는 여러 확인 단계가 있습니다.

가상 계산 예시: 100개 작업에 총 100달러가 들고 80개가 정해진 품질로 끝났다면 성공 작업당 비용은 100 ÷ 80 = 1.25달러입니다. 토큰 단가만 낮은 모델보다 실패·재시도를 줄이는 모델이 더 경제적일 수 있습니다. 이 숫자는 설명용이며 Muse의 실제 비용·성공률이 아닙니다.

속도도 첫 응답까지의 TTFT, 토큰 사이의 ITL, 전체 완료 시간인 E2EL을 구분해야 합니다. 여기에 품질·지연 조건을 만족한 유효 처리량인 goodput과 성공 작업당 비용을 함께 보면 에이전트를 더 현실적으로 비교할 수 있습니다. 용어는 LLM 추론 성능 지표 학습 글에서 이어 읽을 수 있습니다.

Appendix. 공개 사양과 해석의 한계

모델 카드의 입력은 텍스트·이미지·영상·오디오, 출력은 텍스트이며 추론 컨텍스트 길이는 100만 토큰입니다. 실제 서비스의 플랜·요청 제한과 모든 언어의 성능을 보장하는 숫자는 아닙니다. 긴 문맥 지원만으로 모델의 파라미터 수나 실제 HBM 사용량도 알 수 없습니다. [3]

비교표는 공개된 시점의 평가 결과입니다. 모델·도구·추론 설정이 달라지면 결과도 달라질 수 있습니다. 이 글에는 직접 써봤다는 경험담, 실측 속도, 당일 주가의 원인 추정, 공개되지 않은 공급사·매출 추정치를 넣지 않았습니다.

출처

Meta AI Research, Muse Wonder 공식 발표 — 2026-10-12.
Meta 개발자 페이지, 모델·제공 경로·평가표 — 2026-10-14 확인.
Muse Wonder Model Card — 사양·평가 방법·한계.
Meta 2026년 2분기 실적·CapEx 전망 — 2026-07-29.
NVIDIA, KV 캐시 계층화·오프로딩 설명 — 2025-09-18. Muse 구현을 확인하는 자료는 아닙니다.
Engineering at Meta, AI 인프라 과제 — 2025-09-29.
AMD·Meta GPU 협력 발표 — 2026-02-24.

보도 확인: Axios의 출시 기사. 기술·수치 주장은 위 공식 자료에서 별도로 확인했습니다. 기사·공식 자료의 그림은 복제하지 않았습니다.

JP모건(JPM) 실적, 순익 증가에도 EPS가 예상 밑돈 이유

2026-10-14T13:23:11.051+09:00

JP모건은 2026년 3분기 순이익이 전년보다 6% 늘었지만, 주당순이익(EPS)은 시장 예상에 못 미쳤습니다. 회사가 공개한 6억5,800만 달러의 순투자증권 손실이 보고 EPS를 0.18달러 낮췄고, 채권 매매 부문의 매출도 전년보다 줄었습니다.

그렇다고 은행의 핵심 영업 전체가 약해졌다고 단정하기는 어렵습니다. 순이자이익과 전체 매출은 증가했고, 주식시장 관련 거래와 투자은행 수수료도 성장했습니다.

이번 실적은 ‘순익 증가’와 ‘예상 하회’가 동시에 나온 이유를 나눠 보는 게 중요합니다. 한 번의 EPS 숫자보다 금리·예금·트레이딩·비용이 각각 어디서 움직였는지 살펴보겠습니다.

핵심 요약

3분기 순이익은 153억 달러로 전년 대비 6% 증가했고, 순매출은 509억 달러로 8% 늘었습니다.
희석 EPS는 5.57달러였습니다. AP가 보도한 시장 예상치 5.93달러에는 못 미쳤지만, 전년 동기의 5.07달러보다는 높았습니다.
회사는 6억5,800만 달러의 순투자증권 손실이 EPS를 0.18달러 낮췄다고 밝혔습니다. 이 항목을 제외한 회사의 비GAAP 조정 EPS는 5.75달러로, AP가 인용한 예상치와는 여전히 차이가 있습니다.
순이자이익과 주식시장 부문은 강했지만, 고정수익(채권) 시장 매출은 전년 대비 4% 감소했습니다. 따라서 실적을 한 가지 원인만으로 설명하면 중요한 차이를 놓칠 수 있습니다.

1. 실적은 늘었는데 왜 ‘예상 하회’가 나왔을까?

JP모건체이스의 2026년 3분기 순이익은 153억 달러, 희석 EPS는 5.57달러였습니다. 전년 동기와 비교하면 순이익은 6%, EPS는 10% 증가했습니다. 하지만 AP가 10월 13일 보도에서 인용한 월가 EPS 예상치 5.93달러와 비교하면 실제 EPS는 0.36달러 낮았습니다. 예상치는 집계 기관과 시점에 따라 달라질 수 있으므로, 여기서는 AP 보도에 인용된 수치로 한정합니다.

회사는 기업 부문에 반영된 6억5,800만 달러의 순투자증권 손실이 분기 EPS를 0.18달러 낮췄다고 설명했습니다. 회사가 제시한 이 손실 제외 EPS는 5.75달러입니다. 조정 수치도 보고 EPS와 구분해서 봐야 하고, 이 항목 하나만으로 시장 예상과의 차이가 전부 설명되는 것은 아닙니다.

2. 어떤 사업이 받쳐주고, 어떤 사업이 약했나?

전체 순매출은 509억 달러로 전년 대비 8% 늘었습니다. 순이자이익은 271억 달러로 13% 증가했습니다. 회사는 시장 관련 수익을 제외한 순이자이익도 247억 달러로 6% 늘었다고 밝혔고, 예금·카드·도매대출 잔액 증가가 기여했다고 설명했습니다. 다만 금리 하락 효과는 일부 부담으로 작용했습니다.

지표	3분기 결과
순이익	153억 달러, 전년 대비 +6%
순매출	509억 달러, 전년 대비 +8%
순이자이익	271억 달러, 전년 대비 +13%
희석 EPS	5.57달러, 전년 동기 5.07달러
고정수익(채권) 시장 매출	54억 달러, 전년 대비 -4%
주식시장 매출	50억 달러, 전년 대비 +49%

투자은행 수수료는 30억 달러로 전년 대비 14% 증가했지만 전분기보다는 8% 감소했습니다. 시장 부문 안에서도 고정수익 매출은 4% 줄고 주식시장 매출은 49% 늘어 방향이 달랐습니다. AP는 채권 트레이딩 활동 둔화를 짚었고, 회사 자료는 원자재·금리·신용·공공금융 부문의 낮은 매출이 통화·신흥시장 부문의 증가로 일부 상쇄됐다고 설명합니다.

3. 다음 분기에는 무엇을 확인하면 좋을까?

순이자이익의 구성: 예금과 카드 잔액이 늘어나는 효과가 금리 하락에 따른 마진 압박을 얼마나 상쇄하는지 확인합니다.
채권·주식 거래의 균형: 이번에는 주식시장 매출 증가가 고정수익 부문의 감소를 보완했습니다. 시장 변동성이 바뀌면 이 조합도 달라질 수 있습니다.
비용과 신용손실: 회사 전체 비이자비용은 273억 달러로 전년 대비 12% 늘었습니다. 카드 연체·대손 비용과 함께 보면 이익의 지속성을 더 잘 판단할 수 있습니다.
조정 수치와 보고 수치: 증권 손익을 제외한 비GAAP 수치는 참고 자료이지, GAAP 기준 보고 실적을 대체하지 않습니다.

미국 기업 실적이 좋아도 주가가 자동으로 오르는 것은 아닙니다. 실적 발표와 주가 반응을 함께 읽는 방법은 애플·아마존 실적 발표 뒤 기술주가 하락했던 사례와 비교해 볼 수 있습니다. 업종마다 매출 구조와 민감한 지표가 다르다는 점은 함께 기억해야 합니다.

이 글은 매수·매도 추천이 아니라 기업 실적과 은행 산업을 이해하기 위한 정보입니다.

Appendix. 순이자이익과 EPS

순이자이익(NII)은 대출·증권 등에서 얻는 이자수익에서 예금·차입 등에 지급한 이자비용을 뺀 값입니다. EPS는 순이익 중 보통주에 귀속되는 몫을 주식 수로 나눈 주당 수치입니다. 회사의 조정 EPS는 특정 항목을 제외한 비GAAP 지표이므로, 보고 EPS와 나란히 보고 조정 근거도 확인해야 합니다.

출처

JPMorgan Chase, 2026년 3분기 실적 발표 자료(SEC 제출, 2026-10-13)
JPMorgan Chase, 3Q26 Earnings Release (공식 IR PDF)
Associated Press, Big banks post strong Q3 profits, but warn higher rates and inflation could bite (2026-10-13) — 시장 예상치와 채권 트레이딩 관련 보도
NYSE Holidays & Trading Hours — 거래일 확인

LLM 추론 성능 지표 이해하기, TTFT·TPOT·ITL부터 처리량까지

2026-10-12T17:51:57.000+09:00

DEOKS · TECH LEARNINGLLM PERFORMANCELLM이 빠르다는 말은 첫 반응, 답을 이어 쓰는 속도, 전체 처리량 중 무엇을 재는지에 따라 달라집니다. 이 글에서는 TTFT·TPOT·ITL과 처리량을 정의부터 예시·계산 방법까지 차례로 살펴봅니다.

첫 글자는 빨리 나오는데 답변 중간에 멈추는 챗봇을 떠올려보세요. “첫 반응은 빠르다”와 “끝까지 매끄럽게 읽힌다”는 서로 다른 평가입니다. 여기에 여러 사람을 동시에 처리하는 서버의 능력까지 구분하면 성능표가 훨씬 명확해집니다.

다루는 범위는 LLM 추론 서비스의 응답 속도와 처리 능력입니다. 추론 문제의 정답률은 별도 평가해야 합니다. 모든 그림·GIF의 수치는 교육용 가정이며 특정 모델·GPU의 실측 결과가 아닙니다.

핵심 용어 정의 한눈에 보기

용어	먼저 기억할 정의
TTFT	요청부터 첫 내용 토큰을 받을 때까지의 시간.
TPOT	첫 토큰 이후, 출력 토큰당 걸리는 평균 시간.
ITL	이어지는 출력 사이의 간격. 제품에 따라 평균 간격을 뜻하기도 합니다.
Latency / E2E	요청부터 답변 완료까지 걸리는 전체 시간.
Throughput	일정 시간에 처리한 양. 전체 토큰/요청 처리량과 개별 속도를 구분합니다.
TPS / RPS	초당 토큰 수 / 이 글에서 초당 완료한 요청 수.

핵심은 기다림, 이어 쓰는 시간, 전체 처리량을 따로 보는 것입니다. 보조 용어는 아래의 해당 절에서 정의부터 설명합니다.

1. 기본 준비 — 토큰과 생성 단계

Token: 모델이 처리하는 텍스트 조각입니다. 한 글자나 한 단어와 항상 같지는 않습니다.
Tokenizer: 텍스트를 토큰으로 나누고 숫자 ID로 바꾸는 도구입니다.
ISL(Input Sequence Length): 모델에 들어간 입력 토큰 수입니다. 질문·시스템 지시·대화 기록·추가 문서 등이 포함될 수 있습니다.
OSL(Output Sequence Length): 모델이 생성한 출력 토큰 수입니다. 생각 과정 토큰의 포함 여부는 도구에서 확인합니다.

목적은 비교하는 작업의 크기를 맞추는 것입니다. 한국어 한 글자 = 한 토큰으로 계산하지 마세요. 같은 문장도 모델·토크나이저·언어에 따라 토큰 수가 달라질 수 있으므로 “50 tok/s”가 항상 같은 분량의 한국어 답변을 뜻하지는 않습니다.

Prefill: 입력을 처리하고 생성에 필요한 상태를 준비하는 단계입니다.
Decode: 앞선 문맥을 이용해 다음 토큰을 이어 생성하는 단계입니다.
KV Cache: 이전 토큰의 Key/Value 상태를 메모리에 보관해 다시 활용하는 장치입니다.

첫 반응과 완료 시점 구분. Deoks 자체 제작·가상 사례이며 단계 길이는 시간에 비례하지 않습니다.

입력이 길면 준비할 일이 많아질 수 있고, 답변을 이어 쓰는 동안에는 메모리·스케줄링 등 다른 조건도 중요해집니다. 다만 첫 토큰 전의 시간 전체가 Prefill은 아닙니다. 대기열과 전송도 섞일 수 있습니다.

2. TTFT(Time To First Token) — 첫 반응

정의: 요청 전송부터 첫 비어 있지 않은 내용 토큰을 받을 때까지의 시간입니다.
의미·목적: 사용자가 답변의 시작을 기다리는 경험을 평가합니다.
단위·읽는 법: 초(s) 또는 밀리초(ms). 같은 조건에서 작을수록 첫 반응이 빠릅니다.

예를 들어 요청을 0초에 보내고 첫 토큰을 0.80초에 받았다면 TTFT는 800ms입니다. 1초는 1,000ms입니다. 연결 헤더나 빈 스트리밍 메시지가 온 순간을 첫 답변으로 세면 안 됩니다.

언제 쓰나요?
전송 버튼을 눌렀는데 답이 늦게 시작된다면 TTFT와 큐 대기·ISL·캐시 상태를 확인합니다. 클라이언트 기준 TTFT에는 입력 처리·첫 출력 준비·전송 등이 포함될 수 있으므로 GPU 계산 시간과 동일시하지 않습니다.

3. TPOT(Time Per Output Token) — 평균 생성 간격

정의: 첫 토큰 이후 출력 토큰당 걸리는 평균 시간입니다.
의미·목적: 답변이 시작된 뒤 평균적으로 얼마나 빨리 이어지는지 비교합니다.
단위·읽는 법: ms/token. 같은 조건에서 작을수록 평균적으로 빠릅니다.

첫 토큰은 0.80초, 마지막 토큰은 1.40초에 왔고 전체 출력은 5토큰이었다고 해봅시다. 첫 토큰 뒤에는 4개 간격이 있으므로 1을 뺍니다.

TPOT = (E2E − TTFT) ÷ (출력 토큰 수 − 1)
= (1.40 − 0.80) ÷ (5 − 1)
= 150ms/token

쓰임새: 같은 모델·부하·출력 조건에서 생성 속도를 비교할 때 봅니다. 평균 TPOT가 같아도 중간에 한 번 오래 멈출 수 있으므로 ITL도 함께 봐야 합니다.

계산 조건
위 식은 첫 응답에 토큰 하나가 오고, 마지막 내용 토큰 수신을 완료로 잡은 예제입니다. 출력이 1개 이하이면 이 식은 정의되지 않습니다. 첫 청크에 여러 토큰이 있거나 완료 끝점이 다르면 측정 도구의 식을 확인합니다.

4. ITL · Chunk · ICL — 스트리밍의 끊김

정의: ITL(Inter-Token Latency)은 이어지는 출력 사이의 간격입니다. 이 글에서는 개별 간격으로 설명합니다.
의미·목적: 평균 속도에 숨은 멈춤과 간격의 흔들림을 확인합니다.
단위·읽는 법: ms. 평균뿐 아니라 긴 간격과 분포를 확인합니다.

간격이 100 · 300 · 100 · 100ms이면 평균은 150ms지만 두 번째 간격에서는 300ms를 기다립니다. 네 간격이 모두 150ms인 경우와 평균은 같아도 읽는 느낌은 달라질 수 있어요.

평균 TPOT가 같아도 개별 간격은 다릅니다. Deoks 자체 제작·가상 수치.

쓰임새: 첫 반응은 빠른데 답변 중간이 끊긴다면 ITL 분포와 스케줄링·전송 조건을 확인합니다. 이것만으로 원인이 확정되는 것은 아닙니다.

Chunk: 스트리밍에서 함께 전달하는 묶음입니다. 토큰 여러 개가 한 청크에 들어갈 수 있습니다.
ICL(Inter-Chunk Latency): 이어지는 청크 사이의 수신 간격입니다.

주의: ITL이라는 이름도 도구마다 다릅니다
NVIDIA NIM/AIPerf는 평균 ITL을 TPOT와 같은 뜻으로 설명하기도 합니다. vLLM의 출력 이벤트 간격과 요청별 TPOT는 집계 방식이 다를 수 있습니다. 토큰/청크, 개별 간격/요청 평균, 가중치를 먼저 확인해야 합니다. 수신 간격은 서버의 순수 한 토큰 계산 시간과도 다릅니다.

5. Latency(E2E) — 총 응답 시간

정의: E2E 또는 E2EL(End-to-End Latency)은 요청부터 답변 완료까지의 시간입니다.
의미·목적: 완성된 답변을 언제 사용할 수 있는지 평가합니다.
단위·읽는 법: 초(s) 또는 ms. 같은 작업·출력 길이에서 비교합니다.

앞의 가정에서는 마지막 토큰이 1.40초에 도착하므로 E2E는 1.40초입니다. 첫 반응이 빠르더라도 답변이 길거나 생성이 느리면 완료까지 오래 걸릴 수 있습니다.

E2E = TTFT + TPOT × (출력 토큰 수 − 1)
= 0.80 + 0.15 × 4 = 1.40초
앞의 토큰당 1회 전달·마지막 토큰 완료 조건에서의 계산입니다.

쓰임새: 요약·보고서·코드 생성처럼 전체 결과가 필요한 작업에 유용합니다. 스트리밍에서도 E2E를 잴 수 있습니다. 도구가 마지막 내용 토큰, 종료 신호, 클라이언트 대기 중 어디까지 포함하는지는 확인하세요.

6. Throughput · TPS · RPS — 처리 능력

정의: Throughput은 일정 시간 동안 처리한 양입니다. 여기서는 서버 전체 출력 토큰 처리량을 중심으로 봅니다.
의미·목적: 많은 요청을 처리하는 서비스의 용량과 효율을 평가합니다.
단위·읽는 법: 출력 토큰 처리량은 tok/s, 요청 처리량은 req/s. 같은 조건에서 비교합니다.

TPS(Tokens Per Second): 초당 토큰 수입니다. 요청 하나의 속도인지 서버 전체의 처리량인지 표시해야 합니다.
RPS(Requests Per Second): 이 글에서는 초당 완료한 요청 수입니다. 들어오는 요청의 속도와 구분합니다.

한 사람이 받는 속도와 서버 전체의 처리량은 같은 숫자가 아닙니다. 아래는 동시 요청 수가 늘면서 전체 처리량은 증가하지만, 요청 하나의 몫은 줄어들 수 있다는 가상 차트입니다.

전체 처리량 증가와 개별 요청 속도 저하가 함께 나타날 수 있습니다. Deoks 자체 제작·특정 제품 측정 결과 아님.

쓰임새: 서버 용량을 판단할 때는 전체 처리량을, 사용자 경험에는 요청별 TTFT·TPOT를 함께 봅니다. 입력+출력 토큰 처리량을 출력 전용 처리량과 섞지 않으며, 요청마다 답변 길이가 달라 RPS와 TPS도 서로 대체하지 않습니다.

TPOT와 Throughput의 차이
TPOT는 요청 하나의 평균 생성 간격, 전체 Throughput은 서버가 처리한 양입니다. 같은 부하에서 지연 목표를 지키면서 처리량이 얼마인지 확인해야 합니다. 큰 배치가 항상 더 빠른 사용자 경험이나 항상 더 나쁜 지연을 뜻하는 것은 아닙니다.

7. 부하 조건 — Concurrency · Request Rate · Batching

Concurrency: 동시에 진행 중인 요청 수입니다.
Request Rate: 초당 새로 들어오는 요청 수입니다. 완료한 RPS와는 다릅니다.
Batching: 여러 요청을 묶어 처리하는 방식입니다.
Continuous Batching: 완료된 요청을 빼고 새 요청을 넣으며 처리 묶음을 계속 갱신하는 방식입니다.

목적·쓰임새: 성능표가 어느 부하에서 나온 값인지 설명합니다. 동시에 10개가 진행 중인 상황과 초당 10개가 새로 들어오는 상황은 다릅니다. 도착률이 완료 능력을 계속 넘으면 대기열이 늘 수 있습니다.

배칭은 하드웨어 활용도를 높일 수 있지만 지연과 처리량의 균형은 묶음 크기·스케줄링·모델에 따라 달라집니다. 배칭 설정을 바꿀 때 요청별 TTFT·TPOT와 전체 처리량을 함께 비교하세요.

8. 느린 경험과 목표 — P50 · P95 · P99 · SLO · Goodput

P50: 중앙값입니다. 측정값의 약 절반이 이 값 이하입니다.
P95 / P99: 측정값의 약 95% / 99%가 이 값 이하인 경계입니다.
SLO(Service Level Objective): 서비스가 지키려는 목표입니다.
Goodput: 정한 SLO를 충족한 요청의 유효 처리량입니다.

목적·쓰임새: 평균에 가려진 느린 사용자 경험과 목표를 지킨 처리량을 확인합니다. P95 TTFT가 2초라면 측정한 요청의 약 95%가 2초 이내에 첫 토큰을 받았다는 의미입니다. 작은 표본의 P99는 불안정할 수 있습니다.

Goodput 가상 예제
10초 동안 100개 요청 완료 → 전체 10 req/s
정한 목표를 모두 지킨 요청은 60개 → Goodput 6 req/s
목표 만족률은 60%이며 Goodput과 단위가 다릅니다.

SLO는 예를 들어 “TTFT 1초 이하 그리고 TPOT 100ms 이하”처럼 정할 수 있지만 모든 서비스에 맞는 권장값은 아닙니다. 요청별 평균 TPOT와 개별 ITL은 다른 분포이므로 P95 TPOT가 낮다고 모든 출력 간격이 짧다고 단정하지 않습니다.

9. 그래서 어떻게 재고 계산하나요?

9.1 요청 시각과 내용 도착 시각을 같은 시계로 기록하기

클라이언트에서 요청 전송 시각, 첫 내용 도착 시각, 이후 내용 도착 시각, 완료 시각을 기록합니다. 시간 간격은 단조 증가 시계를 사용하는 방식이 적합합니다. 빈 메시지는 첫 답변으로 세지 않고, 청크마다 몇 토큰이 들어왔는지도 구분해야 합니다.

이벤트	요청 이후 도착 시각
요청 전송	0.00초
T1: 첫 토큰	0.80초
T2	0.90초
T3	1.20초
T4	1.30초
T5: 마지막 토큰	1.40초

토큰당 한 번 전송하는 개념 애니메이션. Deoks 자체 제작·실측 아님·가상 시간을 2배 느리게 재생.

이 가정은 한 번에 토큰 하나씩 전달합니다. GIF는 가상 시간을 2배 느리게 보여줍니다. 실제 스트리밍 청크를 토큰 하나라고 간주하면 ITL과 TPOT가 잘못 계산될 수 있습니다.

9.2 가상 시각으로 계산하는 Python 예제

아래 코드는 이미 주어진 가상 시각의 산술만 계산합니다. 실제 모델이나 API를 호출하는 벤치마크 코드가 아닙니다. 이 계산 코드는 실행해 결과를 확인했습니다.

PYTHON · 가상 시각 계산

request_sent = 0.0
token_arrivals = [0.80, 0.90, 1.20, 1.30, 1.40]

ttft = token_arrivals[0] - request_sent
itl = [b - a for a, b in zip(token_arrivals, token_arrivals[1:])]
e2e = token_arrivals[-1] - request_sent
tpot = (e2e - ttft) / (len(token_arrivals) - 1)

print(f"TTFT: {ttft * 1000:.0f} ms")
print("ITL:", [round(x * 1000) for x in itl], "ms")
print(f"TPOT: {tpot * 1000:.0f} ms/token")
print(f"E2E: {e2e:.2f} s")

실행 결과(가상 시각 계산)
TTFT: 800ms
ITL: 100 · 300 · 100 · 100ms
TPOT: 150ms/token
E2E: 1.40s

같은 요청의 속도도 분모에 따라 다릅니다. 첫 토큰 이후만 계산하면 4 ÷ 0.60 ≈ 6.67 tok/s, 첫 대기까지 포함하면 5 ÷ 1.40 ≈ 3.57 tok/s입니다. “사용자당 속도”라는 이름만 보지 말고 계산 범위를 확인하세요.

실제 벤치마크에서 맞출 조건
모델·버전·토크나이저·언어·ISL·OSL, 하드웨어·정밀도·엔진·캐시, 동시 요청·도착률, 클라이언트/서버 시계와 완료 끝점, 평균/백분위·표본 수·워밍업, 오류·답변 품질·비용을 함께 기록합니다. 실제 GPU/API 성능 테스트는 이 글에서 실행하지 않았습니다.

10. 요약 — 어떤 지표를 먼저 볼까?

질문	먼저 볼 지표
첫 답변이 왜 늦을까?	TTFT → 큐 대기·입력 길이·캐시
답변 중간이 왜 끊길까?	ITL/ICL 분포 → 스케줄링·전송
평균적으로 얼마나 빨리 이어 쓰나?	TPOT
완성된 결과를 언제 받나?	E2E와 출력 길이
서버가 얼마나 처리하나?	같은 부하의 전체 Throughput·RPS
느린 경험과 목표를 놓치지 않았나?	P95/P99·SLO·Goodput·오류

이 표는 원인을 확정하는 진단표가 아니라 다음 확인 항목을 고르는 안내입니다. 하나의 속도 숫자보다 같은 조건의 지연·처리량·목표 달성을 함께 보는 것이 중요합니다.

KV Cache와 메모리의 관계를 더 알고 싶다면 기존 한국어 산업 글 KV 캐시 재사용, HBM은 덜 필요할까를 함께 읽어보세요. 이 성능 지표를 특정 기업의 매출이나 주가 전망으로 바로 바꾸지는 않습니다.

Appendix. 다음 단계에서 알아둘 최적화 용어

용어	정의와 확인할 점
Prefix Caching	공통 입력 접두부의 계산 결과를 재사용합니다. 캐시가 있는 측정과 없는 측정을 구분합니다.
Chunked Prefill	긴 입력 처리를 나눠 스케줄링합니다. TTFT·생성 간격·처리량의 균형을 확인합니다.
Quantization	양자화. 낮은 정밀도로 표현해 메모리·계산 비용을 바꿉니다. 답변 품질과 지원 환경도 확인합니다.
Speculative Decoding	추측 디코딩. 후보 토큰을 제안하고 검증해 생성 속도를 높이는 기법입니다. 여러 토큰이 함께 전달될 수 있어 청크/토큰 구분이 중요합니다.

공식 출처와 자료 사용 안내

Hugging Face — Tokenization algorithms: 토큰·토크나이저
NVIDIA — Inference Optimization: Prefill·Decode·KV Cache·배칭
NVIDIA NIM — Benchmarking Metrics: TTFT·E2E·평균 ITL·TPS·RPS
vLLM — Metrics: 이벤트 간격·TPOT·집계 방식
NVIDIA AIPerf — Metrics Reference: 청크·ICL·사용자당 처리 속도
vLLM SenDNN — Benchmarking and Performance: 성능 비교 조건
GuideLLM — GoodputSLO: 서비스 목표 충족 기준

구성 참고: AI의 정석의 LLM 속도 개념 글. 용어별 정의·의미에서 예시·측정·요약으로 이어지는 조직 방식을 참고했으며 문장·그림·코드는 복제하지 않았습니다.

기준일: 2026-10-12. 도표·GIF는 Deoks 자체 제작이며 가상 수치입니다. Python 시각 계산만 실행했고 실제 GPU/API 벤치마크는 실행하지 않았습니다. 실제 비교에는 도구의 버전과 측정 정의를 확인하세요.

OpenAI Revenue Concerns: What $50B vs. $70B Really Means

2026-10-10T15:04:41.033+09:00

OpenAI’s reported $50 billion and $70 billion figures do not describe the same thing. The first was a reported annualized revenue pace at the end of September; the second was a reported outlook for the annualized pace at year-end.

Neither is audited full-year revenue, and neither settles the questions that matter for financial durability: recognized revenue, margin, cash collection, and the cost of supplying compute.

That distinction also helps with the stock-market story. Premarket sentiment improved after the later outlook report, but the October 9 regular-session closes were mixed: Nvidia ended lower while Microsoft, Oracle, and CoreWeave ended higher.

Latest Tech(EN): Amazon’s $1B Data-Center Community Plan: The New Constraint Is Permission to Build

한국어 버전: 한국어 분석 읽기: 오픈AI 매출 우려 완화, 500억·700억 달러는 같은 숫자가 아니다

Key Takeaways

Reuters reported, citing an unnamed source, that OpenAI’s September annualized revenue was close to $50 billion. OpenAI did not respond to Reuters’ request for comment. [Source 1]
Bloomberg later reported, citing unnamed people, that OpenAI expected to reach or exceed a $70 billion annualized pace by year-end, with enterprise growth as a driver. OpenAI declined to comment. [Source 2]
A run rate extrapolates a recent sales pace. It is not automatically recognized annual revenue, operating profit, free cash flow, or customer cash collection.
At the October 9 U.S. regular-session close, NVDA was down 0.52%; MSFT, CRWV, and ORCL were up. A single “AI stocks surged” headline would not describe these four closes accurately. [Source 3] [Source 4] [Source 5] [Source 6]

Why $50B and $70B are not a contradiction by themselves

The two reported figures use different reference points. Reuters described a September-end annualized pace near $50 billion. Bloomberg described an expected year-end annualized pace of $70 billion or more. A current pace and a future expectation cannot be read as two versions of the same completed-year income statement.

Figure	What it describes	What it does not establish
About $50B	Reported annualized pace at the end of September	Audited 2026 revenue, profit, or cash flow
$70B or more	Reported year-end annualized-pace outlook	Already-recognized revenue
$2B per month	OpenAI’s company-issued March 31 revenue reference	Confirmation of either later report

Reuters said an earlier roughly $70 billion figure was tied to efforts to compare OpenAI’s presentation with Anthropic’s. The report also noted that annualized revenue can be a misleading measure when a recent month is multiplied by twelve. The available reporting does not provide a public reconciliation for every category of partner-mediated sales. [Source 1]

Annualized revenue is not automatically ARR

For a simple example, a company with $1 billion of revenue in one month has a $12 billion annualized pace if that month is multiplied by twelve. It may not have earned $12 billion over the prior twelve months, and future monthly sales may not match the extrapolation.

“Annual recurring revenue” also needs a definition. It is not automatically the same measure as an annualized revenue run rate, especially where subscription revenue sits next to usage-based API spending and partner channels. Before comparing companies, ask which sales are included, which period is extrapolated, and whether a partner sale is presented on a gross or net basis.

There is a separate dated reference from OpenAI itself: on March 31, the company said it was generating $2 billion in monthly revenue and that enterprise customers accounted for more than 40% of revenue. That reference should not be converted into confirmation of a later anonymous-source report. [Source 7]

Premarket mood was not the closing result

Morning commentary described improved sentiment around the updated outlook. The regular-session close tells a narrower, later-in-the-day story. The Nasdaq Composite rose 0.64% and the S&P 500 rose 0.59%, while the four AI-linked stocks below did not move in one direction. [Source 8]

Company	Ticker	October 9 close	Raw close-to-close change	Public connection to OpenAI
Nvidia	NASDAQ: NVDA	$229.28	-0.52%	Infrastructure and strategic-investment relationship described by OpenAI
Microsoft	NASDAQ: MSFT	$535.07	+2.38%	Major shareholder and primary cloud partner
CoreWeave	NASDAQ: CRWV	$82.08	+0.61%	Included in OpenAI’s infrastructure network
Oracle	NYSE: ORCL	$141.40	+4.21% (raw close $135.69 → $141.40)	OpenAI named among contracted OCI customers

The table uses U.S. regular-session raw closing prices, excluding after-hours moves and dividends. Oracle’s data page shows a 4.59% daily change because it uses a $135.19 adjusted prior close rather than the $135.69 raw prior close. This article uses 4.21% only for an apples-to-apples raw-price comparison; it does not call either series a total return or infer a single cause for the difference. [Source 6]

Broader market variables were also active: Reuters cited the upcoming earnings season, inflation data, yields, and oil-related geopolitical headlines. This is an event-adjacent price comparison, not a controlled estimate of the OpenAI reports’ effect on any stock. [Source 8]

Public-company exposure is not the same as OpenAI ownership

The revenue reports concern OpenAI, a private company in the reports, while the listed companies above have different commercial or ownership relationships. Owning their shares is not the same as owning an OpenAI stake.

Nvidia: OpenAI says Nvidia is foundational to its training fleet and most of its inference stack. [Source 7]
Microsoft: OpenAI says Microsoft remains a major shareholder and primary cloud partner; the amended model and product-IP license is non-exclusive. [Source 9]
Oracle: Oracle’s financing-plan release names OpenAI among large OCI customers whose contracted demand it is preparing to serve. [Source 10]
CoreWeave: OpenAI lists CoreWeave in its infrastructure strategy. [Source 7]

Those links have different sensitivities to customer concentration, data-center delivery, funding costs, other clients, and non-OpenAI businesses. A headline about an OpenAI run rate does not answer how much revenue or cash each company will recognize.

Three questions that matter more than the headline

Which metric is being quoted? Bookings, remaining performance obligations, contracts, recognized revenue, and cash collection are not interchangeable.
Which period is being compared? A September pace and a year-end outlook should not be treated as competing completed-year results.
What does the business retain after compute? Revenue growth alone does not answer compute cost, capital investment, margin, or free-cash-flow questions.

Oracle’s own September earnings release is a useful reminder of the distinction: it reported $19.3 billion of first-quarter revenue and negative free cash flow while investing heavily in cloud capacity. That does not describe OpenAI’s finances; it simply illustrates why a capacity-and-revenue headline is not a full cash-flow analysis. [Source 11]

Appendix. What would be stronger evidence?

Stronger evidence would include a comparable year-end run rate, clearer definitions for the reported measure, durable enterprise usage, recognized revenue, gross margin, compute spending, and cash collection. Supplier contracts also need to become delivered capacity and paid usage. A run-rate update can narrow one immediate concern without resolving all of those questions.

Sources and date basis

U.S. share prices use the October 9, 2026 regular-session close. The research cutoff is October 10, 2026. This is factual news analysis, not investment advice.

오픈AI 매출 우려 완화, 500억·700억 달러는 같은 숫자가 아니다

2026-10-10T15:04:01.144+09:00

처음엔 오픈AI 매출 숫자가 700억 달러에서 500억 달러로 줄었다는 이야기처럼 보였다.

하지만 500억 달러는 9월 말의 연환산 매출 속도 보도이고, 700억 달러 이상은 연말에 도달할 수 있다는 전망 보도다. 어느 쪽도 2026년 확정 매출이나 이익이 아니다.

그래서 이번 뉴스는 AI 수요가 사라졌는지보다, 서로 다른 매출 산식과 시간대를 한 숫자로 섞어 읽었는지를 먼저 봐야 할 것 같다.

미국 증시도 한 방향으로 움직이지 않았다. 10월 9일 정규장 종가 기준 엔비디아는 내렸고, 마이크로소프트·오라클·코어위브는 올랐다.

최근 Tech(KR) 글: AI 대화가 길면 내 PC 메모리도 늘까? 브라우저와 KV Cache

관련 한글 주식·산업 분석: 메타, 기업용 AI 플랫폼 발표…고객은 움직일까 — AI 서비스의 고객 수요와 사업 연결을 확인하는 관점

English version: Read the independent English analysis: OpenAI Revenue Concerns: What $50B vs. $70B Really Means

핵심 요약

로이터는 익명 관계자를 인용해 오픈AI의 9월 연환산 매출이 약 500억 달러였다고 보도했다. 회사는 논평 요청에 응답하지 않았다. [출처 1]
블룸버그는 익명 관계자를 인용해 오픈AI가 연말 연환산 매출 700억 달러 이상을 예상한다고 보도했다. 이는 전망이지 확정 실적이 아니다. [출처 2]
연환산 매출은 짧은 기간의 매출 속도를 1년으로 환산한 값이다. 실제 12개월 매출 합계, 이익, 현금흐름과 같은 말이 아니다.
10월 9일 미국 정규장에서는 NVDA가 -0.52%였지만 MSFT·ORCL·CRWV는 각각 올랐다. 한 뉴스가 모든 AI 관련주를 같은 방향으로 움직였다고 볼 수 없다. [출처 3] [출처 4] [출처 5] [출처 6]

숫자 두 개를 먼저 분리해 보기

아래 표는 실적 표가 아니다. 같은 회사의 성장을 말하는 듯해도, 기준 시점과 성격이 다른 보도 수치를 분리해 읽기 위한 정보 카드다.

수치	무엇을 뜻하나	확인 상태
약 500억 달러	2026년 9월 말 기준으로 보도된 연환산 매출 속도	익명 관계자 인용 보도, 회사 논평 없음
700억 달러 이상	2026년 말까지의 연환산 매출 전망	익명 관계자 인용 보도, 확정 매출 아님
월 20억 달러	2026년 3월 31일 OpenAI가 공식 발표한 당시 월 매출	회사 공식 발표

여기서 가장 조심할 부분은 ‘연환산’이다. 예를 들어 한 달 매출을 12배로 환산하는 방식이라면, 계절성·사용량 변화·계약 갱신·할인·파트너 판매 인식이 남은 12개월에 그대로 이어진다고 보장하지 않는다. 로이터도 이 지표가 빠르게 성장하는 비상장 기업에서 널리 쓰이지만 오해를 부를 수 있다고 설명했다. [출처 1]

매출 우려가 완화됐다는 말의 범위

우려가 완화됐다고 볼 수 있는 부분은 있다. 9월 말 속도가 약 500억 달러였다는 보도 뒤에, 연말 700억 달러 이상을 기대한다는 후속 보도가 나왔기 때문이다.

다만 이 두 줄만으로 “200억 달러의 실매출이 사라졌다가 회복됐다”고 쓰면 틀린다. 로이터 보도는 이전의 약 700억 달러 수치가 앤트로픽과의 비교를 맞추려는 과정과 연결됐다고 전했고, 오픈AI는 클라우드 파트너를 통한 판매를 앤트로픽과 다르게 포함한다고 설명했다. 정확한 화해표가 공개된 것은 아니므로, 보도 숫자만으로 항목별 차이를 계산할 수는 없다. [출처 1]

OpenAI의 3월 공식 발표는 당시 월 매출 20억 달러와 기업용 사업 비중 40% 초과를 제시했다. 이 숫자는 날짜와 발표 주체가 분명한 기준점이다. 반면 9월 말 500억 달러와 연말 700억 달러 이상은 회사가 재무제표로 발표한 확정치가 아니라 익명 취재원 보도라는 차이를 남긴다. [출처 7]

AI 관련주 반응, 장전 분위기와 종가는 달랐다

10월 9일은 지수 자체도 올랐다. 로이터의 장 마감 보도에 따르면 S&P 500은 0.59%, 나스닥 종합은 0.64% 상승했다. 같은 기사도 AI 모멘텀 종목이 전반적으로 강했다고 표현했을 뿐, 오픈AI 관련 보도 하나가 유일한 원인이라고 말하지는 않았다. [출처 8]

기준: 아래는 미국 현지 2026년 10월 9일 정규장 원시 종가와 전일 원시 종가를 비교한 가격 변화다. 배당을 포함한 총수익률이 아니며, 뉴스의 인과효과를 측정한 결과도 아니다.

회사·티커	10월 9일 종가	전일 대비	확인할 연결고리
NVIDIA (NASDAQ: NVDA)	$229.28	-0.52%	OpenAI는 엔비디아를 학습·추론 인프라의 기반으로 설명
Microsoft (NASDAQ: MSFT)	$535.07	+2.38%	OpenAI의 주요 주주이자 1차 클라우드 파트너
CoreWeave (NASDAQ: CRWV)	$82.08	+0.61%	OpenAI가 열거한 클라우드 인프라 포트폴리오 중 하나
Oracle (NYSE: ORCL)	$141.40	+4.21% (원시 종가 $135.69→$141.40)	Oracle은 OpenAI를 OCI 대형 고객 중 하나로 언급

ORCL은 데이터 제공 화면의 조정 기준 일간 변화율이 4.59%로 보일 수 있다. 이 글은 종가 135.69달러와 141.40달러를 직접 비교한 4.21%를 사용했다. 배당·조정 기준 수익률과 원시 종가 수익률을 같은 그래프나 문장에 섞지 않기 위해서다. [출처 6]

티커가 있다고 오픈AI 지분을 뜻하지는 않는다

이번 보도에서 말하는 OpenAI의 수치는 상장사 실적 공시가 아니라 비상장 기업에 관한 취재 보도다. 따라서 NVDA·MSFT·ORCL·CRWV를 보유하는 일은 OpenAI 지분을 직접 보유하는 것과 다르다.

공개 자료에서 확인되는 연결도 서로 다르다. OpenAI는 엔비디아가 자사 학습 플릿과 대부분의 추론 스택의 기반이라고 설명했다. 마이크로소프트는 주요 주주이자 1차 클라우드 파트너지만, 2026년 개정 계약에서는 모델·제품 IP 라이선스가 비독점으로 바뀌었다. 오라클은 OpenAI를 OCI 수요 확대의 고객 중 하나로 열거했고, CoreWeave 역시 OpenAI의 클라우드 전략에 포함된다. [출처 7] [출처 9] [출처 10]

하지만 공급·클라우드·투자 관계가 있다는 사실과 특정 분기의 매출·마진·현금흐름이 늘었다는 사실은 다르다. 고객의 실제 사용량, 계약 개시, 데이터센터 가동, 자금조달 비용, 다른 대형 고객의 수요가 각 회사의 실적과 주가에 함께 작용한다.

놓치기 쉬운 건 매출이 아니라 산식과 비용이다

뉴스에서 가장 놓치기 쉬운 부분은 숫자의 크기보다 경계선이다. 파트너를 거친 판매를 총액으로 볼지, 플랫폼 회사의 몫으로 순액 인식할지는 서로 다른 숫자를 만들 수 있다. 그것만으로 회계 오류나 허위 매출을 뜻하지는 않지만, 비교 전에는 산식을 먼저 확인해야 한다.

또 하나는 비용이다. 연환산 매출 속도가 커져도 모델 학습·추론을 위한 컴퓨팅 비용, 데이터센터 투자, 자금조달, 고객 획득비를 빼고 남는 이익과 현금흐름은 별도 질문이다. 이번 보도는 수요 급감 해석을 약하게 만들 수는 있어도, 수익성까지 확정해 주지는 않는다.

다음에 확인할 숫자

연말 700억 달러 이상 전망이 어떤 산식과 범위로 제시되는지
기업용 성장에서 계약·사용량·현금 회수가 어떻게 이어지는지
연환산 매출이 아닌 확정 매출, 비용, 이익·현금흐름 자료가 공개되는지
클라우드·GPU·데이터센터 파트너의 계약 가동과 실제 매출 인식이 뒤따르는지

Appendix. 연환산 매출은 어디까지 답해주나

연환산 매출은 빠르게 커지는 서비스의 최근 매출 속도를 가늠하는 보조 지표다. 성장의 방향을 읽는 데는 쓸 수 있지만, 감사된 연간 매출·영업이익·잉여현금흐름을 대신하지는 않는다. 특히 사용량 과금과 파트너 판매가 섞인 AI 서비스에서는 계산 범위와 비교 기준이 숫자만큼 중요하다.

출처·기준일

미국 주가 기준일은 2026년 10월 9일 정규장 종가, 작성 기준일은 2026년 10월 10일 KST다. 이 글은 특정 종목의 매수·매도 권유가 아니다.

스페이스X 스타링크 모바일, 800MHz 인수 계약과 통신주 급락을 읽는 법

2026-10-10T15:01:42.970+09:00

스페이스X의 스타링크 모바일 계획은 아직 미국 이동통신 서비스를 시작했다는 뜻이 아니다. 핵심은 전국 800MHz 대역의 최대 14MHz 페어드 주파수를 사들이기로 한 계약이며, 거래 종결에는 FCC 승인과 통상적인 조건이 남아 있다.

그래도 시장은 이 계약을 잠재적 경쟁의 신호로 읽었다. 미국 현지 10월 9일 정규장 원시 종가 기준으로 SPCX는 1.25% 올랐고, TMUS는 13.27% 내렸다. AT&T와 Verizon도 원시 종가 기준으로는 각각 10.82%, 10.14% 낮아졌다.

여기서 중요한 것은 ‘800MHz’와 ‘14MHz’를 섞지 않는 것, 그리고 통신주의 원시 종가 변화와 배당 조정 수치를 한 표에 섞지 않는 것이다.

최근 Tech(KR) 글: AI 대화가 길면 내 PC 메모리도 늘까? 브라우저와 KV Cache

관련 한글 주식·산업 분석: 세미파이브 703억원 AI칩 수주, 확정금액은 얼마일까 — 계약 금액을 확정 실적과 구분해 읽는 기준

핵심 요약

SpaceX와 Grain Management는 800MHz 대역에서 최대 14MHz 페어드 주파수 포트폴리오를 넘기는 definitive agreement를 발표했다. 거래는 아직 FCC 승인과 종결 조건을 기다린다. [출처 1]
SpaceX는 이 저대역 주파수를 위성-휴대전화와 지상망을 결합한 Starlink Mobile 계획에 쓰겠다고 설명했다. 이는 회사의 계획 설명이지, 이미 검증된 전국 실내 서비스 결과가 아니다. [출처 2]
SpaceX는 2026년 6월부터 NASDAQ에서 SPCX로 거래되고 있다. EchoStar의 현 티커는 ECHO다. 오래된 ‘비상장 SpaceX’ 또는 ‘SATS’ 표기는 이 사건에 맞지 않는다. [출처 3] [출처 4]
10월 9일 통신주의 큰 하락은 그날의 원시 종가 변화다. 계약 하나가 향후 가입자·이익 감소를 확정했다는 뜻은 아니다.

지금 확정된 것과 아직 아닌 것

뉴스를 읽을 때는 주파수의 매매 계약, 서비스 기술, 실제 상용화 단계를 분리해야 한다. 지금 공개된 것은 첫 단계와 계획의 범위다.

구분	공개된 내용	아직 확인할 일
거래	Grain의 전국 800MHz 포트폴리오를 SpaceX가 인수하기로 한 definitive agreement	FCC 승인 및 통상적인 종결 조건 충족
주파수	800MHz 대역 안의 최대 14MHz 페어드 주파수	상용망 구성, 서비스 지역, 단말·요금제
네트워크	위성-휴대전화와 지상망을 결합하겠다는 회사 계획	실내 품질, 커버리지, 용량의 실측 결과

800MHz는 주파수가 놓인 대역이고, 14MHz는 이번 포트폴리오에서 언급된 최대 페어드 대역폭이다. “800MHz 폭을 샀다”는 표현은 정확하지 않다. SpaceX는 새 저대역이 벽 같은 장애물을 통과하는 커버리지 층을 보완하고, 2GHz 중대역은 용량을 맡는다는 구상을 제시했다. [출처 2]

주파수는 어떤 경로로 이동했나

이 자산을 SpaceX가 곧바로 기존 이동통신사에서 산 것은 아니다. T-Mobile은 8월 11일 Grain에 800MHz 포트폴리오를 넘기고 현금 29억 달러와 Grain의 600MHz 라이선스를 받았다고 발표했다. 이어 10월 8일 Grain은 SpaceX와의 후속 계약을 공시했다.

시점	단계	무엇을 읽어야 하나
2026년 8월 11일	T-Mobile → Grain, 거래 완료	현금 29억 달러 및 600MHz 라이선스의 교환
2026년 10월 8일	Grain → SpaceX, definitive agreement	FCC 승인과 그 밖의 종결 조건이 남음
향후	종결·구축·서비스	계약 가격보다 실제 네트워크 투자와 사용 품질이 중요

따라서 과거의 29억 달러를 Grain이 이 자산을 산 ‘전부의 가격’으로 놓거나, 언론이 보도한 후속 거래 가격을 확정 공시 가격처럼 쓰면 안 된다. 전자는 현금과 600MHz 교환이 함께 있었고, 후자는 양사가 이번 발표에서 가격을 공개하지 않았다. [출처 5] [출처 1]

통신주 급락: 원시 종가로만 비교하기

아래는 미국 현지 2026년 10월 8일과 9일의 원시 정규장 종가를 직접 비교한 표다. 배당을 더하지 않았고, 시간외·장전 등락률도 넣지 않았다. 변화율은 ‘10월 9일 원시 종가 ÷ 10월 8일 원시 종가 - 1’로 계산했다.

회사·티커	10월 8일 → 9일 원시 종가	단순 가격 변화	관찰 범위
SpaceX (NASDAQ: SPCX)	$160.57 → $162.57	+1.25%	상장 SpaceX 전체에 대한 가격
T-Mobile US (NASDAQ: TMUS)	$171.31 → $148.58	-13.27%	기존 800MHz 보유·매각 이력
AT&T (NYSE: T)	$24.87 → $22.18	-10.82%	미국 이동통신 사업자
Verizon (NYSE: VZ)	$46.35 → $41.65	-10.14%	미국 이동통신 사업자

원시 종가 기준으로 T와 VZ의 하락률은 각 데이터 화면에 보이는 일간 Change와 다르다. 그 화면은 전일의 조정 종가를 각각 $24.59, $45.64로 보여주며, 그 기준의 변화는 -9.81%, -8.75%다. 원시 종가와 조정 종가를 한 그래프에 섞으면 변화율이 달라진다. 어느 하나를 배당 포함 총수익률이라고 부르지 않고, 표마다 기준을 붙이는 편이 안전하다. [출처 6] [출처 7]

로이터의 장 마감 보도도 T-Mobile·AT&T·Verizon이 8.8%~13.3% 하락했다고 전하면서 SpaceX 거래를 미국 무선 시장의 경쟁 변수로 다뤘다. 그러나 같은 날 금리, 유가, 실적 시즌 같은 다른 시장 변수가 함께 있었다. 이 표는 사건 주변의 가격 관찰이지 계약의 순수 효과를 계산한 결과가 아니다. [출처 8]

FCC 관련 문구는 어디까지 읽어야 하나

SpaceX는 같은 발표에서 FCC가 Starlink Mobile Gen2 신청을 승인해 2GHz용으로 최적화된 위성 1만5,000기를 발사할 수 있게 됐다고 밝혔다. 이 글의 직접 검토 범위에서는 그 2026년 설명과 일치하는 FCC 명령문을 독립적으로 찾지 못했다.

따라서 이 수치는 “SpaceX가 발표에서 말한 허가 규모”로만 쓴다. 위성 1만5,000기가 이미 운용 중이라는 뜻도 아니고, 800MHz 인수 계약이 곧바로 종결됐다는 뜻도 아니다. 서비스 일정과 실제 네트워크 조건은 후속 규제 문서와 회사의 상용화 발표에서 다시 확인해야 한다. [출처 2]

Appendix. 다음 뉴스에서 체크할 네 가지

Grain-to-SpaceX 거래의 FCC 승인과 실제 종결 공지
서비스 지역·요금제·단말 호환성에 관한 구체적인 회사 자료
저대역·중대역·지상망이 실제로 어떤 품질을 내는지에 대한 측정 결과
기존 통신사의 다음 실적에서 보이는 가입자, 가격, 설비투자 변화

출처·기준일

시장 수치는 2026년 10월 9일 미국 정규장 마감 기준이며, 작성 기준일은 2026년 10월 10일 KST다. 이 글은 사실·산업 분석이며 특정 증권의 매수·매도 권유가 아니다.

AI 대화가 길면 내 PC 메모리도 늘까? 브라우저와 KV Cache

2026-10-09T19:18:16.634+09:00

짧은 답: 보통은 아니다. 클라우드 AI에서 대화가 길어질 때의 KV Cache는 모델을 실행하는 서버 쪽 상태이고, 내 브라우저 탭이 쓰는 메모리는 대화 화면·DOM·JavaScript·첨부물처럼 다른 층의 비용이다. 다만 내 PC에서 로컬 LLM을 돌린다면, 그때는 문맥 길이가 GPU 메모리나 시스템 메모리와 직접 만난다.

탭이 무거워졌다고 해서 서버에서 쓰는 모델 메모리까지 내 PC로 내려온 것은 아니다. 반대로 대화가 길어도 브라우저 탭 메모리만 보고 서비스의 추론 자원 상태를 알 수는 없다.

특정 AI 서비스의 내부 구현은 공개 문서 없이 단정할 수 없다. 여기서는 브라우저에서 보이는 현상과 모델이 실행되는 곳의 상태를 나눠 보려 한다.

이전 Tech(KR) 글: SVN 웹 접속이 안 될 때, URL·인증·권한을 나눠 확인하는 순서

핵심 요약

클라우드 AI: 대화 문맥을 계산하는 모델은 보통 서비스 제공자의 실행 환경에 있다. 그 환경의 KV Cache와 브라우저 탭의 메모리는 같은 숫자가 아니다.
브라우저: 대화 목록·렌더링된 답변·이미지·JavaScript 객체는 탭의 메모리에 영향을 줄 수 있다. Chrome도 OS 메모리와 JavaScript Memory를 구분해 관찰하도록 안내한다.
로컬 LLM: 모델을 내 PC에서 실제로 실행할 때에는 문맥 길이와 생성 상태가 GPU 메모리 또는 시스템 메모리 사용량에 직접 영향을 줄 수 있다.
안전한 판단: 한 화면의 메모리 수치만으로 원인을 결론내지 말고, 먼저 “브라우저 탭인가, 로컬 모델 프로세스인가, 서비스 서버인가”를 나눈다.

자체 제작 도식. 브라우저 탭 메모리와 모델 실행 측 KV Cache는 같은 지표가 아니다. 특정 서비스의 내부 구현을 나타내지 않는다.

KV Cache는 ‘대화창 저장 공간’이 아니다

언어 모델은 다음 토큰을 만들 때 앞 문맥을 참조한다. 이때 이미 만든 내부 표현 중 key와 value를 보관해 다음 계산에서 다시 쓰는 것이 KV Cache다.

vLLM의 공식 Automatic Prefix Caching 문서는 같은 앞부분을 공유하는 새 요청이 기존 KV Cache를 재사용해 그 부분의 계산을 건너뛸 수 있다고 설명한다. 즉, KV Cache는 채팅 화면의 문장을 단순 복사해 두는 브라우저 기능이 아니라 모델 추론 엔진이 다루는 실행 상태다.

그래서 긴 대화가 서비스 쪽 추론 비용이나 상태 관리와 무관하다고 말할 수는 없다. 다만 그 비용이 정확히 어느 장비의 어떤 메모리에 얼마나 남는지는 모델, 문맥 정책, 동시 요청, 제품 구현에 따라 달라진다.

탭 메모리는 무엇을 가리키나

브라우저에서 보는 메모리는 페이지가 화면을 만들고 동작하는 데 쓰는 자원이다. 대화가 길어지면 렌더링된 메시지, DOM node, JavaScript 객체, 이미지와 확장 기능 등이 함께 영향을 줄 수 있다.

Chrome DevTools 공식 안내도 Chrome Task Manager의 Memory footprint와 JavaScript Memory를 다른 지표로 설명한다. 전자는 운영체제 메모리 관점이고, 후자는 페이지의 도달 가능한 JavaScript 객체와 관련된 수치다.

따라서 웹 AI 탭의 메모리가 늘었다면, 먼저 그것을 브라우저 페이지의 관찰값으로 읽는 편이 안전하다. 그 값 하나로 서버의 모델 KV Cache가 늘었다거나, 반대로 서버가 메모리를 쓰지 않는다고 판단할 수는 없다.

같은 ‘긴 대화’도 세 갈래로 나뉜다

1. 웹으로 쓰는 클라우드 AI

내 PC에서는 주로 브라우저가 대화 UI를 처리한다. 모델 추론은 서비스 사업자의 인프라에서 이뤄지는 것이 일반적이므로, 모델 상태를 내 탭의 메모리 숫자와 일대일로 연결하면 안 된다. 서비스가 어느 시점까지의 대화를 모델에 넣고, 무엇을 요약하거나 버리는지는 공개되지 않았다면 알 수 없다.

2. 로컬 앱 또는 로컬 LLM

모델이 내 장비에서 실행된다면 이야기가 달라진다. 활성 문맥과 생성 상태는 그 실행 프로세스가 쓰는 GPU 메모리나 시스템 메모리에 놓인다. 이 경우에는 대화가 길어질수록 모델 프로세스 자원과 문맥 길이를 함께 보는 것이 맞다. 단, 모델 구조와 설정에 따라 증가 양상은 다르므로 특정 수치를 일반화하면 안 된다.

3. 브라우저 안에서 로컬 추론을 돌리는 경우

브라우저가 UI만 맡는지, 브라우저의 WebGPU 같은 경로로 실제 모델도 실행하는지에 따라 관찰 대상이 달라진다. 같은 브라우저 창이라도 탭 메모리만으로 GPU 사용량과 모델의 내부 상태를 완전히 설명할 수 없다는 뜻이다.

서비스 쪽에서도 ‘무한히 쌓인다’고 볼 수 없는 이유

긴 대화가 항상 처음부터 끝까지 동일한 상태로 남는 것은 아니다. 각 서비스는 지원하는 문맥 길이, 요청의 수명, 캐시 정책, 요약·절단 방식에 따라 다른 선택을 할 수 있다.

vLLM의 최적화 문서는 KV Cache 공간이 동시 요청을 담기에 부족하면 요청을 preempt하고 다시 계산할 수 있음을 설명한다. 이것은 한 추론 시스템의 구현 예시다. 특정 클라우드 서비스가 같은 정책을 쓴다는 증거는 아니지만, KV Cache가 모델을 실제 실행하는 쪽에서 용량과 동시성의 제약을 받는다는 점은 잘 보여준다.

느려졌을 때, 먼저 어디를 볼까

웹 AI가 느리거나 탭이 무겁다: 브라우저 탭 문제와 서비스 응답 지연을 먼저 분리한다. 탭의 메모리 수치가 오른 사실은 페이지의 UI·스크립트 쪽 단서이지, 서버 KV Cache의 측정값은 아니다.

로컬 LLM이 느리거나 메모리 부족이 난다: 실행 중인 모델 프로세스의 GPU/시스템 메모리, 선택한 모델, 문맥 길이, 동시 요청 설정을 함께 확인한다. 설정을 무작정 키우기보다 현재 실행기 문서의 메모리 한계와 오류 메시지를 먼저 읽는 편이 안전하다.

서버를 운영한다: KV Cache 용량, 동시 요청 수, 지연 시간은 같이 봐야 한다. 캐시를 크게 잡으면 동시성에 영향을 줄 수 있고, 부족하면 재계산과 지연이 생길 수 있다. 단일 지표만 늘려 해결됐다고 단정하지 않는다.

Appendix. 이 구분이 왜 필요한가

“대화가 길어졌다”는 한 문장 안에는 서로 다른 세 문제가 들어갈 수 있다. 브라우저 페이지의 렌더링, 로컬 장비의 모델 실행, 클라우드 서비스의 추론 자원이다. 관찰 위치를 먼저 나누면 불필요하게 브라우저를 탓하거나, 반대로 서버의 문맥 정책을 탭 메모리 수치로 추정하는 일을 줄일 수 있다.

이 글은 특정 서비스의 내부 구조를 공개 정보 없이 추정하지 않는다. 모델을 로컬에서 실행하지 않는 한, 사용자가 보는 탭 메모리만으로 서비스의 KV Cache 사용량을 확인할 수 없다는 점이 핵심이다.

출처와 확인일

자료 확인일은 2026년 10월 9일이다. 아래 문서는 각각의 구현·브라우저 진단 방법을 설명하며, 특정 상용 AI 서비스의 내부 구성을 뜻하지 않는다.

vLLM — Automatic Prefix Caching — 지속 갱신 공식 문서, 2026-10-09 확인.
vLLM — Optimization and Tuning — 지속 갱신 공식 문서, 2026-10-09 확인.
Chrome DevTools — Fix memory problems — Google 공식 문서, 2026-10-09 확인.

SVN 웹 접속이 안 될 때, URL·인증·권한을 나눠 확인하는 순서

2026-10-07T19:09:28.000+09:00

SVN 접속이 막히면 아래 증상부터 고르세요. 설정을 바꾸기 전에 URL → 인증 → 경로 권한 순서로 확인합니다.

접속 안 됨 · 인증 반복·401 · 권한·403 · 주소·404

30초 빠른 진단: 다음 행동 하나만 고르기

접속 자체가 안 됨
확인: 정확한 저장소 URL과 오류 문구.
다음: svn info https://svn.example.com/svn/team-repo로 읽기 전용 조회.
주의: 예시 URL을 실제 주소로 바꾸고, 비밀번호는 명령에 넣지 않습니다.
인증 창 반복·401
확인: 요청 URL이 사용하는 인증 영역.
다음: 관리자에게 계정·인증 제공자·Require valid-user 설정 확인 요청.
주의: 확인 없이 인증 요구를 끄지 않습니다.
로그인했는데 403
확인: 접근이 막힌 저장소와 하위 경로.
다음: 관리자에게 해당 사용자·그룹의 authz 읽기 규칙 대조 요청.
주의: 전체 익명 접근이나 전체 쓰기 권한을 열지 않습니다.
404
확인: Location 접두어와 저장소 이름.
다음: 관리자에게 확인받은 URL로 svn ls https://svn.example.com/svn/team-repo 조회.
주의: 저장소를 새로 만들기 전에 URL 매핑부터 확인합니다.

두 명령은 공식 문서에서 확인한 조회 예시입니다. 이 글을 준비하며 실제 서버·저장소에 실행하거나 설정을 바꾸지는 않았습니다.

이전 Tech(KR) 글: VirtualBox 화면 크기 자동 조절 안 될 때, Guest Additions부터 VMSVGA까지

도식: 자체 제작 · URL 매핑 → 인증 → 경로 권한 순서로 원인을 분리하는 확인 흐름

상세: URL·인증·권한이 다른 이유

웹 화면 ≠ SVN 접속 확인: mod_dav_svn은 HTTP 위의 WebDAV/DeltaV 요청을 처리합니다. 브라우저에서 페이지가 열려도 클라이언트의 저장소·경로 접근까지 확인된 것은 아닙니다.
주소 매핑: Location은 URL 접두어, DAV svn은 SVN 연결입니다. SVNPath는 저장소 하나, SVNParentPath는 상위 디렉터리 아래 여러 저장소를 연결합니다. 실제 URL·Location·설정값·저장소 이름을 대조하세요. /svn/team-repo/trunk에서 접두어·저장소 이름·내부 경로는 서로 다릅니다.
신원과 접근 권한: Require valid-user는 인증된 사용자를 요구합니다. mod_authz_svn과 AuthzSVNAccessFile은 사용자·그룹별 경로 접근을 판단하므로, 로그인 성공이 모든 폴더의 읽기·쓰기 허용을 뜻하지 않습니다.

예외와 설정 변경 전 확인

301: DocumentRoot와 SVN Location의 URL 공간이 겹치는 구성도 확인 대상입니다. 401·403·404·301은 원인을 확정하는 증거가 아니라 확인을 시작할 신호입니다.
인증 창이 없어도 정책은 있습니다: 익명 읽기·인증된 쓰기 또는 특정 하위 경로만 인증하는 혼합 정책이 가능합니다.
변경은 한 번에 하나: URL·발생 시각·오류 문구를 기록하고 관리자와 오류 로그를 확인하세요. 현재 설정 백업과 변경 승인을 거친 뒤 같은 조회로 다시 확인합니다.

적용 범위는 Apache HTTP(S) 기반 SVN입니다. 현재 Apache·Subversion 버전, 인증 제공자, 프록시와 조직의 접근 정책에 따라 구성이 달라지므로 오래된 설치 명령을 그대로 복사하지 마세요.

출처 및 업데이트

2026-10-07 확인: Version Control with Subversion — Apache HTTP Server configuration
2026-10-07 확인: Apache Subversion Quick Start
2026-10-07 확인: Apache Subversion FAQ
조회 명령 확인: svn info · svn list (ls)