왜 지금 '엣지에서의 추론(Reasoning)'인가
예전에는 멀티스텝 추론이 가능한 모델을 엣지 디바이스에서 돌린다는 건 사실상 불가능에 가까웠어요. 파라미터 수가 너무 커서 데이터센터 GPU를 써야 했고, 그 결과 네트워크 의존성, 비용 증가, 그리고 '데이터가 기기 밖으로 나가면 안 되는' 상황에서의 보안 리스크까지 따라붙었죠.
그런데 2026년 들어 상황이 확 바뀌었습니다. 컴팩트한 오픈 모델들이 데이터센터급 추론 성능을 엣지에서도 낼 수 있게 됐고, NVIDIA Jetson 라인업에서도 바로 돌릴 수 있게 됐어요. 차량 내 어시스턴트, 실시간 이상 감지, 통신이 불안정한 환경의 로봇 같은 시나리오에서 이게 바로 의미가 있습니다.
이 글에서는 Nemotron 3.5 Lightning과 Qwen3.8-27B를 예시로, Jetson에서 어떻게 모델을 고르고, 최적화하고, 검증하는지 실습 위주로 정리해볼게요.
참고로 이 내용은 NVIDIA Developer Blog의 근거자료를 바탕으로 실무 관점에서 재구성했습니다.
모델 선택: Dense vs MoE, 뭘 골라야 할까?
결론부터 말하면 워크로드 특성에 따라 다릅니다. 두 모델의 아키텍처 차이를 먼저 이해해야 해요.
| 구분 | Qwen3.8-27B | Nemotron 3.5 Lightning |
|---|---|---|
| 아키텍처 | Dense | MoE (Mixture-of-Experts) |
| 전체 파라미터 | 27B | 30B |
| 토큰당 활성 파라미터 | 27B (전부) | 3B |
| 적합한 워크로드 | 적은 수의 '어려운 결정' | 응답량 많은 반복 워크플로우 |
| 토큰 생성 속도 | 상대적으로 느림 | 빠름 |
- Nemotron 3.5 Lightning: MoE라서 토큰당 3B만 활성화됩니다. 응답 생성이 많은 에이전트 루프(센서 모니터링 → 조치 → 검증 → 에스컬레이션)에 유리해요.
- Qwen3.8-27B: Dense라서 매 토큰마다 27B 전부 계산. 대신 '한 번의 결정'에 깊은 추론이 필요한 작업에 강합니다.
Jetson Orin Nano라면 Gemma 4 E4B가 좋은 출발점이고, AGX Orin / AGX Thor라면 위 두 모델이 현실적인 선택지예요.
vLLM으로 서빙하기: 실전 커맨드
먼저 vLLM 컨테이너를 띄웁니다.
docker run --pull=always --runtime nvidia --rm -it \
--network host \
--ipc=host \
-v ~/.cache/huggingface:/root/.cache/huggingface \
--entrypoint bash \
vllm/vllm-openai:v0.28.0
Nemotron 3.5 Lightning (NVFP4 + DSpark)
vllm serve nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4 \
--reasoning-parser nemotron_v3 \
--enable-auto-tool-choice \
--tool-call-parser qwen3_coder \
--max-model-len 128000 \
--kv-cache-dtype fp8 \
--gpu-memory-utilization 0.7 \
--trust-remote-code \
--max-num-batched-tokens 16384 \
--enable-prefix-caching \
--speculative-config '{"method":"dspark","model":"nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4-DSpark","num_speculative_tokens":5}' \
--mamba-backend flashinfer \
--mamba-ssm-cache-dtype float16 \
--enable-mamba-cache-stochastic-rounding \
--mamba-cache-philox-rounds 5 \
--mamba-cache-mode align
Qwen3.8-27B (NVFP4 + DFlash2)
VLLM_GDN_DECODE_KERNEL=triton vllm serve Inferact/Qwen3.8-27B-NVFP4 \
--served-model-name qwen38 \
--reasoning-parser qwen3 \
--enable-auto-tool-choice \
--tool-call-parser qwen3_coder \
--max-model-len 50000 \
--max-num-seqs 8 \
--gpu-memory-utilization 0.85 \
--trust-remote-code \
--speculative-config '{"method":"dflash","model":"incoai/Qwen3.8-27B-DFlash2","num_speculative_tokens":7}'
포인트는 --speculative-config인데, 모델마다 최적의 draft 방식이 다릅니다. Nemotron은 DSpark, Qwen은 DFlash2가 가장 빨랐다는 점을 기억해두세요.
최적화 원리: NVFP4 + Speculative Decoding
두 기법은 서로 보완 관계예요.
- NVFP4 양자화: 각 추론 패스에서 GPU가 옮기고 계산해야 하는 데이터량을 줄입니다. BF16 대비 품질 손실을 최소화하면서 속도와 메모리 효율을 올려요.
- Speculative Decoding: 작은 draft 모델이 여러 토큰을 먼저 제안하고, 메인 모델이 한 번에 검증합니다. 여러 개가 수락되면 한 번의 패스로 여러 토큰을 생성하는 셈이죠.
Draft 방식 비교
| 방식 | 특징 | 호환성 |
|---|---|---|
| MTP | 메인 모델에 학습된 prediction head 사용 | Qwen, Gemma, Nemotron 등 광범위 |
| DFlash | 별도 diffusion 기반 draft가 블록 단위 제안 | 가장 많은 draft 체크포인트 지원 |
| DSpark | DFlash 확장, draft 보정 + 약한 제안 조기 중단 | 체크포인트 수는 적지만 더 빠를 수 있음 |
주의사항 (실무 관점)
- 벤치마크 수치에 속지 마세요. 모델 레벨 벤치마크는 시작점일 뿐이고, 실제 애플리케이션 프롬프트로 다시 측정해야 합니다. NVIDIA 측 테스트에서도 워크로드별 처리량 편차가 컸어요 (Nemotron 123
138 tok/s, Qwen 2734 tok/s). - Acceptance rate를 반드시 확인하세요. draft 토큰 수락률이 낮으면 검증 비용이 이득을 상쇄합니다.
- 국내 SI/제조 환경 주의점: 폐쇄망 공장이나 원격지 장비에 Jetson을 붙이는 경우, 모델 체크포인트를 사전에 이미지에 포함시켜두지 않으면 Hugging Face 접근이 막혀 초기 배포에서 삽질하기 쉽습니다. 오프라인 번들링을 미리 준비하세요.
- 커스텀 학습은 최후의 수단: 대부분은 기존 양자화 체크포인트로 충분합니다. 정확도가 문제될 때만 NVIDIA Model Optimizer의 QAT/QAD를 고려하세요.
마무리: 검증 없이는 배포 없다
정리하면 이 흐름입니다.
- 워크로드 특성 파악 → Dense(Qwen) vs MoE(Nemotron) 선택
- vLLM 컨테이너에서 NVFP4 체크포인트 서빙
- Speculative Decoding 설정은 모델별로 다르게 (DSpark vs DFlash2)
- 반드시 실제 애플리케이션 프롬프트로 재검증
- 정확도/속도 갭이 명확할 때만 커스텀 학습
엣지에서 추론 모델을 돌리는 시대가 본격적으로 열렸습니다. 데이터센터 왕복 없이 로컬에서 에이전트 루프를 완결할 수 있다는 건, 레이턴시와 보안 양쪽에서 큰 변화예요. 다음 단계로는 Jetson AI Lab의 모델 레시피를 참고해 본인 워크로드에 맞는 조합을 찾아보시는 걸 추천합니다.