로컬 AI 가이드

사기 전에 속도와 비용부터

모델별 실행 레시피

최종 업데이트

Qwen3.6 35B-A3B 실행 설정: Mac·RTX·DGX Spark NVFP4

Qwen3.6 35B-A3B를 DGX Spark에서 vLLM으로 실행해요

Qwen3.6-35B-A3B는 텍스트 입력을 받아 답변을 생성하는 MoE1 모델이에요. DGX Spark 한 대에서는 NVIDIA ARM64·Blackwell용 vLLM 컨테이너와 공식 NVFP42 체크포인트3를 함께 사용해요. 이 안내는 모델을 로드하고 loopback API4에서 첫 응답을 확인한 다음 메모리와 문맥 옵션을 조절하는 흐름이에요.

NVFP4 가중치 형식, 컨테이너 버전, 모델 ID를 맞춰야 해요. NVFP4는 가중치 형식이고 FP85 KV cache6는 문맥 상태를 저장하는 별도 설정이에요. 먼저 TP1·8K 문맥·요청 하나로 endpoint를 확인하고, 그다음 긴 문맥이나 동시 요청, MTP7를 한 가지씩 시험해요.

목차
실행 조건과 핵심 내용
  • 단일 Spark 경로는 vLLM v0.28.0 컨테이너와 nvidia/Qwen3.6-35B-A3B-NVFP4를 사용해요.
  • 가중치의 NVFP4와 KV cache dtype은 다른 메모리 항목이에요.
  • 127.0.0.1에서 모델 목록과 짧은 completion을 확인해요.
장비별 실행 설정으로 이동

속도 체감값과 서버 실측을 먼저 구분해요

아래 세 장비의 속도 페이지는 4,096토큰8 입력, 한 명 사용 조건의 계산 기반 예상값이에요. 실제 서버에서 측정한 결과가 아니므로 실행 뒤 재현 기록과 같은 표본으로 섞지 않아요.

Mac mini M4 32GB의 Q4_K_M·가속 없음 조건은 생성 7.8~22.5 tok/s, 첫 토큰 5.5~15.7초, 입력 처리 263~757 tok/s, 필요 메모리 21.3GB, 사용 가능 27GB로 표시돼요. DGX Spark 128GB의 NVFP4·MTP 조건은 각각 61.2~111.1 tok/s, 1.5~3.1초, 1,341~2,661 tok/s, 필요 24.3GB, 사용 가능 116GB예요.

DGX Spark 두 대, 256GB의 Q4_K_M·가속 없음 예상값은 생성 17~61.4 tok/s, 첫 토큰 0.91~2.4초, 입력 처리 1,763~4,563 tok/s, 필요 메모리 21.3GB, 사용 가능 232GB예요. 두 장비의 메모리는 모델 분할에 쓸 수 있지만 답변 속도가 자동으로 두 배가 되지는 않아요. 연결과 분산 설정이 필요한 별도 구성이에요.

Qwen3.6 35B-A3B MoE 모델과 4K 입력 설정을 보여주는 장면
4K 입력·단일 요청 속도 페이지의 계산 예상값과 실제 서버 시험을 구분해요.

컨테이너와 모델 파일을 한 조합으로 맞춰요

DGX Spark에서는 이미지 생성용이나 다른 아키텍처용 컨테이너 대신 Spark 대상 NVIDIA vLLM 레시피를 사용해요. 여기서 다루는 건 GB10 단일 노드예요. 두 대 이상에서 Ray나 tensor parallel9을 설정하는 레시피는 네트워크와 분산 프로세스가 다른 별도 배포예요.

단일 Spark NVFP4 프로필은 vLLM v0.28.0 컨테이너와 nvidia/Qwen3.6-35B-A3B-NVFP4 저장소를 지정해요. NVIDIA 레시피에는 RTX 5090과 RTX PRO 6000용 프로필도 있지만, 이 절의 GB10 설정을 그 카드에 복사하지 않아요. 장비별 커널·메모리 설정과 모델 파일 접근 권한을 해당 경로에서 확인해요.

NVFP4는 모델 가중치에 쓰는 정밀도이고 --kv-cache-dtype fp8은 요청 문맥 상태를 저장하는 형식이에요. FP8 KV cache와 MTP, 컨텍스트 옵션을 한 번에 추가하지 말고 우선 공식 단일 Spark 설정으로 endpoint가 시작되는지 확인해요.

loopback endpoint를 열고 첫 응답을 확인해요

기본 확인은 컨테이너 v0.28.0, TP1, 8K 문맥, 동시 요청 한 개로 시작해요. 공식 GB10 경로의 FlashInfer·Marlin·FP8 KV와 메모리 비율 0.5는 그대로 두고, 문맥과 요청 수만 낮춘 프로필이에요. host networking을 사용하더라도 서버는 127.0.0.1에 묶어 로컬에서만 접근하게 해요.

서버 로그에서 가중치 적재와 엔진 준비가 끝난 뒤 /v1/models를 요청해요. 목록에 qwen3.6-35b-a3b가 보이면 chat completion의 model 값에도 그 이름을 써요. choices[0].message.content에 답이 있으면 API 연결을 확인한 거예요. 이 짧은 함수 설명은 동작 확인용이지 benchmark가 아니에요.

Spark NVFP4 최소 vLLM endpoint
docker run --rm --gpus all --ipc=host --network host -v "$HOME/.cache/huggingface:/root/.cache/huggingface" vllm/vllm-openai:v0.28.0 nvidia/Qwen3.6-35B-A3B-NVFP4 --served-model-name qwen3.6-35b-a3b --host 127.0.0.1 --port 8000 --tensor-parallel-size 1 --trust-remote-code --kv-cache-dtype fp8 --attention-backend flashinfer --moe-backend marlin --gpu-memory-utilization 0.5 --max-model-len 8192 --max-num-seqs 1
공식 Spark 프로필의 커널과 FP8 KV를 유지해요. 컨테이너가 vllm serve를 실행하므로 이미지 뒤에 모델 ID를 적어요.
모델 목록과 짧은 요청 확인
curl --fail-with-body http://127.0.0.1:8000/v1/models
curl --fail-with-body http://127.0.0.1:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{"model":"qwen3.6-35b-a3b","messages":[{"role":"user","content":"Explain this function's empty-input behavior in one sentence: def first_item(items): return items[0]"}],"temperature":0,"max_tokens":64}'
두 요청 모두 loopback 주소를 써요. 반환된 답은 연결 확인에만 사용해요.

문제가 난 단계에 맞춰 옵션을 바꿔요

서버가 응답한 뒤에는 기존 레시피의 FP8 KV, context limit, 동시 sequence 설정을 필요에 따라 조정해요. 긴 입력은 요청별 cache 공간을 늘리고 동시 요청은 여러 cache를 사용하므로, 두 값을 한 번에 올리지 않고 하나씩 시험해요.

컨테이너가 시작되지 않으면 이미지 tag, 모델 ID와 파일 접근, 아키텍처 지원을 로그에서 확인해요. 모델은 적재됐지만 요청 도중 메모리 오류가 나면 문맥이나 동시 sequence 중 하나를 낮춰요. playbook에 없는 옵션을 추가하기보다 시작 단계와 요청 단계 중 어디에서 실패했는지 먼저 나눠요.

두 대의 Spark에 모델을 나누는 Ray 구성을 단일 노드 명령과 섞지 않아요. 목표가 개인용 응답이라면 단일 Spark에서 실제 답변 시간과 메모리 상태가 충분한지 먼저 확인해요. 다중 Spark는 연결과 분산 실행이 필요한 별도 운영 선택이에요.

같은 실제 작업으로 결과를 평가해요

짧은 함수 설명이 끝나면 평소 작업을 그대로 보내요. 코드를 고칠 목적이라면 입력·출력 조건과 테스트도 함께 두고, 문서 질문이라면 답을 확인할 수 있는 날짜나 항목을 물어요. 시작 명령, 컨테이너 tag, 모델 revision, 요청 문구와 출력 상한을 기록해 두면 바꾼 옵션의 영향을 비교할 수 있어요.

결과를 직접 측정할 때는 준비 실행을 제외하고 반복 요청의 전체 완료 시간, GPU10 메모리와 답 정확성을 기록해요. 공식 지원 정보와 계산 기반 속도 예상은 실행 실측과 다른 자료예요. Qwen3 reasoning parser를 쓸 때는 vLLM 0.19.0 이상에서 해당 parser와 모델을 실제 지원하는지 확인하고, 버전 숫자만으로 동작을 단정하지 않아요.

oMLX 0.7.0의 공개 M5 Ultra 결과는 별도 플랫폼 참고값이에요. M5 Ultra 256GB·80코어 GPU에서 Qwen3.6-35B-A3B 4-bit code_python 시험은 최대 출력 128토큰, temperature 0 조건으로 4K 프리필11 9,126 tok/s와 디코드12 158.3 tok/s였어요. 0.7.0rc1은 각각 7,931 tok/s와 158.2 tok/s로, 해당 항목에서 프리필 값은 올랐지만 디코드는 거의 같아요. 이 표만으로 Qwen3.6의 MTP가 디코드를 가속한다고 말할 수는 없어요.

아래 이진 탐색 요청은 범용 모델 ID를 사용하는 예시예요. 앞의 Spark 명령으로 서버를 열었다면 요청의 model 값을 qwen3.6-35b-a3b로 바꿔요. 다른 서버에 연결할 때는 /v1/models에서 실제 이름을 조회해 넣어요. LM Studio라면 포트 1234와 앱에서 로드한 모델 식별자를 사용해요.

추론 응답 스트리밍 API 확인
curl -N http://127.0.0.1:8000/v1/chat/completions   -H "Content-Type: application/json"   -d '{
    "model": "Qwen/Qwen3.6-35B-A3B",
    "messages": [
      {"role": "user", "content": "파이썬으로 이진 탐색 함수를 작성하고 시간 복잡도를 설명해줘."}
    ],
    "max_tokens": 1024,
    "stream": true
  }'
vLLM 8000 포트로 질문을 보내고 stream에 reasoning과 최종 답변이 어떻게 도착하는지 확인해요.
실행 확인을 마친 뒤 실제 작업을 끝내 보는 과정을 나타내는 장면
기본 연결뿐 아니라 평소 코드나 문서 작업이 끝나는지 확인해요.

문맥과 동시 요청은 필요에 따라 하나씩 늘려요

24GB 데스크톱에서 Q4 변환본을 고른다면 약 20GB 안팎의 가중치 파일을 출발점으로 살펴봐요. 다운로드 항목의 실제 파일 크기를 확인하고, KV 캐시와 런타임13이 사용할 공간도 남겨요. 여기서 안내하는 Spark NVFP4 경로와는 파일 형식과 실행기가 다른 구성이에요.

24GB에서 여유가 적다면 우선 요청 하나와 짧은 문맥으로 기준 답변을 확인해요. 필요한 입력 길이를 단계적으로 늘릴 때마다 cache와 피크 메모리를 확인하고, 서버 설정 상한과 실제 입력 토큰 수도 따로 기록해요. 시스템 지시와 앞선 대화도 입력 길이에 포함될 수 있어요.

MTP를 추가했으면 같은 코드 요청에서 승인 길이와 첫 토큰 뒤의 디코드 시간이 바뀌는지 확인해요. 코드 작성 결과를 일반 글쓰기의 성능으로 일반화하지 않아요. 캐시 정밀도, 프리필 청크, MTP를 동시에 바꾸지 말고 실제로 늦었던 구간부터 시험해요.

짧은 기준 요청은 정상이고 긴 문맥에서만 OOM이나 스왑이 나타나면 먼저 context 또는 동시 sequence를 낮춰요. target 자체가 적재되지 않거나 짧은 요청에서도 메모리가 계속 부족하면 가중치 파일과 실행 메모리 조건을 다시 살펴요. 확인된 병목에 맞춰 더 큰 메모리 구성을 검토해요.

24GB 장비에서 모델 파일 적재 뒤 메모리를 살피는 안내 장면
모델 파일 적재 뒤에는 KV cache와 실제 요청이 쓸 여유도 확인해요.

공식 실행 자료에서 버전을 다시 확인해요

단일 Spark의 NVFP4 컨테이너와 공식 vLLM 체크포인트 경로는 아래 자료에서 확인해요. 명령을 실행하기 전 현재 이미지 tag와 모델 revision, 지원 옵션을 다시 대조해요.

LM Studio 경로에서는 Q4 파일을 먼저 내려받고 lms ls로 확인하세요. 다음 lms load에서 나타나는 목록에서 그 파일을 골라요. 적재한 모델의 API 별칭은 qwen36-local이에요. LM Studio에 연결할 때는 1234 포트와 이 별칭을 사용하고, 앞의 Spark vLLM 요청은 8000 포트와 기존 서버 별칭으로 유지하세요.

vLLM 0.19.0 이상 공식 체크포인트 (멀티 GPU)
GPU_COUNT=8 # The official example uses 8 GPUs; change this to match your system
vllm serve Qwen/Qwen3.6-35B-A3B   --host 127.0.0.1   --port 8000   --tensor-parallel-size "$GPU_COUNT"   --max-model-len 8192   --reasoning-parser qwen3   --gpu-memory-utilization 0.92
GPU 개수와 모델 경로를 운영 장비에 맞추는 공식 서버 예시예요.
LM Studio 데스크톱 서빙 (Q4 GGUF)
lms ls
lms load --gpu=max --context-length=8192 --identifier qwen36-local
lms server start --port 1234
32GB 이상 Mac 또는 고용량 GPU에서 Q4 파일을 로컬 데몬으로 제공하는 예시예요.

용어 각주

  1. MoE — 여러 전문가 하위망 중 일부를 입력에 따라 선택해 사용하는 모델 구조입니다. 총 파라미터 수와 한 토큰 처리에 활성화되는 파라미터 수는 다를 수 있습니다.

    본문으로 돌아가기

  2. NVFP4 — NVIDIA가 정의한 4비트 부동소수점 데이터 형식입니다. 지원 여부는 GPU 세대, 모델과 소프트웨어 구현에 따라 다릅니다.

    본문으로 돌아가기

  3. 체크포인트 — 학습된 모델의 가중치 등을 저장한 파일입니다. 같은 모델 계열도 버전이나 용도에 따라 다른 체크포인트를 쓸 수 있습니다.

    본문으로 돌아가기

  4. API — 프로그램의 기능을 다른 코드에서 호출하기 위한 약속된 인터페이스입니다.

    본문으로 돌아가기

  5. FP8 — 값 하나를 8비트로 표현하는 부동소수점 수치 형식입니다.

    본문으로 돌아가기

  6. KV 캐시 — 어텐션에서 이전 토큰의 키·값을 저장해 다음 토큰 생성 때 재사용하는 메모리입니다. 문맥 길이와 배치 크기에 따라 용량이 달라집니다.

    본문으로 돌아가기

  7. MTP — 한 번에 여러 미래 토큰을 예측하도록 학습하는 목표 또는 이를 수행하는 모델 구성입니다. 추측 디코딩에서는 이 예측을 후보 토큰으로 제안할 수 있습니다.

    본문으로 돌아가기

  8. 토큰 — 모델이 입력이나 출력을 나누어 처리하는 단위입니다.

    본문으로 돌아가기

  9. 텐서 병렬 — 모델 층 안의 행렬과 연산을 여러 장치로 분할해 함께 계산하는 방식입니다. 부분 결과를 모으기 위해 장치 간 통신이 필요합니다.

    본문으로 돌아가기

  10. GPU — 많은 계산을 병렬로 처리하는 프로세서입니다. AI 모델 실행에서는 모델 계산을 맡습니다.

    본문으로 돌아가기

  11. 프리필 — LLM이 입력 프롬프트를 읽고 각 토큰의 내부 표현을 계산하는 단계입니다. 입력이 길수록 처리할 토큰이 많아집니다.

    본문으로 돌아가기

  12. 토큰 디코드 — 입력과 앞서 만든 답변을 바탕으로 다음 출력 토큰을 차례로 생성하는 단계입니다.

    본문으로 돌아가기

  13. 런타임 — 프로그램이 실행될 때 필요한 기능을 제공하는 소프트웨어 환경입니다. 로컬 AI에서는 모델을 실행하는 엔진을 가리키기도 합니다.

    본문으로 돌아가기

자주 묻는 질문

이 글에서 가장 먼저 확인할 것은 무엇인가요?
Qwen3.6-35B-A3B는 텍스트 입력을 받아 답변을 생성하는 MoE 모델이에요. DGX Spark 한 대에서는 NVIDIA ARM64·Blackwell용 vLLM 컨테이너와 공식 NVFP4 체크포인트를 함께 사용해요. 이 안내는 모델을 로드하고 loopback API에서 첫 응답을 확인한 다음 메모리와 문맥 옵션을 조절하는 흐름이에요.
필요한 메모리는 어느 정도인가요?
Mac mini M4 32GB의 Q4_K_M·가속 없음 조건은 생성 7.8~22.5 tok/s, 첫 토큰 5.5~15.7초, 입력 처리 263~757 tok/s, 필요 메모리 21.3GB, 사용 가능 27GB로 표시돼요. DGX Spark 128GB의 NVFP4·MTP 조건은 각각 61.2~111.1 tok/s, 1.5~3.1초, 1,341~2,661 tok/s, 필요 24.3GB, 사용 가능 116GB예요.

실행 레시피

장비별 설정

한 사람이 사용할 때

사용할 장비를 고르면 실행 명령과 조정할 옵션이 나옵니다.

가용 메모리: 56GB / 대역폭: 307GB/s

운용 프로필

Apple MacBook Pro M5 Pro (64GB)

메모리 적정

권장 런타임: oMLX (MLX 4비트 (GGUF Q4_K_M과 별도 형식)) · 문서화된 런타임 설정

설치 직후 처음 실행하거나 매일 안정적으로 사용할 때

선택 프로필 문맥

16,384 토큰

런타임 문서 기반MBP M5 Pro 64GB · Q4 · 요청 1개

런타임 문서에 따른 시작 설정입니다. 아래 순서로 조정하며 속도를 비교하세요.

계산기 예상 디코드

22.6 ~ 54.1 tok/s

단일 사용자 예상치

계산기 예상 TTFT

8.9 ~ 21.2초

프리필: 774 ~ 1,854 tok/s

예상 메모리 점유

약 21.91GB / 56GB

남은 여유: 약 34.1GB

서버 주소

http://127.0.0.1:8000

로컬 전용 127.0.0.1

예상치는 계산기의 추천 양자화·가속과 16,384토큰 기준입니다. 위 실행 설정의 실측값은 아닙니다.

이 프로필의 실제 설정

적용값왜 이렇게 잡았나
가중치MLX 4비트 (GGUF Q4_K_M과 별도 형식)MLX 모델 디렉터리를 사용합니다. GGUF의 Q4_K_M과 같은 파일 형식이 아닙니다.
입력 길이 확인16,384요청 전 모델 설정의 입력 제한을 확인합니다. 이 실행 명령은 문맥 길이를 지정하지 않습니다.
KV 캐시모델 설정에서 확인이 실행 명령은 KV 캐시 정밀도를 지정하지 않습니다.
프리필 배치런타임 설정에서 확인llama.cpp의 batch-size와 ubatch-size를 MLX 설정값으로 대신 쓰지 않습니다.
동시 요청1한 요청의 속도를 확인합니다. 여러 요청의 합산 처리량과 구분합니다.
메모리 여유2GB 이상모델을 불러온 뒤 실제 메모리와 스왑 여부를 확인합니다.

MBP M5 Pro 64GB 실행 명령어 (oMLX)

Apple Silicon · MLX 모델 · 메모리 가드
MODEL_DIR="$HOME/.omlx/models"
omlx serve \
  --model-dir "$MODEL_DIR" \
  --host 127.0.0.1 \
  --port 8000 \
  --max-concurrent-requests 1 \
  --memory-guard balanced
먼저 이 설정으로 기준 속도를 기록한 뒤 아래 튜닝 순서를 따라 한 항목씩 바꿉니다.

실행 후 확인

  1. 01서버 시작 로그에서 모델 적재 완료와 실제 컨텍스트 길이를 확인합니다.
  2. 02준비 실행 뒤 요청은 하나씩 보냅니다. 길이가 같은 서로 다른 입력 세 개로 첫 입력 처리 시간을 기록합니다.
  3. 03같은 입력을 반복한 결과는 캐시 재사용으로 따로 기록합니다. 첫 입력 결과와 합치지 않습니다.
  4. 04프리필 tok/s, 디코드 tok/s, 피크 메모리를 함께 기록한 뒤 한 항목씩만 바꿉니다.

바뀌는 점

  • 문맥과 동시 요청을 보수적으로 잡아 장비의 최대 처리량보다 낮게 나올 수 있습니다.
추천 설정으로 속도 보기 MBP M5 Pro 64GB 가격·전력·판매 구성 보기

한 항목씩 조정

속도를 올리는 순서

여러 값을 한꺼번에 바꾸면 원인을 찾기 어렵습니다.

  1. STEP 1

    기준값 저장

    첫 입력과 캐시 재사용을 구분하고 각각 세 번 기록합니다. 프리필·디코드·피크 메모리를 함께 비교합니다.

    멈출 때: 오류가 있거나 메모리 여유가 2GB보다 작으면 다음 단계로 넘어가지 않습니다.

  2. STEP 2

    프리필 청크 조정

    1,024 → 2,048 → 4,096 순서로 올리며 긴 입력의 TTFT와 피크 메모리를 비교합니다.

    멈출 때: TTFT가 줄지 않거나 메모리 정점이 급증하면 직전 값으로 돌아갑니다.

  3. STEP 3

    KV 캐시 조정

    문맥이 부족할 때만 F16/BF16 기준값과 Q8 캐시를 같은 질문으로 비교합니다.

    멈출 때: 출력 차이가 생기거나 필요한 문맥이 이미 확보됐다면 기본 정밀도를 유지합니다.

  4. STEP 4

    MTP·투기 디코딩

    지원 모델에서만 켠 뒤 코드와 일반 문장을 나눠 수락률과 실제 디코드 tok/s를 측정합니다.

    멈출 때: 세 번의 중앙값이 기준보다 좋아지지 않으면 끕니다.

  5. STEP 5

    문맥 확장

    실제로 필요한 길이까지 두 배씩 늘리고 중간 정보 검색과 스왑 여부를 확인합니다.

    멈출 때: 검색 정확도가 떨어지거나 스왑·메모리 압축이 시작되면 한 단계 줄입니다.

내 장비 측정 기록 보내기

같은 조건으로 3회 이상 측정한 JSON을 가져오세요. 전송 버튼을 누르기 전에는 이 브라우저에서만 확인합니다.

장비·모델·실행 조건과 측정값만 받습니다. 질문·답변·원본 로그·파일 경로는 넣지 마세요.

기록 파일이 없다면, 실행 중인 로컬 서버에서 측정 도구로 만들 수 있습니다. Node.js 20 이상이 필요하며 결과를 자동 전송하지 않습니다.

측정 방법 읽기측정 도구 받기장비·설정 양식 받기

검토한 이용자 제출 기록입니다. 이 사이트의 직접 측정과는 구분합니다.

설정 오류 제보

선택한 설정에서 막힌 부분을 알려주세요. 제보는 관리자만 확인합니다.

전송할 설정 · MBP M5 Pro 64GB · Qwen3.6 35B-A3B (MoE) · 균형 설정

수정 내역

사이트의 안내가 바뀐 기록입니다. 설치된 엔진·모델 버전을 자동으로 확인한 결과는 아닙니다.

  1. Mac의 모델 형식과 실행 설정 정정

    Mac의 MLX 실행 경로를 GGUF Q4_K_M과 구분하고, 엔진 이름·모델 형식·명령의 표기를 맞췄습니다. 명령에서 지정하지 않는 KV 캐시 정밀도와 프리필 배치는 모델·런타임 설정에서 확인하도록 바꿨습니다.

    명령이 그대로인데 배치만 커진 것처럼 보이던 MLX 속도 프로필도 제거했습니다.

  2. 첫 입력과 캐시 재사용의 기록 분리

    검증 순서에서 처음 읽는 입력과 같은 입력을 반복한 결과를 따로 기록하도록 바꿨습니다. 캐시 효과를 프리필 처리량이나 장비 차이로 합산하지 않습니다.

  3. 장비·프로필 저장과 다시 열기 추가

    실행 가능한 프로필은 장비와 함께 이 브라우저에 최대 5개까지 저장하고, 가이드 목록에서 다시 열 수 있게 했습니다. 저장한 뒤 공개 설정이 바뀌거나 프로필이 없어지면 실행 전에 다시 확인하도록 안내합니다.

  4. 실행 엔진 설명으로 이어지는 링크 추가

    설정에 표시된 엔진 이름에서 해당 실행 프로그램의 설명으로 이어지도록 했습니다. 엔진이 확인되지 않은 경로에는 임의의 프로그램을 연결하지 않습니다.