AI 제품을 운영하다 보면 곧 이런 질문에 부딪힙니다. "모든 질문에 비싼 추론 모델을 써야 하나?" 간단한 FAQ, 문서 검색, 코드 한 줄 설명까지 30B급 모델로 처리하면 품질은 안정적일 수 있지만 지연 시간과 비용이 빠르게 커집니다.
NVIDIA의 Star Elastic이 흥미로운 지점은 여기입니다. 이것은 단순히 30B, 23B, 12B 모델을 새로 냈다는 소식이 아니라, 하나의 체크포인트 안에서 서로 다른 추론 예산을 꺼내 쓰는 배포 패턴을 제안합니다. MarkTechPost 보도에 따르면 Star Elastic은 Nemotron Nano v3 30B 기반에서 23B와 12B 중첩 모델을 별도 파인튜닝 없이 추출하도록 설계됐습니다.1
문제는 모델 크기가 아니라 "항상 같은 크기"를 쓰는 습관이다
기존에는 12B, 23B, 30B 중 하나를 고르는 일이 배포 전 의사결정에 가까웠습니다. 작은 모델은 싸고 빠르지만 어려운 문제에서 불안하고, 큰 모델은 안정적이지만 모든 요청에 쓰기엔 과합니다.
Star Elastic의 핵심은 이 선택을 고정값이 아니라 런타임 전략으로 바꾸는 데 있습니다. ICML 2026 초록 기준으로, 이 방식은 하나의 부모 추론 모델에 여러 중첩 서브모델을 넣고, thinking과 answering 같은 추론 단계별로 다른 모델 크기를 쓰는 "elastic budget control"을 가능하게 합니다.2
실무적으로는 "어떤 모델을 쓸 것인가"보다 "이 요청은 어느 정도의 추론 예산을 받을 자격이 있는가"가 더 중요한 질문이 됩니다. 예를 들어 고객지원 봇이라면 배송 상태 조회는 12B, 계약 조항 해석은 23B, 고위험 법무 검토 초안은 30B로 보낼 수 있습니다.
하나의 체크포인트가 운영 복잡도를 줄일 수 있는 이유
확인된 구조를 보면 Star Elastic은 30B 전체 파라미터 모델 안에 23B, 12B 변형을 중첩합니다. Hugging Face 모델 카드 기준 NVFP4 버전은 30B, 23B, 12B 세 변형을 하나의 체크포인트에 담고, 각 변형은 총 파라미터와 활성 파라미터가 다릅니다. 30B는 3.6B active, 23B는 2.8B active, 12B는 2.0B active입니다.3
이 차이는 MoE 모델을 이해할 때 중요합니다. "30B"라고 해서 매 토큰마다 30B 전체를 쓰는 것이 아니라, 라우팅된 일부 전문가와 경로만 활성화됩니다. 여기에 중첩 슬라이싱이 더해지면, 팀은 모델 패밀리 전체를 따로 저장하고 운영하는 대신 하나의 계열로 관리할 여지가 생깁니다.
수치도 꽤 실용적입니다. Hugging Face 자료는 세 개의 독립 BF16 체크포인트를 저장하면 126.1GB가 필요하지만, 단일 elastic BF16 체크포인트는 58.9GB라고 설명합니다.4 또한 H100에서 BF16 기준 12B 변형은 30B 대비 2.4배 처리량을 보였다고 제시합니다.5
해석하면, Star Elastic의 가치는 "벤치마크 점수"만이 아닙니다. 모델 레지스트리, 배포 이미지, 롤백, 캐시, 라우팅 정책을 단순화할 수 있다는 운영상의 이점이 큽니다.
빛나는 사용처와 조심해야 할 지점
가장 자연스러운 적용처는 요청 난도가 크게 흔들리는 서비스입니다. 에이전트 워크플로우, 엔터프라이즈 검색 비서, 코딩 코파일럿, 티어형 고객지원이 여기에 들어갑니다. 쉬운 요청은 작게, 복잡한 계획 수립이나 최종 답변 합성은 크게 처리하는 방식입니다.
특히 흥미로운 부분은 thinking 단계와 answering 단계를 나누는 전략입니다. NVIDIA 모델 카드와 관련 자료는 작은 모델로 긴 reasoning trace를 만들고, 큰 모델로 최종 답을 합성하는 구성이 정확도-지연 시간 균형에서 유리했다고 설명합니다. 23B → 30B 구성은 표준 단일 모델 예산 제어 대비 최대 16% 높은 정확도와 1.9배 낮은 지연 시간을 달성한 것으로 보고됐습니다.6
하지만 이 결과를 곧바로 모든 서비스에 일반화하면 위험합니다. 첫째, 어떤 요청을 12B로 보낼지 판단하는 라우터가 필요합니다. 라우터가 틀리면 비용 절감은 품질 사고로 바뀝니다. 둘째, 중첩 모델 간 응답 성향이 완전히 같다고 가정하면 안 됩니다. 같은 체크포인트를 공유해도 활성 차원이 다르면 오류 양상은 달라질 수 있습니다.
셋째, 지원 생태계도 아직 완성형은 아닙니다. Hugging Face 모델 카드에는 thinking 중 23B에서 30B로 바꾸는 식의 모델 전환이 표준 vLLM에서는 아직 지원되지 않으며, 커스텀 추론 경로가 필요하다고 명시되어 있습니다.7 즉 "제로샷 슬라이싱"은 가능하지만, "제품 수준의 동적 전환"은 별도의 엔지니어링 과제입니다.
도입 판단 기준: elastic이 맞는 팀, 아닌 팀
Star Elastic을 검토할 만한 팀은 세 조건을 봐야 합니다. 요청 난도 분포가 넓고, GPU 비용이 민감하며, 모델 패밀리를 여러 개 운영하는 부담이 큰 경우입니다. 이때 elastic 모델은 정확도·지연 시간·비용 사이의 스위치를 더 촘촘하게 만들어줍니다.
반대로 별도 모델이 더 나은 경우도 있습니다. 특정 도메인에 깊게 특화된 모델이 필요하거나, 모델 버전별 재현성이 엄격해야 하거나, 12B와 30B를 완전히 다른 트래픽 패턴으로 독립 확장해야 한다면 separate deployment가 단순할 수 있습니다.
NVIDIA NIM의 기존 reasoning model 문서가 보여주듯, 지금까지의 효율화는 주로 "detailed thinking on/off"처럼 같은 모델의 추론 모드를 프롬프트로 조절하는 방식이었습니다.8 Star Elastic은 한 단계 더 나아가 모델 용량 자체를 추론 예산의 일부로 다루려는 시도입니다.
지금 당장 신경 써야 할 독자는 대형 모델을 이미 운영 중인 AI 플랫폼 팀입니다. Star Elastic의 질문은 "30B가 좋은가, 12B가 좋은가"가 아닙니다. "우리 서비스에서 30B가 정말 필요한 순간은 언제인가"입니다. 그 답을 측정할 수 있는 평가셋과 라우팅 정책이 있다면 elastic 모델은 비용 절감 기술을 넘어, 추론 인프라 설계 방식 자체를 바꿀 수 있습니다.
참고
2Star Elastic: Many-in-One Reasoning LLMs with Efficient Budget Control
3nvidia/NVIDIA-Nemotron-Labs-3-Elastic-30B-A3B-NVFP4 · Hugging Face
4nvidia/NVIDIA-Nemotron-Labs-3-Elastic-30B-A3B-NVFP4 · Hugging Face
5nvidia/NVIDIA-Nemotron-Labs-3-Elastic-30B-A3B-NVFP4 · Hugging Face
6nvidia/NVIDIA-Nemotron-Labs-3-Elastic-30B-A3B-NVFP4 · Hugging Face
7nvidia/NVIDIA-Nemotron-Labs-3-Elastic-30B-A3B-NVFP4 · Hugging Face
8Using Reasoning Models -- NVIDIA NIM for Large Language Models (LLMs)
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.