Cornserve — Easy, Fast and Scalable Multimodal AI

강의의 출발점은 vLLM 의 디자인이 가정하는 세계와 multimodal 의 실제 세계의 간극. vLLM 은 “Transformer decoder 한 개” 위에서 PagedAttention · continuous batching 을 깐다. multimodal 은 그 가정을 다 깨뜨린다 — vision encoder, projector, LLM, decoder 가 다른 자원 / 다른 latency / 다른 batching 패턴.

Jeff 가 강조하는 단어는 fission. 핵분열처럼 한 모델을 components 로 쪼개고, 각 component 를 독립적으로 scale. 같은 component 를 여러 application 이 공유. “하나의 거대한 model 을 호스팅한다” 가 아니라 “여러 component 의 mesh 를 호스팅한다” 의 시각 변화.

강의의 끝에 손에 잡혀야 하는 건 3개의 추상(component / application / route)과 1개의 자동 planner(Cornfigurator). 그리고 “언제 fission 이 회수되는가” 의 판단 기준.

2024–25 의 multimodal LLM (LLaVA · Qwen2-VL · GPT-4o · Gemini) 의 공통 패턴 — 입력은 이미지/오디오/텍스트의 혼합, 출력은 텍스트 또는 다시 이미지/오디오. 한 request 가 들어오면 여러 모델이 sequential / parallel 로 돈다.

그리고 이 그림 위에 추가되는 복잡성.

• 모델 컴포넌트의 재사용 — 한 회사가 LLaVA · Qwen2-VL · 두 개의 chat app 을 동시에 서빙. 같은 ViT 인스턴스를 모두에서 공유 가능하다면 GPU 낭비가 없다.
• 입력 양식의 다양성 — text-only request, image+text request, video request, audio request 가 한 endpoint 에 섞여 들어옴. 각 path 가 다른 component 를 거친다.
• 동일 모델 다른 변형 — Qwen2-VL-7B 와 Qwen2-VL-72B 가 같은 ViT 를 쓴다. encoder 는 한 번, LLM 만 분기.
• any-to-any 미래 — 출력이 텍스트만이 아닌 이미지/오디오인 경우. decoder 도 fission 의 한 자리.

multimodal pipeline 의 각 컴포넌트는 다른 hardware 가 가장 효율적. 그래서 fission 의 진짜 가치는 component 마다 적합한 GPU 를 따로 배치할 수 있다는 데서 나온다.

이 표가 보여주는 사실 — 한 GPU type 으로 모든 component 를 서빙하는 건 거의 항상 sub-optimal. ViT 는 L4 면 충분한데 H100 위에 올라가면 H100 이 비어 있는 시간이 생긴다. LLM decode 는 H100 의 HBM bandwidth 가 필요한데 L4 위면 throughput 이 안 나온다. component 별로 적합한 GPU 에 배치하는 게 fission 의 첫 보상.

Cornserve 의 핵심 추상. 사용자는 component 들을 등록하고, application 을 component 들의 그래프로 정의. Cornserve 는 그 그래프를 분산 환경에 배치하고, request 가 들어오면 그래프를 따라 routing 한다.

# pseudo-code — Cornserve component / app 정의
from cornserve import Component, Application

vit_l = Component(
    model="openai/clip-vit-large-patch14",
    gpu="L4",
    replicas=4,
)

qwen_7b = Component(
    model="Qwen/Qwen2-7B-Instruct",
    gpu="H100",
    replicas=2,
    backend="vllm",
)

qwen_72b = Component(
    model="Qwen/Qwen2-72B-Instruct",
    gpu="H100",
    replicas=8,
    backend="vllm",
    tensor_parallel=4,
)

# 같은 vit_l 을 두 app 이 공유
chat_vlm     = Application([vit_l, qwen_7b])
chat_vlm_pro = Application([vit_l, qwen_72b])
doc_qa       = Application([vit_l, qwen_7b])

그리고 fission 이 만들어내는 새로운 비용 — component 사이 통신. ViT 의 출력이 다른 GPU 위 LLM 으로 가야 한다. RDMA / NVLink-Sharp / IB 가 필요. 한 노드 안이면 NVLink, 노드 사이면 IB. 이 통신 비용을 fission 으로 얻는 자원 효율과 trade-off 하는 게 Cornfigurator 의 일이다 (§ 07).

LLM 추론 비용의 큰 부분이 prefill — long prompt 의 attention 을 처음에 계산하는 자리. 같은 prefix (system prompt · few-shot example · 같은 image embedding) 가 여러 request 에 등장하면, KV cache 를 한 번만 계산해 reuse 가능. SGLang 의 RadixAttention 이 이 아이디어를 구현. Cornserve 는 application 단위로 prefix 가 정의되어 application 사이의 cache reuse 가 첫 시민.

• per-application prefix cache: 한 application 의 system prompt 는 모든 request 에 들어감. 첫 request 에서 prefill 한 KV cache 를 다음 request 가 그대로 사용.
• per-image cache: ViT 의 image embedding 이 LLM 의 input prefix 가 됨. 같은 이미지를 두 application 이 다른 질문으로 묻는 경우 — image embedding 의 KV cache 를 공유.
• session continuation: 같은 user 의 multi-turn 대화. 이전 turn 의 KV cache 를 다음 turn 의 prefill 시작점으로.
• cache eviction: GPU 메모리 한정. LRU / TTL 또는 application 별 priority. cold start 비용을 감수하고 evict 하는 결정의 자동화.

request 가 들어오면 Cornserve 는 application 의 component graph 를 따라 각 component 의 적합한 인스턴스로 routing. 단순한 path 같지만, 실제로는 load balancing · cache locality · KV cache 공유의 세 trade-off 가 동시에 작용.

1. load balancing: ViT 인스턴스 4개 중 가장 idle 한 것 — 단순 round-robin 이 baseline.
2. cache locality: 같은 application 의 같은 prefix 가 cache 된 인스턴스가 있다 → 거기로 보냄. cache miss 가 prefill 의 큰 비용.
3. KV cache 공유 가능성: image embedding 의 KV cache 가 같은 LLM 인스턴스에 있으면, 다음 request 가 그곳으로 가야 reuse.
4. queue length: cache locality 를 따져도 그 인스턴스의 queue 가 너무 길면 latency 가 더 들 수 있음. 동적 trade-off.

Cornserve 의 함께 발표된 사이드 프로젝트 — Cornfigurator (arXiv 2512.14098). component 의 자원 요구량과 cluster 의 GPU inventory 를 입력으로 받아, 어떤 component 를 어디에 몇 replica 로 배치할지를 자동으로 푸는 planner.

• 입력: component 별 throughput 모델 (input → latency / GPU mem), application 의 SLO (P95 latency, target QPS), 사용 가능한 GPU pool.
• 최적화 목표: SLO 만족 + 총 GPU 비용 최소.
• 출력: 각 component 의 GPU type, replica 수, collocate 정책 (어떤 component 가 같은 노드에).
• 알고리즘: queueing model 위 ILP 또는 metaheuristic — 정확한 형태는 논문 참조.

그리고 plan 의 dynamic 갱신. traffic 이 갑자기 image-heavy 가 되면 — Cornfigurator 가 ViT replica 를 늘리고 LLM replica 를 줄이는 plan 을 다시 생성. K8s 의 native scaling 위에서 실행. component-level autoscaling 의 자연스러운 형태.

강의에서 자주 묻는 질문 — “vLLM 과 뭐가 다른가”. 답: Cornserve 는 vLLM 의 대체가 아니라 위 layer.

Cornserve 의 자리는 “여러 vLLM 인스턴스 + 여러 ViT 인스턴스를 묶어 한 application 으로 보이게 하는 layer”. backend 는 vLLM/SGLang 그대로 쓰고, 그 위에 graph routing · cache sharing · auto deployment 를 추가.

2026 의 multimodal LLM 은 출력도 multimodal — GPT-4o 의 voice, Gemini 의 native image generation. 입력 fission 은 이미 이해됐지만, 출력 fission 은 새 도전.

• token-level streaming: text 출력은 LLM 의 token 단위. image 출력은 diffusion 의 step 단위, audio 는 vocoder 의 chunk 단위. 같은 framework 안에서 다 표현하려면 — 일반화된 “step” 추상.
• pipelining: text → audio 의 경우, text 가 다 끝나기 전에 audio decoder 가 시작할 수 있음. early streaming.
• quality control loop: 출력이 image 면 별도 verifier 가 평가. agentic 한 자리 — 강의에서 future work 로.
• edge inference: encoder 는 device 위, LLM 은 cloud 위 — fission 이 cloud-edge 분할에도 자연스럽게.

Cornserve 의 디자인이 이 미래에 잘 맞는 이유 — component graph 가 임의 위상이라 출력 component 도 “또 다른 노드” 일 뿐. text-only LLM 은 한 path, multimodal output 은 다른 path. 같은 application 추상.

실습 시퀀스

1. Cornserve K8s 셋업 — repo 의 single-command install. minikube 또는 작은 cluster 위에 띄우고 health check.
2. LLaVA application 정의 — ViT-L + Qwen2-7B 를 component 로 등록, application graph 로 묶음. 첫 image+text request.
3. component sharing 확인 — 두 application (LLaVA-7B / LLaVA-13B) 이 같은 ViT-L 을 공유하도록. GPU 메모리 사용량 측정.
4. cache hit 측정 — 같은 이미지에 다른 질문 두 번. 두 번째 request 의 latency 가 처음의 절반 이하인지 확인.
5. Cornfigurator dry-run — 가상의 cluster + application 으로 plan 생성. 사람이 손으로 짠 plan 과 비교.

• transcript 가 실패해서 본 노트의 코드 예시는 repo README 패턴 + 일반적 multimodal serving 도메인 지식의 결합. 실제 API 형태는 repo 의 example 파일 참조.
• Cornfigurator 의 정확한 알고리즘 — ILP vs simulated annealing vs RL. arXiv 논문에서 직접 확인 필요.
• throughput 비교 숫자 — vLLM 직접 사용 대비 Cornserve 의 이득이 몇 배인지의 구체적 비율은 강의 영상에 등장했을 가능성 (확인 필요).
• 실제 사용 사례 — repo 의 v0.1.0 시점에서 production 에서 채택한 곳이 있는지 미확인.
• any-to-any 의 현재 지원 범위 — image 출력 / audio 출력의 v0.1.0 지원 여부 확인 필요.
• fault tolerance — component 한 개가 죽었을 때 graph 의 다른 path 로 우회하는 mechanism 이 어떻게 구현됐는지.