안녕하세요, Shrijith Venkatramana입니다. 저는 모든 커밋에서 실행되는 AI 코드 리뷰어인 git-lrc를 만들고 있습니다. 개발자들이 이 프로젝트를 발견할 수 있도록 Star Us를 눌러주세요. 꼭 사용해 보시고 제품 개선을 위한 피드백을 공유해 주세요.

모든 LLM 데모는 빨라 보입니다.

사용자가 프롬프트(Prompt) 하나를 보냅니다. 모델이 응답합니다. 모두가 행복해합니다.

하지만 프로덕션(Production) 환경은 전혀 다른 세상입니다.

하나의 GPU가 수백 명의 사용자를 서비스합니다. 많은 프롬프트가 동일한 시스템 프롬프트(System Prompt)로 시작합니다. 어떤 사용자는 20개의 토큰(Token)을 생성하지만, 다른 사용자는 20,000개를 생성합니다. 에이전트(Agents)는 여러 추론 경로로 분기됩니다. 메모리(Memory)는 가득 차고, GPU 활용률(Utilization)은 떨어집니다. 비용은 상승합니다.

이것이 바로 SGLang이 해결하고자 하는 문제입니다.

SGLang을 단순히 "또 다른 추론 프레임워크(Inference Framework)"라고 생각하기 쉽지만, 이는 핵심 아이디어를 놓치는 것입니다.

SGLang은 사실 **프로그래밍 언어와 런타임(Runtime)의 공동 설계(Co-design)**입니다. 언어는 LLM 애플리케이션이 어떻게 동작하는지를 기술하며, 런타임은 그 정보를 사용하여 애플리케이션을 훨씬 더 효율적으로 실행합니다.

이것이 왜 중요한지 알아봅시다.

SGLang의 탄생 배경

SGLang은 UC Berkeley, Stanford, 그리고 LMSYS 프로젝트의 연구원들로부터 탄생했습니다. Lianmin Zheng, Ion Stoica, Joseph Gonzalez, Christos Kozyrakis를 포함한 여러 저자들은 수년간 분산 시스템(Distributed Systems), 머신러닝 인프라(Machine Learning Infrastructure), 그리고 고성능 컴퓨팅(High-performance Computing) 분야에서 활동해 왔습니다. ([[Stanford MAST Lab][1])

그들의 관찰은 간단했습니다.

대규모 언어 모델(Large Language Models)은 더 이상 단 하나의 프롬프트에만 답하지 않는다는 것입니다.

현대적인 애플리케이션은 다음과 같은 작업을 수행합니다:

• 다중 LLM 호출 (Multiple LLM calls)
• 분기 로직 (Branching logic)
• 루프 (Loops)
• 검색 (Retrieval)
• 도구 호출 (Tool calls)
• 구조화된 출력 (Structured outputs)

단순한 고객 지원 에이전트(Customer support agent)라 할지라도 최종 답변을 내놓기 전까지 10번 이상의 모델 생성(Generation) 과정을 거칠 수 있습니다.

전통적인 추론 엔진(Inference engines)은 모든 생성을 거의 독립적으로 취급합니다.

반면 SGLang은 전체 워크플로(Workflow)를 하나의 프로그램으로 취급합니다.

이 작은 변화가 모든 것을 바꿉니다.

상위 수준의 직관: CPU 컴파일러처럼 생각하기

C 컴파일러가 다음과 같은 코드를 본다고 가정해 봅시다:

for (int i = 0; i < 1000; i++) {
    sum += a[i];
}

컴파일러는 한 번에 하나의 명령어를 실행하지 않습니다.

컴파일러는 루프(loop) 전체를 최적화합니다.

불필요한 작업을 제거합니다.

메모리 액세스 (memory access)를 개선합니다.

벡터 명령어 (vector instructions)를 사용합니다.

프로그래머는 여전히 단순한 코드를 작성합니다.

컴파일러가 그것을 빠르게 만듭니다.

SGLang은 동일한 아이디어를 LLM 애플리케이션에 적용합니다.

머신 명령어 (machine instructions)를 최적화하는 대신, **언어 생성 프로그램 (language generation programs)**을 최적화합니다.

런타임 (runtime)은 이미 다음 사항들을 알고 있습니다:

• 어떤 프롬프트 (prompts)가 접두사 (prefixes)를 공유하는지
• 어떤 분기 (branches)가 이전 작업을 재사용하는지
• 생성이 어디서 시작되고 멈추는지
• 어떤 출력 (outputs)이 고정된 구조를 갖는지

이러한 추가 정보 덕분에 런타임은 방대한 양의 반복되는 계산을 제거할 수 있습니다.

경제성: 토큰을 재계산하는 것이 왜 비용이 많이 드는가

생성된 모든 토큰은 이전의 모든 토큰에 의존합니다.

이는 모델이 점점 커지는 **KV 캐시 (KV cache)**를 생성한다는 것을 의미합니다.

긴 대화의 경우, 이 캐시는 생성된 텍스트 자체보다 훨씬 더 커집니다.

1,000명의 사용자가 있다고 가정해 봅시다.

각 요청은 정확히 동일한 시스템 프롬프트 (system prompt)로 시작합니다.

System prompt
↓

...

프롬프트에 4,000개의 토큰이 포함되어 있다고 가정해 봅시다.

재사용이 없다면:

1000 users × 4000 tokens

=
...

GPU는 동일한 계산을 천 번 수행합니다.

이는 낭비되는 작업입니다.

공유된 접두사 (shared prefix)를 한 번만 계산하고 재사용한다면, 그 반복되는 계산의 거의 대부분이 사라집니다.

이것이 바로 SGLang이 목표로 하는 워크로드 (workload)의 종류입니다.

컨텍스트 윈도우 (context windows)가 수십만 또는 수백만 토큰으로 계속 커짐에 따라, 추론 (inference)의 비용이 많이 드는 부분이 생성 (generation)에서 프롬프트 처리 (prompt processing)로 이동하기 때문에 접두사 재사용 (prefix reuse)은 훨씬 더 가치 있어집니다. ([ Stanford MAST Lab][1])

RadixAttention: 핵심 기술 아이디어

SGLang 내부의 핵심 혁신은 RadixAttention이라고 불립니다.

이 이름은 **접두사 트리 (prefix tree)**라고도 불리는 **래딕스 트리 (radix tree)**에서 유래되었습니다.

래딕스 트리는 공통된 접두사를 공유함으로써 문자열을 저장합니다.

예를 들어:

apple
application
apply

세 단어 모두 다음을 공유합니다:

appl

접두사(prefix)를 세 번 저장하는 대신, 트리는 이를 한 번만 저장합니다.

SGLang은 동일한 아이디어를 KV 캐시 (KV caches)에도 적용합니다.

많은 프롬프트(prompts)는 동일한 텍스트로 시작합니다:

System Prompt
↓

...

사용자의 질문만 달라질 뿐입니다.

세 개의 독립적인 KV 캐시 (KV caches)를 생성하는 대신:

Prompt A
Prompt B
Prompt C

런타임(runtime)은 하나의 공유된 접두사(prefix)를 저장하고 모든 요청이 이를 참조할 수 있게 합니다.

그 결과는 다음과 같습니다:

• GPU 메모리 감소
• 반복 계산 감소
• 처리량 (throughput) 향상
• 지연 시간 (latency) 감소

이것이 RadixAttention이 특히 다음과 같은 분야에서 유용해지는 이유입니다:

• 채팅 애플리케이션 (chat applications)
• 코딩 어시스턴트 (coding assistants)
• 검색 시스템 (retrieval systems)
• 에이전트 프레임워크 (agent frameworks)
• 퓨샷 프롬프팅 (few-shot prompting)

API 호출 체이닝 대신 LLM 애플리케이션 프로그래밍하기

오늘날 많은 LLM 애플리케이션은 다음과 같은 형태를 띱니다:

response1 = llm(...)
response2 = llm(...)
response3 = llm(...)

애플리케이션 로직은 Python에서 실행됩니다.

추론 엔진 (inference engine)은 오직 고립된 요청들만 보게 됩니다.

SGLang은 생성을 기술하는 더 높은 수준의 방식을 도입합니다.

프로그램은 다음과 같은 것들을 포함할 수 있습니다:

• 변수 (variables)
• 루프 (loops)
• 분기 (branches)
• 구조화된 생성 (structured generation)
• 도구 호출 (tool calls)

개념적으로는 다음과 같습니다:

요약 생성

만약 신뢰도가 낮다면:
...

수많은 단절된 API 호출 대신, 런타임 (runtime)은 하나의 완전한 생성 프로그램 (generation program)을 보게 됩니다.

이러한 가시성 덕분에 런타임은 요청을 더 잘 스케줄링하고, 캐시된 접두사 (cached prefixes)를 재사용하며, 작업을 더 효과적으로 배치(batch)하고, 불필요한 메모리 이동을 피할 수 있습니다.

이 결과는 어셈블리 언어에서 현대적 컴파일러로의 진화와 유사합니다.

개발자는 의도(intent)를 기술합니다.

런타임은 최적화(optimization)를 수행합니다.

이것이 차세대 AI 시스템에 중요한 이유

LLM 소프트웨어의 1세대는 모델 품질에 집중했습니다.

2세대는 **시스템 엔지니어링 (systems engineering)**에 집중합니다.

프런티어 모델 (frontier model)은 GPU당 수만 달러의 비용이 들 수 있습니다.

대규모 배포는 수천 개의 GPU를 지속적으로 가동할 수 있습니다.

활용도(utilization)를 아주 조금만 높여도 매년 수백만 달러를 절약할 수 있습니다.

이것이 추론 (inference)이 주요 연구 분야가 된 이유입니다.

최근 연구에는 다음이 포함됩니다:

• 연속 배치 (continuous batching)
• 추측적 디코딩 (speculative decoding)
• 페이지드 어텐션 (paged attention)
• 접두사 캐싱 (prefix caching)
• 양자화 (quantization)
• 전문가 병렬화 (expert parallelism)

SGLang은 이러한 아이디어 중 다수를 하나의 프로덕션 런타임 (production runtime)으로 결합하는 동시에, 단순한 HTTP API보다 더 많은 최적화 기회를 제공하는 프로그래밍 모델을 제공합니다. 오늘날 SGLang은 수십만 개의 GPU에 걸친 프로덕션 배포를 지원하며 매일 수조 개의 토큰을 생성합니다. ([SGLang Documentation][2])

마치며

수년 동안 더 빠른 소프트웨어는 더 나은 컴파일러 (compiler)를 통해 탄생했습니다.

SGLang은 동일한 철학을 LLM 애플리케이션에 적용합니다.

모든 프롬프트 (prompt)를 고립된 요청으로 취급하는 대신, 전체 워크플로 (workflow)를 분석 및 최적화할 수 있는 하나의 프로그램으로 취급합니다.

이러한 변화는 작게 들릴 수 있습니다.

하지만 대규모 프로덕션 시스템에서 이는 메모리 사용량, 처리량 (throughput), 지연 시간 (latency), 그리고 궁극적으로 비용을 변화시킵니다.

AI 시스템이 더욱 에이전트화 (agentic)되고 롱 컨텍스트 (long-context) 모델이 보편화됨에 따라, 이러한 방식의 런타임 최적화는 모델의 품질 자체만큼이나 중요해질 것입니다.

개발자들을 위한 질문: LLM 인프라의 미래가 범용 서빙 엔진 (general-purpose serving engines)의 것이 될 것이라고 생각하십니까, 아니면 SGLang과 같은 특화된 시스템이 프로덕션 AI의 표준이 될 것이라고 생각하십니까?

*AI 에이전트는 코드를 빠르게 작성합니다. 하지만 당신에게 알리지 않고 조용히 로직을 제거하거나, 동작을 변경하고, 버그를 유발하기도 합니다. 이는 종종 프로덕션 환경에서 발견되곤 합니다.

git-lrc가 이를 해결합니다. git 커밋에 연결되어 모든 차이점 (diff)이 반영되기 전에 검토합니다. 60초면 설정이 완료됩니다. 완전히 무료입니다.*

모든 피드백과 기여자를 환영합니다! 온라인에서 확인 가능하며, 소스 공개(source-available) 상태로 누구나 사용할 준비가 되어 있습니다.

GitHub logo HexmosTech / git-lrc

Git 커밋에서 실행되는 무료 마이크로 AI 코드 리뷰

| 🇩🇰 Dansk | 🇪🇸 Español | 🇮🇷 Farsi | 🇫🇮 Suomi | 🇯🇵 日本語 | 🇳🇴 Norsk | 🇵🇹 Português | 🇷🇺 Русский | 🇦🇱 Shqip | 🇨🇳 中文 | 🇮🇳 हिन्दी |

git-lrc

커밋에서 실행되는 무료 마이크로 AI 코드 리뷰

Go Report Card

gitleaks.yml

osv-scanner.yml

govulncheck.yml

semgrep.yml

dependabot-enabled

오늘날의 GenAI (생성형 AI)는 브레이크 없는 레이싱 카와 같습니다. 매우 빠르게 가속합니다. 무언가를 설명하기만 하면 거대한 코드 블록이 즉시 나타납니다. 하지만 AI 에이전트는 사용자에게 알리지도 않은 채 조용히 문제를 일으킵니다. 논리를 제거하고, 제약 조건을 완화하며, 비용이 많이 드는 클라우드 호출을 도입하고, 자격 증명 (Credentials)을 유출하며, 동작을 변경합니다. 여러분은 대개 운영 환경 (Production)에 도달해서야 이 사실을 알게 됩니다.

git-lrc는 여러분의 브레이크 시스템입니다. 이 도구는 git commit에 연결되어, 변경 사항 (Diff)이 반영되기 전에 모든 차이점에 대해 AI 리뷰를 실행합니다. 설정에는 60초가 소요됩니다. 완전히 무료입니다.

요약하자면, git-lrc는 장애, 보안 침해, 그리고 기술 부채 (Technical Debt)가 발생하기 전에 이를 방지하도록 돕습니다.