글

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

이미지
DEOKS · TECH LEARNING LLM PERFORMANCE LLM이 빠르다는 말은 첫 반응, 답을 이어 쓰는 속도, 전체 처리량 중 무엇을 재는지에 따라 달라집니다. 이 글에서는 TTFT·TPOT·ITL과 처리량을 정의부터 예시·계산 방법까지 차례로 살펴봅니다. 첫 글자는 빨리 나오는데 답변 중간에 멈추는 챗봇을 떠올려보세요. “첫 반응은 빠르다”와 “끝까지 매끄럽게 읽힌다”는 서로 다른 평가입니다. 여기에 여러 사람을 동시에 처리하는 서버의 능력까지 구분하면 성능표가 훨씬 명확해집니다. 다루는 범위는 LLM 추론 서비스의 응답 속도와 처리 능력 입니다. 추론 문제의 정답률은 별도 평가해야 합니다. 모든 그림·GIF의 수치는 교육용 가정이며 특정 모델·GPU의 실측 결과가 아닙니다. 이번 글의 목차와 용어 핵심 용어 정의 한눈에 보기 → 1. 기본 준비 — Token · Tokenizer · ISL · OSL · Prefill · Decode · KV Cache → 2. TTFT — 첫 반응까지의 기다림 → 3. TPOT — 첫 토큰 이후의 평균 속도 → 4. ITL · Chunk · ICL — 스트리밍의 끊김 → 5. Latency(E2E) — 답변 완료까지의 시간 → 6. Throughput · TPS · RPS — 전체 처리 능력 → 7. Concurrency · Request Rate · Batching — 부하 조건 → 8. P50 · P95 · P99 · SLO · Goodput — 느린 경험과 목표 → 9. 그래서 어떻게 재고 계산하나요? → 10. 요약 — 어떤 지표를 먼저 볼까? → Appendix. 캐싱 · 입력 분할 · 양자화 · 추측 디코딩 → 공식 출처와 자료 사용 안내 → 핵심 용어 정의 한눈에 보기 용어 먼저 기억할 정의 TTFT 요청부터 첫 내용 토큰을 받을 때까지의 시간. TPOT 첫 토큰 이후, 출력 토큰당 걸리는 평균 시간. ITL 이어지는 출력 사이의 간격. 제품에 따라 평균 간격을 뜻하기도 합니다. L...

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

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’ r...

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

처음엔 오픈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] 숫자 두 개를 먼저 분리해 보기 아래 표는 실적 표가 아니다. 같은 회사의 성장을 말하는 듯해도, ...

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

스페이스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일 통신주의 큰 하락은 그날의 원시 종가 변화다. 계약 하나가 향후 가입자·이익 감소를 확정했다는 뜻은 아니다. 지금 확정된 것과 아직 아닌 것 뉴스를 읽을 때는 주파...

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

이미지
짧은 답: 보통은 아니다. 클라우드 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를 보관해 다음 계산에서 다시 쓰는 ...

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

이미지
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 요청을 처리합니다. 브라우저에서 페이지가 열려도 클라이언트의 저장소·경로 접근까...

VirtualBox 화면 크기 자동 조절 안 될 때, Guest Additions부터 VMSVGA까지

창을 넓혔는데 우분투 화면은 그대로이고, 가장자리에는 빈 공간이나 스크롤바만 남는 경우가 있다. 처음에는 모니터 해상도 문제처럼 보이지만, VirtualBox에서는 호스트 창의 크기와 게스트 운영체제의 해상도가 별개의 값이다. 이럴 때는 창을 계속 끌어 보기보다 화면 자동 조절 상태, Guest Additions, 그래픽 컨트롤러를 차례로 확인하는 편이 빠르다. 대상은 VirtualBox 7.2 계열과 Ubuntu 24.04 LTS Desktop 64-bit(amd64) 게스트, x86_64 호스트 다. 실제 VM 테스트 없이 공식 문서로 정리한 점검 순서이며, 아래 진단 명령도 실행하지 않았다. 이전 Tech(KR) 글: 세미파이브·모빌린트 로봇 AI 칩, LPDDR6·UCIe가 양산은 아닌 이유 핵심 요약 Auto-resize Guest Display 는 호스트 창을 키울 때 게스트 해상도도 바꾸는 기능이다. 단순 확대와는 다르다. Oracle 문서상 Windows·Linux·Oracle Solaris 게스트는 Guest Additions가 설치되어 있고 자동 조절을 지원하면 창 크기에 맞춰 게스트 해상도가 바뀐다. Linux 게스트의 기본 그래픽 컨트롤러는 VMSVGA 이고, Windows 7 이후 새 VM의 기본값은 VBoxSVGA 다. 게스트 종류와 맞지 않는 설정부터 의심한다. Scale Factor는 화면을 크게 보이게 할 수 있지만 게스트의 실제 해상도를 바꾸는 진단과는 다르다. Guest Additions와 호스트 VirtualBox의 버전이 다르면 곧바로 고장이라고 단정할 수는 없지만, Oracle은 최선의 결과를 위해 같은 버전을 권장한다. 먼저 구분할 것: 호스트 창, 게스트 해상도, 화면 확대 호스트 는 VirtualBox가 설치되어 VM 창을 띄우는 실제 PC의 운영체제다. 게스트 는 그 창 안에서 실행되는 운영체제다. 창을 키우는 동작은 호스트에서 일어나지만, 글자와 바탕화면의 실제 픽셀...