전체 글39 [LLM] LLM 서빙 프레임워크 4종 비교: vLLM, TensorRT-LLM, SGLang, llama.cpp 이 글은 Chi Wang, Peiheng Hu, 「Hands-On LLM Serving and Optimization: Hosting LLMs at Scale」(O'Reilly Media) 8장 "LLM Serving Frameworks"의 내용을 참고하여 인프라 실무자 관점에서 쉽게 재구성한 글이다.들어가며 — LLM을 서비스에 올리려는데, 뭘 써야 하지?사내 챗봇이든 고객 대상 AI 기능이든, 오픈소스 LLM을 직접 서비스에 올리기로 했다면 가장 먼저 부딪히는 질문이 있다. "vLLM이 유명하다는데, 그냥 이거 쓰면 되는 걸까?"라는 질문이다.결론부터 말하면 vLLM은 무난한 선택지가 맞다. 하지만 상황에 따라 더 나은 선택지가 따로 있다. 이 글에서는 LLM 서빙에 가장 많이 쓰이는 네 가지 프레임.. 2026. 8. 28. [LLM] GPU 인터커넥트 완전정리: PCIe부터 NVSwitch까지 들어가며대규모 언어 모델(LLM)을 서빙하다 보면 GPU 하나로는 부족한 상황을 마주하게 된다. 모델 자체가 너무 커서 GPU 한 장의 메모리에 다 올라가지 않는 경우도 있고, 지연 시간 요구사항을 맞추기 위해 여러 GPU가 동시에 연산을 나눠 처리해야 하는 경우도 있다. 이럴 때 반드시 고려해야 하는 것이 바로 GPU 간 통신, 즉 인터커넥트(interconnect)다.아무리 빠른 GPU를 여러 장 갖추더라도 GPU끼리 데이터를 주고받는 속도가 느리면 전체 시스템 성능은 그 병목에 맞춰 떨어진다. 인터커넥트는 크게 한 서버(노드) 안에서 GPU끼리 연결하는 노드 내부(intra-node) 인터커넥트와, 여러 서버에 걸쳐 GPU를 연결하는 노드 간(inter-node) 인터커넥트로 나뉜다. 이 글에서는 .. 2026. 8. 23. [LLM] LLM 서빙 시스템, 원리부터 직접 만들어보기 들어가며이 글은 "Hands-On LLM Serving and Optimization" 3장을 읽고 정리한 노트다. 저자는 vLLM이나 Triton 같은 특정 프레임워크를 바로 설명하는 대신, "LLM 서빙 시스템이 내부적으로 어떻게 동작하는가"를 원리(first principles)부터 직접 코드로 짚어나가는 방식을 택하는데, 그 흐름이 꽤 설득력 있어서 핵심 내용을 내 나름대로 재구성해봤다. 코드는 책에 실린 예제를 단순화·발췌한 것이라, 정확한 전체 구현이 궁금하면 책이 안내하는 GitHub 저장소를 참고하는 게 좋다.왜 프레임워크부터 배우지 않고 직접 만들어보는가오픈소스 서빙 프레임워크와 상용 솔루션은 이미 수백 개가 나와 있다. 그런데도 책이 굳이 "밑바닥부터 만들기"를 거치는 이유는 단순하다... 2026. 8. 16. [LLM] Hands-On LLM Serving and Optimization Study ch1-2 정리 CloudNet@ 팀 / 가시다님이 주관하는 스터디에 참여하게 되었다.4주간 GitAIOps에 대해 다룬 'AI 시대에 개발자가 알아야 할 인프라 구성·배포 with Claude Code' 교재를 스터디한 내용을 정리한다. 느리고 비싼 LLM, 서빙만 잘해도 달라진다 — LLM 서빙과 최적화 기초 정리ChatGPT처럼 근사한 답변을 만들어내는 LLM도, 막상 서비스에 붙여보면 이야기가 달라진다. 응답은 느리고, GPU 비용 청구서는 매달 놀랍고, 사용자가 몰리는 순간 서버는 버벅인다. 많은 팀이 이 문제를 "더 좋은 모델을 쓰면 해결되겠지"라고 오해하지만, 실제 원인은 대부분 모델이 아니라 서빙 방식에 있다.이 글은 자체 서빙이 정말 필요한지 판단하는 기준과 어떤 아키텍처를 고를지부터 시작해, LLM이 .. 2026. 8. 1. [GitAIOps] ch9. GitAIOps 살아있는 표준의 탄생 CloudNet@ 팀 / 가시다님이 주관하는 스터디에 참여하게 되었다.4주간 GitAIOps에 대해 다룬 'AI 시대에 개발자가 알아야 할 인프라 구성·배포 with Claude Code' 교재를 스터디한 내용을 정리한다. 들어가며지금까지 쌓은 Git을 클로드를 분석하면서 프로젝트를 되돌아보자.1. AI에게 저장소 분석시키기1.1 저장소 구조 분석디렉터리 구조notiflex-platform/├── app/ # Go 애플리케이션│ ├── main.go # 227 lines│ ├── Dockerfile│ ├── go.mod / go.sum├── k8s/│ ├── smb/ # SMB.. 2026. 7. 27. [GitAIOps] ch8. 고도화 CloudNet@ 팀 / 가시다님이 주관하는 스터디에 참여하게 되었다.4주간 GitAIOps에 대해 다룬 'AI 시대에 개발자가 알아야 할 인프라 구성·배포 with Claude Code' 교재를 스터디한 내용을 정리한다.1. 배경 및 아키텍처 결정(Why & What)1.1 해결하고자 하는 문제: 운영 고도화와 자동화API 알림 지연 및 타임아웃서비스 간 호출이 복잡해지면 장애시 발견 어려움일일 통계 집계 및 미발송 알림 재처리 직접 처리하는 번거로움1.2 이벤트 기반의 아키텍처로 전환: Kafka문제 상황현재 Notiflex는 동기 방식이다.notiflex-api Pod은 그 요청 하나를 처리하느라 붙잡혀 있다. 요청이 100개 몰리면 100개가 동시에 각자 처리 완료를 기다리며 서버 리소스를 잡아먹.. 2026. 7. 26. 이전 1 2 3 4 ··· 7 다음
