NVIDIA DGX Spark로 n8n AI 워크플로우를 로컬 구동

대부분의 소규모 비즈니스는 비슷한 몇 가지 AI 작업을 원합니다. 이메일 초안 작성, 통화 요약, 청구서 읽기, 자체 문서 검색, 그리고 가끔 이미지 생성이 그것입니다. 그중 상당수는 이런 작업을 위해 고객 데이터를 클라우드 API로 보낼 수 없습니다.

대개 그 이유는 데이터 프라이버시와 주권 때문입니다. 병원, 로펌, 회계사는 계약, 규제, 또는 직업상 의무에 따라 반드시 자신들이 통제하는 범위 안에 보관해야 하는 기록을 다룰 수 있습니다. 그 데이터가 클라우드 API로 넘어가는 순간, 데이터는 다른 사람의 하드웨어 위에 놓이게 되고, 심지어 다른 관할권에 있을 수도 있으며, 제공업체가 바꿀 수 있는 조건 아래 있게 됩니다. 직접 소유한 하드웨어에서 모델을 실행하면 데이터가 건물 안에 머물게 되고, 감사자에게 정확히 어디로 갔는지 보여줄 수 있습니다.

n8n 워크플로는 통화 내용을 텍스트로 변환하고, 청구서를 읽고, 자체 문서에서 질문에 답하고, 클라우드 API로 바이트 하나 보내지 않고도 답장을 초안으로 작성할 수 있습니다. 이 글에서는 n8n의 OpenAI 노드가 이미 이해하는 하나의 OpenAI 호환 엔드포인트 뒤에서, 그러한 워크플로에 필요한 모든 모델을 NVIDIA DGX Spark 한 대로 제공하는 방법을 보여줍니다.

DGX Spark는 CPU와 GPU가 공유하는 통합 메모리 128GB를 갖추고 있습니다. 올바른 모델을 선택한다면, 이런 작업들을 모두 동시에 올려둘 수 있을 만큼 충분한 용량입니다. 이 글의 대부분은 바로 그 부분에 관한 것입니다.

self-hosted AI starter kit는 한 사람이 노트북에서 로컬 모델을 실행할 수 있게 해줍니다. 이번 단계는 그 다음입니다. 사무실 안에 있는 한 대의 장비가 팀 전체에 서비스를 제공하고, 각 작업에 맞는 모델과 이를 실행하는 코드까지 갖춘 구성입니다.

이 글에서 다룰 내용:

• DGX Spark의 메모리 대역폭에 맞는 모델 선택하기
• vLLM을 사용해 NVFP4에서 35B Mixture-of-Experts 모델 제공하기
• 전체 AI 스택을 한 대의 장비 공유 메모리 안에 담기
• 팀별 키를 사용해 모든 작업을 하나의 LiteLLM 엔드포인트로 라우팅하기
• n8n을 스택에 연결하고 클라우드 API를 전혀 호출하지 않는 워크플로 만들기
• 누군가 이미지를 생성할 때 채팅 속도가 어떻게 변하는지 측정하기

파라미터 수가 아니라 대역폭에 맞춰 모델을 선택하세요

DGX Spark의 GB10 Grace Blackwell Superchip은 메모리를 초당 273GB로 읽습니다. 모델이 텍스트를 생성할 때는 토큰마다 활성 가중치를 메모리에서 읽어 오므로, 읽어야 할 바이트 수가 적을수록 더 빠르게 동작합니다.

Mixture-of-Experts(MoE) 모델은 토큰마다 일부 전문가만 활성화합니다. Qwen3.6-35B-A3B는 총 파라미터 수가 35B이지만, 활성화되는 것은 약 3B입니다. NVFP4(NVIDIA의 4비트 부동소수점 형식)로 저장하면, 이 활성 가중치는 일반적인 dense 모델에 비해 아주 작은 비율에 불과합니다.

제 DGX Spark에서는 Qwen3.6-35B-A3B가 한 사용자 기준 초당 120토큰을 생성했고, 8명의 사용자 전체 합계로는 초당 359토큰을 생성했습니다. 이 수치에는 모델이 답변을 내기 전에 작성하는 추론 토큰도 포함됩니다.

여기서 첫 번째 설계 원칙이 나옵니다. 텍스트 형태의 작업에는 강력한 MoE 모델 하나를 전부 사용한다. 요약, 분류, 추출, 초안 작성, 코딩, 스크린샷 읽기까지 모두 같은 모델로 처리합니다. 모델이 하나씩 늘어날 때마다 고정하고, 패치하고, 모니터링해야 할 컨테이너가 하나씩 늘어나므로, 전문 모델은 LLM으로는 할 수 없는 작업에만 자리를 줍니다.

스택

한 대의 DGX Spark에 계속 올려두는 모델은 다음과 같습니다:

스택의 모든 모델은 상업적 사용을 허용합니다. 이 규칙은 기술적인 어떤 규칙보다 더 큰 비용이 들었고, 이에 대한 내용은 나중에 다룹니다.

1단계: 오프라인 사용을 위해 모든 것을 캐시하세요

네트워크 케이블을 뽑은 상태에서도 스택이 동작해야 하므로, 각 모델을 한 번씩 다운로드하고 얻은 정확한 커밋을 기록해 두세요. 이 루프는 각 모델을 캐시하고 저장소와 커밋이 담긴 잠금 파일을 씁니다:

12345678pipx install "huggingface_hub[cli]"
hf auth login

for repo in nvidia/Qwen3.6-35B-A3B-NVFP4 Qwen/Qwen3-Embedding-4B Qwen/Qwen3-Reranker-0.6B \
            openai/whisper-large-v3-turbo zai-org/GLM-OCR Tongyi-MAI/Z-Image-Turbo; do
  hf download "$repo"
  echo "$repo $(cat ~/.cache/huggingface/hub/models--${repo//\//--}/refs/main)" >> models.lock
done

모델을 시작할 때는 models.lock의 커밋을 --revision에 넘기세요. 그러면 vLLM은 main이 오늘 가리키는 것이 아니라 테스트한 가중치를 제공하므로, 상위 저장소의 변경으로 가중치나 라이선스가 예고 없이 바뀌는 일을 막을 수 있습니다.

vLLM 버전을 확인하세요, 태그가 아니라

컨테이너도 같은 방식으로 고정하고, 그 안에 무엇이 들어 있는지 확인하세요. 제 첫 시도는 vLLM의 cu130-nightly 태그를 사용했습니다. 그 태그는 더 이상 갱신되지 않았고, 받아온 이미지는 5개월 전의 것으로 vLLM 0.19가 들어 있었습니다. 이 상태로는 Qwen3.6을 전혀 불러올 수 없었습니다. 오류 메시지에는 버전이 언급되지 않았습니다. 누락된 weight-scale 매개변수에 대한 KeyError였고, 보기에는 손상된 체크포인트처럼 보였습니다.

이미지를 믿기 전에, 그 안의 vLLM 버전을 출력해 보세요:

docker run --rm --entrypoint python3 <image> -c "import vllm; print(vllm.__version__)"

작동했던 이미지는 공식 vllm/vllm-omni:v0.30.0이었고, arm64 빌드가 포함된 vLLM 0.30.0을 제공합니다. vLLM-Omni는 이미지와 음성을 위한 추가 서빙 모드를 갖춘 완전한 vLLM이므로, 일반 LLM도 함께 서빙할 수 있습니다. 기본 엔트리포인트가 vllm serve가 아니므로, 한 번 감싸서 사용하세요:

printf 'FROM vllm/vllm-omni:v0.30.0\nENTRYPOINT ["vllm", "serve"]\n' | docker build -t vllm-spark:omni-0.30.0 -

Kokoro-FastAPI 이미지는 arm64에서 빌드되도록 커뮤니티의 수정이 필요했습니다. 이 Dockerfile은 NVIDIA Developer Forums의 swann.schilling의 게시물 에서 가져왔습니다.

2단계: 백본 서빙하기

이 명령은 vLLM에서 메인 모델을 시작합니다:

1234567891011121314docker run -d --name qwen3.6 --gpus all --ipc=host \
  -p 172.17.0.1:8001:8000 \
  -e HF_HUB_OFFLINE=1 -e VLLM_API_KEY=<your-backend-key> \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm-spark:omni-0.30.0 \
  nvidia/Qwen3.6-35B-A3B-NVFP4 --revision <commit-from-models.lock> \
  --served-model-name qwen3.6-35b \
  --gpu-memory-utilization 0.32 --max-model-len 65536 \
  --max-num-seqs 8 --max-num-batched-tokens 8192 \
  --trust-remote-code --kv-cache-dtype fp8 --moe-backend marlin \
  --enable-chunked-prefill --async-scheduling --enable-prefix-caching \
  --speculative-config '{"method":"mtp","num_speculative_tokens":3,"moe_backend":"triton"}' \
  --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_xml \
  --host 0.0.0.0 --port 8000

제 DGX Spark에서는 docker run 후 311초 만에 이 모델이 서빙 가능한 상태가 되었습니다.

포트는 Docker의 브리지 주소인 172.17.0.1에 공개되므로, 이 머신의 컨테이너만 접근할 수 있습니다. VLLM_API_KEY는 키가 없는 요청을 vLLM이 거부하게 합니다.

DGX Spark에서 가장 중요한 플래그는 다음과 같습니다.

• --gpu-memory-utilization 0.32는 이 모델이 메모리의 약 3분의 1만 쓰도록 제한합니다. 나머지는 다른 모델들이 필요로 합니다.
• --kv-cache-dtype fp8은 KV 캐시가 필요한 메모리를 절반으로 줄여, 같은 예산으로 더 긴 컨텍스트를 담을 수 있게 합니다.
• --moe-backend marlin은 양자화된 전문가 레이어에 사용할 커널을 선택합니다. 드래프트 모델의 전문가들은 양자화되어 있지 않으므로, --speculative-config가 자체 moe_backend를 설정합니다.
• --speculative-config는 다중 토큰 예측(MTP)을 켭니다. 이 모델은 앞으로 세 토큰을 초안으로 생성하고 한 번의 패스로 검증합니다.
• --reasoning-parser와 --tool-call-parser는 모델 계열과 일치해야 합니다. 도구 호출이 실패하면, 모델을 탓하기 전에 이 플래그들을 확인하세요.

vLLM이 어떤 커널을 선택했는지는 시작 로그에서 확인하세요. 제 실행에서 나온 줄은 다음과 같습니다:

1234Using MarlinNvFp4LinearKernel for NVFP4 GEMM
Using 'MARLIN' NvFp4 MoE backend out of potential backends: ['FLASHINFER_TRTLLM', 'FLASHINFER_CUTEDSL', ...]
Your GPU does not have native support for FP4 computation but FP4 quantization is being used.
Weight-only FP4 compression will be used leveraging the Marlin kernel.

마지막 경고는 DGX Spark에서 "NVFP4"를 어떻게 해석할지와 관련해 중요합니다. 이 vLLM 빌드에서는 가중치가 4비트로 저장되지만, 연산은 16비트로 수행됩니다. 그래도 대부분의 이점을 얻을 수 있는데, 토큰 생성의 병목은 메모리에서 가중치를 읽는 데 있고 4비트 가중치는 크기가 4분의 1이기 때문입니다. GB10용 더 빠른 FP4 커널이 이후 빌드에서 이 수치를 더 높일 수 있습니다.

3단계: 나머지를 공유 메모리에 맞추기

DGX Spark에서는 GPU와 운영체제가 하나의 128GB 풀을 공유합니다. 제 장비에서는 Linux가 그중 121GB를 총 메모리로 보고했습니다. 이 점은 일반적인 개별 GPU에서는 당연하게 여길 수 있는 두 가지를 바꿉니다.

첫째, --gpu-memory-utilization은 시작 시점에 전체 풀의 일부를 비율로 잡습니다. 남는 메모리의 비율이 아닙니다. 상한이 없는 인스턴스는 거의 전부를 가져가려 하고, 다음 모델은 시작하지 못합니다.

둘째, vLLM은 시작 시점에 남아 있는 메모리를 기준으로 캐시 크기를 정합니다. 두 모델을 동시에 시작하면 같은 메모리를 두고 경쟁하게 됩니다. 하나씩 시작하고, 다음 모델을 시작하기 전에 각각의 health check가 응답할 때까지 기다리세요:

until curl -sf http://172.17.0.1:8001/health; do sleep 5; done

모델이 CUDA error: out of memory로 실패했는데 free에서는 여유가 충분해 보인다면, Linux 페이지 캐시가 메모리를 잡고 있는 것입니다. 220GB의 가중치를 바로 다운로드한 직후에는 흔한 일입니다. 캐시를 비운 뒤 모델을 다시 시작하세요:

sudo sh -c 'sync; echo 3 > /proc/sys/vm/drop_caches'

페이지 캐시를 먼저 비운 상태에서 각 서비스가 콜드 상태로 로드되는 데 걸린 시간과, 사용한 메모리는 다음과 같습니다.

vLLM 0.30.0의 임베딩 모델에는 --convert embed라는 플래그가 하나 더 필요했고, 나머지 모델보다 더 늦게 시작했습니다. 7개 모델을 모두 로드한 상태에서 DGX Spark는 108GB를 사용했고 13GB가 남아 있었습니다. 이것이 DGX Spark 한 대가 수용할 수 있는 한계입니다. 누군가 필요로 하기 훨씬 전에 스택을 시작하세요. 표에 있는 6개 서비스는 시작하는 데 약 12분이 걸렸습니다.

또한 vLLM은 시작 시 Error in memory profiling으로 실패할 수 있습니다. vLLM이 사용 가능한 메모리를 측정하는 동안 다른 프로세스가 메모리를 해제하면 이런 일이 발생합니다. 공유 메모리 환경에서는 다른 모델이 로드 중이거나 종료 중일 때 이런 현상이 생깁니다. 박스가 조용해지면 모델을 다시 시작하세요.

4단계: 앞단에 하나의 엔드포인트 두기

LiteLLM은 모든 클라이언트에 OpenAI 호환 엔드포인트 하나를 제공합니다. 각 작업은 이름이 있는 라우트이므로, 어떤 클라이언트도 건드리지 않고 라우트 뒤의 모델을 바꿀 수 있습니다. LiteLLM은 오픈소스 버전에서도 가상 키, 팀, 예산을 처리합니다.

LiteLLM의 config.yaml 안 각 라우트는 백엔드를 가리킵니다. 아래 발췌문은 그중 3개를 보여줍니다:

1234567891011121314151617181920212223242526272829model_list:
  - model_name: qwen3.6                 # main model: chat, coding, vision, extraction
    litellm_params:
      model: hosted_vllm/qwen3.6-35b
      api_base: http://host.docker.internal:8001/v1
      api_key: os.environ/BACKEND_API_KEY

  - model_name: whisper
    litellm_params:
      model: openai/whisper-large-v3-turbo
      api_base: http://host.docker.internal:8101/v1
      api_key: os.environ/BACKEND_API_KEY
    model_info:
      mode: audio_transcription

  - model_name: image                   # Z-Image-Turbo on vLLM-Omni
    litellm_params:
      model: openai/z-image-turbo
      api_base: http://host.docker.internal:8103/v1
      api_key: os.environ/BACKEND_API_KEY
    model_info:
      mode: image_generation

litellm_settings:
  drop_params: true                     # needed for the image route, see below

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL

drop_params: true는 유지하세요. 이것이 없으면 LiteLLM은 response_format을 설정한 모든 이미지 요청을 400 오류로 거부합니다. 자체 호스팅 이미지 모델에 대해 이 필드를 매핑하지 않기 때문입니다. 이 설정이 있으면 LiteLLM이 해당 필드를 제거하고, vLLM-Omni는 어차피 이미지를 base64로 반환합니다.

LiteLLM도 Docker에서 실행됩니다. 백엔드에 접근할 수 있도록 하려면, Compose 서비스에서 host.docker.internal을 호스트에 매핑하세요:

    extra_hosts:
      - "host.docker.internal:host-gateway"

백엔드들은 Docker의 브리지 네트워크에서만 수신하고 공유 키를 필요로 하므로, 사무실 네트워크에 노출되는 서비스는 LiteLLM뿐입니다. LiteLLM은 박스의 LAN 주소가 아니라 브리지를 가리키게 하세요. LAN 주소를 사용하면 백엔드가 그 주소에서 수신하지 않기 때문에 연결을 거부합니다.

LiteLLM은 이미지 다이제스트로 고정하고, 버전 1.84.0 이상을 사용하세요. 2026년 3월에 PyPI 릴리스 두 개가 백도어 공격을 당했고, 1.84.0은 인증 우회 2개를 수정했습니다. 저는 1.99.1을 사용했습니다.

이제 어떤 OpenAI 클라이언트도 DGX Spark와 함께 작동합니다. 아래 Python 예시는 같은 클라이언트를 통해 3개의 서로 다른 모델을 호출합니다:

123456789101112131415161718from openai import OpenAI

client = OpenAI(base_url="http://<spark-ip>:4000/v1", api_key="<your-litellm-key>")

reply = client.chat.completions.create(
    model="qwen3.6",
    messages=[{"role": "user", "content": "Draft a two-line reply confirming Tuesday's delivery."}],
)

with open("call.wav", "rb") as audio:
    transcript = client.audio.transcriptions.create(model="whisper", file=audio)

image = client.images.generate(
    model="image",
    prompt="a delivery van outside a bakery at dawn",
    size="1024x1024",
    extra_body={"num_inference_steps": 8},
)

num_inference_steps는 OpenAI 파라미터가 아니므로 extra_body에 넣습니다. LiteLLM은 이를 vLLM-Omni로 전달합니다. 다음 섹션에서 그 이유를 설명합니다.

5단계: n8n 연결하기

n8n의 OpenAI 자격 증명은 사용자 지정 기본 URL을 허용하므로, n8n은 OpenAI와 통신하듯이 DGX Spark와 통신할 수 있습니다. n8n을 DGX Spark에 연결하려면 다음 단계를 따르세요:

1. 워크플로를 소유한 팀에 대해, 필요한 라우트로만 제한된 LiteLLM 가상 키를 만드세요. 다음 명령은 LiteLLM 마스터 키로 이를 생성하고 출력합니다:

curl -s http://<spark-ip>:4000/key/generate \
  -H "Authorization: Bearer <your-litellm-master-key>" -H 'Content-Type: application/json' \
  -d '{"key_alias": "n8n-accounts", "models": ["qwen3.6", "ocr"]}'

1. n8n에서 OpenAI 자격 증명을 만드세요.
2. API Key에 가상 키를 입력하세요.
3. Base URL을 http:// :4000/v1로 설정하세요.

각 팀이 자체 가상 키를 갖게 되므로, 토큰 단위 과금은 없더라도 LiteLLM은 팀별 지출과 사용량을 추적합니다.

AI Agent 또는 Basic LLM Chain에서 DGX Spark를 사용하려면, 이 자격 증명으로 OpenAI Chat Model 노드를 추가하고, 모델 By ID를 qwen3.6 같은 LiteLLM 라우트 이름으로 설정하세요. 그런 다음 노드 옵션에서 Use Responses API를 끄세요. 버전 1.3부터 이 노드는 기본적으로 OpenAI의 더 새로운 Responses API를 호출하는데, DGX Spark의 모델들은 chat completions를 통해 제공됩니다.

워크플로: 인보이스 읽기

이 워크플로는 웹 폼을 제공합니다. 인보이스 이미지를 업로드하면 클라우드 호출 없이 공급업체, 인보이스 번호, 날짜, 총액을 보여줍니다. 템플릿 받기 .

이 워크플로에는 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)는 qwen3.6에 공급업체, 인보이스 번호, 날짜, 총액, 통화를 JSON으로 요청합니다.
5. Invoice fields (Edit Fields)는 응답을 해당 5개 필드를 가진 하나의 item으로 바꿉니다.
6. Show the fields (Form Ending)는 폼의 결과 페이지에 이를 표시합니다.

인보이스를 자동으로 분류하려면 폼을 Email Trigger (IMAP) 노드로 바꾸고, 결과 페이지를 Postgres 또는 Google Sheets 노드로 바꾸세요.

두 HTTP Request 노드는 이전 섹션의 OpenAI 자격 증명을 사용하므로 동일한 키를 보냅니다. 둘 다 OpenAI 노드가 아니라 HTTP Request를 사용하는 이유는 각 호출에 OpenAI 노드가 설정하지 않는 필드가 하나씩 필요하기 때문입니다. OCR 호출에는 이미지가 필요하고, 추출 호출에는 생각 스위치가 필요합니다. 다음은 추출 요청의 본문입니다:

1234567{
  model: 'qwen3.6',
  max_tokens: 512,
  temperature: 0,
  chat_template_kwargs: { enable_thinking: false },
  messages: [{ role: 'user', content: 'Extract supplier name, invoice number, invoice date, total amount and currency from this OCR text. Reply with one JSON object and nothing else. Use null for anything missing.\n\n' + $json.choices[0].message.content }]
}

chat_template_kwargs는 이 호출에서 모델의 사고 과정을 끄며, 그 점이 속도의 원인입니다. 깨끗한 단일 페이지 샘플 인보이스에서 테스트했습니다:

사고 과정을 켠 상태에서는 모델이 78토큰 답변을 내기 전에 1,538개의 추론 토큰을 작성했습니다. 사고 과정을 끈 상태에서는 다섯 개 필드를 모두 1초도 안 되어 정확히 맞혔습니다. 고정 형식 추출에서는 사고 과정을 끄세요.

OCR은 모든 품목 항목과 합계를 올바르게 읽었지만, VAT ID에서 0 하나를 하나 누락했습니다. 파일링하기 전에 ID를 검증하세요. 이 폼은 PNG와 JPEG 파일을 받습니다. PDF 인보이스는 먼저 이미지로 변환하세요. GLM-OCR은 이미지를 사용하기 때문입니다.

스캔하거나 촬영한 인보이스는 이 깨끗한 페이지보다 더 어렵습니다. 따라서 OCR을 실제 문서에 적용하기 전에 직접 테스트해 보세요.

이 스택이 제공하는 다른 워크플로

• 통화 요약: Whisper가 녹음을 전사하고, qwen3.6이 이를 요약한 뒤, Kokoro가 그 요약을 음성사서함이나 내부 업데이트용으로 다시 읽어 줍니다.
• 자신의 문서로부터의 답변: embed가 벡터 스토어를 채우고, rerank가 일치 항목의 순서를 정하며, qwen3.6 위의 AI Agent가 그 항목들을 사용해 답합니다.

단일 DGX Spark에서 측정한 결과

모든 수치는 2026년 10월 13일에 vLLM 0.30.0과 고정된 모델 커밋으로 실행한 한 번의 벤치마크 결과에서 나왔습니다. 다른 이미지, 모델, 프롬프트를 쓰면 수치는 달라집니다. 모든 채팅 프롬프트는 랜덤 태그로 시작했기 때문에 prefix cache가 결과를 유리하게 만들 수 없었습니다.

채팅 속도

사용자당 속도는 각 요청의 생성 속도 중앙값이며, 첫 토큰이 나온 뒤를 기준으로 측정했습니다. 전체는 생성된 모든 토큰을 테스트 경과 시간으로 나눈 값이므로, 첫 토큰까지 걸린 시간과 더 느린 요청도 함께 반영합니다. 단일 사용자 실행에서는 다섯 개 요청 중 하나가 초당 43토큰으로 실행되었고, 나머지 넷은 117~129토큰으로 실행되어 전체 값이 87까지 내려갔습니다.

8,537토큰 프롬프트에서는 첫 토큰이 1.14초 걸렸습니다.

사용자당 속도는 사용자가 늘어날수록 떨어지지만, 전체 처리량은 계속 올라갑니다. 이것이 배칭의 효과입니다. vLLM은 가중치를 한 번 지나갈 때 여러 사용자를 함께 처리합니다.

그 밖의 모든 작업

음성은 양방향 모두 실제 시간보다 훨씬 빠릅니다. 30초 오디오를 양방향 모두 1초도 안 되어 처리합니다. Whisper의 전사는 정확했지만, 오디오에는 없는 "Thank you."를 끝에 덧붙였습니다. Whisper는 무음 구간에서 텍스트를 지어내는 것으로 알려져 있으므로, 전사하기 전에 끝부분의 무음을 잘라 내세요.

이미지 생성의 스텝 수는 직접 설정합니다. Z-Image-Turbo는 약 8스텝 만에 이미지를 만들도록 설계되었지만, vLLM-Omni의 기본값은 약 48스텝이었고 각 스텝이 1.5초 정도 걸려 이미지당 72초가 들었습니다. 8스텝에서는 같은 1024x1024 이미지가 12.2초 걸렸습니다.

이미지 생성 중 채팅하기

이 장비의 모든 모델은 하나의 GPU를 공유합니다. 메모리에 들어간다고 해서 함께 잘 돌아간다는 뜻은 아닙니다. 이 점에 대한 공개된 DGX Spark 벤치마크를 찾지 못해 직접 측정했습니다. 서버의 기본 스텝 수로 1024px 이미지를 연속 생성하는 동안 채팅 테스트를 다시 실행했습니다.

이미지가 생성되는 동안 채팅 속도는 평소의 약 3분의 1 수준이었고, 이미지도 느려져서 73초에서 85~122초 사이로 늘어났습니다.

하나의 DGX Spark가 전체 스택을 감당할 수는 있지만, 이미지 생성을 돌리면 모두의 채팅이 느려집니다. 작은 팀이라면 이미지 작업은 대기열에 넣거나 근무 시간 외에 실행하세요. 이미지 생성이 일상 업무의 일부가 되면 미디어 처리를 두 번째 DGX Spark로 옮기고 첫 번째는 텍스트 전용으로 두세요.

라이선스 문제

모델 품질이 어려운 부분은 아니었습니다. 라이선스가 문제였습니다.

최고 수준의 오픈 텍스트 음성 변환 및 이미지 모델 몇 가지는 상업적 사용을 허용하지 않습니다. Z-Image-Turbo와 경쟁하는 FLUX 모델은 비상업용이거나 별도로 가격이 책정된 라이선스가 필요합니다. 작성 시점의 가장 강력한 오픈 이미지 모델인 Qwen-Image-2.1은 연구용 라이선스로 제공됩니다. 일부 저장소는 관대한 원본 옆에 비상업용 쌍둥이 저장소를 두기도 해서, 잘못된 저장소 ID를 캐시하면 라이선스가 달라집니다.

이 스택이 따르는 규칙은 다음과 같습니다.

• Apache 2.0, MIT, CC-BY-4.0, OpenMDW, 그리고 NVIDIA Open Model License만 허용합니다.
• 모든 모델을 Hugging Face 커밋에 고정해 두어, 상류에서 라이선스가 바뀌어도 조용히 반영되지 않게 합니다.
• CC-BY-4.0 모델은 문서에 출처를 표기합니다.

이것은 법률 자문이 아닙니다. 판매하거나 고객에게 배포하기 전에 고정된 각 라이선스를 반드시 검토받으세요.

주의할 점

• 새 체크포인트는 고정해 둔 버전보다 더 최신의 vLLM이 필요할 수 있지만, 오류 메시지에는 그 내용이 나오지 않습니다. 먼저 이미지 안의 버전을 확인하세요.
• faster-whisper는 arm64용 CUDA 빌드가 없어서, 이를 기반으로 만든 도구는 알려주지 않아도 CPU에서 동작합니다.
• 이 스택은 스타터 키트에 포함된 Ollama 대신 vLLM을 사용합니다. Ollama는 노트북에서 한 사람이 쓰기에 적합합니다. 팀 환경에서는 vLLM이 여러 사용자의 요청을 각 가중치 통과마다 묶어 처리하며, 여기서 다중 사용자 처리량이 나옵니다.

직접 사용해 보기

• 인보이스 워크플로 템플릿 을 가져오세요.
• 아직 DGX Spark가 없다면 자체 호스팅 AI 스타터 키트 부터 더 작은 규모로 시작하세요.

자신의 DGX Spark에서 이걸 실행했다면, 결과 수치를 n8n 커뮤니티 포럼 에 공유해 주세요.

출처

• 원문: https://blog.n8n.io/n8n-nvidia-dgx-spark/ (2026-10-19 · Jamie Madden)