Modelplane이 추론 엔지니어링 실무 가이드를 공개했다

Modelplane이 추론을 처음 맡는 플랫폼 엔지니어를 위한 실무 가이드를 공개했다. GPU 메모리와 추론 엔진의 기초부터 프로덕션 배포·운영, 도구 선택과 경력 개발까지 다루며, 수치·가격·도구 버전은 2026년 10월 기준이라고 안내한다. 문서는 Modelplane main 브랜치용으로, 최신 릴리스 v0.5와 일치하지 않을 수 있다.

가이드는 자체 호스팅이 필요한 이유로 코드와 내부 데이터를 외부 서비스에 보낼 수 없는 경우, 호스팅 API 비용이 커지는 경우, 지연 시간이나 신뢰성 요구가 공급업체의 한계를 넘어서는 경우를 든다. 다만 제품 초기에는 호스팅 API가 여전히 적절할 수 있다고 설명한다. Hugging Face에는 오픈 모델이 200만 개 넘게 올라와 있으며, 가이드는 DeepSeek R1이 2025년 1월 공개된 뒤 약 한 달 후 수학·코딩 벤치마크에서 OpenAI o1과 맞먹었다는 논문 결과를 사례로 든다. 자체 운영은 지연 시간, 가동 시간, 데이터가 머무는 위치를 직접 관리하게 해주며, 사용량이 많을 때 비용을 약 80% 줄일 수도 있다는 Baseten의 주장을 소개한다. 이는 특정 조건에서의 가능성이지 모든 조직에 적용되는 절감률은 아니다.

플랫폼 엔지니어의 기존 역량은 GPU 배치, 메모리 용량 산정, 캐시를 고려한 라우팅, 대기열과 KV 캐시 사용량에 따른 오토스케일링, 모델·하드웨어·엔진 버전 관리, 사용자 체감 지연 시간 지표, GPU 관측성, 토큰당 비용 계산으로 이어진다. 가이드는 2026년 8월 공개 채용 게시판에서 추론 관련 공고 약 58개를 확인했지만 직무명이 정착되지 않았다고 전한다.

추론의 구성과 메모리

추론 엔진은 모델 가중치를 API로 제공하는 서버다. vLLM이나 SGLang 같은 엔진은 GPU 메모리에 가중치를 올리고, 대화별 상태인 KV 캐시를 유지하며, 요청을 묶어 GPU 작업을 스케줄링한다. 데이터베이스 서버와 비슷한 면이 있지만 작업 집합을 시스템 RAM이 아니라 용량이 작고 비싼 GPU 메모리에 둔다. 추론 스택은 계산을 수행하는 커널, 엔진, 엔진 여러 개를 배포·관리하는 컨트롤 플레인, 모델과 복제본으로 요청을 보내는 게이트웨이의 네 층으로 나뉜다. 요청은 게이트웨이와 엔진을 통과하지만 컨트롤 플레인을 지나지는 않는다.

메모리 용량을 잡을 때는 고정된 가중치와 요청에 따라 커지는 KV 캐시, 런타임 오버헤드를 모두 계산해야 한다. 대부분의 모델은 매개변수당 2바이트(BF16 또는 FP16)로 배포되므로 8B 모델은 GPU 메모리 약 16GB를 차지한다. 48GB L40S에서는 나머지 공간에 KV 캐시와 다른 런타임 사용량이 들어간다. KV 캐시는 동시에 처리하는 대화의 문맥 길이에 따라 커진다. 모델 설정에서 토큰당 캐시 용량을 추산하는 식은 다음과 같다.

KV bytes per token = 2 × layers × KV heads × head dimension × bytes per value

Llama 3 70B를 FP16으로 실행할 때(80개 층, KV 헤드 8개, 헤드 차원 128) 토큰당 약 320KB가 필요하다. 128K 토큰 대화 하나는 캐시 약 40GB를 쓸 수 있어 GPU가 처리할 수 있는 사용자 수를 제한할 수 있다. 전문가 혼합(MoE) 모델은 활성 매개변수 수와 관계없이 모든 가중치를 메모리에 둬야 한다. 전체 320B 매개변수 중 18B만 활성화되는 모델도 FP8에서 약 320GB가 필요할 수 있다. 다만 dtype 표만 보고 파일 크기를 계산하지 말고 실제 체크포인트 크기를 확인해야 한다. Upbound는 한 MoE 모델의 dtype을 바탕으로 약 315GB라고 추정했지만, 전문가 가중치가 4비트 형식으로 저장돼 실제 파일은 177.7GB였다. CUDA 그래프, 활성값, 메모리 단편화도 공간을 차지하므로 시작 시 들어맞는 모델이 며칠 뒤 실제 트래픽에서 메모리 부족을 일으킬 수 있다.

요청 처리에는 입력을 병렬로 읽고 첫 토큰과 KV 캐시를 만드는 프리필(prefill), 토큰을 하나씩 생성하는 디코드(decode) 단계가 있다. 프리필은 주로 계산량에 제한되고, 첫 토큰까지 걸리는 시간(TTFT)을 좌우한다. 디코드는 가중치와 KV 캐시를 메모리에서 읽는 대역폭에 제한되며, 출력 토큰당 시간과 초당 토큰 수에 영향을 준다. 긴 문맥에서는 캐시를 읽는 비용이 가중치를 읽는 비용보다 커질 수도 있다. 따라서 두 단계를 따로 측정해야 한다. 배치를 크게 하면 전체 처리량은 오르지만 개별 사용자의 속도는 떨어진다. 대화형 채팅과 코딩은 지연 시간을, 야간 배치 작업은 처리량을 우선할 수 있으므로 튜닝 전에 작업의 조건을 정해야 한다.

가이드는 사용자에게 실제로 보이는 첫 토큰까지의 시간, 출력 토큰 간 지연, 사용자별 초당 토큰 수, 전체 처리량, 지연 시간 목표를 만족하는 유효 처리량(goodput), 요청 오류·거부, p50·p90·p99 지연 시간, 백만 토큰당 비용을 추적하라고 권한다. 추론 모델은 첫 토큰 전에 숨은 사고 토큰을 생성할 수 있으므로 엔진의 첫 토큰이 아니라 사용자가 보는 첫 토큰을 재야 한다. 요청 길이에 따라 총 응답 시간이 달라지므로 전체 응답 시간만으로 SLO를 정하지 말고, 거부 응답도 오류로 세어 문맥 제한이 성능 향상처럼 보이지 않게 해야 한다. 비용 비교도 실제 운용 부하에서 해야 한다.

Cost per million tokens = GPU cost per hour / (tokens per second × 3600) × 1,000,000

Spheron의 예에서는 시간당 2.90달러 GPU가 초당 1,200토큰을 지속 처리하면 백만 토큰당 비용은 약 0.67달러다. 최적화는 증상에 맞춰 단계적으로 적용한다. 모델이 시작되지 않거나 KV 캐시 공간이 거의 남지 않으면 모델·정밀도·GPU 조합을 다시 고른다. 연속 배칭과 페이지형 KV 캐시는 vLLM·SGLang에서 기본으로 켜져 있는 경우가 많으므로 새로 만들기보다 설정을 확인한다. GPU 계산 여유가 있는데 요청이 대기하면 양자화를 검토하고, 긴 프롬프트를 반복 전송하는 에이전트나 채팅 앱에서는 접두부 캐시 적중률을 살핀다. 부하가 낮은데도 응답 스트리밍이 느리면 추측 디코딩을 고려할 수 있다. 모델이 한 GPU에 들어가지 않을 때 GPU 분할을 계획하고, 두 번째 모델·복제본·클러스터를 추가할 때 게이트웨이와 컨트롤 플레인을 검토한다. 대기열이나 유휴 GPU 비용이 문제면 오토스케일링을, 장문 입력이 대규모로 스트리밍을 막고 RDMA급 네트워크가 있을 때는 프리필과 디코드를 분리하는 방식을 검토한다. 대부분의 팀은 처음부터 모든 기법을 쓸 필요가 없다.

프로덕션 배포와 운영

하드웨어보다 먼저 사용 사례와 통과 기준을 정한다. Upbound의 사례에서 코딩 에이전트는 긴 문맥, 도구 호출 파싱, 스트리밍, 수 시간 지속되는 세션, Claude Code용 Anthropic 호환 API가 필요했다. 채팅은 낮은 첫 토큰 지연과 동시 처리, 기존 도구와의 OpenAI 호환 API를 요구했다. 플랫폼은 실제 호스트 이름의 TLS, 회사 도메인에 연결된 인증, 엔진 상태를 구분할 관측성, 안정적인 GPU 배치가 필요했다. 대화형 작업과 배치 작업은 목표가 다르므로 필요하면 배포도 나눠야 한다.

모델은 공개 벤치마크만 보지 말고 자체 작업으로 평가한다. 작은 모델부터 시작해 운영 경험을 쌓고, 모델이 실제 하드웨어와 엔진 빌드에서 로드되는지 확인한다. 상업적 사용을 제한하는 라이선스가 있는지, 채팅 템플릿과 도구 호출 파서가 맞는지도 점검해야 한다. 잘못된 설정은 HTTP 200 응답을 반환하면서도 도구 호출을 망가뜨릴 수 있다. 요청마다 최대 출력 길이를 설정하고, 최대 문맥 길이를 줄일 때는 그보다 긴 대화가 거부되는 것을 오류로 집계한다. vLLM의 메모리 설정이 무엇을 포함하는지 업그레이드 때마다 확인한다. 실제 부하에서 메모리 부족이 나면 메모리 비율을 조금 낮추고, 확장 가능한 메모리 세그먼트를 켜고, 동시 시퀀스를 제한한 뒤 여유 메모리를 다시 측정하라는 안내도 담겼다.

기법을 여러 개 한꺼번에 적용하면 상호작용을 파악하기 어렵다. 공통 프롬프트와 도구 정의를 먼저, 사용자별 내용을 뒤에 두면 접두부 캐시를 더 활용할 수 있다. 접두부 캐시는 첫 번째로 달라지는 토큰에서 재사용이 멈춘다. 양자화는 선형 가중치, 활성값, KV 캐시 순으로 민감도가 높아지며, 어텐션 층은 작은 오차가 긴 시퀀스에서 누적될 수 있다. FP8은 Ada, Hopper, Blackwell GPU에서 기본 지원된다. 추측 디코딩은 온도, 주제, 초안 모델에 따라 수용률이 달라지며, 예측이 거부되면 계산 낭비가 생긴다. 배치가 커지면 추측에 쓸 계산 여유도 줄어든다. 한 Baseten 엔지니어가 고객 처리량을 두 배로 만든 설정을 찾기까지 77개 구성을 시험한 사례도 소개한다. 한 번에 한 가지를 바꾸고 측정해야 한다. 청크 프리필은 긴 입력을 여러 차례로 나눠 다른 요청의 디코드가 멈추지 않도록 한다. 가이드는 현재 vLLM에서 기본 활성화돼 있으며, 분리 배치를 고려하기 전에 패스당 토큰 예산을 조정하라고 설명한다.

GPU 할당량은 실제 인스턴스 가용성을 보장하지 않는다. 같은 GPU라도 인스턴스 크기마다 별도 용량 풀이 있을 수 있고, 클라우드 API만으로 실제 시작 가능 여부를 알기 어렵다. 원하는 GPU를 항상 확보할 수 있다고 가정하지 말고, 여러 가용 영역과 더 작은 노드에 모델을 나누는 경우를 계획한다. Kubernetes 동적 리소스 할당(DRA) 선택자로 GPU 아키텍처나 최소 메모리를 지정하되, 선언을 되풀이하는 상태 필드가 아니라 GPU 드라이버가 제공하는 정보로 배치를 확인한다. 클라우드 인스턴스와 노드 합류 상태도 컨트롤러 상태와 별도로 살핀다. H100·H200·B200 같은 SXM GPU는 NVLink로 연결되지만 L40S와 RTX PRO 6000 같은 PCIe 카드는 그렇지 않아 병렬화 방식의 효율이 달라진다. 모니터링·컨트롤러·게이트웨이가 쓸 일반 노드 용량도 별도로 확보해야 한다.

게이트웨이에서는 단순 라운드로빈 대신 접두부 캐시가 있는 복제본으로 보내는 캐시 인식 라우팅을 고려한다. 한 호스트 이름에서 요청의 모델 필드로 여러 모델을 구분할 수 있다. 대부분의 도구는 OpenAI API를 기대하지만 Claude Code는 Anthropic Messages API를 사용하며, 가이드에 따르면 vLLM은 스트리밍과 도구 호출을 포함해 이를 기본 제공한다. 수 분 걸리는 생성과 추론 모델을 위해 요청 경로의 모든 시간 제한을 점검해야 한다. 게이트웨이 경로 제한, 로드밸런서 유휴 제한, 재시도, 클라이언트와 보조 호출이 모두 영향을 준다. 스트림이 중간에 끊겨도 유효한 토큰과 HTTP 200이 돌아올 수 있으므로 잘린 응답을 감지하고, 사용자별 토큰 사용량 한도와 할당량으로 과도한 요청이 다른 사용자를 막지 않도록 한다.

보안은 게이트웨이에 주소를 부여하기 전에 인증 정책을 적용하는 것부터 시작한다. 실제 호스트 이름에 TLS를 설정하고 인증서를 발급·갱신할 계획을 둔다. 브라우저 로그인은 게이트웨이의 OIDC로 처리할 수 있지만, 수 시간 실행되는 에이전트에는 60분짜리 토큰이 세션 중간에 만료될 수 있으므로 장기 API 키나 갱신 가능한 자격 증명이 필요하다. 게이트웨이와 애플리케이션에 만료되는 로그인 세션을 겹쳐 두지 않는다. 누락·잘못된 형식·서명되지 않음·만료·폐기된 키와 위조된 호출자 헤더는 거부되는지 정기적으로 시험하고, 상태 확인 경로처럼 계속 열려 있어야 하는 경로도 함께 확인한다. 모델 가중치는 코드처럼 취급해 safetensors를 우선하고, 검토하지 않은 저장소의 원격 코드를 켜지 않으며, 모델 리비전을 고정한다.

관측성은 엔진의 Prometheus 지표를 실제로 수집하도록 설정하는 데서 시작한다. 실행 중 요청과 동시성 한도, 대기 요청, KV 캐시 사용량, TTFT, 출력 토큰 간 지연, 요청당 출력량, 접두부 캐시 적중률, 추측 디코딩 수용률, 상태 코드별 오류와 취소를 대시보드에 둔다. 도구 호출 파싱 실패, 길이 제한으로 잘린 응답, 빈 출력, 거부 응답, 요청당 숨은 추론 토큰도 서버에서 집계한다. GPU-Util이 100%에 가까워도 GPU의 실제 연산 장치나 텐서 코어가 충분히 일하고 있다는 뜻은 아니다. 가이드의 사례에서는 GPU-Util 99%일 때 텐서 코어 사용률이 약 10%였다. SM 활동과 텐서 활동도 함께 관찰해야 한다. 지표 수집기가 데이터 없이도 API가 정상이라고 보고할 수 있으므로, 감시 시스템 자체의 데이터 신선도와 새 지표 유입을 별도로 확인한다. 요청별 호출자 로그를 보관하고, 충돌 후에는 kubectl logs --previous도 확인한다.

오토스케일링은 CPU가 아니라 대기열 깊이, KV 캐시 사용량, 처리 중인 요청 수 같은 추론 지표에 맞춘다. 트래픽은 수요에 앞서 확장할 수 있게 하지만 실제 부하는 뒤늦게 나타나므로 함께 본다. GPU 노드는 부팅, 대형 이미지 다운로드, 가중치 로딩에 시간이 걸리며 큰 모델은 가중치 로딩만 30분이 걸릴 수 있다. 클러스터별 공유 저장소에 가중치를 캐시하면 새 복제본이 다시 내려받는 일을 줄일 수 있다. 0개까지 축소하면 노드가 준비되기 전에 수요가 끝나거나 GPU 용량을 다시 얻지 못할 수 있다. 수백 GPU를 넘는 규모에서는 여러 지역과 공급업체의 클러스터를 함께 다룰 컨트롤 플레인이 필요할 수 있다.

변경은 모델·하드웨어·엔진 빌드의 세 가지 버전을 함께 추적하고, 한 번에 하나씩 바꾸며 자체 트래픽으로 시험한다. 독점 GPU를 쓰는 단일 복제본을 일반적인 롤링 업데이트로 바꾸면 새 파드는 GPU를 배정받지 못하고 이전 파드는 떠나지 않는 교착 상태가 생길 수 있다. Recreate 전략을 쓰거나 하나의 사용 불가 복제본을 허용하고 중단 시간을 예산에 반영한다. 파드가 준비 상태여도 게이트웨이가 라우팅을 시작하기까지 1~2분 늦을 수 있다. 테스트는 노트북에서 설정과 시험 도구를 확인하는 오프라인 단계, 가짜 게이트웨이나 작은 모델로 전체 흐름을 확인하는 리허설, 목표 하드웨어에서 장문 입력·도구 호출·스트리밍·거부 요청을 보내는 스모크 테스트, 동시 부하와 평가를 함께 실행하는 부하 시험, 소량 실트래픽을 보내는 카나리, 전체 배포 순으로 진행한다. 카나리 전에 롤백 조건을 적고, 새 버전이 트래픽 피크에도 기준을 지킬 때까지 이전 버전을 되돌릴 수 있게 둔다.

오픈 모델 평가 점수가 낮으면 모델 탓을 하기 전에 시험 하네스, 인프라, 채점기를 확인한다. 기존 호스팅 모델이 더 약한 모델보다 낮은 점수를 받으면 하네스가 잘못됐을 수 있다. 시간 초과·만료된 자격 증명·라우팅 오류가 모델 실패로 기록되지 않도록 해당 실행은 ‘측정되지 않음’으로 표시한다. 에이전트의 설명이 아니라 작업의 최종 상태를 채점하고, 사람이 이미 받아들이거나 거부한 답으로 채점기를 검증한다. 정답에 필요한 데이터를 고정하고 모든 모델에 같은 문맥을 제공하며, 모델이 읽을 수 없는 시험 표식을 둔다. 온도 0에서도 배칭 서버가 같은 요청에 다른 토큰을 반환할 수 있으므로 반복 실행과 결과 변동을 고려한다.

도구와 학습 경로

가이드는 엔진을 깊이 배우되 Kubernetes, 게이트웨이, 관측성과 관련한 기존 경험을 활용하라고 권한다. GPU 운영에는 NVIDIA GPU Operator, Kubernetes DRA와 NVIDIA 드라이버, DCGM exporter를 소개한다. 커널과 라이브러리에는 CUDA, PyTorch, Triton, FlashAttention, torch.compile을 든다. 추론 엔진은 vLLM, SGLang, TensorRT-LLM이며, 로컬 학습·시제품에는 Ollama와 llama.cpp를 제시한다. 분산 서빙에는 NVIDIA Dynamo, llm-d, KServe, LeaderWorkerSet, 게이트웨이에는 Envoy Gateway, Agent Router, Gateway API Inference Extension이 포함된다. 관측에는 Prometheus, Grafana, OpenTelemetry, Loki, Sloth, Pyrra를, 벤치마크에는 vLLM 도구, NVIDIA AIPerf, GuideLLM, SemiAnalysis AgentX를 제안한다. 평가 도구로는 UK AI Security Institute의 Inspect와 Hugging Face upskill을 소개한다.

vLLM은 폭넓은 모델 지원과 OpenAI·Anthropic API를 제공해 보통 첫 배포 대상으로 꼽힌다. 자주 새 플래그가 나오므로 버전을 고정하고 업그레이드 때마다 다시 벤치마크해야 한다. SGLang은 접두부 캐시를 활용하는 구조와 스케줄러가 에이전트·긴 다중 대화에 맞을 수 있지만, 커뮤니티가 더 작고 새 모델에 태그된 릴리스보다 야간 빌드가 먼저 필요할 수 있다. TensorRT-LLM은 NVIDIA 하드웨어에 맞춘 커널과 Blackwell의 FP4를 지원하지만 NVIDIA에 종속된다. NVIDIA Dynamo는 여러 노드와 프리필·디코드 분리를 조정하는 엔진 상위 계층이므로 다중 노드 규모에서 고려한다. Ollama와 llama.cpp는 학습·시제품용 로컬 서빙에 적합하지만 동시 사용자가 많은 환경을 위해 설계된 도구는 아니다. Hugging Face TGI는 유지보수 모드에 들어갔으므로 릴리스 주기와 유지관리자, 재단 지원 여부를 확인하라고 안내한다.

Upbound는 약 10명의 엔지니어에게 코딩 모델을 제공하던 두 개의 8-GPU 노드에서 팀 규모를 15명으로 늘리는 방법을 시험했다. 같은 하드웨어와 에이전트 트래픽에서 vLLM에서 SGLang으로 바꾼 것이 측정된 가장 큰 단일 개선이었다. 반면 KV 캐시가 차지 않아 SGLang의 호스트 메모리 캐시를 추가해도 측정 가능한 이득은 없었다. 이는 해당 팀의 시험 결과이며 다른 작업에도 같은 차이가 난다는 뜻은 아니다.

Modelplane은 Upbound가 공개한 Apache 2.0 라이선스의 오픈소스 프로젝트로, Crossplane을 기반으로 여러 클라우드·네오클라우드·자체 GPU에서 모델, 추론 엔진, AI 인프라를 선언형 API로 조정한다. 기존 추론 클러스터를 사용하거나 새로 프로비저닝할 수 있다. 플랫폼 팀은 클러스터·하드웨어 종류·게이트웨이, 모델 운영자는 배포·서비스·가중치 캐시를 맡고, Modelplane은 그 사이의 모델 엔드포인트와 복제본을 구성한다. 엔진 컨테이너와 플래그는 사용자가 제공하고 Modelplane이 배치를 구성한다. 사용자와 에이전트는 리소스를 직접 만들지 않고 모델 이름으로 InferenceGateway를 호출한다. vLLM과 SGLang의 지표 이름을 기본 매핑하며 다른 엔진은 MetricMapping으로 추가할 수 있다. 문서는 Modelplane 문서에서 볼 수 있다.

학습 순서는 GPU 한 대에서 vLLM을 실행하고 API와 지표를 확인한 뒤, NVIDIA GPU Operator를 사용하는 Kubernetes에 배포하고 장치 선택자로 배치하는 방식이다. 이후 TLS·인증·장시간 스트림용 시간 제한을 갖춘 게이트웨이를 두고 Prometheus로 엔진·GPU 지표를 수집한다. 동시성 부하 시험과 소규모 평가를 병행하고, 같은 모델을 SGLang에서도 실행해 실제 트래픽으로 비교한다. 그 다음 텐서·파이프라인 병렬화와 분산 서빙을 익히고, 커널과 프로파일링을 읽는 데 필요한 CUDA 지식을 더한다.

사례와 경력 개발

Upbound의 Project Champagne는 AWS와 Nebius GPU에서 Modelplane으로 채팅, 코딩 에이전트, CVE 수정 빌드 에이전트를 오픈 모델로 자체 운영한 다섯 편의 사례다. 팀은 vLLM과 스케줄링보다 TLS, 신원 확인, 시간 제한, 저장소와 관측성에 더 많은 시간을 썼다고 밝혔다. H100 인스턴스 768 vCPU에 대한 할당량 승인을 받았지만 인스턴스는 하나도 얻지 못했고, 계획한 GPU는 약 절반의 시간에만 확보됐다. 모델 하나는 두 가용 영역의 두 노드로 나뉘었다. 시작할 때 문제없던 채팅 모델은 나흘 동안 아홉 번 메모리 부족을 겪었다. 메모리 비율을 0.92에서 0.88로 낮추고 확장 가능한 세그먼트를 켜며 동시 시퀀스를 16개로 제한하자 4.6GiB를 확보했다.

사례에는 조용한 장애도 나온다. 잘린 스트림이 HTTP 200을 반환했고, 지표 API는 데이터가 없어도 사용 가능하다고 보고했으며, 모니터링은 6일 동안 대기 상태였다. 기본 15초 경로 시간 제한과 60초 로드밸런서 유휴 제한이 이어져 생성 중인 답변을 끊었다. 에이전트 세션은 한 시간씩 이어져 60분짜리 토큰을 넘겼고, 추론 모델은 사용자가 보는 첫 토큰 전에 1분 넘게 사고하기도 했다. 시험 하네스의 가짜 셸 때문에 Claude가 0점을 받았으며, 60초 유휴 제한을 늘리자 모든 실행을 완료한 모델도 있었다. 대시보드가 정상인데도 최대 강도 추론으로 생성이 느려진 사례와 GPU-Util 99%인데 텐서 코어가 약 10%만 바빴던 사례도 소개한다. 에이전트 프롬프트의 중앙값은 59K 토큰, p90은 125K였고, 토큰 약 3분의 2가 접두부 캐시를 이용했다. 짧은 프롬프트 세션은 하위 에이전트를 실행해 더 많은 요청을 동시에 처리하기도 했다. 128K 문맥 제한은 긴 대화를 거부했기 때문에 겉으로만 더 빠르게 보였다.

경력 방향은 GPU 클러스터와 스케줄링을 다루는 추론 플랫폼, SLO·관측성·용량 계획·장애 대응을 맡는 추론 신뢰성, 엔진 튜닝·양자화·병렬화·커널을 다루는 런타임 성능으로 나뉜다. 플랫폼 엔지니어는 트랜스포머 기초와 어텐션·KV 캐시·MoE 모델을 익히고, 엔진 하나를 깊게 다룬 뒤 GPU 배치, 장시간 스트림, 추론 신호 기반 오토스케일링과 엔진 관측성을 연결할 수 있다. 평가 체계를 만들고 용량 시험과 백만 토큰당 비용을 계산하는 역량도 중요하다고 가이드는 강조한다.

실습 프로젝트로는 GPU 한 대에서 8B 모델을 실행해 동시 사용자 1·10·50명을 비교하기, 32K 토큰 세션 수용량을 예측하고 시험하기, FP16·FP8·가능하면 4비트 형식의 품질과 속도를 비교하기, 공통 프롬프트 내용을 앞뒤에 배치해 캐시 적중률과 TTFT를 비교하기, Kubernetes와 TLS·인증 게이트웨이·오토스케일링·대시보드를 구성하기, 에이전트형 트래픽에서 vLLM과 SGLang을 한 번에 하나씩 바꾸며 비교하기 등을 제시한다. 결과물에는 설정, 부하 스크립트, 그래프, 비용, 시험 방법과 결과를 함께 공개하라고 권한다. 실패 사례와 재현 절차도 깨끗한 데모만큼 유용한 실무 자료가 될 수 있다.

가이드는 추론 직무의 이름이 아직 일정하지 않으므로 inference engineer, performance engineer, model serving engineer, ML infrastructure engineer, AI platform engineer 등을 함께 검색하라고 조언한다. Chris Zeoli가 2026년 8월 조사한 사례에는 Anthropic의 추론 성능 직무 연봉 35만~85만 달러, OpenAI의 유사 직무 29만5천~55만5천 달러가 나온다. 이는 조사된 채용 공고의 수치다. 새 직장을 찾지 않더라도 회사가 첫 자체 모델을 운영할 때 프로젝트에 참여하는 것이 직접 경험을 얻는 방법이라고 안내한다.

자료에는 Upbound의 Project Champagne 연재, Philip Kiely의 Inference Engineering, The Pragmatic Engineer의 추론 엔지니어링 심층 기사, ByteByteGo 가이드, Data Gravity의 업계 분석, Spheron 가이드와 AI Inference Engineering Roadmap이 포함된다. 핵심 연구·도구 자료로는 Orca, PagedAttention, DistServe, 추측 디코딩, FlashAttention, Anthropic의 에이전트 평가 안내, AI Evals FAQ 등을 제시한다.