AI 답변 한 줄이 데이터센터를 통과하는 15단계

AI 서비스에 질문을 보내면 화면에는 글자가 한 토큰씩 나타나요. 그 짧은 시간에 요청은 인증과 라우팅을 거쳐 GPU에 배치되고, GPU 메모리와 서버 간 연결망을 통과해요. 답변 속도와 비용은 모델 크기만으로 정해지지 않아요. 캐시 적중률, 메모리 대역폭, 배치 방식, 네트워크 혼잡까지 함께 작용해요. 1
핵심 요약
| 구분 | 실제로 일어나는 일 | 서비스 운영에서 볼 지점 |
| 요청 진입 | 토큰화, 인증, 과금 등급 확인, 부하 분산을 거쳐요 | 요청 제한과 캐시 친화적 라우팅이 초기 비용을 바꿔요 |
| 프리필 | 입력 토큰을 병렬로 읽고 KV 캐시를 만들어요 | 입력 길이와 연산량이 첫 토큰 대기시간에 영향을 줘요 |
| 디코드 | 이전 결과를 참고해 다음 토큰을 하나씩 만들어요 | HBM 대역폭과 출력 토큰 수가 속도와 비용을 좌우해요 |
| 서버 연결 | GPU, NVLink, 스위치, NIC가 중간 결과를 주고받아요 | 큰 모델일수록 서버 내부와 랙 사이 통신이 중요해요 |
| 응답 완료 | 토큰을 텍스트로 바꾸고 스트리밍한 뒤 사용량을 정산해요 | 평균값보다 p99 지연시간과 실패율을 함께 봐야 해요 |
1. AI 답변은 GPU 한 번 호출로 끝나지 않아요
사용자가 보낸 문장은 먼저 토크나이저를 거쳐 정수 ID의 배열로 바뀌어요. API 게이트웨이는 요청 형식과 사용량 한도를 확인해요. 인증 계층은 적용할 요금과 우선순위를 찾고, 부하 분산기와 추론 라우터는 어느 모델과 복제본에서 실행할지 정해요. 같은 시스템 지시문이나 문서 접두사가 이미 처리된 복제본을 고르면 기존 KV 캐시를 다시 쓸 수 있어요. 단순한 라운드로빈보다 요청의 내용과 캐시 상태를 아는 라우팅이 유리한 이유예요. 2
프리필과 디코드는 서로 다른 문제예요
프리필은 입력 문장을 한꺼번에 읽는 단계예요. 긴 문서나 대화 기록을 병렬로 처리해 각 토큰의 Key와 Value를 KV 캐시에 저장해요. 행렬 연산이 많아서 GPU 계산 성능과 최초 토큰 시간인 TTFT가 중요해요.
디코드는 답변 토큰을 하나씩 만드는 단계예요. 새 토큰을 만들 때마다 모델 가중치와 커진 KV 캐시를 HBM에서 읽어요. 계산 장치가 빨라도 메모리에서 데이터를 가져오지 못하면 기다리는 시간이 늘어요. 그래서 출력 속도는 연산량보다 HBM 대역폭에 묶이는 경우가 많아요.
이 차이를 알면 최적화 기술도 구분해서 볼 수 있어요. 지속 배치는 끝난 요청을 빼고 새 요청을 즉시 넣어 GPU의 빈 시간을 줄여요. PagedAttention은 KV 캐시를 고정 크기 페이지로 나눠 메모리 낭비를 줄여요. 양자화는 가중치가 차지하는 바이트를 줄이고, 추측 디코딩은 작은 모델이 제안한 여러 토큰을 큰 모델이 한 번에 검증해요. 모두 속도를 높이지만 겨냥하는 병목은 달라요.
캐시는 비용 할인 기능이 아니라 시스템 설계예요
반복되는 긴 입력을 매번 프리필하면 같은 계산과 메모리 쓰기가 되풀이돼요. 입력 캐싱은 이미 계산한 접두사의 KV 캐시를 재사용해 이 구간을 건너뛰어요. 원문은 일부 서비스에서 캐시 입력 가격이 일반 입력보다 90% 낮고, 긴 입력의 지연시간도 약 85% 줄 수 있다고 설명해요. 수치는 제공업체와 모델에 따라 달라지지만, 반복 접두사를 안정적으로 유지해야 캐시가 실제로 맞는다는 원리는 같아요. 2
RAG나 코딩 도구를 운영한다면 요청마다 문서 순서와 접두사 형태를 바꾸는 설계부터 살펴볼 필요가 있어요. 내용이 같아도 직렬화 순서가 달라지면 캐시 키가 달라질 수 있어요. 캐시 적중률은 단순한 할인율이 아니라 첫 응답 속도와 GPU 수용량을 함께 바꾸는 운영 지표예요.
큰 모델에서는 네트워크도 추론 과정에 들어와요
모델이 GPU 한 대에 들어가지 않으면 가중치와 연산을 여러 GPU로 나눠요. 각 계층에서 부분 결과를 합치거나 MoE의 전문가로 토큰을 보낼 때 GPU 사이 통신이 발생해요. NVLink와 NVSwitch는 서버 내부의 빠른 통신을 맡고, NIC와 Ethernet 또는 InfiniBand는 랙 사이의 데이터를 옮겨요.
이 구간에서는 링크 하나의 혼잡이 여러 GPU를 함께 기다리게 할 수 있어요. GPU 이용률이 낮다고 해서 GPU 자체만 바꾸면 해결되지 않는 경우가 생겨요. 집합 통신 시간, 네트워크 재전송, 랙 배치, 광학 모듈의 전력까지 확인해야 원인을 좁힐 수 있어요. AI 데이터센터에서 네트워크와 전력이 칩의 부속품이 아니라 독립적인 병목으로 다뤄지는 배경이에요.
서비스 지표는 평균 응답시간 하나로 부족해요
사용자가 체감하는 속도는 첫 글자가 나오기까지 걸린 TTFT와 이후 토큰 생성 속도로 나눠 봐야 해요. 긴 입력에서 첫 응답만 느리다면 프리필이나 캐시를 먼저 확인할 수 있어요. 첫 토큰은 빠른데 문장이 천천히 완성된다면 디코드, HBM 대역폭, 출력 길이가 더 가까운 원인일 수 있어요.
평균값이 괜찮아도 일부 요청이 오래 멈추면 서비스 품질은 나빠져요. p95와 p99 지연시간, 요청 거부율, 캐시 적중률, 입력·출력 토큰 비율을 함께 기록해야 해요. 모델 공급자를 비교할 때도 게시된 100만 토큰 가격만 보면 실제 비용을 놓치기 쉬워요. 캐시 할인, 배치 처리, 출력 비중, 목표 지연시간을 반영한 혼합 비용으로 비교하는 편이 정확해요.
왜 중요한가요
AI 제품의 원가는 모델 API 가격표보다 넓은 곳에서 생겨요. 긴 입력은 프리필 시간과 KV 캐시를 늘리고, 긴 출력은 메모리 대역폭을 더 오래 점유해요. 트래픽이 늘면 지속 배치와 캐시가 GPU 활용률을 바꾸고, 큰 모델에서는 통신 구조가 처리량의 상한을 만들어요. 2 2
개발팀은 모델 품질과 함께 요청 경로를 측정해야 해요. TTFT가 길면 입력 길이와 캐시 적중률을 보고, 출력이 느리면 토큰 생성 속도와 배치 크기를 봐야 해요. 트래픽이 몰릴 때만 느려지면 스케줄러 대기시간과 p99 네트워크 지연을 확인해요. 병목을 단계별로 나누면 무조건 더 큰 GPU를 사거나 더 비싼 모델로 바꾸는 시행착오를 줄일 수 있어요.
참고 자료
- AI 토큰은 데이터센터를 어떻게 여행하는가 — GeekNews
- How an AI Token Travels Through a Data Center — Data Gravity
'IT & AI' 카테고리의 다른 글
| Postgres 19 프로퍼티 그래프, 조인을 MATCH로 읽는 법 (0) | 2026.07.13 |
|---|---|
| AI 에이전트 SaaS, 도구보다 반복 업무를 먼저 골라야 해요 (0) | 2026.07.13 |
| SQLite 타입 오류를 일찍 막는 STRICT 테이블 사용법 (1) | 2026.07.13 |
| AI가 코드를 짜도 배포 책임은 엔지니어에게 남아요 (0) | 2026.07.13 |
| 코딩 에이전트 기록을 한곳에서 찾는 AgentsView, 비용과 변경 파일까지 보여줘요 (0) | 2026.07.13 |