Introduction

CKAD: Kubernetes 환경에서 cloud-native application을 효과적으로 설계, 구축, 배포 및 구성할 수 있는 역량을 검증하는 CNCF의 공식 자격증

CKAD curriculum에서 CKAD가 포함하는 내용들을 아래와 같이 확인할 수 있다.

Domain	Weight	Key Points
Application Design and Build	20%	✅ Define, build and modify container images ✅ Choose and use the right workload resource (Deployment, DaemonSet, CronJob, etc.) ✅ Understand multi-container Pod design patterns (e.g. sidecar, init and others) ✅ Utilize persistent and ephemeral volumes
Application Deployment	20%	✅ Use Kubernetes primitives to implement common deployment strategies (e.g. blue/green or canary) ✅ Understand Deployments and how to perform rolling updates ✅ Use the Helm package manager to deploy existing packages ✅ Kustomize
Application Observability and Maintenance	15%	✅ Understand API depreciations ✅ Implement probes and health checks ✅ Use built-in CLI tools to monitor Kubernetes applications ✅ Utilize container logs ✅ Debugging in Kubernetes
Application Environment, Configuration and Security	25%	✅ Discover and use resources that extend Kubernetes (CRD, Operators) ✅ Understand authentication, authorization and admission control ✅ Understand requests, limits, quotas ✅ Define resource requirements ✅ Understand ConfigMaps ✅ Create & consume Secrets ✅ Understand ServiceAccounts ✅ Understand Application Security (SecurityContexts, Capabilities, etc.)
Services and Networking	20%	✅ Demonstrate basic understanding of NetworkPolicies ✅ Provide and troubleshoot access to applications via services ✅ Use Ingress rules to expose applications

Efficient Memory Management for Large Language Model Serving with PagedAttention

Introduction

GPT $_[$$_{5}$$_,$$_{37}$$_]$, PaLM $_[$$_{9}$$_]$과 같은 large language models (LLMs)의 등장으로 programming assistant $_[$$_{6}$$_,$$_{18}$$_]$와 범용적인 chatbot $_[$$_{19}$$_,$$_{35}$$_]$과 같은 새로운 applications로 인해 우리의 일과 일상에 큰 영향을 미치기 시작했다.
다양한 cloud 회사들 $_[$$_{34}$$_,$$_{44}$$_]$이 hosted services로 이러한 applications를 제공하기 위해 경쟁 중이지만, 매우 비싸고 GPU와 같은 hardware 가속기가 매우 많이 필요하다.
최근 추정에 따르면 LLM 요청 처리 비용은 기존 keyword query보다 10$\times$ 더 비쌀 수 있다 $_[$$_{43}$$_]$.
따라서 이러한 높은 비용을 고려했을 때, LLM serving system의 throughput을 높이고 요청당 비용을 줄이는 것이 더욱 중요해지고 있다.

LLM의 core에는 autoregressive Transformer model $_[$$_{53}$$_]$이 있고, 이 model은 입력 (prompt)과 지금까지 생성한 출력 tokens의 이전 sequence를 기반으로 한 번에 하나씩 단어들 (tokens)을 생성한다.
매 요청마다 이러한 값비싼 process는 termination token을 출력하기 전까지 반복되며 이러한 순차적 생성 process는 workload를 memory에 집중시켜 GPU의 연산 능력을 충분히 활용하지 못하고 throughput을 제한한다.

pie
    "Parameters (26GB, 65%)" : 65
    "KV Cache (>30%)" : 30
    "Others" : 5

Figure 1. Memory layout when serving an LLM with 13B parameters on NVIDIA A100. The parameters persist in GPU memory throughout serving. The memory for the KV cache is (de)allocated per serving request

Throughput은 다수의 요청을 batching하여 개산할 수 있지만 batch 내에서 다수의 요청을 처리하려면 각 요청을 위한 memory가 효율적으로 관리되어야한다.
예를 들어, Fig. 1은 40GB RAM을 가지는 NVIDIA A100 GPU에서 130억 (13B) parameter
LLM의 memory 분포를 보여준다.
약 65%의 memory가 serving 중 고정적이게 model 가중치로 할당되고, 약 30%의 memory가 요청에 대한 동적인 상태 (dynamic states)를 저장하기 위해 사용될 것이다.
Transformers에서 이러한 상태는 KV cache $_[$$_{41}$$_]$라고 불리는 attention mechanism과 관련된 key와 value tensors로 구성되며, 이는 이전 tokens의 context를 나타내어 순서대로 새 출력 token을 생성한다.
그리고 남아있는 나머지 memory는 LLM을 평가할 때 생성되는 일시적인 tensor인 activation을 포함한 다른 data에서 사용된다.
Model의 가중치는 고정되어있고, activations는 GPU memory의 작은 부분만 차지하므로 KV cache가 관리되는 방식은 최대 batch size를 결정하는데 중요하며 비효율적으로 관리될 경우 KV cache memory는 batch size를 크게 제한하고, 결과적으로 LLM의 throughput을 제한할 수 있다.

Introduction

In the previous article, I explored why vLLM is gaining popularity and the process of setting up an OpenAI-compatible server when using vllm serve.
While the first article focused on the architectural foundations and server initialization process, in this article, I want to dive deeper into the runtime behavior and request processing pipeline.

The /v1/chat/completions endpoint has become the de facto standard for conversational AI applications, powering everything from customer service chatbots to sophisticated AI assistants.
Unlike the legacy /v1/completions endpoint, which operates on simple text completion, the chat completions endpoint provides structured message handling, role-based conversations, and built-in context management.

Through this deep dive, I’ll walk you through:

• Endpoint Comparison: Detailed comparison between /v1/completions and /v1/chat/completions
• Request Processing: Step-by-step breakdown of how chat messages are preprocessed and transformed
• Chat Template System: How vLLM applies model-specific chat templates to structure conversations
• Internal Pipeline: Deep dive into the inference process, from message parsing to response generation
• Performance Considerations: Understanding token efficiency and memory management in chat contexts

By examining vLLM’s implementation of the OpenAI-compatible chat completions endpoint, I’ll uncover the sophisticated engineering that enables high-performance conversational AI serving while maintaining full API compatibility.

Introduction

vLLM $_[$$_{1}$$_,$$_{2}$$_]$ is a fast and easy-to-use library for LLM inference and serving.
Originally developed in the Sky Computing Lab at UC Berkeley, vLLM has evolved into a community-driven project with contributions from both academia and industry. $_[$$_{3}$$_]$

The rapid advancement of Large Language Models (LLMs) has brought efficient model serving and inference optimization to the forefront of MLOps concerns.
In response to these challenges, vLLM has emerged as a leading solution, garnering significant attention with 49.2k stars on GitHub as of June 9, 2025.
As demonstrated in the star history graph below, vLLM has established itself as the most prominent LLM serving framework among various competing solutions.

A particularly noteworthy aspect is the standardized API interface provided by OpenAI’s GPT series.
With countless developers already building applications based on this API specification, ensuring compatibility has become crucial for any LLM serving solution.
This article provides a comprehensive analysis of vLLM’s core technological foundations and examines the internal implementation processes that enable OpenAI-compatible server deployment when executing the vllm serve command.

결제 시스템

결제 (payment) system: 금전적 가치의 이전을 통해 금융 거래를 정산하는 데 사용되는 모든 system

1단계: 문제 이해 및 설계 범위 확정

• 기능 요구사항
  • 대금 수신 (pay-in) 흐름: 결제 system이 판매자를 대신하여 고객으로부터 대금 수령
  • 대금 정산 (pay-out) 흐름: 결제 system이 전 세계의 판매자에게 제품 판매 대금 송금
• 비기능 요구사항
  • 신뢰성 및 내결함성: 결제 실패는 신중하게 처리
  • 내부 service (결제 system, 회계 system)와 외부 service (결제 servcice 제공업체) 간의 조정 process: System 간의 결제 정보가 일치하는지 비동기적으로 확인
• 개략적인 규모 추정
  • 하루에 100만 건의 transaction 처리
  • $1,000,000/10^5=10TPS$
  • 10TPS는 일반적 database로 문제 없이 처리 가능하기 때문에 처리 대역폭 대신 결제 transaction의 정확한 처리에 초점