5090 한 장, 모델 하나 — Ignis는 일부러 좁은 길을 택했다
어떤 모델이든 다 돌리겠다는 헛된 욕심을 버리고 딱 하나에 올인한 미친 엔진이 나왔다.
그동안 로컬 LLM 추론 엔진들의 미덕은 ‘넓은 범용성’이었다. llama.cpp는 구형 랩톱 CPU부터 최신 맥북 GPU까지 죄다 품었고, vLLM은 엔터프라이즈 데이터센터에서 온갖 모델을 다 돌린다. 둘 다 “어떤 모델이든, 어떤 하드웨어든 상관없이 다 돌려드립니다”를 모토로 삼았다. 그런데 새벽에 r/LocalLLM에 등장한 Ignis는 정반대의 좁은 길을 택했다. 지원하는 모델은 오직 Qwen3.8-27B(NVFP4) 딱 하나, 지원하는 하드웨어도 오직 RTX 5090(SM120a) 계열 딱 한 종류뿐인 Rust 기반 추론 엔진이다. 오픈소스 Apache-2.0으로 시원하게 풀었다. 언뜻 보면 “뭐 하러 이렇게 편협하게 만들었지?” 싶은데, 벤치마크 숫자를 보는 순간 입이 떡 벌어진다.
작성자인 u/gpillon은 Ninfer 엔진에서 출발해 몇 주 동안 핵심 커널을 바닥부터 다시 짰다고 한다. 목표가 아주 뾰족하다. 실제 AI 코딩 에이전트를 돌릴 때 발생하는 극악의 워크로드, 즉 부모 에이전트 하나와 여러 서브 에이전트들이 단일 그래픽카드를 동시에 두들겨 패는 병렬 요청 상황을 엔진 아키텍처 레벨에 그대로 새겨 넣는 것이었다.
미친 벤치마크 숫자부터 보자
호스트 PC 사양은 오히려 평범하다. 흔한 DDR4-3200 메모리에 구형 PCIe 3.0 슬롯이다. 거기에 RTX 5090 한 장을 꽂고 DFlash2 스펙큘러티브 디코딩(드래프트 7개)을 돌린 결과다.
단일 스트림(코딩 프롬프트) ~200 tok/s
8레인 동시 합산 >800 tok/s
KV 캐시 9 KB/token (BF16 대비 7.1배 용량 절감)
8레인 × 40K 컨텍스트 약 3 GB 점유
최대 컨텍스트 512K (YaRN 2배 확장)
윈도우와 리눅스 빌드만 제공한다. macOS는 아예 지원 대상이 아니라고 못을 박아버렸다(맥북 유저인 나는 가슴이 찢어졌지만). 프리필 속도가 상대적으로 느린 아키텍처는 애초에 이 엔진의 관심사가 아니라는 단호한 이유다.
범용 추론 서버와 무엇이 다른가
Ignis의 디코딩 루프는 철저하게 묶음 단위로 돌아간다. 동시 8개 레인 전체를 하나의 배치 라운드로 묶어서 단일 CUDA 그래프로 통째로 재생한다. 라운드 연산 자체가 GPU 카드 대역폭 한계치로 가중치를 쏟아붓는 스트리밍 작업이 되기 때문에, 여러 서브 에이전트의 요청이 난폭하게 섞여 들어와도 전체 속도가 곤두박질치지 않는다.
모든 요청에는 interactive와 agent 태그가 붙는다. 서브 에이전트들이 떼거리로 몰려오면 쉬고 있는 빈 레인을 먼저 채우는 구조라, 개발자가 터미널 포그라운드에서 실시간으로 대화하던 메인 세션을 튕겨내지 않는다. 대화 상태(state)는 단일 요청보다 오래 살아남아 프리픽스 재사용과 형제 요청 간 메모리 공유를 척척 해내고, VRAM이 넘치면 시스템 RAM으로 매끄럽게 흘려보낸다.
VRAM도 모델 로드 시점에 미리 100% 예약하고 메모리 할당 계획을 터미널에 투명하게 찍어준다. 40분쯤 작업하다가 갑자기 OOM(Out of Memory) 터지며 세션이 죽는 참사가 없다. 로컬에서 에이전트 서너 개 띄워본 사람이라면 이게 얼마나 고마운 기능인지 안다. 컨텍스트가 차오르면서 메모리가 제멋대로 부풀어 오르고, 서브 에이전트 하나가 폭주해서 메인 작업을 길동무 삼아 자폭하는 악몽을 원천 차단해 준다.
토큰을 1개도 생성하지 않고 정답 찾기
이 엔진의 진짜 충격적인 부분은 따로 있다. /v1/decide와 /v1/systemone 엔드포인트는 답변 토큰을 텍스트로 생성하지 않는다. 대신 모델의 attention 헤드에서 곧바로 관련도를 읽어와 결론을 내린다.
이미지 처리부터가 남다르다. 고해상도 스크린샷을 딱 한 번만 인코딩해 두면, 이후 “이 버튼 좌표 어디야?” 같은 질문에 답하는 데 단 60~90ms밖에 안 걸린다. 4096px 초고해상도 화면에서 테스트한 모든 UI 좌표 지정 테스트에서 마우스 클릭 위치를 100% 버튼 안쪽으로 정확하게 짚어냈다.
로그 검색 성능은 그야말로 경악스럽다. 100만 토큰에 달하는 방대한 서버 로그를 통째로 부어 넣고 “카드 결제 프로세서가 unavailable이라고 뜬 줄이 몇 번째 줄이야?”라고 물으면, 중복 로그를 템플릿으로 접고 보정된 attention 헤드가 후보군을 좁힌 뒤 단 한 줄을 칼같이 짚어낸다. 생성된 토큰은 0개. 실제 프로덕션 쿠버네티스 로그(100K~1M 토큰) 테스트에서 23번 시도 중 21번을 적중시켰고, 중앙값 소요 시간은 겨우 2.6초였다. 같은 작업을 모델한테 “그 줄을 텍스트로 인용해 줘”라고 시키면 프롬프트 프리필에만 47초가 걸리고, 100만 토큰을 넘어가면 아예 에러를 뿜는다.
산문과 JSON 데이터 검색도 지원한다. 200K 토큰까지는 원하는 문장을 92% 확률로 찾아내고, 1만 개 JSON 레코드 중에서 조건에 맞는 데이터를 29번 중 29번 완벽하게 골라냈다.
attention 맵에서 문맥 관련성을 뽑아내는 학술 연구(ICR, QRHead 등)는 이전에도 있었지만, 이걸 실제 고속 서빙 엔진으로 구현하고 이미지와 초장문 컨텍스트까지 묶어낸 실전 코드는 이 엔진이 처음이다.
왜 여기에 주목해야 할까
이걸 단순히 “조금 더 빠른 llama.cpp 짝퉁”으로 보면 본질을 놓친다. “특정 하드웨어와 단 하나의 모델을 극단적으로 결합하면 어디까지 미친 효율을 뽑아낼 수 있는가?”라는 완전히 새로운 질문에 대한 대답이다.
답변을 굳이 토큰으로 한 글자씩 타이핑(생성)할 필요가 없다는 통찰도 신선하다. 검색이나 UI 좌표 찾기처럼 정답이 이미 입력 데이터 안에 박혀 있는 작업이라면, 굳이 비싼 토큰 생성을 거치지 않고 어텐션 가중치에서 정답을 바로 낚아채는 게 10배는 빠르고 합리적이다. 47초와 2.6초의 격차가 바로 그 발상의 전환에서 나왔다.
물론 단점도 명확하다. 다른 모델을 돌리고 싶으면 다른 엔진을 써야 한다. 극단적인 편식이다. 하지만 작성자는 이 좁은 외길을 계속 파겠다고 선언했다. 다음 목표는 5090 한 장에서 Qwen 3.8-flash-next 125B 모델을 올리는 것이라고 한다. 레딧에서 “5090을 사려고 가진 장비를 전부 팔았다”는 작성자의 고백에 “신장은 안 팔았길 바란다”는 댓글이 달렸는데 절로 피식했다(참고로 이 엔진은 고전 게임 둠 E1M1을 실시간 비전 제로샷으로 클리어하기도 했다).
정리
Ignis가 대중적인 표준이 될지는 미지수다. 하지만 로컬 LLM의 다음 전선이 어디로 향하는지는 또렷하게 보여준다. 무작정 덩치 큰 모델을 클라우드에서 빌려 쓰는 시대에서, 내 워크로드에 완벽하게 맞춤 설계된 로컬 엔진을 극한으로 쥐어짜는 ‘엔지니어링의 시대’로 진입했다는 것.
모든 모델을 애매하게 지원하는 만능 도구보다, 내가 매일 쓰는 모델 하나를 초음속으로 돌려주는 전용 엔진이 훨씬 섹시할 수 있다는 걸 증명한 멋진 프로젝트다.