cloudflare2026년 8월 3일

더 작고, 더 빠르고, 더 안전하게: Kimi와 GLM을 대규모로 실행하기 (새 탭에서 열림)

Cloudflare는 대규모·장문 컨텍스트 MoE 모델인 Kimi와 GLM을 GPU 메모리에 효율적으로 탑재하기 위해 KV 캐시 양자화, 모델 가중치 압축, 공유 캐시 무결성 검사를 적용했다. FP8 KV 캐시와 INT4 가중치는 정확도를 거의 유지하면서 동시 처리량과 비용을 개선하며, 캐시 무결성 검사는 1% 미만의 오버헤드로 데이터 오염 위험을 줄인다. 특히 프리필과 디코드 단계를 분리해 각 단계에 가장 적합한 정밀도를 선택한 것이 핵심이다. ## 장문 컨텍스트의 메모리 병목 - 모델 추론에서 GPU 메모리는 크게 두 부분이 사용된다. - 모델 가중치 - 이전 토큰의 어텐션 Key·Value를 저장하는 KV 캐시 - 장문 컨텍스트 모델에서는 가중치보다 KV 캐시가 먼저 메모리를 가득 채우는 경우가 많다. - Cloudflare는 모든 실험과 운영 트래픽에 오픈소스 추론 프레임워크 SGLang을 사용한다. - 프리필(prefill)은 입력 전체를 처리하는 단계이고, 디코드(decode)는 토큰을 하나씩 생성하는 단계다. - 프리필: 주로 연산량에 제한됨 - 디코드: 메모리 용량과 메모리 대역폭에 제한됨 ## FP8 기반 KV 캐시 양자화 - 기본 BF16 형식의 KV 캐시를 FP8(e4m3)로 저장해 캐시 크기를 절반으로 줄였다. - Kimi K2.6에서는 GPU에 저장 가능한 컨텍스트가 약 68만 6천 토큰에서 137만 토큰으로 증가했다. - 단일 동시 요청에서는 FP8 변환 비용 때문에 BF16보다 토큰 처리 속도가 몇 퍼센트 느리다. - 그러나 더 많은 요청을 동시에 수용할 수 있다. - BF16: 동시 요청 32개에서 메모리 부족 - FP8: 동시 요청 64개까지 처리 - 최대 처리량: 약 41% 증가 - 토큰당 비용: 약 30% 감소 - 프리필은 메모리보다 연산이 병목이므로 BF16을 유지하고, 디코드에만 FP8을 적용한다. - 평가 결과 FP8과 BF16의 성능 차이는 사실상 구분하기 어려웠다. - GSM8K, ARC, MMLU 등 주요 벤치마크에서 점수 차이가 미미함 - 도구 호출 유효성도 BF16 92.2%, FP8 92.6%로 유사 ## INT4 기반 모델 가중치 압축 - GLM 5.2의 가중치를 FP8에서 INT4로 줄였다. - 모델 체크포인트 크기: - 705GB → 421GB - 약 40% 감소 - 8-way 텐서 병렬 구성에서 GPU당 가중치 메모리: - 약 88GB → 52GB - 확보된 공간으로 동일한 하드웨어에서 약 118만 토큰의 KV 캐시를 수용할 수 있다. - 디코드에서는 매 토큰 생성 시 가중치를 GPU 메모리에서 읽어야 하므로, 가중치가 작을수록 메모리 대역폭 부담이 줄어든다. - INT4 디코드 성능 개선: - 동시 요청 1개: 60 → 92 tok/s, 55% 향상 - 동시 요청 8개: 21% 향상 - 동시 요청 32개: 27% 향상 - 반면 프리필에서는 INT4 가중치를 연산 전에 확장해야 하므로 느려진다. - FP8: 약 10,160 tok/s - INT4: 약 8,660 tok/s - 따라서 디코드는 INT4, 프리필은 FP8로 실행하는 방식이 가장 효율적이다. - 벤치마크 전반에서 INT4와 FP8의 정확도 차이는 0.8점 이내로, 실질적인 품질 저하가 관찰되지 않았다. ## 공유 KV 캐시 무결성 검사 - 캐시 압축으로 더 많은 요청이 같은 GPU와 물리적 KV 캐시 페이지를 공유하게 되면서, 페이지 재사용 오류의 위험도 커진다. - Cloudflare는 각 물리적 캐시 페이지에 재할당 때마다 바뀌는 태그를 부여했다. - 요청마다 사용할 페이지와 태그 정보를 기록하고, 디코드 전에 실제 매핑과 일치하는지 검사한다. - 불일치가 발생하면 잘못된 캐시 데이터를 반환하지 않고 해당 요청을 중단한다. - 검사는 어텐션 커널에 직접 삽입하지 않고 별도의 배치 검사로 실행해 GPU 스레드 간 경쟁 상태를 피했다. - 측정 결과 오버헤드는 매우 작았다. - 처리량 감소: 약 0.38~0.79% - p95 지연시간 증가: 약 0.42~0.80% - 기능이 필요 없는 배포 환경에서는 기본 no-op 추적기를 사용해 측정 가능한 오버헤드가 없다. ## 향후 방향 - 더 많은 모델과 배포 환경에 FP8 KV 캐시를 확대할 예정이다. - NVIDIA Blackwell GPU에서 NVFP4 가중치를 검증하고 있다. - KV 캐시 무결성 검사를 거의 비용 없이 모든 환경에서 활성화하는 것을 목표로 한다. - 이러한 최적화는 정확도를 유지하면서 더 많은 고객에게 낮은 비용으로 모델을 제공하기 위한 기반이다. 실용적으로는 추론 단계를 하나의 설정으로 처리하기보다, 프리필과 디코드의 병목이 다르다는 점을 반영해 정밀도를 분리하는 것이 중요하다. 디코드에는 FP8 KV 캐시와 INT4 가중치를, 프리필에는 BF16 KV 캐시와 FP8 가중치를 선택하는 방식이 대표적인 최적화 전략이다.

gpu-inferencemixture-of-expertskv-cachecontinuous-batching+4

netflix2026년 7월 17일

넷플릭스의 사내 LLM 서빙 (새 탭에서 열림)

Netflix는 LLM을 별도 ML 시스템이 아니라 기존 JVM 기반 서빙 플랫폼과 GPU 추론 백엔드 안에서 운영한다. 엔진으로는 vLLM을 선택하고, Triton·OpenAI 호환 API·통합 배포 제어 plane을 결합해 연구에서 운영까지의 전환 비용을 낮췄다. 다만 운영 환경에서는 엔진 버전 불일치, 커스텀 모델 처리, JSON 제약 누락, 모델 버전과 입력 스키마 변경 간 조정 문제가 주요 리스크로 드러났다. ## Netflix의 통합 추론 아키텍처 - 통합 JVM 서빙 시스템이 라우팅, A/B 테스트, 후보 생성, feature 조회, 추론, 후처리, 로깅을 end-to-end로 처리한다. - 실시간 요청과 캐시된 배치 경로를 모두 지원한다. - 호출 방식은 다음 두 가지다. - 기존 서빙 시스템을 통한 gRPC - 최신 LLM 애플리케이션을 위한 직접 HTTP - 소형 CPU 모델은 원격 호출 비용을 피하기 위해 서빙 프로세스 내부에서 실행한다. - 대형 GPU 모델은 Model Scoring Service(MSS)로 추론을 위임한다. - MSS는 XGBoost, TensorFlow, PyTorch, LLM을 동일한 인터페이스로 제공하며, 내부 GPU 실행은 NVIDIA Triton Inference Server가 담당한다. - Java 기반 control plane은 모델 배포, 버전 관리, 상태 점검, 자동 확장, 멀티리전 롤아웃과 무중단 업그레이드를 관리한다. ## vLLM을 표준 추론 엔진으로 선택 Netflix는 원래 Triton과 통합된 TensorRT-LLM을 사용했지만, 2025년경 워크로드 변화에 맞춰 재평가했다. - 임베딩 생성, prefill-only 추론, autoregressive decoding, 복잡한 제약 로직이 필요한 커스텀 모델까지 지원해야 했다. - vLLM을 선택한 이유: - 별도의 다단계 컴파일 없이 커스텀 모델 아키텍처 로딩 가능 - 커스텀 디코딩 로직을 위한 확장 지점 제공 - 컴파일 중심 엔진보다 장애와 중간 상태를 디버깅하기 쉬움 - 연구자들이 이미 익숙하게 사용해 연구-운영 전환 비용이 낮음 - 전문화된 엔진과 오픈소스 엔진 간 성능 격차가 줄어든 점도 선택에 영향을 주었다. ## Triton과 vLLM의 패키징 방식 Triton에서 vLLM 모델을 패키징하는 방식은 유지보수성과 프론트엔드 변경의 결합도에 큰 영향을 준다. - **Python backend** - 패키징 시 입력·출력 tensor 스펙을 직접 정의한다. - 프론트엔드의 요청 생성 방식이 바뀌면 패키징 코드도 함께 수정해야 한다. - 변경이 맞물리지 않으면 런타임 요청이 실패한다. - 전처리, 후처리, 앙상블, 커스텀 토크나이징 등 비표준 로직이 필요한 모델에는 적합하다. - **vLLM backend** - 모델 가중치와 tokenizer 경로를 담은 JSON 설정만 제공한다. - Triton이 배포 시점에 I/O tensor 스펙을 동적으로 생성한다. - 모델 아티팩트와 프론트엔드를 독립적으로 발전시킬 수 있어 기본 선택으로 적합하다. ### 운영에서 드러난 패키징 문제 - Triton의 vLLM backend는 특정 vLLM API에 맞춰 컴파일된다. - 예를 들어 Triton 25.09가 vLLM 0.11.2에서 제거된 `vllm.engine.metrics`를 import하면 backend 자체가 로드되지 않는다. - 따라서 서비스 이미지 생성 시 Triton과 vLLM 호환 버전을 고정해야 한다. - 모델 작성자가 패키징 단계에서 vLLM 버전을 임의로 덮어쓰지 못하도록 제한할 필요가 있다. - 표준 HuggingFace 모델이 아닌 커스텀 실행 흐름은 여전히 Python backend를 사용해야 한다. ## OpenAI 호환 HTTP API Netflix는 LLM을 기존 모델과 다른 “특수 모델”로 취급하지 않기 위해 모든 모델을 동일한 gRPC 호출 체계로 제공한다. - 기존 클라이언트 라이브러리, 상태 점검, 배포 파이프라인을 LLM에도 재사용한다. - 동시에 생태계 표준이 된 OpenAI 호환 API를 추가 HTTP 프론트엔드로 제공한다. - 호스팅 모델에서 자체 파인튜닝 모델로 전환할 때 API를 그대로 유지할 수 있다. - 이에 따라 품질, 지연시간, 비용, 데이터 프라이버시를 이유로 자체 호스팅을 선택해도 애플리케이션 코드 변경이 거의 없다. ## Triton 프론트엔드와 JSON 출력 제약 구현에는 NVIDIA의 Triton OpenAI 호환 프론트엔드를 활용했다. - 내장 Triton 서버가 실행된다. - `TritonLLMEngine`이 HTTP 요청 스키마를 Triton 추론 요청으로 변환한다. - FastAPI를 통해 응답을 제공한다. - KServe HTTP/gRPC 프론트엔드도 활성화해 Java control plane이 동일한 Triton 인스턴스에 gRPC로 접근할 수 있다. - 운영 중 `response_format`이 스키마에서는 허용되지만 vLLM까지 전달되지 않는 문제가 발견됐다. - 그 결과 JSON 응답을 요청해도 guided decoding이 적용되지 않아 잘못된 JSON이 반환될 수 있었다. - Netflix는 프론트엔드를 git subtree로 가져와 `response_format`을 vLLM의 guided decoding 파라미터로 변환하도록 직접 패치했다. ## 무중단 배포와 스키마 변경 문제 GPU 모델은 CPU 서비스보다 기동 시간이 길고, 모델 버전 사이에 I/O 스키마가 달라질 수 있어 배포 시 추가 조정이 필요하다. ### Red-Black 배포 - 새 버전을 기존 버전과 동시에 실행한다. - 새 인스턴스가 health check를 통과하면 트래픽을 단계적으로 이동한다. - 새 버전이 확장되는 속도만큼 기존 버전을 축소한다. - 중간 단계에서 실패하면 원자적으로 롤백한다. - 모델 인터페이스가 안정적인 경우 적합하다. - 하지만 입력 tensor 차원 추가처럼 I/O 스키마가 바뀌면 문제가 생긴다. - upstream 소비자는 새 모델이 완전히 배포되기 전까지 설정을 바꿀 수 없다. - 마이그레이션 중 새 모델에 이전 형식 요청이 전달된다. - 결과적으로 요청이 실패한다. 제공된 글은 Red-Black 방식의 한계와 `Versioned` 배포 전략을 설명하기 시작한 지점에서 끝나므로, Versioned 전략의 구체적인 동작과 장단점은 확인할 수 없다. 실무적으로는 vLLM을 표준 경로로 삼되, Triton·vLLM 버전을 강하게 고정하고 Python backend라는 예외 경로를 유지하는 것이 현실적이다. 또한 OpenAI 호환 API를 도입할 때는 스키마가 실제 추론 엔진의 제약 기능까지 전달되는지 검증하고, 모델 배포와 입력 스키마 변경을 독립적으로 조정할 수 있는 버전 관리 전략을 마련해야 한다.

gpu-inferencegrpcvllmfastapi+4

gitlab2026년 5월 21일

GitLab Duo Agent Platform Self-Hosted를 위한 더 많은 AI 모델 (새 탭에서 열림)

GitLab 19.0은 GitLab Duo Agent Platform Self-Hosted에서 사용할 수 있는 오픈소스 AI 모델을 확대해, 에어갭·규제 환경에서도 더 강력한 에이전트 기능을 제공한다. 기업은 데이터와 소스 코드를 외부 API로 전송하지 않고도 작업 유형과 인프라에 맞는 모델을 선택할 수 있으며, 필요하면 GitLab 관리형 모델과 자체 호스팅 모델을 혼합할 수도 있다. ## 규제·에어갭 환경의 AI 제약 - 데이터 레지던시, 네트워크 격리, 규제 준수 때문에 소스 코드를 외부 클라우드 API로 보낼 수 없는 조직이 대상이다. - 완전한 에어갭 환경에서는 인터넷과 외부 API를 사용할 수 없으므로, 자체 인프라에서 실행하는 오픈소스 모델이 사실상 유일한 선택지다. - 기존에는 이런 환경이 최신 AI 기능 도입에서 뒤처지거나, 모든 작업에 하나의 모델만 사용해야 하는 문제가 있었다. ## GitLab 19.0의 오픈소스 모델 확대 GitLab은 Duo Agent Platform의 실제 에이전트 작업에 필요한 다음 기준을 바탕으로 모델을 평가했다. - 여러 단계의 도구 호출 및 작업 수행 - 지시사항 준수 - 코드 생성 품질 - 대규모 diff와 여러 파일로 구성된 코드베이스에 대한 추론 새롭게 지원되는 모델은 다음과 같다. - Mistral Devstral 2 123B - GLM-5.1 - Kimi-K2.6 - MiniMax-M2.7 이를 통해 단순 작업에는 효율적인 모델을, 복잡한 에이전트 작업에는 더 강력한 모델을 선택하는 방식의 운영이 가능해진다. ## 온프레미스 및 가상 인프라 배포 - 권장 방식은 자체 하드웨어에서 vLLM을 사용해 모델을 제공하는 것이다. - 모든 추론이 조직 내부에서 실행되므로 소스 코드와 데이터가 외부로 나가지 않는다. - 전용 GPU를 직접 구매하기 어려운 팀은 GPU가 연결된 프라이빗 클라우드의 가상 머신에서 모델을 실행할 수 있다. - 이 방식은 필요할 때만 GPU 용량을 확보하면서도 데이터 격리 정책을 유지할 수 있다. ## 배포 환경별 모델 선택 - **완전한 에어갭 환경** - 자체 추론 하드웨어에 오픈소스 모델을 배포해야 한다. - 모델별 GPU·하드웨어 요구사항을 사전에 확인해야 한다. - **하이브리드 환경** - 기능별로 자체 호스팅 모델과 GitLab 관리형 모델을 혼합할 수 있다. - AI Gateway 설정을 통해 어떤 기능이 어떤 모델을 사용할지 구성한다. - **온라인 라이선스 환경** - 사용량 기반 모델을 이용할 수 있다. - 자체 호스팅 모델과 GitLab 관리형 모델을 함께 사용하는 구성이 가능하다. ## 이용 조건 - 오프라인 라이선스 고객은 GitLab Duo Agent Platform Self-Hosted 애드온이 필요하다. - 온라인 라이선스 고객은 사용량 기반 모델을 사용할 수 있으며, 자체 호스팅·GitLab 관리형 모델의 하이브리드 구성이 가능하다. ## 실용적인 권장 사항 완전한 네트워크 격리와 데이터 보안이 중요하다면 vLLM 기반의 자체 GPU 인프라에 지원 모델을 배포하는 것이 적합하다. 반면 작업별 성능과 운영 비용을 균형 있게 관리하려면, 민감한 코드는 자체 호스팅 모델로 처리하고 일반 작업이나 고난도 작업은 GitLab 관리형 모델로 분리하는 하이브리드 구성을 검토할 수 있다.

gpu-inferencegitlab-duo-agent-platformvllmself-hosted-ai+3

pinterest2026년 2월 2일

투 타워를 넘어서: 차 (새 탭에서 열림)

전통적인 추천 시스템의 표준인 'Two-Tower' 모델은 효율적이지만, 사용자-아이템 간의 복잡한 상호작용 특징(Interaction features)을 반영하지 못하는 구조적 한계가 있습니다. 이를 해결하기 위해 핀터레스트는 범용 신경망 기반의 복잡한 랭킹 모델을 도입하기로 결정하고, 이를 지원하기 위한 GPU 기반의 서빙 스택 재설계를 단행했습니다. 데이터 전송 병목 현상을 해결하고 비즈니스 로직을 모델 내부에 통합함으로써, 초기 4,000ms에 달하던 지연 시간을 실시간 서비스 가능한 수준인 20ms까지 단축하는 데 성공했습니다. ### Two-Tower 모델의 한계와 새로운 도전 * **표현력의 제약:** Two-Tower 구조는 사용자(User)와 아이템(Item)을 각각 독립적인 벡터로 인코딩한 뒤 마지막에 내적(Dot product)만 수행하므로, 네트워크 깊은 곳에서 두 피처가 결합되는 '교차 피처(Cross-features)'나 '타겟 어텐션(Target attention)'을 활용하기 어렵습니다. * **복잡한 모델 도입의 필요성:** 보다 정교한 추천을 위해 피처 간의 직접적인 상호작용을 모델링할 수 있는 일반적인 딥러닝 아키텍처 도입이 필요해졌습니다. * **서빙 인프라의 한계:** 기존 인프라는 단순한 연산(내적 또는 ANN 검색)에 특화되어 있어, 무거운 GPU 추론 단계를 지연 시간 손실 없이 통합하는 것이 핵심 과제였습니다. ### 인벤토리 세분화를 통한 피처 패칭(Feature Fetching) 최적화 * **데이터 전송 병목:** 수만 개의 후보군에 대해 네트워크를 통해 피처를 가져오는 I/O 작업이 모델 추론보다 더 긴 시간을 소모하는 문제가 발생했습니다. * **고가치 인벤토리(Segment 1):** 매출 기여도가 높은 약 100만 개의 문서는 피처를 PyTorch 모델 파일 내의 'Registered Buffer' 형태로 직접 삽입했습니다. 이를 통해 모델 가중치처럼 GPU의 고대역폭 메모리(HBM)에 피처가 상주하게 되어 네트워크 오버헤드를 완전히 제거했습니다. * **롱테일 인벤토리(Segment 2):** 나머지 10억 개 이상의 문서는 고성능 Key-Value 저장소와 인-호스트 캐시를 조합하여 피처를 가져오도록 이원화했습니다. ### 비즈니스 로직의 모델 내부 통합 * **데이터 전송량 최소화:** 기존에는 GPU에서 계산된 수만 개의 점수를 모두 CPU로 보낸 뒤 필터링했으나, 이는 Device-to-Host(D2H) 전송 병목을 야기했습니다. * **로직 내재화:** 유틸리티 계산(pCTR, pCVR, 입찰가 조합 등), 다양성 규칙, Top-K 정렬 등의 비즈니스 로직을 PyTorch 텐서 연산으로 구현하여 모델 내부에 포함시켰습니다. * **병렬 처리 이점:** 복잡한 필터링과 정렬을 GPU의 대규모 병렬 연산으로 처리함으로써 CPU 기반 처리보다 속도를 높였고, 최종 결과값(약 1,000개)만 출력하여 전송 효율을 극대화했습니다. ### GPU 추론 가속화 및 시스템 최적화 * **멀티 스트림 CUDA:** 단일 스트림 방식에서 벗어나 여러 CUDA 스트림을 사용하여 데이터 전송(H2D, D2H)과 연산(Compute)이 서로 겹쳐서 수행(Overlap)되도록 설계했습니다. * **커널 퓨전(Kernel Fusion):** Triton 커널을 사용하여 선형 레이어와 활성화 함수 같은 반복적인 레이어 패턴을 하나로 합침으로써 메모리 대역폭 압박을 완화했습니다. * **수치 형식 최적화:** FP32 대신 BF16(Brain Floating Point 16) 형식을 채택하여 메모리 사용량을 줄이고 연산 속도를 높였습니다. * **워커 정렬:** 호스트 CPU 코어 수에 맞춰 워커 스레드 수를 조정하고 고정(Pinning)하여 컨텍스트 스위칭과 락 경합을 최소화했습니다. 이러한 재설계는 고성능 추천 시스템을 구축할 때 모델 아키텍처뿐만 아니라, 데이터 흐름과 하드웨어 가속기(GPU)의 특성을 고려한 인프라 최적화가 필수적임을 보여줍니다. 특히 대규모 트래픽 환경에서 GPU를 효율적으로 활용하려면 비즈니스 로직을 포함한 전체 서빙 파이프라인을 모델과 밀접하게 통합하는 전략이 유효합니다.

gpu-inferencemachine-learningrecommendation-systemspytorch+4