n8n 공식 블로그(2026-10-19)가 NVIDIA DGX Spark 한 대로 클라우드 API 없이 전체 AI 스택을 운영하고 n8n 워크플로우에 연결하는 방법을 공개했습니다. 데이터를 외부로 보낼 수 없는 의원·법무법인·회계사무소 등 규제 업종을 주요 대상으로 하며, 텍스트·음성·이미지·OCR 모두 사무실 내 장비에서 처리합니다.
이 설정으로 자동화할 수 있는 것
n8n 공식 블로그(2026년 10월 19일 게시)에 따르면 DGX Spark 한 대로 다음 업무를 클라우드 API 호출 없이 처리할 수 있습니다.
– **인보이스 자동 처리**: 이미지 업로드 → GLM-OCR로 텍스트 추출 → Qwen3.6으로 공급사·청구번호·날짜·금액 JSON 추출 → 결과 표시 또는 데이터베이스 저장
– **통화 요약**: Whisper로 녹음 전사 → qwen3.6으로 요약 → Kokoro로 음성 변환
– **문서 Q&A**: 임베딩으로 벡터 스토어 구성 → 리랭킹 → AI Agent가 답변 생성
– **이메일 자동 처리**: Email Trigger(IMAP)로 수신 → 처리 → Google Sheets 또는 Postgres 저장
공식 설명에서 이 모든 작업이 클라우드 API 없이 사무실 내 장비에서 처리됩니다.
- 인보이스·통화·문서·이미지 생성 — 모두 클라우드 API 없이 사무실 내 처리
- 형식이 고정된 추출 작업은 thinking 비활성화로 응답 시간 0.59초(thinking 활성화 시 12.1초) 달성
- n8n 워크플로우는 HTTP Request 노드 또는 OpenAI Chat Model 노드로 동일 엔드포인트 사용
근거: Run your n8n AI workflows on NVIDIA DGX Spark, with no cloud API – n8n Blog
DGX Spark에서 선택해야 하는 모델과 이유
공식 블로그는 모델을 파라미터 수가 아닌 메모리 대역폭 기준으로 선택하도록 안내합니다. DGX Spark의 GB10 Grace Blackwell Superchip은 메모리 대역폭이 273 GB/s이며, 텍스트 생성 시 토큰당 활성 가중치를 메모리에서 읽기 때문에 읽는 바이트 수가 적을수록 빠릅니다.
공식 블로그에 명시된 스택(모두 상업적 사용 허가 라이선스):
| 용도 | 모델 | 라이선스 |
|—|—|—|
| 채팅·코딩·비전·추출 | nvidia/Qwen3.6-35B-A3B-NVFP4 | Apache 2.0 |
| 임베딩 | Qwen/Qwen3-Embedding-4B | Apache 2.0 |
| 리랭킹 | Qwen/Qwen3-Reranker-0.6B | Apache 2.0 |
| 음성→텍스트 | openai/whisper-large-v3-turbo | MIT |
| 문서 OCR | zai-org/GLM-OCR | MIT |
| 이미지 생성 | Tongyi-MAI/Z-Image-Turbo | Apache 2.0 |
| 텍스트→음성 | hexgrad/Kokoro-82M | Apache 2.0 |
공식 설명에서 MoE 모델(Qwen3.6-35B-A3B)은 전체 35B 파라미터 중 토큰당 약 3B만 활성화되며, NVFP4로 저장하면 활성 가중치가 크게 줄어든다고 명시합니다. 벤치마크(2026-10-13, vLLM 0.30.0 기준) 기준 단일 사용자 기준 사용자당 120 토큰/초, 총 처리량 87 토큰/초이며, 8명 동시 사용 시 총 359 토큰/초입니다.
공식 주석: 단일 사용자 총 처리량(87 tok/s)이 사용자당 속도(120 tok/s)보다 낮은 이유는 5개 요청 중 1개가 43 tok/s로 느리게 처리됐기 때문입니다.
- 메모리 대역폭 273 GB/s 기준: 읽는 바이트가 적을수록 생성 속도 향상
- MoE 구조: 35B 파라미터, 토큰당 약 3B만 활성화 → 속도 유리
- 스택 7종 모두 상업적 사용 허가 라이선스 (Apache 2.0 또는 MIT)
- 벤치마크: 1명 사용자당 120 tok/s · 총 처리량 87 tok/s, 8명 동시 사용 시 전체 359 tok/s (2026-10-13, vLLM 0.30.0 기준)
근거: Run your n8n AI workflows on NVIDIA DGX Spark, with no cloud API – n8n Blog
메모리 배분과 모델 기동 순서
공식 블로그에 따르면 DGX Spark는 GPU와 운영체제가 128GB 메모리 풀을 공유합니다. 이 구조에서 두 가지 주의사항이 공식적으로 명시됩니다.
1. **–gpu-memory-utilization은 전체 풀의 비율**: 남은 여유 메모리가 아닌 전체 128GB 기준입니다. 제한 없이 시작하면 거의 전부를 가져가 다음 모델이 시작되지 않습니다.
2. **반드시 한 번에 하나씩 기동**: vLLM은 시작 시 여유 메모리를 측정해 캐시 크기를 정합니다. 두 모델을 동시에 시작하면 같은 메모리를 놓고 경쟁합니다.
공식 블로그에 명시된 대기 명령:
“`
until curl -sf http://172.17.0.1:8001/health; do sleep 5; done
“`
각 서비스의 로드 시간과 메모리 점유(공식 측정값, 페이지 캐시 해제 후 콜드 스타트 기준):
| 서비스 | 준비까지(초) | 점유(GB) |
|—|—|—|
| qwen3.6 | 237 | 43 |
| rerank | 106 | 8 |
| whisper | 136 | 8 |
| ocr | 137 | 11 |
| image | 96 | 20 |
| tts | 21 | 3 |
공식 블로그는 qwen3.6 모델이 `docker run` 실행 후 서비스 준비까지 311초가 소요됐다고 별도로 명시합니다. 위 표의 237초는 페이지 캐시 해제 후 콜드 스타트 측정값이며, 311초는 실제 운영 환경의 docker run 기준 수치입니다.
7개 모델 전체 로드 시 108GB 사용, 13GB 여유. 공식 설명에서 스택 전체 기동까지 약 12분이 소요된다고 명시합니다.
**CUDA OOM 오류 대처**: 여유 메모리가 충분해 보여도 OOM이 발생하면 Linux 페이지 캐시가 메모리를 점유한 경우입니다. 공식 안내 명령:
“`
sudo sh -c 'sync; echo 3 > /proc/sys/vm/drop_caches'
“`
- –gpu-memory-utilization 0.32: 주 모델을 전체 메모리의 약 1/3으로 제한
- 모델은 반드시 하나씩 기동, 헬스체크 통과 후 다음 모델 시작
- qwen3.6: 콜드 스타트 표 기준 237초, docker run 기준 311초 (공식 별도 명시)
- 7모델 전체: 108GB 사용, 13GB 여유, 기동 약 12분
- OOM 오류 시 페이지 캐시 해제(drop_caches) 후 재시도
근거: Run your n8n AI workflows on NVIDIA DGX Spark, with no cloud API – n8n Blog
vLLM과 LiteLLM 설정 — 버전 고정이 핵심
공식 블로그는 컨테이너와 모델 버전을 반드시 고정하도록 강조합니다.
**모델 버전 고정(공식 안내)**:
“`
hf download "$repo"
echo "$repo $(cat ~/.cache/huggingface/hub/models–${repo//\//–}/refs/main)" >> models.lock
“`
`–revision` 플래그로 models.lock의 커밋을 지정하면 업스트림 변경으로 가중치나 라이선스가 바뀌는 것을 방지합니다.
**vLLM 버전 확인 필수(공식 경험)**:
공식 블로그에 따르면 cu130-nightly 태그를 사용했더니 5개월 전 이미지(vLLM 0.19)가 내려받아졌고, Qwen3.6 로드 실패가 버전 불일치가 아닌 가중치 오류처럼 보였다고 명시합니다.
“`
docker run –rm –entrypoint python3 <image> -c "import vllm; print(vllm.__version__)"
“`
공식 블로그가 사용한 이미지: `vllm/vllm-omni:v0.30.0`(arm64 빌드 포함, vLLM 0.30.0)
**LiteLLM 버전 주의(공식 명시)**: 2026년 3월 두 개의 PyPI 릴리스에서 백도어가 발견됐으며, 1.84.0에서 인증 우회 취약점 2건이 수정됐습니다. 공식 블로그 실행 버전은 1.99.1입니다. 이미지 다이제스트로 버전을 고정하도록 권장합니다.
**주요 vLLM 플래그(공식 안내)**:
– `–gpu-memory-utilization 0.32`: 전체 메모리의 약 1/3으로 제한
– `–kv-cache-dtype fp8`: KV 캐시 메모리를 절반으로 절감
– `–reasoning-parser qwen3` / `–tool-call-parser qwen3_xml`: 모델 패밀리와 반드시 일치해야 함
– `–speculative-config MTP`: 3토큰 미리 예측 후 한 번에 검증
- 모델 버전: models.lock에 커밋 기록 후 –revision으로 고정
- vLLM 버전: 반드시 컨테이너 내부에서 직접 확인(태그 신뢰 금지)
- LiteLLM 1.84.0 이상 사용 필수 — 인증 우회 취약점 수정 버전
- –kv-cache-dtype fp8로 KV 캐시 메모리 절반 절감
- LiteLLM drop_params: true — 이미지 라우트에서 반드시 필요, 없으면 400 오류
근거: Run your n8n AI workflows on NVIDIA DGX Spark, with no cloud API – n8n Blog
n8n에서 DGX Spark 연결하기
공식 블로그에 안내된 n8n 연결 방법입니다.
**1단계: LiteLLM 가상 키 생성**
“`
curl -s http://<spark-ip>:4000/key/generate \
-H "Authorization: Bearer <litellm-master-key>" \
-H 'Content-Type: application/json' \
-d '{"key_alias": "n8n-accounts", "models": ["qwen3.6", "ocr"]}'
“`
팀별로 키를 발급하면 LiteLLM이 팀별 사용량과 지출을 추적합니다.
**2단계: n8n OpenAI 자격증명 설정**
– API Key: 위에서 생성한 가상 키 입력
– Base URL: `http://<spark-ip>:4000/v1`
**3단계: 노드 설정 주의사항(공식 명시)**
AI Agent 또는 Basic LLM Chain 노드에 OpenAI Chat Model 노드를 추가할 때 **옵션에서 'Use Responses API'를 반드시 끄세요**. n8n 1.3 버전부터 기본값이 OpenAI Responses API로 변경됐으나, DGX Spark 모델은 chat completions로 제공됩니다.
**4단계: 모델 이름 지정**
모델 ID에 LiteLLM 라우트 이름(예: `qwen3.6`)을 직접 입력합니다.
HTTP Request 노드도 동일한 OpenAI 자격증명을 사용할 수 있으며, 공식 인보이스 워크플로우는 OCR 단계와 추출 단계 모두 HTTP Request 노드로 구성됩니다.
- LiteLLM 가상 키: 팀별 발급, 허용 라우트 목록 지정 가능
- n8n OpenAI 자격증명: Base URL = http://<spark-ip>:4000/v1
- Use Responses API 반드시 비활성화 (n8n 1.3 이후 기본값 변경됨)
- 모델 ID에 LiteLLM 라우트 이름(qwen3.6 등) 직접 입력
근거: Run your n8n AI workflows on NVIDIA DGX Spark, with no cloud API – n8n Blog
인보이스 자동화 워크플로우 — 단계별 구성
공식 블로그에 명시된 인보이스 워크플로우 구성입니다(공식 템플릿 제공).
노드 6개:
1. **Upload invoice** (n8n Form Trigger): 파일 필드 하나의 웹 폼 제공
2. **Image to base64** (Extract from File): 업로드 파일을 base64 문자열로 변환
3. **OCR on the DGX Spark** (HTTP Request): `ocr` 라우트로 이미지 전송, 텍스트 반환
4. **Extract fields with Qwen3.6** (HTTP Request): 공급사·청구번호·날짜·금액·통화를 JSON으로 추출
5. **Invoice fields** (Edit Fields): 5개 필드로 정리
6. **Show the fields** (Form Ending): 폼 결과 페이지에 표시
**추출 요청 본문 핵심 설정(공식 제시)**:
“`json
{
"model": "qwen3.6",
"chat_template_kwargs": {"enable_thinking": false},
…
}
“`
공식 측정값(단일 페이지 샘플 인보이스): thinking 활성화 시 12.1초(1,616 토큰), thinking 비활성화 시 0.59초(76 토큰). 형식이 고정된 추출에는 thinking을 끄도록 공식 안내합니다.
**공식 주의사항**:
– GLM-OCR은 이미지만 입력 가능. PDF는 이미지로 변환 후 처리 필요
– OCR이 VAT ID에서 숫자를 누락한 사례 확인됨 → 파일링 전 ID 검증 필요
– 스캔·촬영 인보이스는 깨끗한 디지털 인보이스보다 어려울 수 있음 → 실제 문서로 먼저 테스트 권장
– 이메일로 자동 수신하려면 Form Trigger를 Email Trigger(IMAP)로, 결과 페이지를 Postgres·Google Sheets 노드로 교체
- 폼 업로드 → OCR(GLM-OCR) → JSON 추출(Qwen3.6) → 결과 표시 또는 DB 저장
- thinking 비활성화: 추출 시간 0.59초 / 활성화: 12.1초 (공식 측정값)
- PDF는 이미지 변환 필수, OCR 결과의 ID·숫자는 반드시 검증
- 이메일 수신 자동화: Form Trigger → Email Trigger(IMAP) 교체
근거: Run your n8n AI workflows on NVIDIA DGX Spark, with no cloud API – n8n Blog
보안·프라이버시 설계와 네트워크 분리
공식 블로그에 명시된 보안 설계 원칙입니다.
**데이터 로컬 보관의 의미**: 클라우드 API로 데이터를 보내면 공급자의 하드웨어에 저장되며, 다른 국가에 위치할 수 있고, 공급자가 약관을 변경할 수 있습니다. 공식 블로그는 의원·법무법인·회계사무소처럼 계약·규제·직업적 의무로 데이터를 직접 관리해야 하는 업종을 주요 대상으로 명시합니다.
**네트워크 분리(공식 안내)**:
– 각 vLLM 백엔드는 Docker 브리지 주소(172.17.0.1)에만 노출 → 같은 서버의 컨테이너만 접근 가능
– VLLM_API_KEY로 키 없는 요청 거부
– LiteLLM만 사무실 네트워크에 노출 → 단일 진입점
– LiteLLM 설정에서 백엔드 주소를 LAN 주소가 아닌 브리지 주소로 지정해야 함(LAN 주소로 지정하면 백엔드가 거부)
**가상 키로 접근 제어**: 팀별로 허용 라우트를 다르게 설정한 가상 키를 발급합니다. LiteLLM 오픈소스 버전에서 팀·예산·사용량 추적이 가능합니다.
**모델 오프라인 운영**: 모든 모델을 사전에 다운로드하고 `HF_HUB_OFFLINE=1` 환경변수로 네트워크 케이블을 뽑아도 동작하도록 설정합니다. 공식 안내에서 감사자에게 데이터가 어디로 갔는지 정확히 보여줄 수 있다고 명시합니다.
- vLLM 백엔드: Docker 브리지만 노출, 키 없는 요청 거부
- LiteLLM 단일 진입점: 팀별 가상 키, 허용 라우트·예산 제어
- HF_HUB_OFFLINE=1: 네트워크 없이 완전 오프라인 운영 가능
- 규제 업종(의료·법무·회계) 데이터 주권 요건에 대응 가능
근거: Run your n8n AI workflows on NVIDIA DGX Spark, with no cloud API – n8n Blog
누가 써야 하는가 — 적합한 조직과 제약 조건
공식 블로그에서 명시하거나 설명에서 직접 도출할 수 있는 적합한 사용 조건입니다.
**적합한 경우**:
– 데이터를 클라우드로 보낼 수 없는 규제 업종(의료·법무·회계·금융)
– 팀 전체가 공유하는 온프레미스 AI 인프라가 필요한 소규모 조직
– n8n Cloud 또는 셀프 호스팅 환경에서 외부 API 비용 없이 AI를 운영하고 싶은 팀
– 텍스트·음성·이미지·OCR을 한 대의 장비에서 모두 처리해야 하는 팀
**현재 제약사항(공식 기준)**:
– DGX Spark 하드웨어 필요: 128GB 통합 메모리, GB10 Grace Blackwell Superchip
– 7개 모델 전체 로드 시 108GB 사용, 확장 불가 (13GB 여유가 상한)
– **이미지 생성 중 채팅 속도 약 1/3 수준으로 저하**: 공식 측정 결과, 이미지 생성이 진행되는 동안 1인 채팅 속도는 122→38 tok/s(-69%), 4인 동시 사용은 69→24 tok/s(-65%)로 하락합니다. 이미지 생성 자체도 느려집니다(73초→85~122초). 소규모 팀의 경우 이미지 작업을 큐에 넣거나 업무 시간 외에 처리하는 것을 공식 블로그가 권장합니다.
– PDF → 이미지 변환 단계 별도 필요 (GLM-OCR은 이미지 입력만 지원)
– 벤치마크는 2026-10-13, vLLM 0.30.0, 핀된 모델 커밋 기준이며 다른 이미지·모델·프롬프트에서는 다를 수 있음
**이 설정이 필요 없는 경우**:
– 데이터 규제가 없고 클라우드 API를 자유롭게 사용할 수 있는 경우 → n8n Cloud + Gemini/OpenAI 연동이 더 간단
– 단일 사용자 노트북 환경 → n8n 자체 AI 스타터 킷이 더 적합하다고 공식 블로그에 명시
- DGX Spark 필요: 128GB 통합 메모리, 7모델 로드 시 108GB 사용
- 규제 업종의 데이터 주권 요건에 가장 적합
- 이미지 생성 중 채팅 속도 약 1/3로 하락 (-65~-69%): 이미지 작업은 큐 처리 또는 업무 시간 외 권장 (공식 측정)
- 클라우드 규제 없는 환경: n8n Cloud + 외부 API 연동이 더 단순
- 노트북 단독 환경: n8n AI 스타터 킷이 더 적합(공식 블로그 명시)
근거: Run your n8n AI workflows on NVIDIA DGX Spark, with no cloud API – n8n Blog
공식 자료 확인 기준
이 글의 공식 자료 확인일은 2026년 10월 20일이며, 원문 게시일은 2026년 10월 19일입니다. 벤치마크 수치(토큰 속도, 로드 시간, 메모리 점유)는 2026년 10월 13일 단일 측정 기준이며 vLLM 버전·모델 커밋·하드웨어 상태에 따라 달라질 수 있습니다. LiteLLM 보안 업데이트, vLLM 새 릴리스, 각 모델 라이선스 변경은 각 공급자 공식 페이지에서 최신 정보를 확인하세요.
- 공식 자료: n8n 공식 블로그(blog.n8n.io) 2026-10-19 게시
- 벤치마크: 2026-10-13, vLLM 0.30.0, 핀된 커밋 기준 — 환경마다 다름
- LiteLLM 1.84.0+ 필수 (인증 우회 취약점 수정)
- 모델 라이선스·단가 변경은 각 공급자 공식 페이지 별도 확인
근거: Run your n8n AI workflows on NVIDIA DGX Spark, with no cloud API – n8n Blog
자료 확인 기준
2026년 10월 20일에 공식 원문을 확인했습니다. 확인일과 정책·공연의 시행일은 다를 수 있으며 변경 공지는 원문을 우선합니다.
답글 남기기