코딩 모델 Ornith-1.5-122B, DGX Spark 한 대 실측

코딩 모델 Ornith-1.5-122B를 책상 위 DGX Spark 한 대에서 실행하는 방식 네 가지를 같은 장비에 차례로 설치했다. 한국어 속도와 동시 처리, 이미지 이해와 도구 호출, 한자 혼입을 같은 문항으로 측정했다.

Ornith 측정 2026-10-22(하루, 약 2시간) · 비교 기준은 같은 장비·같은 측정 도구로 10월 18일에 잰 값(펠리컨 과제만 10월 22일) · 장비 NVIDIA DGX Spark(GB10, 통합 메모리 128GB) 1대 · 실행 설정을 공개한 저장소 저자의 수치는 출처를 달아 우리 측정과 구분했다

결론부터

혼자 쓸 때 가장 빠른 방식은 Mia-AiLab이 만든 4비트 모델을 TensorFold 엔진으로 실행하는 방식이었다. 한국어는 초당 38토큰, 영어는 초당 46토큰을 생성해 비교 기준 Qwen3.8-Flash-Next와 비슷했다. 회사 공식 4비트 모델을 vLLM으로 실행하면 초당 27토큰이었다. Unsloth의 4비트 모델을 llama.cpp로 실행하면 초당 22토큰이었다.

요청 네 건을 동시에 보내면 순위가 바뀌어 vLLM 방식의 합계 처리량이 가장 높았다. 측정한 세 방식 모두 이미지 이해와 도구 호출은 정상이었지만, 한국어 답변 19개 가운데 1~3개에 중국어 한자가 섞였다.

측정한 모델

Ornith-1.5-122B는 AI 모델 개발팀 Ornith가 10월 20일 MIT 라이선스로 공개한 코딩·에이전트용 모델이다. 답하기 전에 <think> 블록에 사고(Thinking) 과정을 먼저 쓰는 reasoning model(추론 모델)이고, 이미지 입력도 받는다. 이 글에서 "사고 끔"은 이 과정을 건너뛰고 바로 답하게 한 상태다.

비교 기준은 같은 장비에서 운영하던 Qwen3.8-Flash-Next다. 크기가 비슷한 MoE(전문가 혼합) 모델로, 엔비디아의 4비트(FP4) 버전을 TensorFold 계열 엔진으로 실행해 왔다.

회사가 발표한 점수는 아래와 같다. 두 모델 값 모두 Ornith 모델 카드의 표에서 옮겼고, 외부 평가 기관 Artificial Analysis의 점수는 아직 없다.

Qwen 팀이 직접 발표한 Qwen3.8-Flash-Next 점수는 이 표보다 높다. SWE-bench Pro는 62.5점이다. SWE-bench Multilingual은 81.0점, Toolathlon은 73.5점이다. 회사마다 채점 조건이 달라서 생긴 차이일 수 있다. 점수와 장비 크기는 앞서 쓴 인사이트에 자세히 정리했다.

네 가지 실행 방식

DGX Spark는 CPU와 GPU가 메모리 128GB를 나눠 쓴다. 원본 모델은 250GB라서 quantization(양자화)으로 크기를 줄인 모델만 실행할 수 있다. 양자화는 모델의 숫자를 더 적은 비트로 저장해 크기를 줄이는 방법이다.

이번에 측정한 네 방식은 모두 4~5비트 모델이다. NVFP4는 엔비디아 GPU용, GGUF는 llama.cpp용, EXL3는 ExLlamaV3용으로 만든 양자화 형식이다. 방식 이름은 쓰는 추론 엔진(모델을 실행하는 프로그램)에서 따왔다.

vLLM판을 뺀 세 방식은 speculative decoding(추측 디코딩)으로 속도를 높인다. 작은 초안 모델이 다음 토큰 여러 개를 미리 추측하면, 본 모델이 그 추측을 한 번에 검사해 맞는 토큰만 확정하는 방식이다.

DFlash2는 inco.ai가 Ornith-1.5-122B용으로 공개한 초안 모델이다. MTP는 모델 안에 들어 있는 다음 토큰 예측 층이다. DFlash2 제작사는 추측 디코딩을 써도 본 모델의 출력 분포는 바뀌지 않는다고 설명한다.

혼자 쓸 때는 TensorFold판이 가장 빨랐다

요청 한 건을 보냈을 때의 생성 속도다. 사고를 끄고 600토큰짜리 산문을 쓰게 했다. 한국어 다섯 문항과 영어 세 문항을 두 번씩 실행해 중앙값을 냈다. 단위는 초당 생성 토큰 수(tok/s)다.

TensorFold판은 한국어에서 vLLM판보다 약 40% 빨랐다. 비교 기준인 Qwen3.8-Flash-Next와는 한국어에서 비슷하고 영어에서는 조금 앞섰다. 비교 기준 값은 같은 측정 도구와 같은 문항으로 10월 18일에 측정했다.

600토큰 분량의 한국어 답을 쓰는 데 TensorFold판은 16초 안팎이 걸린다. 나머지 세 방식은 같은 분량에 22~30초가 걸린다.

사고를 켜면 답 앞에 사고 과정을 먼저 쓰므로 기다리는 시간이 더 길다. 뒤의 펠리컨 그림 과제에서 TensorFold판은 사고를 켜고 답을 마치는 데 141초가 걸렸다. 첫 토큰이 나오기까지의 시간과 긴 입력을 읽는 속도는 이번에 측정하지 않았다.

저장소 저자가 밝힌 속도와 우리 측정

TensorFold판과 llama.cpp판은 저자가 실행 설정과 패치를 모아 공개한 저장소(레시피)를 따랐다. 저자 수치는 각 저장소의 설명 문서를 직접 열어 확인했고, 측정 조건이 우리와 달라 숫자를 그대로 비교할 수는 없다.

TensorFold판 저자 Mia-AiLab은 초안 모델 없이 실행하면 초당 35토큰 정도라고 밝혔다. 저자는 코드 생성에서 초당 83.3토큰을 측정했다. 우리는 코드 생성 속도를 따로 측정하지 않았다.

llama.cpp판은 sxuff가 공개한 GB10용 저장소의 실행 설정을 따랐다. 다만 모델은 Unsloth의 4비트 버전으로 바꿨다. 컨텍스트도 저자 설정의 절반인 13만 1,072토큰으로 줄였다. sxuff는 산문에서는 MTP 추측이 36%만 맞아 이득이 거의 없다고 적었다.

요청 네 건을 동시에 보내면 vLLM판 합계 처리량이 가장 높았다

한국어 요청을 여러 건 동시에 보내, 요청 한 건이 받는 속도(건당)와 모든 요청을 더한 속도(합계)를 측정했다. 요청 한 건 값은 앞 표와 조금 다르다.

TensorFold판의 이점은 동시 요청이 늘수록 빠르게 줄었다. 두 건부터 건당 속도가 vLLM판과 비슷해졌고, 네 건에서는 합계 처리량이 vLLM판보다 낮았다.

레시피 저자는 동시 네 건 합계를 초당 90.4토큰으로 적어, 우리 한국어 측정보다 높았다. 다만 저자는 여러 요청을 동시에 처리하는 상황은 부하 시험을 하지 않았다고 밝혔다. 우리 조건에서는 팀 몇 명이 함께 쓰는 서버에 vLLM판이 더 맞았다.

이미지 이해와 도구 호출은 세 방식 모두 정상

4비트 모델에서도 기능이 빠지지 않는지 확인했다. vLLM+DFlash2판은 출력층만 바꾼 같은 모델이고 추측 디코딩은 출력을 바꾸지 않아, 이 항목은 따로 측정하지 않았다.

이미지 이해는 표·차트·스캔 문서 이미지를 보여 주고 정답 단어가 답에 들어 있는지로 판정했다. 도구 호출은 OpenAI 형식의 tool_calls로 도구를 제대로 부르는지 확인했다.

이미지 이해는 비교 기준도 같은 도구와 같은 이미지로 측정했다. 다만 한자 혼입과 답변 길이의 비교 기준 값은 참고로만 봐야 한다. 문항과 설정은 같지만, 비교 기준은 측정 때 함께 보낸 시스템 프롬프트가 달랐고 앞단의 중계 서버를 거쳤다. Ornith 세 방식은 같은 날 같은 프롬프트로 측정했다.

한국어 답에 한자가 섞였다

한국어 문장 중간에 중국어 한자가 섞이는 현상이 세 방식 모두에서 나왔다. 「빠른 기능迭代」, 「横확장」처럼 단어 하나가 한자로 바뀌는 식이다. 비교 기준 Qwen3.8-Flash-Next는 같은 19문항에서 한 번도 섞이지 않았지만, 시스템 프롬프트가 달라 참고값이다.

시스템 프롬프트 없이 자기소개를 시키자 TensorFold판은 자신을 「알리바바 통이 Qwen」이라고 소개했다. Ornith는 122B가 어떤 모델을 기반으로 했는지 밝히지 않았지만, 모델 설정 파일의 구조는 알리바바 Qwen3.5 계열 MoE와 같다.

펠리컨 그림 과제는 여섯 번 모두 성공했다

긴 코드를 끝까지 써 내는지 보려고 「자전거 타는 펠리컨을 움직이는 SVG로 그려 달라」고 요청했다. 세 방식마다 사고를 끈 상태와 켠 상태로 한 번씩 실행했다.

Ornith-1.5-122B는 여섯 장 모두 펠리컨이 자전거에 올라탄 그림을 그렸다. 가장 자연스러운 그림은 vLLM판이 사고를 켜고 그린 것으로, 펠리컨이 날개로 핸들을 잡고 발을 페달에 올렸다.

사고를 켜도 Ornith-1.5-122B는 8,000토큰 안에서 코드를 마쳤다. 비교 기준과 같은 1만 6,000토큰 한도였어도 끝낼 수 있는 분량이다. 비교 기준 모델은 사고를 켜자 두 번 모두 1만 6,000토큰 한도 안에 SVG를 끝내지 못했다. 다만 Ornith의 토큰 한도는 3만 2,000토큰이었고, 비교 기준이 같은 한도에서 끝냈을지는 측정하지 않았다. 실행 횟수도 Ornith는 방식마다 한 번, 비교 기준은 두 번이라 경향으로만 봐야 한다.

비교 기준 모델도 조건이 다르면 사고를 켜고 SVG를 끝까지 완성했다. 10월 25일 서비스 화면에서 사고 강도를 최대로 두고 「자전거 타는 펠리컨을 SVG로 그려 HTML 파일로 인터랙티브하게 만들어 달라」고 요청하자, 1만 3,840토큰에서 정상 종료했다. 요청 문장과 시스템 프롬프트가 위 측정과 달라 같은 조건의 결과는 아니다.

설치하며 겪은 문제

vLLM에서는 DFlash2 초안 모델을 붙이자 오히려 느려졌다. 한국어에서 초안 모델이 추측한 토큰 가운데 검사를 통과한 것이 한 번에 평균 0.84개뿐이었고, 초안 모델 없이 실행할 때보다 느렸다. 반면 TensorFold판 저자는 같은 초안 모델을 붙여 초당 35토큰에서 52.6토큰으로 빨라졌다고 밝혔다. 엔진 쪽 구현 차이로 보인다.

vLLM에 DFlash2를 붙이려면 모델 출력층(lm_head)을 BF16 형식으로 되돌려야 했다. Ornith 공식 NVFP4 모델은 출력층까지 4비트로 저장돼 있어 vLLM이 초안 모델 연결을 거부한다. 4비트 값을 BF16으로 바꾼 출력층은 원본 출력층과 값이 평균 9.5% 정도 어긋났다(상대 오차). 이 차이가 답의 품질에 주는 영향은 측정하지 않았다.

공식 NVFP4 모델의 내장 MTP 층은 vLLM에서 바로 쓸 수 없었다. MTP 층은 양자화되지 않은 BF16인데, GB10에서 필요한 --moe-backend marlin 설정과 함께 켜면 vLLM이 marlin is not supported for unquantized MoE 오류를 내고 시작하지 않는다.

vLLM은 기본 메모리 사용 비율 0.92로는 시작되지 않았다. 이 비율로 계산한 메모리가 GB10에서 실제로 쓸 수 있는 메모리보다 커서다. 0.80으로 낮추자 실행됐고, 운영체제의 파일 캐시를 비운 뒤 처음 불러올 때는 436초가 걸렸다.

TensorFold판 레시피는 기본 접속 주소가 0.0.0.0이라 모든 네트워크에서 접속할 수 있다. 외부 IP가 있는 장비라면 받자마자 127.0.0.1로 바꿔야 한다.

네 방식 모두 장비 메모리의 절반 이상을 썼다. 어느 방식이든 다른 큰 모델과 한 장비에서 함께 실행하기는 어렵다.

누구에게 맞나

DGX Spark 한 대를 혼자 쓰는 개발자라면 TensorFold판을 권한다. 한국어 초당 38토큰은 비교 기준 Qwen3.8-Flash-Next와 비슷한 속도이고, 메모리도 네 방식 가운데 가장 적게 쓴다. 대신 레시피를 처음 실행할 때 Mia-AiLab의 패치 27개를 적용한 엔진을 직접 빌드하고, 동시 요청이 늘면 속도 이점이 줄어든다.

여러 사람이 함께 쓰는 서버라면 vLLM판이 낫다. 한 건 속도는 느리지만, 네 건을 동시에 처리할 때 합계 처리량이 초당 67.5토큰으로 가장 높았다. 비슷한 크기의 Qwen3.8-Flash-Next를 같은 장비에서 엔진 다섯 가지로 비교한 리뷰에서도 여러 명이 쓰는 서버에는 vLLM 기반 조합을 골랐다.

Ornith-1.5-122B는 이번 SVG 과제에서 긴 코드를 끝까지 완성했고, 4비트 모델에서도 이미지 이해와 도구 호출이 정상으로 동작했다. 반면 한국어 답변에는 한자가 섞였다. 한국어 서비스에 쓰려면 답변에서 한자를 걸러 내는 장치를 따로 두어야 한다.

재현 정보

TensorFold판은 레시피 저장소를 받아 ./start.sh를 실행한다. 처음 실행할 때 패치를 적용한 엔진을 빌드하고 모델과 초안 모델을 내려받는다.

vLLM판 실행 명령은 다음과 같다.

vLLM+DFlash2판은 여기에 --no-async-scheduling --speculative-config '{"method":"dflash","model":"<DFlash2 경로>","num_speculative_tokens":7}'를 더했다.

llama.cpp판 실행 명령은 다음과 같다.

속도는 스트리밍 응답으로 계산했다. 생성한 토큰 수에서 1을 빼고, 첫 토큰이 나온 때부터 마지막 조각이 도착할 때까지 걸린 시간으로 나눴다. 모델 가중치는 Ornith 모델 카드의 MIT 표기를, 초안 모델 DFlash2는 Apache-2.0 라이선스를 따른다.