특정 모델·하드웨어에 맞춘 추론 엔진이 늘어나는 이유

AI 요약

저자는 i5-12600K, DDR5 64GB, RTX 4070 12GB를 사용해 125B 파라미터 MoE 모델 Qwen3.8-Flash-Next를 실행했습니다. llama.cpp 설정을 조정해 얻은 최고 속도는 초당 27토큰이었습니다. 같은 컴퓨터에서 해당 모델을 지원하는 런타임 Strata를 시험하자, 6만 토큰 문맥에서 프롬프트 처리 속도는 초당 2,013토큰, 생성 속도는 초당 53.2토큰으로 나왔습니다. 다만 두 런타임의 양자화 방식과 설정이 달라 통제된 비교는 아니며, 이는 각기 다른 전체 서빙 구성의 성능 비교라고 선을 긋습니다.

범용성보다 특정 조합의 속도를 택하는 엔진

Strata 외에도 특정 모델군과 하드웨어에 맞춘 추론 엔진이 등장하고 있습니다. ninfer는 RTX 5090과 일부 Qwen 체크포인트에 맞춰 C++·CUDA로 작성됐고, Splash는 Apple Silicon M3 이상에서 Qwen 계열을 겨냥합니다. DwarfStar는 Metal·CUDA·ROCm을 지원하며, llamAmpere는 RTX 3090 계열을 대상으로 llama.cpp를 수정했습니다. gufo는 AMD Strix Halo에 맞춘 HIP 커널과 추측 디코딩 기법을 사용합니다.

저자는 이런 프로젝트가 일반적인 소프트웨어 기준으로는 모델과 하드웨어에 강하게 결합되고 이식하기 어렵다고 설명합니다. 하지만 한정된 대상을 위해 연산 그래프, 메모리 배치, 커널을 함께 설계하면 범용 런타임이 지닌 제약을 피할 수 있습니다. llama.cpp처럼 CUDA, ROCm, Metal, Vulkan, SYCL과 여러 모델군을 지원하는 프로젝트는 한쪽을 바꾸면 다른 백엔드가 깨지지 않는지 검토해야 합니다. 반면 단일 대상만 고려하는 작은 코드베이스는 과감한 변경과 실험을 빠르게 시도할 수 있습니다.

전용 엔진이 늘어나는 배경과 수명

저자는 세 가지 배경을 제시합니다. 첫째, 범용성에는 성능 비용이 따릅니다. 여러 모델과 장치를 지원하는 코드에서는 메모리 관리나 전문가(expert) 배치 같은 최적화를 공통 구조에 반영하고 검토해야 합니다. 둘째, AI 코딩 도구가 엔진 제작 비용을 낮춥니다. 이전에는 숙련된 시스템 엔지니어가 몇 달간 프로파일링해야 했던 작업을, 이제 개발자가 코딩 에이전트와 함께 커널을 작성하고 측정하는 방식으로 짧게 반복할 수 있습니다. DwarfStar README도 AI 코딩 에이전트의 강한 도움을 받았다고 밝힙니다. 저자는 전용 런타임 제작에 드는 시간이 수개월의 전문가 작업에서 수주 이하로 줄었을 가능성을 제시하지만, 이를 뒷받침할 정량 자료는 없다고 덧붙입니다.

셋째, 추론 최적화에는 측정 가능한 목표가 있습니다. 고정된 가중치와 토큰을 입력하고, 참조 출력과의 차이를 허용 범위 안에 두면서 토큰 생성 속도를 높이고 메모리를 줄이는 식입니다. 다만 프리필 지연, 전력, 동시성, 문맥 길이, 샘플링, 신뢰성도 고려해야 합니다. 품질 검증 기준이 느슨하면 장문 문맥 정확도나 드문 토큰 처리처럼 측정하지 않은 품질을 희생할 수 있습니다.

저자는 2027년 4월까지 표에 든 엔진 여섯 개 중 최소 네 개가 기본 브랜치에서 60일간 커밋을 하지 않을 것이라고 예측합니다. 포크의 활동이 아니라 각 프로젝트의 기본 브랜치 커밋을 기준으로 삼고, 나중에 결과를 확인하겠다고 밝혔습니다. 모델 구조가 바뀌면 기존 엔진은 멈추고 새 전용 엔진이 등장할 수 있다는 전망입니다.

범용 엔진은 부품 창고가 됩니다

저자는 범용 엔진과 전용 엔진이 서로를 대체하기보다 역할을 나눌 것으로 봅니다. DwarfStar는 llama.cpp의 GGML 커널과 양자화 형식을 활용하고, llamAmpere는 llama.cpp 포크입니다. GGUF 형식과 양자화 방식, 여러 커널도 범용 프로젝트의 축적에서 나왔습니다. 범용 엔진이 형식과 양자화 연구, 백엔드별 기준 구현을 맡고, 전용 엔진은 그 결과물을 특정 모델과 그래픽카드에 맞게 조립한 뒤 다음 모델이 나오면 폐기하는 그림입니다.

엔진이 자주 바뀌어도 사용자 인터페이스와 클라이언트까지 매번 바뀌어서는 안 됩니다. OpenAI Chat Completions API나 Anthropic Messages API를 제공하면 Cursor, Cline, Open WebUI, Aider 같은 클라이언트가 엔진 교체를 거의 의식하지 않습니다. llama-swap 같은 모델 라우터는 하나의 포트에서 요청을 받아 필요한 엔진을 띄우고, 모델을 바꾸며, 일정 시간 유휴 상태가 되면 종료하는 방식으로 여러 엔진을 관리합니다.

속도만큼 따져야 할 신뢰와 품질

저자는 전용 엔진의 빠른 개발과 잦은 교체가 공급망 위험을 키운다고 경고합니다. 프로젝트를 소수 인원이 관리하고, 네이티브 코드를 실행하며 GPU 드라이버와 메모리를 직접 다루는데도 검토자나 보안 공지가 부족할 수 있습니다. 소스에서 직접 빌드하고 커밋을 고정하면 변경 사항을 살펴보기는 쉬워지지만, 보안 감사를 대신하지는 않습니다. 저자는 업데이트 전에 변경 내용을 확인하고, 잃어서는 안 되는 데이터가 있는 컴퓨터에서는 실행하지 말라고 권합니다.

범용 엔진이 성능 격차를 줄일 방법으로는 하드웨어별 커널·전문가 배치·추측 디코딩 설정을 모델과 함께 배포하는 플러그인 방식, 에이전트가 범용 저장소 안에 최적화 변형을 만들고 시험하는 방식, Mojo/MAX·Triton·MLIR 계열 컴파일러가 모델 그래프와 하드웨어 설명에서 최적 코드를 생성하는 방식이 제안됩니다. 다만 저자는 현재 컴파일러가 전용으로 작성한 코드보다 나은 결과를 내기까지는 시간이 필요하다고 봅니다.

Reddit 반응

• @toomanypubes — 앞으로는 로컬 모델이 사용자가 가진 어떤 구형 컴퓨터에서도 최적화 엔진을 만들 것입니다. 지금은 사람이 주도하지만, 나중에는 기본 기능이 될 것입니다.
  • @Asleep-Land-3914 — 라이브러리나 tinygrad 같은 곳의 코드를 대부분 재사용하고 재구성할 것입니다.
  • @JollyJoker3 — 시점을 생각해 보세요. Strata에 들어간 기술은 아직 범용 라이브러리에 들어가지 않았습니다. 새 기법은 아이디어나 논문에서 시작해 특정 목적의 개념 증명으로 공개된 뒤, 더 널리 쓰이게 됩니다.
• @No_Afternoon_4260 — 솔직히 말하면 추론 엔진만의 미래가 아닙니다. 코드를 실행하는 거의 모든 분야에서 용도에 맞춰 만들고 버리는 기반 시설이 나타나는 미래입니다.
  • @unrulywind — 에이전트가 테스트 하나를 돌리려고 큰 테스트 코드를 썼다가 지우는 사례를 이미 봅니다. 예전 프로그램을 찾기보다 오늘만 쓸 간단한 독립 스크립트를 만들라고 시키곤 합니다. 일회용 코드 시대는 이미 왔다고 봅니다.
• @debackerl — SGLang, vLLM, llama-server 사이에서 옮겨도 요청 형식을 조정해야 합니다. 빌드 시스템이 하드웨어별 커널을 최적화하는 건 좋지만, 서로 호환되는 틀에 들어가야 합니다. 표준화 없이 모두가 AI가 만든 자기만의 운영체제를 쓰면 곤란합니다.
• @Due-Memory-6957 — 최신 하드웨어를 쓰는 선진국 사용자에게만 맞는 이야기입니다. Vulkan을 신경 쓰는 엔진이 llama.cpp뿐이라서 저 같은 사람도 이 분야에 참여할 수 있습니다.
• @TokenRingAI — 제 장비인 Xeon Max 두 대에서는 llama.cpp가 Qwen Flash Next를 초당 7토큰, SGLang은 12토큰 처리합니다. 직접 만든 NUMA 엔진은 CPU NUMA와 AMX를 써서 초당 67토큰, 프리필 초당 900토큰을 냅니다. 이런 CPU 최적화는 llama.cpp의 일반적인 목표처럼 보이지만 아직 제대로 동작하지 않았습니다.
  • @Shot-Height-7194 — GitHub에 공개해 주세요.
• @Garblyx — 마음에 들지는 않지만 하드웨어가 워낙 다양해 자연스러운 결과입니다. 모든 플랫폼에서 최적화되는 만능 엔진은 나오지 않을 것 같습니다. 제가 틀리면 좋겠습니다.
  • @brainExploded99 — 플러그인이 많은 부분을 제어하는 구조라면 그런 엔진을 만들기 어렵지 않아 보입니다.
  • @Garblyx — 웹 UI와 컨테이너를 쓰면서 저도 백엔드를 Dockerfile별로 바꿉니다. 같은 하드웨어에서 서로 다른 모델을 위해 vLLM 빌드를 세 개 이상 돌립니다.
  • @brainExploded99 — 그래도 번거롭지 않나요? 플러그인 시스템이라면 llama-server나 llama-swap처럼 재시작 없이 모델을 동적으로 바꿀 수 있습니다.
  • @brainExploded99 — 반대 의견을 내면 반대 표를 받겠지만, 커뮤니티가 크게 파편화되는 건 좋지 않습니다.
  • @1ncehost — Hugging Face가 여러 소프트웨어에서 조합할 커널 라이브러리를 만들고 있습니다. 사용자가 아키텍처에 맞는 커널을 골라 조정하고, AI 에이전트와 검증된 설정을 공유하는 방향으로 갈 수 있습니다.
• @buttplugs4life4me — 범용 엔진이 모델과 하드웨어의 급격한 증가를 따라가지 못하는 것에 가깝습니다. SGLang은 GGUF를 지원하지만 Qwen35는 예외이고, 혼합 양자화나 혼합 KV 캐시 지원도 부족합니다. 일부 기능 조합은 함께 쓸 수 없고 모델 로딩은 230초나 걸리기도 합니다. vLLM에도 MTP와 프리픽스 캐시를 함께 쓸 때 출력 품질이 떨어지는 문제가 여러 릴리스에 걸쳐 있었습니다. 특정 모델과 하드웨어에만 집중하면 일이 줄어듭니다. 그래도 범용 엔진은 언젠가 따라잡을 것입니다.
  • @IknowPi_really — 따라잡지 못할 거라고 봅니다. 하지만 범용 엔진은 계속 범용으로 남고, 다음 큰 변화가 와도 무너지지 않을 유지보수 가능한 기반을 제공할 것입니다.
• @OsmanthusBloom — 추론 엔진의 요구사항은 안정적이지 않습니다. 이미지·오디오·비디오, 새로운 KV 캐시 양자화, MTP, DFlash2 같은 기능이 거의 매주 바뀝니다. 전용 런타임이 갈라지는 세상에서는 기능을 매번 반복해서 구현해야 합니다. 코딩 에이전트가 그 일을 쉽게 만들겠지만, 하드웨어 구성과 모델 구조, 용도, 기능의 조합 폭발을 관리할 방법이 필요합니다.
  • @Imaginary-Unit-3267 — Unix 철학을 출발점으로 삼을 수 있습니다. 추론 엔진을 표준 프로토콜로 통신하는 모듈로 나누고, 새 기능을 부품처럼 연결할 수 있을까요?
• @FullOf_Bad_Ideas — 높은 초안 토큰 수락률을 얻으려고 탐욕적 디코딩을 쓰는지, 탐욕적 디코딩이 추론 품질을 낮추거나 반복을 일으키는지 묻고 싶습니다. 보안 토큰 추출과 코드 작성에서 문제가 없었다는 시험만으로는 결론을 신뢰하기 어렵습니다. 샘플링과 권장 설정을 맞춰 비교하지 않았고, llama.cpp의 프리필 속도도 제시하지 않았습니다.
  • @carteakey — 타당한 반박입니다. Strata에 관한 논의는 별도 글로 옮겼습니다. 품질 저하가 없다고 입증한 비교를 했다는 뜻은 아닙니다. 긴 에이전트 작업과 코딩 시험에서 눈에 띄는 저하를 못 봤지만, 탐욕적 디코딩이 샘플링보다 품질을 보존한다는 증거는 아닙니다. ‘여기서 기본값으로 적절하다’는 표현은 지나쳤고 삭제했습니다. 지적해 주셔서 감사합니다.
• @wishstudio — llama.cpp에 PR을 보내도 몇 달간 검토를 기다려야 했고, GB10 클러스터에서 DeepSeek를 쓰려고 커뮤니티 vLLM 패치를 찾아야 했습니다. 그래서 직접 추론 엔진을 만들기 시작했습니다. 현재 최상위 모델은 사람의 통찰 없이도 이 일을 해낼 수 있습니다. 필요한 기능을 다른 사람이 검토하고 병합할 때까지 기다리는 것보다 직접 구현하는 편이 훨씬 빠릅니다.
  • @xienze — 이런 프로젝트는 쉽게 만든 저품질 PR과 이슈에 파묻혀 있습니다. “Claude, 내가 생각한 대로 안 되니 고쳐서 PR을 써 줘” 같은 요청도 넘칩니다. 기업이 의존하는 소프트웨어는 “성능 두 배, 단점 없음”이라는 주장만으로 코드를 받아들일 수 없습니다. 개인 프로젝트에서 직접 만드는 게 잘 된다면 좋지만, 그것은 표본 하나라는 점을 기억해야 합니다.
• @darktotheknight — 이 흐름은 지속 가능하지 않으므로 미래가 아닐 것입니다. 과거 범용 웹 서버 Apache가 동시 연결 처리에서 느려지자 nginx 같은 이벤트 기반 서버가 생겼지만, Apache는 결국 기능과 속도를 따라잡았습니다. llama.cpp도 특정 설정을 더 잘 최적화하는 방법을 찾을 것입니다. 전용 포크가 쓰는 비밀 기술이 있는 게 아니라, 변경 사항을 검토하고 병합하기 어려운 경우가 많습니다.
  • @Ansible32 — Apache와 nginx의 비교보다 Android와 Linux 커널의 비교가 맞습니다. Linux 커널은 범용이고, Android는 기기마다 맞춤 펌웨어를 씁니다. AI 코딩은 GPU 드라이버가 좋지 않아도 원하는 작업에 맞춰 최적화하는 길을 열어 줍니다.
• @Small-Term672 — 진짜 질문은 다음 모델 아키텍처가 나오면 누가 이 런타임을 유지하느냐입니다. 제 생각에는 아무도 유지하지 않을 것입니다. 그게 바로 취지일 수 있지만, 대부분에게 llama.cpp가 기본값으로 남는 이유이기도 합니다.
• @neopolitan77 — 특히 집에서 쓰는 사용자라면 전용 엔진을 쓰는 게 당연하지 않나요? 실제로 갖고 있지도 않은 하드웨어에서 같은 명령을 쓸 수 있다는 이론적 가능성을 위해 성능을 포기할 이유가 뭔가요?

원문: Carteakey 기술 블로그 / 번역·요약: Trawling