[
  {
    "url": "https://localai.co.kr/guides/qwen-3.8-27b-release-local-guide",
    "slug": "qwen-3.8-27b-release-local-guide",
    "title": "Qwen3.8-27B 공개: 32GB급 장비에서 돌릴 만할까",
    "description": "Qwen3.8-27B 오픈웨이트 모델의 27B 밀집 구조, Q4 메모리 요구량, 256K 문맥, 이미지·영상 입력과 MTP를 로컬 장비 선택 관점에서 정리합니다.",
    "headline": "이번 공개 모델에서 개인 장비와 가장 가까운 선택지는 27B 밀집형입니다.",
    "category": "release",
    "categoryLabel": "새로 나온 모델",
    "term": "Qwen3.8-27B",
    "alternateName": "Qwen 3.8 27B Open-Weight Model",
    "plainSummary": "새 모델이 나왔다는 소식을 들으면 지금 장비에서도 될지부터 궁금해집니다. Qwen3.8-27B는 개인 장비에서 양자화해 검토할 만한 크기지만, ‘27B니까 27GB’로 계산할 수는 없습니다. 내가 쓸 파일과 문서 길이를 정해 실제 필요한 공간부터 보겠습니다.",
    "buyerNote": "모델 이름의 27B만 보고 27GB가 필요하다고 계산하지 마세요. 양자화한 가중치, KV 캐시, 비전 입력과 런타임이 각각 메모리를 사용합니다.",
    "keyPoints": [
      "27B 전체를 매 토큰에 사용하는 밀집 모델이며 네이티브 문맥은 262,144토큰입니다.",
      "Q4 가중치는 대략 17GB 안팎이지만 실제 실행에는 KV 캐시와 런타임 여유가 더 필요합니다.",
      "이미지·영상 입력과 다단계 MTP를 지원하지만 변환본과 런타임별 지원 여부는 다릅니다."
    ],
    "sections": [
      {
        "title": "이 모델로 해보고 싶은 일을 하나 고릅니다",
        "paragraphs": [
          "Qwen3.8-27B는 텍스트와 시각 자료를 입력으로 다루는 밀집형 모델입니다. 문서를 정리하면서 화면 캡처도 함께 묻고 싶은 경우에 살펴볼 수 있습니다. 이미지를 이해한다는 말은 새 이미지나 영상을 생성한다는 뜻과는 다릅니다.",
          "새 모델이라는 이유만으로 기존 모델을 바로 지울 필요는 없습니다. 평소 잘 안 풀리던 코드나 문서 질문을 준비해 결과를 비교해보세요. 모델 소개의 장점이 내 질문에서도 나타나는지 확인하는 것이 교체의 첫 단계입니다."
        ]
      },
      {
        "title": "원본과 Q4 변환본은 다른 구매 조건입니다",
        "paragraphs": [
          "공식 BF16 가중치와 데스크톱용 Q4 변환본은 크기와 실행 경로가 다릅니다. 27B 숫자는 파라미터 규모이지 파일의 GB 표기가 아닙니다. 같은 이름의 파일도 양자화와 포함된 구성 요소에 따라 용량이 달라집니다.",
          "기존 가이드에서 잡은 Q4 가중치 약 17GB대는 출발점으로만 사용하고 받을 파일을 직접 확인하세요. GPU에 들어간 뒤에도 작업 공간과 KV 캐시가 필요합니다. 24GB 카드에서 로드가 됐다고 긴 문서와 이미지까지 같은 여유로 처리할 수 있는 것은 아닙니다."
        ]
      },
      {
        "title": "32GB라는 숫자도 어디에 있는지 봐야 합니다",
        "paragraphs": [
          "외장 GPU의 VRAM과 맥의 통합 메모리는 다른 조건입니다. 맥은 운영체제와 다른 앱이 공간을 함께 쓰므로 모델 전용으로 전부 사용할 수 없습니다. 브라우저와 편집기를 켜놓고 사용할 계획이라면 그 상태의 여유도 필요합니다.",
          "현재 장비가 있다면 짧은 문맥과 한 요청에서 먼저 시작합니다. 긴 문서가 일상적인 작업인지, 가끔만 필요한지에 따라 메모리를 더 살 이유가 달라집니다. 실행 가능 용량만으로 가장 쾌적한 장비까지 고를 수는 없습니다."
        ]
      },
      {
        "title": "긴 문맥과 MTP는 지원과 실사용을 나눕니다",
        "paragraphs": [
          "모델이 지원하는 최대 문맥은 내 장비에 곧바로 적용할 기본값이 아닙니다. 필요한 길이로 시작해 메모리와 첫 토큰을 확인하고 늘리세요. 입력이 길어지면 생성 속도보다 앞쪽 기다림이 더 중요해질 수 있습니다.",
          "MTP 역시 변환본에 관련 가중치가 있고 런타임이 지원해야 합니다. 일반 생성부터 기준을 남긴 뒤 켜야 효과를 분리할 수 있습니다. 이미지 입력과 생각 과정 처리도 현재 앱에서 정상적으로 전달되는지 따로 확인합니다."
        ]
      },
      {
        "title": "더 작은 모델로 충분하다면",
        "paragraphs": [
          "짧은 답변과 간단한 문서 처리에서 작은 모델의 결과가 충분할 수 있습니다. 27B를 위해 장비를 키우기 전에 내가 얻고 싶은 개선이 실제로 있는지 확인해보세요. 코드 오류가 줄거나 놓치던 문서 조건을 더 잘 찾는다면 추가 메모리의 이유가 됩니다.",
          "그다음 장비 선택기에서 같은 Q4와 입력 길이로 예상 체감을 비교하세요. 이 글은 모든 후보를 직접 측정한 구매 보증이 아닙니다. 새 모델의 발표가 장비 구매의 마감일은 아니므로, 현재 하려는 일이 되는지 먼저 시험해도 늦지 않습니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/release-qwen38-27b-workstation.webp",
        "alt": "창가의 작업대에 놓인 고메모리 소형 컴퓨터와 그래픽카드 데스크톱 장비 사진",
        "caption": "Qwen3.8-27B Q4는 24GB에서도 짧은 문맥으로 시작할 수 있지만, 다른 앱과 긴 문맥까지 생각하면 32GB 이상에서 운용 여유가 생깁니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/release-qwen38-27b-dense.webp",
        "alt": "균일한 메모리 모듈 전체가 하나의 계산 보드로 이어지는 27B 밀집 모델 표현 사진",
        "caption": "밀집 모델은 토큰을 만들 때 넓은 가중치 영역을 계속 사용하므로 모델이 들어가는 용량과 메모리 대역폭을 함께 봐야 합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/release-qwen38-27b-multimodal.webp",
        "alt": "사진과 도면, 긴 문서를 로컬 워크스테이션 옆에 펼쳐 놓은 멀티모달 작업대 사진",
        "caption": "문서뿐 아니라 이미지와 영상 입력도 다룰 수 있어, 로컬 장비를 고를 때는 비전 입력이 추가로 쓰는 메모리도 남겨 두는 편이 안전합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/qwen-3.8-flash-next-release-local-guide",
    "slug": "qwen-3.8-flash-next-release-local-guide",
    "title": "Qwen3.8-Flash-Next 공개: 활성 6B인데 왜 180B를 담아야 하나",
    "description": "Qwen3.8-Flash-Next의 180B 상주 가중치, 6B 활성 MoE, 51B PLE 테이블과 4B MTP를 구분하고 DGX Spark와 256GB 장비의 실행 가능성을 설명합니다.",
    "headline": "계산에 쓰는 부분은 작아도, 보관할 모델은 큽니다.",
    "category": "release",
    "categoryLabel": "새로 나온 모델",
    "term": "Qwen3.8-Flash-Next",
    "alternateName": "Qwen 3.8 Flash Next Open-Weight MoE",
    "plainSummary": "활성 6B라는 설명을 보면 가벼운 모델처럼 느껴집니다. 그런데 파일은 훨씬 크고 128GB 장비에서도 특별한 설정이 필요하다고 합니다. Qwen3.8-Flash-Next를 이해하려면 계산할 부분과 보관할 부분이 왜 다른지부터 나누어야 합니다.",
    "buyerNote": "활성 파라미터는 속도를 짐작하는 숫자이고, 전체 상주 가중치는 장비가 담아야 하는 용량입니다. 둘 중 하나만 보면 구매 판단이 틀어집니다.",
    "keyPoints": [
      "코어 LM 125B, PLE 계열 51B와 MTP 4B를 합쳐 약 180B가 상주합니다.",
      "토큰당 활성 계산은 약 6B지만 전체 가중치가 메모리·RAM·SSD 가운데 접근 가능한 곳에 있어야 합니다.",
      "단일 DGX Spark 경로는 일반 설치가 아니라 NVFP4와 PLE SSD 오프로드를 사용하는 실험 구성입니다."
    ],
    "sections": [
      {
        "title": "작다는 말이 가리키는 부분",
        "paragraphs": [
          "Flash-Next는 일부 전문가를 선택해 계산하는 MoE 구조입니다. 활성 규모는 한 토큰에서 쓰는 경로를 설명합니다. 모델의 전체 가중치를 그만큼만 내려받거나 작은 GPU에 담아도 된다는 뜻은 아닙니다.",
          "이 모델의 등록 구성은 코어 LM 약 125B, PLE 계열 테이블 약 51B, MTP 약 4B를 구분합니다. 합계 약 180B의 보관 규모와 토큰당 약 6B 활성 수치를 같은 용량 칸에 넣으면 장비 요구량을 크게 오해할 수 있습니다."
        ]
      },
      {
        "title": "큰 테이블을 다른 곳에 두는 방법",
        "paragraphs": [
          "PLE 테이블을 RAM이나 SSD에 배치하는 지원 경로가 있으면 고속 메모리의 부담을 줄일 수 있습니다. 이것은 디코드 후보를 만드는 반복 문구 가속과 다릅니다. MTP는 후보 예측, PLE 오프로드는 저장 위치라는 역할을 나누어 봐야 합니다.",
          "저장 위치를 바꾸면 조회와 전송 비용이 생길 수 있습니다. 특히 SSD 경로는 첫 접근과 캐시가 남은 반복 접근의 차이가 큽니다. 모델이 실행된다는 장점과 평소 질문이 빨리 끝난다는 장점을 별도로 확인해야 합니다."
        ]
      },
      {
        "title": "단일 Spark 기록은 실행 묶음으로 읽습니다",
        "paragraphs": [
          "단일 DGX Spark의 실험 경로는 특정 NVFP4 체크포인트와 PLE mmap 패치 같은 구성을 사용합니다. 명령어 한 줄이나 토큰 속도만 가져오면 필요한 파일과 패치가 빠질 수 있습니다. 일반 설치로 바로 재현된다는 뜻은 아닙니다.",
          "같은 128GB 안에서 GPU와 CPU의 위치만 바꾸는 것은 물리 메모리를 늘리지 않습니다. 어떤 부분이 NVMe에 있는지, 나머지 가중치와 캐시가 어디에 있는지를 확인해야 단일 장비 경로가 왜 가능한지 이해할 수 있습니다."
        ]
      },
      {
        "title": "두 대를 연결할 때 얻는 것은 무엇일까요?",
        "paragraphs": [
          "두 노드에 나눠 담으면 공간의 여유를 늘릴 수 있습니다. 반면 계산 중 결과를 주고받는 시간이 추가됩니다. 한 답변의 속도가 정확히 두 배가 되는 것은 아니며, 모델 분할과 연결·가속 설정에 따라 달라집니다.",
          "두 대 결과와 한 대 결과를 비교할 때는 모델 파일과 MTP, 입력 길이를 맞춰야 합니다. 서로 다른 압축본의 최고 기록을 장비 수의 효과로만 설명하면 다음 구매에서도 같은 차이를 기대하게 됩니다."
        ]
      },
      {
        "title": "이 실험이 내게 필요한지",
        "paragraphs": [
          "새 실행 경로를 만들어보고 큰 모델을 다루는 것 자체가 목적이라면 충분히 흥미로운 선택입니다. 하지만 매일 문서와 코드를 처리할 도구가 필요하다면 설치와 복구, 업데이트 부담도 함께 봐야 합니다.",
          "이미 작은 모델로 되는 일을 위해 복잡성을 늘릴 필요는 없습니다. 반대로 이 모델에서만 얻는 결과가 있다면 해당 레시피의 조건을 확인하고 예상 체감을 비교하세요. ‘돌릴 수 있다’ 다음에 ‘내가 계속 쓸 수 있다’가 남아 있는 모델입니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/release-qwen38-flash-archive.webp",
        "alt": "대형 가중치 보관 벽에서 일부 모듈만 작업등 아래 활성화된 희소 모델 작업실 사진",
        "caption": "토큰마다 약 6B만 활성화돼도 전체 가중치는 접근 가능한 메모리나 저장장치에 있어야 하므로 작은 모델처럼 적재할 수는 없습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/release-qwen38-flash-memory-tiers.webp",
        "alt": "가속기와 시스템 메모리, 저장장치가 세 층으로 나뉜 대형 모델 적재 작업대 사진",
        "caption": "코어 모델과 PLE 테이블, 캐시의 위치를 나누면 제한된 고속 메모리에서도 실행 경로를 만들 수 있지만 저장장치 전송 지연이 붙습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/release-qwen38-flash-dual-node.webp",
        "alt": "짧은 고속 케이블로 연결된 두 대의 동일한 소형 AI 컴퓨터 사진",
        "caption": "두 노드 구성은 한 대보다 넉넉하게 모델을 나눠 담지만, 한 답변 속도는 연결 비용 때문에 장비 수만큼 늘지 않습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/gemma-4-release-local-guide",
    "slug": "gemma-4-release-local-guide",
    "title": "Gemma 4 공개: 12B와 26B-A4B 중 내 장비에 맞는 모델",
    "description": "Gemma 4 오픈웨이트 모델의 12B 밀집형과 26B-A4B MoE를 중심으로 멀티모달 입력, 256K 문맥, Q4 메모리와 16GB·24GB 장비 선택을 설명합니다.",
    "headline": "같은 Gemma 4라도 크기에 따라 필요한 메모리가 다릅니다.",
    "category": "release",
    "categoryLabel": "새로 나온 모델",
    "term": "Gemma 4",
    "alternateName": "Google Gemma 4 Open-Weight Models",
    "plainSummary": "Gemma 4에는 여러 크기가 있어 고르기가 오히려 어렵습니다. 작은 모델을 받았다가 더 큰 모델의 답변을 놓치는 것은 아닐까 걱정될 수 있습니다. 하지만 내 장비에서 계속 켜두고 쓸 수 있는지도 중요합니다. 12B와 26B-A4B를 중심으로 그 차이를 읽어보겠습니다.",
    "buyerNote": "작은 모델이 무조건 나쁜 것이 아니라 내 장비에서 오프로딩 없이 계속 상주하는 모델이 실제로 더 빠르고 편할 수 있습니다.",
    "keyPoints": [
      "Gemma 4는 E2B·E4B·12B·26B-A4B·31B 크기와 최대 256K 문맥을 제공합니다.",
      "12B는 밀집형, 26B-A4B는 전체 약 26B 중 토큰당 약 4B가 활성화되는 MoE입니다.",
      "16GB 장비는 12B Q4부터, 24GB 이상은 26B-A4B Q4를 검토하는 구간입니다."
    ],
    "sections": [
      {
        "title": "크기보다 사용할 장면을 먼저 놓습니다",
        "paragraphs": [
          "노트북에서 짧은 문서를 정리할 모델과 긴 코드를 계속 생성할 모델의 조건은 다를 수 있습니다. 텍스트 외에 이미지나 음성 입력이 필요한지도 정해야 합니다. 제품군 전체에 소개된 기능이 모든 크기와 변환본에서 똑같이 된다고 보면 안 됩니다.",
          "처음에는 평소 질문 몇 개를 작은 후보에 보내봅니다. 답변이 충분한지, 잘못된 부분을 확인하기 쉬운지 보는 것이 출발점입니다. 크기가 작다는 이유만으로 탈락시키면 이미 가진 장비로 할 수 있는 일을 놓칠 수 있습니다."
        ]
      },
      {
        "title": "12B와 26B-A4B는 숫자만 다른 것이 아닙니다",
        "paragraphs": [
          "12B는 밀집형, 26B-A4B는 전체 가중치 중 일부를 토큰마다 사용하는 MoE입니다. 더 큰 총규모가 매 토큰의 계산량도 같은 비율로 늘어난다는 뜻은 아닙니다. 그렇다고 활성 부분만 메모리에 올리면 되는 것도 아닙니다.",
          "실제로 받을 Q4 파일과 실행 후 캐시·작업 공간을 합쳐보세요. 12B의 공식 가중치는 약 24GB 규모로 확인되지만 이를 데스크톱 Q4 파일의 요구량과 섞으면 안 됩니다. 원본과 변환본은 다른 실행 조건입니다."
        ]
      },
      {
        "title": "작은 메모리에서 먼저 확인할 것",
        "paragraphs": [
          "16GB급 장비라면 호환되는 12B Q4를 짧은 문맥과 한 요청에서 시험하는 식으로 접근할 수 있습니다. 맥에서는 운영체제와 다른 앱도 같은 메모리를 쓰므로 표시 용량만 보고 성공을 보장할 수는 없습니다.",
          "26B-A4B는 전체 전문가 가중치를 보관할 공간이 더 필요합니다. 현재 장비에서 일부가 RAM으로 넘어간다면 낮은 활성 계산량의 이점이 전송 대기에 가려질 수 있습니다. 메모리에 충분히 들어가는 조건과 속도를 함께 확인하세요."
        ]
      },
      {
        "title": "이미지와 음성을 더할 때",
        "paragraphs": [
          "텍스트 질문이 잘 된 뒤 이미지나 오디오 입력을 하나씩 추가합니다. 현재 모델 크기와 앱이 지원하는 입력인지 확인하고 메모리와 첫 토큰 시간이 어떻게 달라지는지 봅니다. 입력 처리 구성 요소가 추가되면 텍스트만 보던 때와 여유가 다를 수 있습니다.",
          "지원 최대 문맥도 처음부터 전부 켤 필요는 없습니다. 실제 문서 길이로 시작해 늘리면서 중요한 내용을 제대로 찾는지 확인하세요. 긴 문서를 받아들였다는 사실과 끝까지 정확하게 활용했다는 사실은 별개입니다."
        ]
      },
      {
        "title": "큰 모델로 바꿀 이유가 생겼을 때",
        "paragraphs": [
          "작은 모델에서 반복해서 틀리는 질문을 큰 모델에도 보내보세요. 실제 오류가 줄고 기다림이 감당할 만하다면 추가 메모리에 비용을 쓸 이유가 있습니다. 결과 차이가 작다면 작은 모델을 여유 있게 유지하는 선택도 가능합니다.",
          "새 제품군의 가장 큰 모델을 모두 따라갈 필요는 없습니다. 지금의 문서와 코드를 처리하는 모델 하나를 안정적으로 남기는 것도 좋은 선택입니다. 장비 비교는 그 모델과 입력 길이가 정해진 뒤에 해도 됩니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/release-gemma4-multimodal.webp",
        "alt": "노트북과 소형 컴퓨터 옆에 카메라와 마이크, 헤드폰이 놓인 로컬 멀티모달 작업대 사진",
        "caption": "Gemma 4의 작은 크기들은 노트북과 소형 데스크톱에서 문서·이미지·오디오 입력을 한 모델로 다루려는 경우에 잘 맞습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/release-gemma4-dense-moe.webp",
        "alt": "하나의 연속 계산 장치와 여러 전문 모듈이 담긴 큰 장치를 나란히 놓은 비교 모형 사진",
        "caption": "12B 밀집 모델과 26B-A4B MoE는 이름의 크기뿐 아니라 전체 적재량과 토큰당 활성 계산량이 서로 다릅니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/release-gemma4-hardware-choice.webp",
        "alt": "얇은 노트북과 통풍구가 큰 데스크톱을 같은 작업대에 나란히 놓은 장비 선택 사진",
        "caption": "16GB급은 12B Q4의 가벼운 사용부터, 24GB 이상은 26B-A4B Q4와 긴 문맥을 검토하는 출발점이 됩니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/server-scale-open-weight-models-2026",
    "slug": "server-scale-open-weight-models-2026",
    "title": "GLM-5.3·DeepSeek-V4 공개: 오픈웨이트인데 개인 PC에서 가능한가",
    "description": "GLM-5.3-Flash 320B와 DeepSeek-V4-Flash-0731 304B를 통해 오픈웨이트와 개인용 로컬 실행의 차이, 활성 파라미터, 분산 적재와 압축본 조건을 설명합니다.",
    "headline": "가중치를 받을 수 있다는 것과 한 대의 소비자용 컴퓨터에서 실용적으로 돌릴 수 있다는 것은 다릅니다.",
    "category": "release",
    "categoryLabel": "새로 나온 모델",
    "term": "서버급 오픈웨이트 LLM",
    "alternateName": "Server-Scale Open-Weight Large Language Models",
    "plainSummary": "가중치가 공개됐다는 소식에 파일을 받으려다 크기부터 놀랄 수 있습니다. 오픈웨이트는 누구나 작은 PC에서 실행한다는 뜻일까요? GLM-5.3-Flash와 DeepSeek-V4-Flash 같은 대형 모델은 공개 여부와 실행 장비의 규모를 나누어 읽어야 합니다.",
    "buyerNote": "모델 카드의 활성 B 숫자를 단일 GPU 메모리 요구량으로 읽지 마세요. 공식 가중치, FP8·FP4 체크포인트와 커뮤니티 Q4 변환본은 크기와 실행 경로가 다릅니다.",
    "keyPoints": [
      "GLM-5.3-Flash는 약 320B 전체·18B 활성, DeepSeek-V4-Flash-0731은 약 304B 전체·13B 활성입니다.",
      "두 모델 모두 매우 긴 문맥을 지원하지만 최대 문맥을 실제 서버의 기본값으로 쓰지는 않습니다.",
      "256GB 통합 메모리에서의 실행은 공식 서버 경로가 아니라 호환되는 압축 변환본이 있을 때의 별도 실험입니다."
    ],
    "sections": [
      {
        "title": "내가 통제하는 환경과 내 책상 한 대는 다릅니다",
        "paragraphs": [
          "오픈웨이트는 정해진 라이선스 조건으로 가중치를 받아 직접 다룰 수 있다는 뜻입니다. 파일이 공개됐다고 메모리와 실행 프로그램의 요구가 작아지는 것은 아닙니다. 한 회사가 운영하는 여러 서버에서도 외부 추론 서비스 없이 실행할 수 있습니다.",
          "따라서 로컬이라는 말은 개인 노트북부터 조직의 내부 서버까지 다른 규모를 포함할 수 있습니다. 모델 발표의 서버 예시를 내 그래픽카드 한 장의 설치 설명처럼 읽으면 장비 조건을 잘못 판단할 수 있습니다."
        ]
      },
      {
        "title": "작은 활성 숫자 뒤에 큰 보관 규모가 있습니다",
        "paragraphs": [
          "이 사이트에 등록된 GLM-5.3-Flash는 전체 약 320B·활성 약 18B, DeepSeek-V4-Flash는 전체 약 304B·활성 약 13B를 구분합니다. 활성 수치는 토큰 하나에서 쓰는 경로이며 전체 파일을 그 규모로 줄여주지 않습니다.",
          "낮은 정밀도로 바꾸더라도 전체 가중치, 캐시와 런타임 공간을 합쳐야 합니다. 어느 모델이 더 가볍다는 판단도 파일 형식과 분할 경로 없이 숫자 하나로 정할 수는 없습니다. 커뮤니티 압축본과 공식 체크포인트도 조건이 다릅니다."
        ]
      },
      {
        "title": "여러 가속기는 연결까지 하나의 구성입니다",
        "paragraphs": [
          "모델을 나누면 각 GPU는 맡은 가중치와 상태를 저장하고 계산 중 필요한 결과를 주고받습니다. GPU 수와 메모리 합계뿐 아니라 실제 연결과 런타임의 병렬 방식이 중요해집니다.",
          "공식 예시가 특정 서버 노드를 사용한다면 같은 개수의 소비자 GPU를 꽂았다고 같은 구성은 아닙니다. 카드별 메모리, 연결 대역폭과 지원 커널이 다릅니다. 복사할 명령보다 먼저 그 명령이 전제로 한 장비를 확인해야 합니다."
        ]
      },
      {
        "title": "대용량 맥에서도 파일과 실행 경로는 따로 확인합니다",
        "paragraphs": [
          "통합 메모리가 크면 압축본을 담을 가능성이 넓어지지만, 새 모델 구조를 앱이 처리하는지는 별개의 문제입니다. 다운로드가 가능하고 용량 계산이 맞아도 실제 실행은 실패할 수 있습니다. 해당 변환본과 버전의 재현 기록이 필요합니다.",
          "최대 문맥을 모두 사용하면 캐시와 입력 처리 부담도 커집니다. 모델이 켜진 뒤 짧은 질문부터 확인하고 긴 문서로 늘려야 합니다. 결과가 나왔을 때는 속도뿐 아니라 문서의 중요한 내용을 놓치지 않았는지도 봐야 합니다."
        ]
      },
      {
        "title": "큰 모델이 꼭 필요한 작업이 있나요?",
        "paragraphs": [
          "작은 모델로 해결되지 않던 질문을 큰 모델에서 더 정확하게 처리한다면 비용을 검토할 이유가 있습니다. 여러 사람이 함께 사용할 서버라면 총 처리량과 운영 통제도 가치가 됩니다. 다만 모델 순위표의 차이가 내 작업에서도 그대로 나타나는지는 확인해야 합니다.",
          "한 사람이 문서와 코딩을 시작하려는 목적이라면 더 작은 모델부터 충분히 쓸 수 있습니다. 공개된 큰 모델을 당장 실행하지 못한다고 로컬 AI를 시작할 수 없는 것은 아닙니다. 내게 필요한 결과가 나오는 규모에서 시작하고, 부족한 이유를 찾았을 때 확장해도 됩니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/release-server-model-chassis.webp",
        "alt": "네 개의 대형 가속기와 굵은 전원 및 냉각 케이블이 장착된 개방형 서버 사진",
        "caption": "수백 B급 공식 체크포인트는 내려받을 수 있다는 사실과 한 대의 소비자용 컴퓨터에서 실용적으로 돌릴 수 있다는 사실을 구분해야 합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/release-server-model-sharding.webp",
        "alt": "네 묶음의 모델 모듈이 각각 계산 장치와 연결된 균형 잡힌 분산 적재 모형 사진",
        "caption": "대형 MoE는 전체 가중치를 여러 가속기에 나누고, 각 토큰마다 선택된 전문가의 결과를 다시 모으는 분산 실행이 필요합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/release-server-model-scale.webp",
        "alt": "일반 작업실의 소형 컴퓨터와 문 너머 여러 가속기 랙을 함께 보여 주는 규모 비교 사진",
        "caption": "같은 오픈웨이트 모델이라도 Q4 변환본과 공식 체크포인트, 단일 사용자와 서버 운용은 필요한 장비 규모가 완전히 달라집니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/monthly-local-ai-speed-2026-09",
    "slug": "monthly-local-ai-speed-2026-09",
    "title": "월간 로컬 AI 속도표: 2026년 9월",
    "description": "2026년 9월 기준 주요 맥과 NVIDIA GPU, DGX Spark, AMD 통합 메모리 장비의 프리필과 토큰 생성 속도를 같은 조건으로 비교합니다.",
    "headline": "이번 달에 실제로 함께 고민할 만한 장비를 같은 모델과 입력 길이로 맞춰 봤습니다.",
    "category": "speed",
    "categoryLabel": "답변 속도와 가속",
    "term": "월간 로컬 AI 속도표",
    "alternateName": "Monthly Local AI Speed Table",
    "plainSummary": "속도표를 열면 자연스럽게 가장 높은 숫자부터 찾게 됩니다. 그런데 그 장비가 내게도 가장 나은 선택인지는 별개의 문제입니다. 이번 표는 답변을 쓰는 속도뿐 아니라 시작 전의 기다림도 함께 봅니다. 순위를 외우기보다 후보 두 개를 남기는 자료로 읽어보세요.",
    "buyerNote": "내 모델이 여유 있게 들어가면서 기다릴 만한 장비를 찾으세요. 이 표는 고정 기록이고, 현재 설정은 장비 비교 화면에서 바꿀 수 있습니다.",
    "keyPoints": [
      "Q4 양자화와 동일한 입력 길이로 장비별 차이를 맞췄습니다.",
      "프리필·디코드·전체 완료 시간을 따로 읽을 수 있습니다.",
      "속도표의 두 장비를 그대로 나란히 실행해 볼 수 있습니다."
    ],
    "sections": [
      {
        "title": "이 표가 비교하는 장면부터 보겠습니다",
        "paragraphs": [
          "이번 기록은 Qwen3.6 35B-A3B의 4비트 모델, 입력 4,096토큰과 답변 302토큰 조건을 사용합니다. 질문이나 모델을 자유롭게 섞은 최고 기록 모음이 아닙니다. 같은 일을 맡긴다고 가정해 장비 차이를 살펴보기 위한 고정 조건입니다.",
          "수치는 사양과 벤치마크 보정을 이용한 계산 결과입니다. 모든 장비를 직접 소유해 측정한 값은 아닙니다. 근거가 없는 MTP 배율을 일괄 적용하지 않았으며, 여러 장비 구성은 지원 런타임이 모델을 나누는 조건의 예상치입니다."
        ]
      },
      {
        "title": "첫 번째 후보는 메모리로 고릅니다",
        "paragraphs": [
          "생성 속도가 높아 보여도 원하는 모델과 캐시를 담지 못하면 같은 조건의 후보가 아닙니다. 특히 맥의 전체 메모리와 GPU 전용 VRAM을 모델만 사용하는 공간처럼 비교하면 안 됩니다. 운영체제와 실행 프로그램 몫을 남긴 가용 공간을 보세요.",
          "큰 MoE 모델은 활성 계산량이 작아 빠를 수 있지만 전체 가중치는 보관해야 합니다. 이번 모델에서 괜찮았던 장비가 다른 대형 모델에서도 충분하다고 확대해석하지 말고, 쓰려는 모델이 다르면 계산기에서 바꿔 확인하세요."
        ]
      },
      {
        "title": "두 번째로 어느 기다림이 긴지 봅니다",
        "paragraphs": [
          "문서를 넣고 짧게 요약받는 경우에는 첫 토큰까지의 시간이 중요합니다. 짧은 지시로 긴 글을 쓸 때는 디코드 속도가 더 오래 영향을 줍니다. 두 값이 한 장비에서 항상 함께 좋은 것은 아닙니다.",
          "같은 모델에서 프리필을 포함해 본 뒤 토큰 생성만 다시 비교해보세요. 처음에는 크게 보이던 차이가 내가 할 작업에서는 작아질 수 있습니다. 반대로 총 완료 시간은 비슷해도 답이 늦게 시작되는 쪽이 더 답답하게 느껴질 수 있습니다."
        ]
      },
      {
        "title": "한 달 전보다 순위가 올랐다는 말의 조건",
        "paragraphs": [
          "이 페이지는 2026년 9월 5일에 저장한 계산 기록입니다. 현재 계산기의 설정이나 보정값이 바뀌어도 표를 조용히 덮어쓰지 않습니다. 오류 정정과 새로운 달의 비교는 변경 기록을 구분해야 과거 링크를 읽는 사람도 같은 내용을 이해할 수 있습니다.",
          "앞으로 다른 달과 비교할 때는 모델·정밀도·입력 길이가 유지됐는지부터 봐야 합니다. 조건이 달라진 표의 순위 변화를 곧바로 장비 성능 향상으로 부를 수는 없습니다. 런타임 개선인지 계산 기준 수정인지도 별개의 변화입니다."
        ]
      },
      {
        "title": "1등을 골랐는데 너무 비싸다면",
        "paragraphs": [
          "순위가 한 단계 낮아도 내 작업에 충분하면 구매 후보로 남길 수 있습니다. 반대로 가격 차이가 작고 매일 긴 답변을 기다린다면 상위 장비에 비용을 쓸 이유가 생깁니다. 순위만으로는 그 판단을 대신할 수 없습니다.",
          "관심 있는 두 장비를 비교 화면에 넣고 조건을 공유해보세요. ‘어느 게 좋나요?’보다 ‘이 모델로 이 길이의 문서를 처리할 때 이 차이면 괜찮을까요?’라고 물으면 더 구체적인 답을 얻을 수 있습니다. 이 표의 역할은 구매를 서두르게 하는 것이 아니라, 다음에 확인할 질문을 줄여주는 데 있습니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/monthly-local-ai-speed-workbench.webp",
        "alt": "여러 로컬 AI 장비를 같은 조건으로 점검하는 절제된 월간 벤치마크 작업대 그림",
        "caption": "월간 속도표는 같은 모델과 양자화, 입력 길이를 고정해 장비 사이의 체감 차이를 한눈에 비교합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/monthly-local-ai-speed-lanes.webp",
        "alt": "입력을 읽는 프리필 구간과 답변을 이어 쓰는 디코드 구간이 두 갈래로 흐르는 그림",
        "caption": "긴 문서를 읽는 속도와 답변 토큰이 이어지는 속도를 분리해야 내 작업에 맞는 장비가 보입니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/monthly-local-ai-speed-lineup.webp",
        "alt": "맥과 단일 GPU, 듀얼 GPU, 소형 AI 시스템을 같은 작업대에 나란히 놓은 장비 구성 그림",
        "caption": "장비 수와 표시 메모리가 커져도 한 요청의 속도와 여러 요청 처리 능력은 같은 비율로 늘지 않습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/prefill-can-reverse-speed-ranking",
    "slug": "prefill-can-reverse-speed-ranking",
    "title": "긴 입력에서는 로컬 LLM 속도 순위가 뒤집힐 수 있습니다",
    "description": "짧은 채팅의 디코드 순위와 긴 문서의 프리필·전체 완료 시간 순위가 달라지는 이유를 실제 장비 선택 관점에서 설명합니다.",
    "headline": "토큰 생성이 빠른 장비가 긴 문서를 가장 먼저 끝낸다고 단정할 수 없습니다.",
    "category": "speed",
    "categoryLabel": "답변 속도와 가속",
    "term": "로컬 LLM 프리필 속도",
    "alternateName": "Long-context Prefill Ranking",
    "plainSummary": "로컬 AI 장비를 고르다 보면 결국 속도표 앞에 앉게 됩니다. 한쪽은 초당 60토큰, 다른 쪽은 30토큰. 이왕 돈을 쓸 거라면 빠른 쪽을 사고 싶습니다. 그런데 그 두 배라는 차이는, 내가 저녁마다 하려던 일에서도 그대로일까요?",
    "buyerNote": "채팅보다 문서 요약과 코드 분석을 많이 한다면 4K 결과만 보지 말고 실제에 가까운 16K 입력으로 장비 두 대를 다시 비교하세요.",
    "keyPoints": [
      "디코드 tok/s는 첫 답변 뒤의 속도만 설명합니다.",
      "입력이 길어지면 프리필과 TTFT의 비중이 빠르게 커집니다.",
      "같은 장비도 작업의 입력·출력 길이에 따라 체감 순위가 달라집니다."
    ],
    "sections": [
      {
        "title": "우리가 빨리 끝내고 싶은 것은 무엇일까요?",
        "paragraphs": [
          "가령 퇴근 후 긴 회의록을 정리하려고 장비를 알아보고 있다고 해봅시다. 낮에는 시간이 없어서 미뤄 두었던 일입니다. 문서에서 결정된 내용과 아직 남은 일만 추려 주면 됩니다. 긴 답변도 필요 없습니다. 내일 아침에 다시 읽을 몇 문단이면 충분합니다.",
          "이때 필요한 것은 화면에 글자가 가장 빠르게 쏟아지는 컴퓨터일까요? 아니면 문서를 넣고 얼마 지나지 않아 필요한 정리를 내놓는 컴퓨터일까요? 비슷해 보이지만, 장비를 비교할 때는 다른 질문입니다.",
          "성능표에는 우리가 처리할 회의록도, 내일 아침까지 정리해야 하는 사정도 없습니다. 주어진 조건에서 측정한 숫자가 있을 뿐입니다. 그 숫자를 내 상황에 맞게 읽는 일은 아직 남아 있습니다. 비싼 쪽을 고르기 전에 이 차이부터 확인해 보겠습니다."
        ]
      },
      {
        "title": "먼저 짧은 질문을 보내 보겠습니다",
        "paragraphs": [
          "이 글의 A와 B는 원리를 설명하기 위한 가상 장비입니다. 특정 제품의 실측값은 아닙니다. 같은 모델로 같은 질문에 약 300토큰짜리 답변을 만든다고 가정하겠습니다.",
          "A는 첫 토큰까지 4초를 기다린 뒤 초당 60토큰을 씁니다. 답변을 이어 쓰는 데 약 5초가 더 걸리니 전체는 약 9초입니다. B는 첫 토큰까지 6초, 이후 초당 30토큰이므로 전체는 약 16초입니다.",
          "이 조건에서는 A가 먼저 끝납니다. 다만 토큰 생성 속도는 두 배여도, 전체 시간이 정확히 절반인 것은 아닙니다. 답변 전의 기다림이 따로 있기 때문입니다.",
          "여기서 60 tok/s와 30 tok/s는 답변이 시작된 뒤의 생성 속도, 즉 디코드 속도입니다. 첫 토큰까지 걸린 시간은 따로 더했습니다. 계산은 이해를 돕기 위해 반올림한 근삿값입니다. 표에서 흔히 보는 큰 숫자 하나가 아니라, 사용자가 기다린 시간을 처음부터 끝까지 세어 본 것입니다."
        ]
      },
      {
        "title": "질문 대신 긴 문서를 넣으면 어떨까요?",
        "paragraphs": [
          "이번에는 두 장비에 같은 긴 문서를 넣고, 답변 길이는 아까와 같은 약 300토큰으로 맞춰 봅시다. 문서를 처리한 결과 A의 첫 토큰이 40초 뒤에, B의 첫 토큰이 10초 뒤에 나온다고 가정하겠습니다. 답변이 시작된 뒤의 속도는 그대로입니다.",
          "A는 약 40초를 기다리고 5초 동안 답하므로 총 45초가 걸립니다. B는 10초를 기다리고 10초 동안 답하므로 총 20초입니다. 토큰을 쓰는 속도는 여전히 A가 빠른데, 작업은 B가 먼저 끝났습니다.",
          "장비 성능이 갑자기 바뀐 것은 아닙니다. 우리가 시킨 일이 달라진 겁니다. 짧은 질문에서는 잘 드러나지 않던 입력 처리 시간이 긴 문서에서 큰 비중을 차지합니다.",
          "긴 입력을 처리하는 단계를 프리필이라고 합니다. 첫 토큰까지의 시간에는 이 단계 외에도 요청 대기나 실행 준비가 들어갈 수 있습니다. 여기서는 그 시간을 모두 합쳐 비교했습니다. 실제 장비에서도 늘 B가 유리하다는 이야기가 아니라, 같은 디코드 순위만으로 다른 작업의 결과까지 알 수는 없다는 뜻입니다."
        ]
      },
      {
        "title": "그렇다면 첫 토큰이 빠른 장비가 더 좋을까요?",
        "paragraphs": [
          "이번에도 답변 길이를 봐야 합니다. 문서에서 날짜 하나만 찾는다면 답변이 짧으니 첫 토큰까지의 기다림이 중요합니다. 반대로 긴 초안을 써 달라고 하면 답변을 이어 쓰는 시간이 커집니다.",
          "즉, 첫 토큰과 디코드 중 하나만 고르면 같은 문제가 반복됩니다. 내가 자주 넣는 입력의 길이와 받고 싶은 답변의 길이를 함께 맞춰야 합니다. 앞의 가상 예도 다른 길이로 바꾸면 차이가 달라집니다.",
          "캐시도 확인해야 합니다. 이미 읽은 문서를 재사용한 결과와 처음 읽는 문서의 결과를 섞으면 장비 차이와 캐시 효과를 구분하기 어렵습니다."
        ]
      },
      {
        "title": "기다릴 수 있는 시간도 작업마다 다릅니다",
        "paragraphs": [
          "밤에 문서 수십 개를 맡겨 두고 아침에 결과를 받는다면 한 요청이 몇 초 늦게 시작하는 것은 큰 문제가 아닐 수 있습니다. 전체 작업이 제시간에 끝나고 중간에 실패하지 않는지가 더 중요할 겁니다.",
          "반면 코드를 조금 고쳐 달라고 묻고, 결과를 보고, 다시 질문하는 작업은 다릅니다. 답변을 기다리는 동안 다음 판단도 멈춥니다. 한 번의 대기보다 그 대기를 하루에 몇 번 반복하는지가 장비 선택에 더 큰 영향을 줄 수 있습니다.",
          "그렇다고 모두에게 통하는 합격선을 몇 초로 정하기는 어렵습니다. 읽으면서 따라가기에는 충분한 속도라도, 긴 결과를 복사해서 쓰려는 사람에게는 느릴 수 있습니다. 내가 괜찮다고 느끼는 지점을 먼저 알아야 성능표의 차이에 얼마를 더 낼지도 판단할 수 있습니다.",
          "잠깐 신기해서 눌러 보는 도구와 다음 날에도 다시 여는 도구는 다를 수 있습니다. 구매 전에 확인하려는 것은 첫날의 감탄만이 아니라, 반복해서 쓸 때도 견딜 만한 기다림인지입니다."
        ]
      },
      {
        "title": "내가 할 작업으로 두 번 비교해 보세요",
        "paragraphs": [
          "먼저 짧은 질문에서 토큰 생성 속도만 비교합니다. 그다음 평소 넣을 문서에 가까운 길이로 바꾸고, 프리필을 포함해 다시 봅니다. 두 결과에서 같은 장비가 앞서는지 확인하세요.",
          "이 사이트의 비교 화면에서는 입력 길이와 프리필 포함 여부를 바꿀 수 있습니다. 표시되는 것은 예상 체감이므로 실제 실행 기록과는 구분해야 하지만, 답변 전의 기다림을 포함했을 때 선택이 달라지는지 살펴볼 수 있습니다.",
          "살 장비를 정할 때 필요한 질문은 ‘어느 쪽의 tok/s가 더 높은가’에서 끝나지 않습니다. ‘내가 자주 시킬 일을 어느 쪽이 더 빨리 끝내는가’까지 이어져야 합니다."
        ]
      },
      {
        "title": "두 배 빠르다는 이유만으로 두 배를 쓸 필요는 없습니다",
        "paragraphs": [
          "이제 처음의 속도표로 돌아가 봅시다. A가 초당 60토큰, B가 30토큰이라는 사실은 틀리지 않았습니다. 다만 회의록을 정리하려던 사람에게 그 사실만으로 구매 결론을 내리기에는 부족했습니다.",
          "문서를 넣을 때의 기다림까지 비교했더니 저렴한 쪽이 내 작업에 충분할 수도 있습니다. 반대로 매번 긴 답변을 끝까지 기다려야 한다면 더 빠른 쪽에 비용을 쓰는 이유가 분명해질 수도 있습니다. 중요한 것은 어느 결론이 나오든, 내가 할 일로 확인했다는 점입니다.",
          "답변의 내용도 빼놓을 수 없습니다. 빠르게 나온 요약이 중요한 결정을 빠뜨린다면 다시 원문을 읽어야 합니다. 속도를 비교할 때 같은 모델을 쓰는 이유이고, 장비를 정하기 전에 그 모델이 내 문서를 제대로 다루는지도 살펴봐야 하는 이유입니다.",
          "우리가 처음 하려던 일은 가장 높은 숫자를 갖는 것이 아니라, 미뤄 둔 회의록을 정리하는 것이었습니다. 그 일을 충분히 잘 끝낼 수 있다면 더 비싼 장비를 사지 않아도 됩니다. 반대로 지금 가진 장비에서 막히는 구간을 찾았다면, 그때는 무엇을 바꾸기 위해 돈을 쓰는지 알 수 있습니다.",
          "장비 두 대를 골라 같은 문서를 처리하는 상황으로 비교해 보세요. 결과가 생각보다 비슷하다면 그것도 도움이 되는 답입니다. 남는 예산을 굳이 성능표의 다음 칸에 쓸 이유는 없으니까요."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/finding-prefill-long-input.webp",
        "alt": "긴 문서 묶음이 첫 토큰 대기 구간을 지나 연속적인 답변 토큰으로 이어지는 과정 그림",
        "caption": "입력이 길어지면 디코드가 빠른 장비도 첫 답변 전에 프리필 대기 시간이 크게 늘어날 수 있습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/finding-prefill-ranking-reversal.webp",
        "alt": "짧은 입력과 긴 입력에서 서로 다른 장비가 앞서는 순위 역전 현상을 표현한 경주 그림",
        "caption": "짧은 채팅의 디코드 순위가 긴 문서 작업의 전체 완료 순위와 반드시 같지는 않습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/finding-prefill-workload-shapes.webp",
        "alt": "짧은 입력과 긴 출력, 긴 입력과 짧은 출력의 서로 다른 작업 형태를 나란히 비교한 그림",
        "caption": "질문과 답변의 길이 조합을 먼저 정하면 프리필과 디코드 가운데 어떤 수치를 우선할지 결정할 수 있습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/dual-dgx-spark-what-actually-improves",
    "slug": "dual-dgx-spark-what-actually-improves",
    "title": "DGX Spark 두 대를 연결하면 무엇이 실제로 좋아질까",
    "description": "DGX Spark 1대와 2대 구성에서 모델 적재량, 단일 요청 생성 속도, 여러 요청 처리량이 각각 어떻게 달라지는지 구분합니다.",
    "headline": "두 배로 확실히 늘어나는 것은 노드와 메모리 총량이고, 한 답변의 속도는 아닙니다.",
    "category": "runtime",
    "categoryLabel": "실행 프로그램과 확장",
    "term": "DGX Spark 2대",
    "alternateName": "Dual DGX Spark Local LLM Serving",
    "plainSummary": "Spark 한 대로 모델을 띄웠습니다. 그런데 답변이 기대보다 느립니다. 같은 장비를 한 대 더 연결하면 해결될까요? 두 번째 장비가 나눠 맡을 일이 무엇인지에 따라 답이 달라집니다. 더 큰 모델을 담는 것부터 한 사람의 기다림을 줄이는 것까지, 각각 나누어 보겠습니다.",
    "buyerNote": "한 사람이 쓰는 답변 속도가 목적이면 단일 장비의 기본 성능을 먼저 보세요. 대형 모델 적재나 여러 사용자의 동시 요청이 목적일 때 두 대 구성이 분명해집니다.",
    "keyPoints": [
      "두 노드의 메모리는 분산 적재로 더 큰 모델을 담는 데 쓰입니다.",
      "한 요청의 디코드는 노드 간 통신과 동기화 비용을 냅니다.",
      "여러 요청을 나누면 전체 처리량 이점이 더 잘 드러납니다."
    ],
    "sections": [
      {
        "title": "한 대에 들어가지 않는 모델이라면",
        "paragraphs": [
          "첫 번째 이유는 비교적 명확합니다. 원하는 모델과 대화용 캐시가 한 대의 메모리에 들어가지 않는 경우입니다. 실행 프로그램이 모델을 두 노드에 나눠 담을 수 있다면, 두 번째 장비의 공간으로 실행 가능 범위를 넓힐 수 있습니다.",
          "총 256GB라는 표기는 128GB 메모리 두 개의 합입니다. 아무 프로그램에서나 256GB 한 덩어리처럼 쓰는 것은 아닙니다. 모델을 어떻게 나누고 각 장비에 캐시를 얼마나 남길지 정하는 분산 실행 경로가 필요합니다."
        ]
      },
      {
        "title": "이미 한 대에 들어간다면 질문이 바뀝니다",
        "paragraphs": [
          "이번에는 같은 모델이 한 대에 여유 있게 들어간다고 해봅시다. 두 대로 나누면 각 장비가 맡는 계산은 줄어들 수 있습니다. 대신 중간 결과를 네트워크로 주고받고 서로 기다리는 시간이 생깁니다. 이 추가 시간을 넘게 계산을 줄여야 한 답변이 빨라집니다.",
          "분할 방식에 따라 차이도 납니다. 모델의 앞뒤를 나누는 경우와 한 층의 계산을 함께 나누는 경우는 통신 시점이 다릅니다. 두 장비의 대역폭 수치를 더한 값만으로 디코드 속도를 계산할 수 없는 이유입니다."
        ]
      },
      {
        "title": "최적 설정이라는 말에 무엇이 들어 있나요?",
        "paragraphs": [
          "빠른 결과를 봤다면 장비 수뿐 아니라 모델 파일, 양자화, MTP, 입력 길이와 동시 요청 수도 함께 봐야 합니다. 한 대는 기본 설정이고 두 대는 MTP와 다른 압축본을 썼다면, 그 차이 전부를 두 번째 장비의 효과라고 할 수는 없습니다.",
          "비교 순서는 한 대에서 사용할 수 있는 설정을 먼저 정하고, 같은 모델의 두 대 경로와 나란히 보는 것입니다. 한 대에 없는 기능을 두 대에서만 쓸 수 있다면 그것도 중요한 장점이지만, 무엇이 달라졌는지를 남겨야 다음 업데이트 뒤에도 결과를 이해할 수 있습니다."
        ]
      },
      {
        "title": "여러 일을 동시에 시키면 이야기가 달라집니다",
        "paragraphs": [
          "채팅 하나가 아니라 문서 처리와 코딩 에이전트가 동시에 요청하는 서버라면 전체 처리량이 중요해집니다. 모델을 각각 복제해 서로 다른 요청을 맡기거나, 분산 모델이 더 많은 요청을 처리하게 구성할 수 있습니다. 어느 쪽이 맞는지는 모델 크기와 런타임에 달려 있습니다.",
          "이때 총 토큰 수가 늘어도 개별 요청은 늦어질 수 있습니다. 한 요청의 첫 토큰 시간과 디코드 속도, 같은 시간 동안 완료한 요청 수를 나누어 기록해야 합니다. 가족이나 팀이 함께 쓰는 환경이라면 가장 오래 기다린 사람의 경험도 빼놓지 마세요."
        ]
      },
      {
        "title": "두 번째 장비의 가격에 무엇을 기대할지",
        "paragraphs": [
          "큰 모델이 꼭 필요해서 한 대로는 실행할 수 없다면 용량 확대 자체가 구매 이유입니다. 반면 혼자 짧은 대화를 빠르게 하려는 목적이라면, 두 대를 관리하고 연결하는 비용까지 내면서 얼마나 기다림을 줄이는지 확인해야 합니다.",
          "사이트에서 한 대와 두 대의 예상 체감을 비교해보세요. 다만 특정 패치와 런타임의 최고 기록을 모든 모델에 적용한 실측 화면은 아닙니다. 차이가 작다면 한 대의 설정을 다듬는 쪽을, 두 대에서만 가능한 일이 있다면 그 작업을 중심으로 판단하면 됩니다. 두 번째 장비가 반드시 할 일이 있어야 합니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/finding-dual-spark-capacity.webp",
        "alt": "DGX Spark 한 대와 두 대 구성이 모델 수납 공간과 처리 통로를 다르게 넓히는 그림",
        "caption": "두 대 연결의 가장 확실한 이점은 더 큰 모델 적재와 동시 요청 처리 여유이며 단일 답변 속도 두 배가 아닙니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/finding-dual-spark-sync.webp",
        "alt": "두 AI 노드 사이에서 계산 결과를 주고받으며 동기화하는 연결 구간을 보여 주는 그림",
        "caption": "모델을 두 노드에 나누면 매 단계의 통신과 동기화가 추가되어 장비 성능을 그대로 합산할 수 없습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/finding-dual-spark-throughput.webp",
        "alt": "두 AI 노드가 여러 요청을 나누어 동시에 처리하는 서버 처리량 중심의 구성 그림",
        "caption": "하나의 긴 답변보다 여러 사용자의 요청을 함께 처리할 때 두 노드의 처리량 이점이 더 분명해집니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/why-moe-can-be-faster-than-dense",
    "slug": "why-moe-can-be-faster-than-dense",
    "title": "35B MoE가 더 작은 밀집 모델보다 빠를 수 있는 이유",
    "description": "총 파라미터와 활성 파라미터를 구분해, 큰 MoE 모델이 작은 Dense 모델보다 빠르게 생성되는 조합과 메모리 조건을 설명합니다.",
    "headline": "저장해야 하는 모델 크기와 토큰 하나를 계산할 때 쓰는 모델 크기는 다를 수 있습니다.",
    "category": "memory",
    "categoryLabel": "메모리와 모델",
    "term": "MoE 활성 파라미터",
    "alternateName": "Mixture of Experts Active Parameters",
    "plainSummary": "모델 이름의 숫자가 커지면 더 느릴 것 같습니다. 그런데 35B 모델이 27B 모델보다 빠르게 답하는 경우가 있습니다. 큰 숫자를 잘못 읽은 걸까요? 사실 두 숫자는 저장할 모델의 크기를 말할 뿐, 토큰 하나를 만들 때 모두 같은 양을 계산한다는 뜻은 아닙니다.",
    "buyerNote": "MoE의 활성 파라미터가 작아도 전체 가중치는 메모리에 들어가야 합니다. 속도와 적재 가능 용량을 서로 다른 칸으로 확인하세요.",
    "keyPoints": [
      "총 파라미터는 모델 파일과 적재 메모리에 가깝습니다.",
      "활성 파라미터는 토큰당 계산량과 디코드 속도에 더 가깝습니다.",
      "전문가 라우팅과 런타임 구현에 따라 이론적 이점이 줄 수 있습니다."
    ],
    "sections": [
      {
        "title": "우선 두 모델의 일을 같게 맞춥니다",
        "paragraphs": [
          "35B와 27B의 속도만 놓고 비교하기 전에 질문과 답변 길이, 양자화와 실행 프로그램을 맞춰야 합니다. 서로 다른 작업에서 나온 숫자라면 구조 차이를 보기 어렵습니다. 여기서는 같은 장비에서 같은 종류의 요청을 보낸 상황을 생각해보겠습니다.",
          "밀집형인 Dense 모델은 새 토큰을 만들 때 대부분의 가중치를 사용합니다. 모델이 커질수록 읽어야 할 가중치도 늘어나는 경향이 있습니다. 그래서 더 큰 Dense 모델이 느릴 것이라는 예상은 출발점으로 이해할 만합니다."
        ]
      },
      {
        "title": "MoE는 전체를 보관하고 일부를 선택합니다",
        "paragraphs": [
          "MoE에는 여러 전문가 블록이 있습니다. 각 토큰에서 라우터가 일부를 선택해 계산합니다. 모든 전문가가 매번 함께 일하는 구조는 아니므로, 전체 파라미터가 커도 한 토큰에서 사용하는 부분은 작을 수 있습니다.",
          "예를 들어 전체 35B에 활성 약 3B라고 표시된 모델은 보관할 규모와 토큰당 계산 규모를 따로 읽어야 합니다. 이 숫자는 설명을 위한 구조 예이지 3B 밀집 모델과 같은 속도나 품질을 약속하는 식은 아닙니다. 공유 층과 라우팅 비용도 남아 있습니다."
        ]
      },
      {
        "title": "계산이 줄면 왜 답변이 빨라질까요?",
        "paragraphs": [
          "한 사람이 답변을 받을 때는 GPU의 계산 능력만큼 메모리에서 가중치를 가져오는 속도가 중요할 수 있습니다. 선택된 가중치만 읽고 계산하는 경로가 효율적이라면, 더 작은 Dense 모델보다 적은 일을 하며 다음 토큰을 만들 수 있습니다.",
          "하지만 실행 프로그램의 MoE 처리가 비효율적이면 이 이점을 충분히 얻지 못합니다. 전문가를 고르고 흩어진 메모리에 접근하는 비용도 있습니다. 모델 구조를 알면 빠를 가능성은 설명할 수 있지만, 실제 tok/s까지 구조만으로 확정할 수는 없습니다."
        ]
      },
      {
        "title": "빠른 모델이 작은 메모리에 들어가는 것은 아닙니다",
        "paragraphs": [
          "여기서 가장 아쉬운 오해가 생깁니다. 활성 부분만 보고 작은 GPU를 샀는데 모델 파일이 들어가지 않는 경우입니다. 다음 토큰이 어떤 전문가를 선택할지 모르므로 전체 가중치는 접근 가능한 메모리나 저장장치에 있어야 합니다.",
          "일부를 RAM이나 SSD에 두는 경로가 있더라도 필요한 부분을 가져오는 지연이 생깁니다. 계산량을 줄여 얻은 이득보다 전송 시간이 커질 수도 있습니다. 모델을 올릴 수 있다는 확인을 먼저 하고, 그 안에서 속도를 비교해야 합니다."
        ]
      },
      {
        "title": "더 큰 모델을 쓸 이유도 작업에서 찾습니다",
        "paragraphs": [
          "MoE가 빠르다고 해서 답변의 정확도까지 자동으로 앞서는 것은 아닙니다. 내가 시킨 코드 수정이나 문서 요약에서 어느 모델의 결과가 더 쓸 만한지 확인해야 합니다. 잘못된 답을 빠르게 받으면 검토 시간은 오히려 늘 수 있습니다.",
          "35B라는 숫자에 부담을 느꼈다면 실제 파일 크기와 활성 규모를 나누어 보세요. 반대로 활성 3B만 보고 가볍다고 생각했다면 전체 적재량을 다시 보세요. 이름이 주는 인상 대신 메모리·속도·작업 결과 세 가지가 맞는 모델을 남기는 것이 목적입니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/finding-moe-expert-drawers.webp",
        "alt": "여러 전문가 가중치 서랍 중 일부만 열어 토큰을 처리하는 MoE 모델의 작업장 그림",
        "caption": "MoE는 전체 전문가를 메모리에 보관하지만 토큰 하나를 계산할 때는 선택된 일부 전문가만 사용합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/finding-moe-active-compute.webp",
        "alt": "모든 블록을 통과하는 밀집 모델과 일부 전문가 경로만 통과하는 MoE 모델을 비교한 그림",
        "caption": "총 파라미터가 더 큰 MoE도 활성 계산량이 작으면 작은 밀집 모델보다 디코드가 빠른 조합이 생길 수 있습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/finding-moe-memory-speed.webp",
        "alt": "큰 메모리 수납장 안에서 소수의 활성 전문가 경로만 빠르게 이어지는 구조 그림",
        "caption": "MoE 장비 선택에서는 전체 가중치가 들어갈 메모리와 실제 활성 경로의 생성 속도를 따로 확인해야 합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/local-llm-hardware",
    "slug": "local-llm-hardware",
    "title": "로컬 LLM 장비 고르는 법: 메모리·속도·전력 기준",
    "description": "로컬 LLM 장비를 고를 때 VRAM과 통합 메모리, 프리필, 토큰 생성 속도, 전기요금과 TCO를 어떤 순서로 봐야 하는지 설명합니다.",
    "headline": "모델이 들어가는지 먼저, 기다릴 만한 속도인지는 그다음입니다.",
    "category": "start",
    "categoryLabel": "먼저 읽기",
    "plainSummary": "로컬 AI를 해보고 싶어 장비를 찾아봤는데, 알아볼수록 예산만 커집니다. 처음에는 작은 맥이면 될 것 같다가도 누군가의 큰 모델 실행 화면을 보면 마음이 흔들립니다. 어디까지 사야 후회하지 않을까요? 제품 목록을 보기 전에, 그 컴퓨터로 끝내고 싶은 일부터 하나 정해보겠습니다.",
    "buyerNote": "제품명보다 메모리 용량을 먼저 보세요. 같은 맥이나 그래픽카드라도 메모리 옵션이 다르면 실행할 수 있는 모델이 달라집니다.",
    "keyPoints": [
      "가용 메모리로 실행 가능한 모델 크기를 먼저 정합니다.",
      "프리필과 디코드 중 내 작업에 중요한 속도를 구분합니다.",
      "본체 가격에 전력·감가·추가 부품을 더해 비교합니다."
    ],
    "sections": [
      {
        "title": "가장 먼저 정할 것은 장비가 아닙니다",
        "paragraphs": [
          "가령 개인 문서를 찾아 요약하고 가끔 코드를 고치는 것이 목적이라고 해봅시다. 이때 필요한 것은 모든 공개 모델을 실행하는 장비가 아니라, 그 작업을 맡길 만한 모델 하나와 그것을 편하게 돌릴 환경입니다. 순서가 바뀌면 장비를 먼저 산 뒤 그 용량을 채울 모델을 찾게 됩니다.",
          "평소 실제로 할 질문을 몇 개 적어보세요. 문서에서 특정 내용을 찾기, 작성한 코드의 오류 살피기, 긴 글의 초안 만들기처럼 결과를 확인할 수 있는 질문이면 좋습니다. 아직 모델을 정하지 못했다면 이 질문에 답을 잘하는 후보부터 좁힙니다."
        ]
      },
      {
        "title": "들어간다는 말에는 빠진 공간이 있습니다",
        "paragraphs": [
          "모델 파일이 메모리에 들어가는지부터 확인합니다. 다만 파일 크기가 전부는 아닙니다. 실행 프로그램의 작업 공간과 입력·답변에 필요한 KV 캐시가 추가됩니다. 긴 문서를 넣을 사람이라면 짧은 인사말이 성공한 것만으로 용량이 충분하다고 판단하면 안 됩니다.",
          "맥의 통합 메모리는 운영체제와 다른 앱도 함께 씁니다. 외장 GPU의 VRAM은 시스템 RAM과 별도입니다. 따라서 같은 32GB 표기를 보고 둘의 모델 전용 공간이 같다고 계산하지 마세요. 브라우저와 문서 작업을 함께 켜둘 때 남는 공간도 생각해야 합니다."
        ]
      },
      {
        "title": "그다음에는 기다려 봐야 합니다",
        "paragraphs": [
          "메모리에 충분히 들어가더라도 답변이 늦으면 자주 쓰지 않게 될 수 있습니다. 긴 문서를 넣고 첫 답을 기다리는 시간과, 답이 시작된 뒤 끝날 때까지의 시간을 나누어 보세요. 각각 입력을 처리하는 프리필과 답변을 이어 쓰는 디코드의 영향을 받습니다.",
          "속도 체험에서 숫자를 읽는 데 그치지 말고, 그 시간 동안 실제로 기다려 보세요. 짧은 요약을 받으려는 경우와 긴 코드를 복사하려는 경우는 같은 속도에서도 느낌이 다릅니다. 사이트의 예상 체감으로 후보를 좁힌 뒤 같은 모델·길이의 실행 기록을 확인하는 순서가 좋습니다."
        ]
      },
      {
        "title": "그래픽카드 가격과 컴퓨터 가격은 다릅니다",
        "paragraphs": [
          "GPU 가격만 보면 맥보다 훨씬 싸 보일 수 있습니다. 이미 적절한 PC가 있다면 실제로 유리한 선택일 수 있습니다. 하지만 새로 맞춰야 한다면 본체, 전원공급장치, 저장장치와 냉각 비용을 더해야 합니다. 카드가 들어갈 공간과 필요한 전력도 확인해야 합니다.",
          "반대로 완제품의 높은 초기 가격에는 조립과 설정 부담을 줄이는 가치가 있을 수 있습니다. 이것을 누구에게나 같은 금액으로 환산할 수는 없습니다. 주말에 설정을 만지는 일이 즐거운 사람과, 문서를 처리할 때만 켜고 싶은 사람의 선택은 달라도 됩니다."
        ]
      },
      {
        "title": "늘릴 수 없는 메모리와 아직 정하지 않은 미래",
        "paragraphs": [
          "구매 후 메모리를 바꾸기 어려운 장비는 한 단계 큰 구성이 마음 편할 수 있습니다. 다만 나중에 어떤 모델을 쓸지 전혀 정하지 않았다면, 막연한 불안만으로 가장 큰 옵션까지 올라갈 필요는 없습니다. 지금 할 일과 다음으로 꼭 해보고 싶은 일을 하나씩 놓고 용량을 계산해보세요.",
          "가끔만 필요한 큰 작업 때문에 매일 쓰는 장비 전체를 키울 것인지도 따로 판단할 문제입니다. 드문 작업에서는 오래 기다리거나 더 작은 모델로 나누어 처리하는 방법을 받아들일 수 있습니다. 반대로 매일 부딪히는 메모리 부족이라면 업그레이드 이유가 분명합니다."
        ]
      },
      {
        "title": "추천을 받기 전에 남겨둘 한 문장",
        "paragraphs": [
          "‘이 장비로 이 모델을 돌려, 이 길이의 문서를 이 정도 기다리며 처리하겠다.’ 여기까지 적을 수 있다면 구매 조건이 꽤 구체적입니다. 이 조건을 만족하는 후보끼리 비교하면, 더 비싼 장비가 왜 필요한지 또는 필요 없는지 설명할 수 있습니다.",
          "장비를 고르는 동안 하려던 일 자체를 잊지 않았으면 합니다. 문서 정리가 목적이었다면 작은 모델로 첫 문서 하나를 끝내는 것도 충분한 시작입니다. 그 과정에서 정말 부족한 점을 찾았다면, 다음 구매는 막연한 기대보다 분명한 경험 위에서 할 수 있습니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/hardware-choice-tco.webp",
        "alt": "통합 메모리 컴퓨터와 단일·듀얼 GPU 장비를 메모리, 속도, 전력, 비용 기준으로 비교한 그림",
        "caption": "장비 크기보다 필요한 메모리, 체감 속도, 소비전력과 구매비를 한 묶음으로 봐야 합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p01-model-fit.webp",
        "alt": "모델 가중치와 KV 캐시, 실행 여유 공간이 장비 메모리 안에 들어가는지 보여 주는 수납장 그림",
        "caption": "표시 용량을 가득 쓰는 것이 아니라 운영체제와 KV 캐시가 쓸 여유까지 남아야 안정적으로 실행됩니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p01-workload-choice.webp",
        "alt": "문서 요약, 대화, 코드 생성처럼 서로 다른 작업이 각기 다른 장비 선택으로 이어지는 그림",
        "caption": "먼저 자주 할 작업과 입력·출력 길이를 정하면 필요한 메모리와 속도 기준이 자연스럽게 좁혀집니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/prefill-vs-decode",
    "slug": "prefill-vs-decode",
    "title": "LLM 프리필·TTFT·디코드 속도 차이",
    "description": "로컬 LLM 벤치마크에서 프리필 처리량, 첫 토큰 시간인 TTFT와 디코드 토큰 생성 속도를 구분해 실제 체감 성능을 읽는 방법입니다.",
    "headline": "첫 답변까지의 기다림과 답변이 이어지는 속도는 서로 다른 지표입니다.",
    "category": "start",
    "categoryLabel": "먼저 읽기",
    "term": "프리필",
    "alternateName": "Prefill",
    "plainSummary": "답변이 나오기까지는 오래 걸렸는데, 일단 시작하니 글이 빠르게 쏟아집니다. 반대로 금방 답하기 시작해 놓고 한 줄씩 천천히 쓰는 경우도 있습니다. 둘 다 속도 차이지만, 기다리는 구간은 다릅니다. 이 둘을 나눠 부르는 말이 프리필과 디코드입니다.",
    "buyerNote": "PDF 요약이 목적이면 첫 답이 나오는 시간을, 채팅과 코딩이 목적이면 답변이 이어지는 속도를 더 중요하게 보세요.",
    "keyPoints": [
      "프리필은 입력 토큰을 처리하는 단계입니다.",
      "TTFT는 프리필과 준비 시간을 합친 첫 응답 지연입니다.",
      "디코드는 첫 토큰 뒤 답변이 이어지는 속도입니다."
    ],
    "sections": [
      {
        "title": "답변이 나오기 전에는 무엇을 할까요?",
        "paragraphs": [
          "처음 로컬 모델을 실행할 때는 이런 기다림이 오류처럼 느껴질 수 있습니다. 질문을 보냈는데 화면에는 아무 글자도 없으니까요. 같은 질문을 한 번 더 보내기 전에, 답변이 나오기까지 어떤 일이 있는지부터 구분해 보겠습니다.",
          "PDF를 넣고 요약을 부탁했다고 해봅시다. 모델은 곧바로 요약문부터 쓸 수 없습니다. 질문과 문서를 먼저 처리해야 합니다. 이 입력 처리 단계를 프리필이라고 부릅니다.",
          "처리할 문서가 길어지면 이 단계의 부담도 커집니다. 그래서 짧은 질문에는 금방 답하던 장비가 긴 회의록 앞에서는 한동안 멈춘 것처럼 보일 수 있습니다. 아직 답변이 안 보인다고 모델이 쉬고 있는 것은 아닙니다."
        ]
      },
      {
        "title": "첫 토큰까지 10초라면, 프리필도 10초일까요?",
        "paragraphs": [
          "꼭 그렇지는 않습니다. 요청을 보낸 뒤 첫 토큰이 화면에 도착할 때까지의 시간을 TTFT라고 합니다. 프리필 외에 요청 대기, 입력을 토큰으로 바꾸는 작업, 실행 준비 등도 포함될 수 있습니다.",
          "사용자 입장에서는 이 전체 시간이 처음 기다린 시간입니다. 반면 프로그램이 보고한 프리필 시간은 그중 입력 처리 구간만 잰 값일 수 있습니다. 서로 다른 화면의 숫자가 다를 때는 무엇부터 무엇까지 쟀는지 먼저 확인하세요."
        ]
      },
      {
        "title": "이제 답변이 시작됐습니다",
        "paragraphs": [
          "첫 토큰 뒤에 답변을 이어 만드는 단계가 디코드입니다. 성능표의 decode tok/s는 이때 초당 얼마나 많은 토큰을 만드는지 나타냅니다. 토큰은 글자와 정확히 같은 단위는 아니지만, 같은 모델을 비교할 때는 숫자가 높을수록 글이 빠르게 이어진다고 볼 수 있습니다.",
          "긴 글을 쓰거나 코드를 많이 출력하는 작업에서는 이 차이를 오래 체감합니다. MTP 같은 가속도 주로 이 구간을 줄이려는 방법입니다. 켤 수 있는지, 실제로 빨라지는지는 모델과 실행 프로그램에 따라 확인해야 합니다."
        ]
      },
      {
        "title": "같은 문서를 다시 물으면 왜 빨라지죠?",
        "paragraphs": [
          "처음에는 오래 기다렸는데 같은 문서로 다시 질문하니 금방 답할 수 있습니다. 앞부분이 같을 때 이전 입력 처리 결과를 다시 쓰는 프롬프트 캐시가 작동했을 가능성이 있습니다.",
          "이 결과를 캐시 없이 처음 실행한 다른 장비와 비교하면 공정하지 않습니다. 처음 읽히는 작업을 비교할지, 같은 문서를 반복해서 묻는 작업을 비교할지 정한 뒤 양쪽 조건을 맞춰야 합니다.",
          "긴 입력에서 일부 토큰을 선별해 처리량을 줄이려는 SpecPrefill도 있지만, 캐시와는 다른 방식입니다. 첫 답변이 빨라졌다는 결과만으로 두 기능을 같은 것으로 보면 안 됩니다."
        ]
      },
      {
        "title": "그래서 어떤 숫자를 보면 될까요?",
        "paragraphs": [
          "긴 문서에서 짧은 요약을 받는다면 첫 토큰까지의 시간을 먼저 보세요. 짧은 지시로 긴 답변을 받는다면 디코드 속도도 중요합니다. 어느 쪽이든 작업을 끝내는 전체 시간을 함께 보면 판단이 쉬워집니다.",
          "비교 화면에서 프리필을 포함한 결과를 본 뒤, 토큰 생성 속도만 따로 보세요. 처음의 기다림이 긴 것인지, 답변을 쓰는 속도가 느린 것인지 나누어 보면 필요한 장비 성능도 달라집니다.",
          "빠른 장비를 찾기 전에 내가 답답했던 순간을 떠올려 보세요. 문서를 넣고 아무것도 안 나올 때였는지, 답변이 시작된 뒤에도 끝까지 한참 기다릴 때였는지. 그 차이를 말할 수 있으면 막연한 “더 좋은 컴퓨터” 대신 필요한 성능을 찾아볼 수 있습니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/p02-prefill-decode-timeline.webp",
        "alt": "긴 입력을 한꺼번에 읽는 프리필과 첫 토큰 뒤 답변을 이어 쓰는 디코드의 시간 흐름 그림",
        "caption": "첫 토큰까지 기다리는 시간과 첫 토큰 뒤 답변이 이어지는 속도는 서로 다른 구간에서 결정됩니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p02-workload-shapes.webp",
        "alt": "긴 입력과 짧은 출력 작업, 짧은 입력과 긴 출력 작업의 길이를 나란히 비교한 그림",
        "caption": "문서 요약은 입력 처리 비중이 크고, 글쓰기와 코딩은 출력 생성 비중이 커서 봐야 할 지표가 다릅니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p02-cache-hit.webp",
        "alt": "처음부터 입력을 계산하는 요청과 저장된 캐시를 재사용해 첫 토큰을 빨리 내는 요청의 비교 그림",
        "caption": "캐시가 맞으면 공통 입력을 다시 읽는 일을 줄일 수 있으므로 TTFT 비교에서는 캐시 상태를 같게 맞춰야 합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/mtp-multi-token-prediction",
    "slug": "mtp-multi-token-prediction",
    "title": "MTP란? 다중 토큰 예측의 원리와 조건",
    "description": "MTP(Multi-Token Prediction)가 여러 미래 토큰을 어떻게 제안하고 검증하는지, 지원 모델과 런타임이 왜 필요하며 언제 빨라지는지 설명합니다.",
    "headline": "여러 토큰을 미리 제안하되, 메인 모델의 검증을 통과한 토큰만 사용합니다.",
    "category": "speed",
    "categoryLabel": "답변 속도와 가속",
    "term": "MTP",
    "alternateName": "Multi-Token Prediction",
    "plainSummary": "같은 장비와 같은 모델인데 MTP를 켰더니 더 빨라졌다는 이야기를 봅니다. 장비를 바꾸지 않고 기다림을 줄일 수 있다면 반가운 일입니다. 그런데 왜 어떤 질문에서는 차이가 작을까요? 미리 만든 토큰 중 실제 답변에 남는 것이 얼마나 되는지부터 살펴보겠습니다.",
    "buyerNote": "MTP는 모든 모델에서 되는 공통 기능이 아닙니다. 장비 광고의 최대 가속 수치보다 MTP를 끈 기본 속도를 먼저 확인하세요.",
    "keyPoints": [
      "MTP는 모델 학습 구조와 추론 가속을 함께 가리키는 말입니다.",
      "MTP 헤드가 들어 있는 체크포인트와 지원 런타임이 모두 필요합니다.",
      "승인되는 토큰이 적거나 검증 비용이 크면 빨라지지 않습니다."
    ],
    "sections": [
      {
        "title": "다음 토큰 하나를 기다리는 대신",
        "paragraphs": [
          "일반적인 생성에서는 지금까지의 문장을 보고 다음 토큰을 만듭니다. 그 토큰이 정해져야 그다음을 만들 수 있습니다. MTP는 여러 미래 토큰을 예상하도록 학습한 추가 예측 부분을 활용합니다. 다음 몇 토큰의 후보를 먼저 준비해 본 모델이 묶어서 확인하게 하는 것입니다.",
          "이때 후보를 곧바로 정답으로 붙이지는 않습니다. 앞에서부터 검증을 통과한 부분을 받아들이고, 어긋난 지점에서는 본 모델의 결과로 이어갑니다. 작은 초안을 그대로 섞어 답변의 수준을 낮추는 것을 목적으로 하는 기술은 아닙니다."
        ]
      },
      {
        "title": "세 개를 제안했다고 세 개가 남지는 않습니다",
        "paragraphs": [
          "후보를 여러 개 만들었어도 첫 부분에서 틀리면 뒤쪽은 쓸 수 없습니다. 후보 생성과 검증에는 시간이 들었으므로, 버린 부분이 많으면 이득이 줄어듭니다. 반대로 여러 토큰이 연속으로 받아들여지면 본 모델이 한 토큰씩 반복하던 횟수를 줄일 수 있습니다.",
          "그래서 한 번에 예측할 길이를 가장 크게 설정하는 것이 항상 최적은 아닙니다. 받아들인 토큰의 비율뿐 아니라 한 번에 평균 몇 토큰을 남겼는지, 그 과정에 몇 초가 들었는지를 함께 봐야 합니다. 같은 질문에서도 설정에 따라 균형이 달라집니다."
        ]
      },
      {
        "title": "버튼보다 모델 파일을 먼저 확인합니다",
        "paragraphs": [
          "모델 파일에 MTP용 가중치가 있어야 하고 실행 프로그램도 그 구조를 지원해야 합니다. 변환 과정에서 추가 가중치가 빠졌다면 일반 답변은 되더라도 MTP가 안 될 수 있습니다. 설정 화면에 켜짐이 보이는 것과 실제 그 경로로 실행되는 것도 구분해야 합니다.",
          "메모리 역시 추가로 필요할 수 있습니다. 모델 본체가 겨우 들어가는 장비라면 MTP와 긴 문맥을 함께 켠 뒤 여유가 사라질 수 있습니다. 이 기능은 부족한 메모리를 대신하는 것이 아니라, 지원되는 환경에서 생성 과정을 바꾸는 선택지입니다."
        ]
      },
      {
        "title": "평소 질문으로 켜고 끈 결과를 남겨보세요",
        "paragraphs": [
          "먼저 MTP 없이 같은 모델이 정상적으로 답하는지 확인합니다. 준비 실행 후 같은 입력을 세 번씩 보내 중앙값을 비교하면 우연히 잘 나온 한 번의 영향을 줄일 수 있습니다. 코드 수정과 자유로운 글쓰기를 모두 한다면 각각 확인하는 편이 낫습니다.",
          "속도와 함께 답변이 정상적으로 끝났는지, 도구 호출 형식이나 중요한 수치가 이상하지 않은지도 보세요. 토큰 생성이 빨라도 반복 출력이 생기거나 실행이 자주 실패하면 유지할 설정은 아닙니다. 효과가 작으면 끄는 것도 정상적인 튜닝 결과입니다."
        ]
      },
      {
        "title": "장비를 사기 전이라면",
        "paragraphs": [
          "MTP가 잘 맞는 조합은 같은 장비를 더 오래 유용하게 쓰게 해줄 수 있습니다. 다만 특정 질문의 최고 배율을 모든 모델의 기본 성능으로 계산하지는 마세요. 지금 사용할 모델과 앱에서 확인된 결과가 먼저입니다.",
          "내 장비에서 이미 충분히 빨라진다면 더 비싼 제품을 볼 이유가 줄어듭니다. 반대로 MTP가 켜져도 긴 문서를 읽는 대기가 그대로라면 문제는 프리필 쪽일 수 있습니다. 빨라졌다는 말보다 어느 기다림이 줄었는지를 알아야 다음 선택도 정확해집니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/mtp-speculative-concept.webp",
        "alt": "토큰을 하나씩 생성하는 기본 방식과 여러 후보를 제안한 뒤 승인된 토큰만 쓰는 가속 방식 비교 그림",
        "caption": "위는 한 토큰씩 만드는 기본 방식이고, 아래는 후보 여러 개를 제안하고 맞은 구간만 받아들이는 방식입니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p03-mtp-heads.webp",
        "alt": "메인 모델에서 여러 미래 토큰 예측 가지가 뻗었다가 검증 결과로 다시 합쳐지는 그림",
        "caption": "MTP의 추가 예측 부분은 두 번째와 세 번째 이후의 토큰 후보를 미리 만들어 검증할 묶음을 준비합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p03-acceptance-depth.webp",
        "alt": "제안한 여러 토큰 가운데 앞에서부터 연속으로 승인된 깊이만 답변에 포함되는 그림",
        "caption": "후보가 연속으로 많이 승인될수록 한 번의 검증에서 더 멀리 진행하므로 가속 이득이 커집니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/lightning-mtp",
    "slug": "lightning-mtp",
    "title": "Lightning MTP란? oMLX 가속 경로 이해하기",
    "description": "Lightning MTP가 Apple Silicon용 oMLX에서 지원 모델의 내장 MTP 헤드를 활용하는 방식과 호환 조건, 일반 MTP와의 차이, 주의점을 설명합니다.",
    "headline": "표준 기술 이름이 아니라 oMLX의 네이티브 MTP 실행 경로를 가리킵니다.",
    "category": "speed",
    "categoryLabel": "답변 속도와 가속",
    "term": "Lightning MTP",
    "alternateName": "oMLX Lightning Multi-Token Prediction",
    "plainSummary": "맥에서 Lightning MTP를 켜면 빨라진다는데, 내 앱에는 그 메뉴가 없을 수 있습니다. 맥의 칩에 숨겨진 기능을 놓친 걸까요? 이 이름은 하드웨어 사양이 아니라 oMLX의 실행 경로를 가리킵니다. 장비·앱·모델 파일 중 무엇을 맞춰야 하는지 차례로 보겠습니다.",
    "buyerNote": "맥을 산다고 자동으로 쓸 수 있는 기능은 아닙니다. 사용할 모델 파일과 oMLX 버전이 모두 지원하는지 확인해야 합니다.",
    "keyPoints": [
      "Lightning MTP는 oMLX 구현에서 사용하는 기능명입니다.",
      "MTP 텐서를 보존한 지원 체크포인트가 필요합니다.",
      "모델·KV 캐시·배칭 조합에 따라 이득과 호환성이 달라집니다."
    ],
    "sections": [
      {
        "title": "맥을 샀다는 것만으로 켜지지는 않습니다",
        "paragraphs": [
          "MTP는 여러 미래 토큰을 예상하는 구조를 가리키고, Lightning MTP는 이를 Apple Silicon에서 활용하는 oMLX 구현의 이름입니다. 모든 맥용 AI 프로그램에 같은 기능이 있는 것은 아닙니다. 같은 모델이라도 다른 앱에서는 다른 가속 경로를 쓰거나 일반 생성만 할 수 있습니다.",
          "따라서 기능을 찾기 위해 장비부터 바꿀 필요는 없습니다. 현재 앱과 버전, 내려받은 모델 파일이 지원되는지 먼저 확인합니다. 모델 제품군 이름이 같아도 세부 구조와 변환 방식이 다르면 호환성이 달라질 수 있습니다."
        ]
      },
      {
        "title": "다운로드한 파일이 같아 보일 때",
        "paragraphs": [
          "일반 답변에 필요한 가중치만 담은 변환본과 MTP 부분을 보존한 변환본은 다를 수 있습니다. 파일 이름에 MTP가 보이는지는 단서지만 그것만으로 실행을 보장하지는 않습니다. 변환 설명과 현재 oMLX 지원 범위를 함께 봐야 합니다.",
          "이미 정상 실행되는 파일은 지우지 말고 기준으로 남겨두세요. 새로운 파일과 기능을 동시에 바꾼 뒤 문제가 생기면 원인을 구분하기 어렵습니다. 같은 질문에서 일반 생성부터 확인하고 다음에 MTP를 켜는 순서가 복구하기도 쉽습니다."
        ]
      },
      {
        "title": "더 깊게 예측하면 더 빠를까요?",
        "paragraphs": [
          "후보를 길게 만들면 여러 토큰을 한 번에 받아들일 기회가 늘어납니다. 하지만 틀린 후보를 만들고 확인하는 비용도 늘어납니다. 본 모델이 실제로 받아들인 길이가 짧다면 높은 설정 숫자가 오히려 손해일 수 있습니다.",
          "짧은 대답 몇 번만으로 설정을 정하지 마세요. 평소 만드는 코드나 긴 문장을 사용하고, 준비 실행 뒤 세 번의 중앙값을 비교합니다. 좋아진 설정이 있다면 그때의 모델 파일과 앱 버전도 같이 적어두어야 업데이트 이후 차이를 알아볼 수 있습니다."
        ]
      },
      {
        "title": "다른 가속도 함께 켜고 싶다면",
        "paragraphs": [
          "KV 캐시 압축, 긴 문맥과 동시 요청 설정은 MTP의 메모리와 검증 경로에 영향을 줄 수 있습니다. 단독으로 잘 작동하던 옵션 두 개가 함께 켜졌을 때도 같은 효과를 내리라는 보장은 없습니다. 한 번에 하나씩 바꾸는 편이 느려 보여도 원인을 찾는 시간을 아낄 수 있습니다.",
          "한 사람이 쓰는 결과가 좋았더라도 여러 요청을 동시에 받는 서버는 따로 확인합니다. 관리 화면의 켜짐 표시만 보지 말고 실제 로그의 경로와 요청별 생성 속도를 보세요. 총 처리량이 늘고 한 사람의 대기가 늘어나는 상황도 구분해야 합니다."
        ]
      },
      {
        "title": "내게 필요한 개선인지 확인합니다",
        "paragraphs": [
          "좋은 설정은 가장 복잡한 설정이 아니라 반복해서 쓸 때도 이득이 남는 설정입니다. MTP를 켜서 답변이 충분히 빨라졌다면 장비 업그레이드를 미뤄도 됩니다. 이득이 없다고 장비가 잘못된 것도 아닙니다. 모델과 작업이 이 경로에 잘 맞지 않을 수 있습니다.",
          "구매 전에는 호환 조합의 결과를 참고하되, 다른 모델을 쓸 때의 기본 속도도 보세요. 기능 하나의 최대 배율보다 내가 계속 쓸 모델들의 실제 대기 시간을 아는 것이 오래 사용하는 장비를 고르는 데 도움이 됩니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/p04-native-pipeline.webp",
        "alt": "통합 메모리 칩 안에서 MTP 후보 생성과 검증이 짧은 경로로 이어지는 그림",
        "caption": "Lightning MTP는 Apple Silicon과 oMLX에 맞춘 실행 경로이며 맥 자체에 MTP 기능을 새로 더하는 것은 아닙니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p04-checkpoint-support.webp",
        "alt": "MTP 추가 가중치가 포함된 모델 파일과 빠진 모델 파일의 구조 차이를 보여 주는 그림",
        "caption": "같은 모델 이름이라도 변환 과정에서 MTP 텐서가 빠지면 일반 생성만 가능하고 가속 경로는 사용할 수 없습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p04-cache-compat.webp",
        "alt": "MTP 검증 경로가 호환되는 KV 캐시에는 연결되고 맞지 않는 캐시에서는 기본 경로로 돌아가는 그림",
        "caption": "모델만 지원한다고 끝나지 않으며 KV 캐시 양자화와 배칭 조합까지 실제 실행 경로에서 확인해야 합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/speculative-decoding",
    "slug": "speculative-decoding",
    "title": "추측 디코딩이란? 초안과 검증의 원리",
    "description": "Speculative Decoding이 작은 초안 모델이나 내장 예측 헤드로 후보 토큰을 만들고 메인 모델이 묶어서 검증해 생성을 가속하는 원리를 설명합니다.",
    "headline": "싼 방법으로 먼저 제안하고, 비싼 메인 모델은 여러 후보를 한꺼번에 확인합니다.",
    "category": "speed",
    "categoryLabel": "답변 속도와 가속",
    "term": "추측 디코딩",
    "alternateName": "Speculative Decoding",
    "plainSummary": "큰 모델의 답변이 마음에 드는데 쓰는 속도가 답답합니다. 작은 모델은 빠르지만 같은 답을 기대하기 어렵습니다. 작은 모델에게 먼저 후보를 만들게 하고 큰 모델이 확인하면 어떨까요? 추측 디코딩은 이 역할 분담으로 생성 시간을 줄이려는 방법입니다.",
    "buyerNote": "작은 초안 모델을 함께 올릴 메모리가 필요할 수 있습니다. 남는 메모리가 적다면 n-gram 방식이나 기본 생성을 먼저 써보는 편이 낫습니다.",
    "keyPoints": [
      "초안 생성기와 타깃 모델 검증기라는 두 역할이 있습니다.",
      "승인률과 초안 비용의 균형이 실제 속도를 결정합니다.",
      "가속 방식이지 모델 품질을 높이는 방식은 아닙니다."
    ],
    "sections": [
      {
        "title": "빠른 초안을 그대로 보내는 것은 아닙니다",
        "paragraphs": [
          "큰 본 모델은 다음 토큰을 하나씩 만들 때마다 계산을 반복합니다. 작은 초안 모델이 후속 후보를 준비하면 본 모델은 여러 위치를 묶어 확인할 수 있습니다. 후보가 잘 맞는 구간은 한꺼번에 받아들여 순차 계산 횟수를 줄입니다.",
          "틀린 후보는 그대로 답변에 들어가지 않습니다. 검증에서 어긋난 뒤쪽을 버리고 본 모델의 결과로 이어갑니다. 정확한 검증을 사용하는 추측 디코딩은 본 모델의 출력을 유지하려는 방법이며, 속도를 위해 임의로 작은 모델의 대답을 섞는 기능과는 다릅니다."
        ]
      },
      {
        "title": "초안을 싸게 만드는 것이 출발점입니다",
        "paragraphs": [
          "별도의 작은 모델을 쓰는 방법 외에도 본 모델의 MTP 헤드나 문맥에서 반복 구문을 찾는 Prompt Lookup을 활용할 수 있습니다. 공통점은 후보를 만드는 일과 본 모델이 검증하는 일을 나눈다는 것입니다. 추가 모델이 없는 방식도 있습니다.",
          "어느 쪽이든 초안이 충분히 가벼워야 합니다. 잘 맞는 초안을 만드는 데 본 모델만큼 시간이 든다면 절감할 여지가 작습니다. 별도 모델 방식에서는 추가 가중치와 캐시가 메모리에 들어가는지도 확인해야 합니다."
        ]
      },
      {
        "title": "승인률이 좋은데 왜 느릴까요?",
        "paragraphs": [
          "많은 후보가 승인됐어도 후보를 만들고 검증하는 시간이 더 길 수 있습니다. 승인률은 중요한 단서지만 최종 목적은 같은 답변을 더 빨리 끝내는 것입니다. 전체 소요 시간과 평균 승인 길이, 메모리 증가를 함께 봐야 합니다.",
          "특히 짧은 답변에서는 준비 비용을 만회하기 전에 출력이 끝날 수 있습니다. 반복이 많은 코드에서는 잘 맞던 설정이 새로운 이야기를 쓰는 질문에서 효과가 작아질 수도 있습니다. 한 작업의 결과를 모든 대화의 배율로 쓰지 않는 이유입니다."
        ]
      },
      {
        "title": "작은 모델을 하나 더 받기 전에",
        "paragraphs": [
          "실행 프로그램이 권장하는 본 모델·초안 모델 조합을 확인하세요. 토큰을 나누는 방식과 모델 구조가 맞아야 하며, 단순히 작은 모델 아무거나 연결하는 것으로 끝나지 않습니다. 우선 본 모델 단독의 정상 답변을 기준으로 남깁니다.",
          "가속을 켠 뒤에는 속도뿐 아니라 반복 출력, 도구 호출 형식과 답변 완료 여부도 확인하세요. 구현과 설정에 문제가 있으면 이론상 목적과 실제 결과가 다를 수 있습니다. 중요한 작업이라면 정답을 아는 질문도 포함해 점검하는 편이 좋습니다."
        ]
      },
      {
        "title": "추가 메모리를 어디에 쓸지",
        "paragraphs": [
          "남는 메모리를 초안 모델에 쓸지, 더 긴 문맥에 남길지, 본 모델의 정밀도를 높일지 선택할 수 있습니다. 어느 선택이 낫다는 답은 작업에 달려 있습니다. 이미 내용이 충분히 좋고 생성만 느리다면 추측 디코딩을 시험할 이유가 있습니다.",
          "반대로 모델이 겨우 들어가는 상황에서는 기본 실행을 안정시키는 것이 먼저입니다. 가속 기능이 많다는 이유로 모두 켜야 하는 것은 아닙니다. 내 질문에서 확실히 줄어든 기다림이 있다면 그 설정만 남겨도 됩니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/p05-draft-target.webp",
        "alt": "작은 초안 모델이 후보 토큰 묶음을 만들고 큰 본 모델이 한 번에 검증하는 그림",
        "caption": "추측 디코딩은 빠른 초안 모델의 제안을 본 모델이 검증해 같은 본 모델의 결과를 더 적은 반복으로 만듭니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p05-tree-verify.webp",
        "alt": "여러 후보 토큰이 나뭇가지처럼 펼쳐진 뒤 검증으로 한 경로만 남는 그림",
        "caption": "트리형 후보를 쓰는 구현도 결국 본 모델이 허용한 연속 경로만 채택하고 나머지는 버립니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p05-overhead-balance.webp",
        "alt": "초안 생성과 검증에 드는 추가 비용, 승인 토큰에서 얻는 이득을 저울처럼 비교한 그림",
        "caption": "초안이 가볍고 후보 승인률이 높아야 추가 작업을 상쇄하므로 모든 프롬프트에서 빨라지는 것은 아닙니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/ngram-prompt-lookup",
    "slug": "ngram-prompt-lookup",
    "title": "반복 문구 가속 (Prompt Lookup)·n-gram 추측 디코딩 설명",
    "description": "Prompt Lookup이 추가 초안 모델 없이 프롬프트와 생성 기록의 반복 구문(n-gram)에서 후속 토큰을 찾아 검증하는 방식과 모델 가중치 오프로드와의 차이점을 설명합니다.",
    "headline": "이미 나온 문구의 다음 부분을 후보로 쓰기 때문에 반복이 많은 작업에서 강합니다.",
    "category": "speed",
    "categoryLabel": "답변 속도와 가속",
    "term": "반복 문구 가속",
    "alternateName": "Prompt Lookup Speculative Decoding",
    "plainSummary": "코드에서 함수 하나만 고쳐 달라고 했는데, 바뀌지 않은 부분까지 한참 다시 출력합니다. 이미 입력에 있는 문장을 좀 더 빨리 이어 쓸 수 없을까요? Prompt Lookup은 그 반복을 후보로 활용합니다. 이름이 비슷한 모델 테이블의 RAM·SSD 오프로드와는 다른 기능입니다.",
    "buyerNote": "코드 수정과 문서 재작성에는 도움이 될 수 있지만 일반 대화에서는 차이가 작을 수 있습니다. 이 기능 때문에 더 비싼 장비를 살 필요는 없습니다.",
    "keyPoints": [
      "별도 초안 모델이 필요 없고 모델 가중치 오프로드(PLE)와 완전히 다른 프롬프트 조회 가속입니다.",
      "입력이나 출력에 반복 패턴이 있어야 후보를 만들 수 있습니다.",
      "코드 수정·요약·문서 재작성에서 유리한 편입니다."
    ],
    "sections": [
      {
        "title": "이미 있는 문장에서 다음 부분을 찾습니다",
        "paragraphs": [
          "최근 생성한 몇 개의 토큰과 같은 패턴을 입력이나 이전 출력에서 찾습니다. 일치하는 곳이 있으면 뒤에 이어졌던 토큰을 후보로 가져옵니다. 본 모델은 이 후보를 묶어서 검증하고 맞는 부분만 사용합니다.",
          "이때 연속된 토큰 묶음을 n-gram이라고 부릅니다. 별도 언어 모델을 실행해 초안을 만드는 것이 아니므로 추가 가중치는 필요하지 않습니다. 다만 조회와 후보 검증에 필요한 작업 공간과 시간까지 전혀 없는 것은 아닙니다."
        ]
      },
      {
        "title": "원문을 많이 남기는 작업에서 생각해볼 수 있습니다",
        "paragraphs": [
          "긴 코드에서 일부만 수정해 다시 출력하거나 기존 문서의 형식을 바꾸는 작업은 원래 문장이 많이 남을 수 있습니다. 다음에 나올 문장이 이미 입력에 있으므로 후보를 찾을 기회도 생깁니다.",
          "반대로 전혀 새로운 설명이나 이야기를 만드는 질문은 일치 구간이 적을 수 있습니다. 이때는 검색을 했지만 쓸 후보가 없거나 검증에서 자주 버리게 됩니다. 어떤 글에서도 똑같이 빨라지는 공통 가속이라고 보기는 어렵습니다."
        ]
      },
      {
        "title": "비슷하다고 복사해서 붙이지는 않습니다",
        "paragraphs": [
          "원문에 있는 문장이라도 지금 답변에 맞는지는 본 모델이 확인해야 합니다. 코드의 변수나 숫자 한 개가 달라졌다면 그 지점 이후의 후보를 그대로 받아들일 수 없습니다. 반복을 이용한다는 말은 검토 없이 원문을 재사용한다는 뜻이 아닙니다.",
          "n을 작게 잡으면 일치는 쉽게 찾지만 엉뚱한 문맥일 수 있고, 크게 잡으면 정확한 패턴을 찾기 어려울 수 있습니다. 후보 길이도 무조건 늘리지 말고 기본값에서 시작해 평균 승인 길이와 전체 시간을 비교하세요."
        ]
      },
      {
        "title": "SSD로 옮긴다는 n-gram과 무엇이 다를까요?",
        "paragraphs": [
          "일부 모델의 큰 임베딩 테이블을 RAM이나 SSD에 두는 PLE 오프로드는 가중치의 저장 위치를 바꾸는 기술입니다. 여기서 설명하는 Prompt Lookup은 문장 기록을 조회해 다음 후보를 만드는 기술입니다. 이름에 n-gram이 함께 등장해도 해결하는 문제가 다릅니다.",
          "Prompt Lookup을 켠다고 본 모델의 큰 가중치가 GPU 밖으로 이동하지 않습니다. 따라서 메모리 부족으로 모델이 로드되지 않는다면 이 옵션이 해결책은 아닙니다. 오프로드 가이드에서는 모델이 담기는 위치와 해당 실행 경로를 따로 확인해야 합니다."
        ]
      },
      {
        "title": "추가 구매 없이 시험할 기능입니다",
        "paragraphs": [
          "평소 수정하는 코드와 자유로운 질문을 각각 준비해 켠 상태와 끈 상태를 비교해보세요. 반복이 많은 예제 한 개의 최고 결과만 남기지 말고, 후보가 잘 안 나오는 작업에서도 손해가 크지 않은지 봅니다.",
          "코드 수정에서만 도움이 된다면 그 작업에만 쓰는 선택도 가능합니다. 모든 질문에 통하는 기능을 찾으려고 장비나 모델을 계속 바꾸기보다, 자주 하는 일 하나의 기다림을 줄이는 것으로도 충분한 개선이 될 수 있습니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/p06-ngram-lookup.webp",
        "alt": "최근 입력에서 같은 토큰 묶음을 찾아 다음 후보를 복사해 제안하는 n-gram 조회 그림",
        "caption": "n-gram 조회는 별도 초안 모델 없이 입력과 최근 출력에서 반복되는 토큰 묶음을 찾아 후보로 사용합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p06-repeated-code.webp",
        "alt": "반복되는 코드와 표 형식의 패턴을 입력 창에서 찾아 다음 구간으로 이어 붙이는 그림",
        "caption": "코드, 표, 서식처럼 반복이 많은 작업에서는 긴 일치 구간을 찾기 쉬워 가벼운 조회만으로도 이득이 날 수 있습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p06-lightweight-compare.webp",
        "alt": "추가 모델 없이 조회 창만 쓰는 방식과 별도 초안 모델을 메모리에 올리는 방식을 비교한 그림",
        "caption": "프롬프트 조회는 메모리 부담이 작지만 반복이 없는 창작 문장에서는 제안할 후보가 적다는 한계가 있습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/qwen-flash-next-ple-offload",
    "slug": "qwen-flash-next-ple-offload",
    "title": "Qwen3.8-Flash-Next PLE RAM·SSD 오프로드 가이드",
    "description": "Qwen3.8-Flash-Next의 180B 상주 가중치 중 51B PLE 임베딩 테이블을 RAM과 NVMe SSD로 오프로드하는 원리, 호환 조건, 페이지 캐시 영향과 점검 체크리스트를 정리합니다.",
    "headline": "51B n-gram 임베딩 테이블을 시스템 RAM과 고속 NVMe SSD로 분할 적재하는 용량 확장 기법입니다.",
    "category": "speed",
    "categoryLabel": "답변 속도와 가속",
    "term": "PLE 오프로드",
    "alternateName": "Qwen Flash Next PLE Offload",
    "plainSummary": "원하는 모델이 GPU 메모리에 들어가지 않는데 PC에는 RAM과 SSD가 남아 있습니다. 그 공간을 빌려 쓸 수 있을까요? PLE 오프로드는 특정 모델의 큰 테이블을 다른 저장 위치로 옮기는 경로입니다. 실행 가능해지는 것과 답변이 빨라지는 것은 여기서도 나누어 봐야 합니다.",
    "buyerNote": "PLE 오프로드는 적재 공간을 확보하는 방법입니다. 필요한 RAM과 NVMe 여유는 실제 체크포인트와 변환·캐시 공간까지 합쳐 확인하세요.",
    "keyPoints": [
      "PLE 오프로드는 디코드 가속이 아닌 GPU VRAM 부족을 해결하는 용량 분할 적재 기술입니다.",
      "공식 vLLM/SGLang의 RAM 오프로드와 실험적 NVMe SSD mmap 희소 스트리밍 경로로 나뉩니다.",
      "SSD의 첫 접근과 페이지 캐시가 남은 반복 접근을 따로 측정해야 합니다."
    ],
    "sections": [
      {
        "title": "전부 옮기는 대신 큰 테이블을 나눕니다",
        "paragraphs": [
          "이 가이드가 다루는 대상은 Qwen3.8-Flash-Next 계열의 PLE 테이블입니다. 코어 모델과 별도로 큰 용량을 차지하는 구성 요소를 호스트 RAM이나 SSD에 두고 필요한 부분에 접근합니다. 모든 모델에서 아무 가중치나 같은 방식으로 내릴 수 있다는 뜻은 아닙니다.",
          "또한 원문에서 반복 문장을 찾아 다음 토큰을 제안하는 Prompt Lookup과도 다릅니다. 둘 다 n-gram이라는 표현이 등장하지만, 하나는 답변 후보를 만들고 다른 하나는 모델의 저장 위치를 바꿉니다. MTP와 함께 쓸 수 있는지도 각각의 구현에서 확인해야 합니다."
        ]
      },
      {
        "title": "RAM에 여유가 있다면 무엇을 확인할까요?",
        "paragraphs": [
          "외장 GPU 시스템에서는 VRAM과 시스템 RAM이 별도입니다. 지원 경로가 테이블을 RAM에 남겨둔다면 GPU 공간을 아낄 수 있습니다. 대신 CPU·GPU 사이 전송과 테이블 조회 비용이 생길 수 있으므로 모두 VRAM에 있는 경우와 같은 속도로 간주하면 안 됩니다.",
          "실제 코어 가중치가 VRAM에 남아 있는지, 호스트 RAM에는 테이블과 운영체제를 위한 공간이 충분한지 확인합니다. 설정 이름만 보고 성공했다고 판단하지 말고 실행 로그와 메모리 사용량을 함께 보세요. 맥의 통합 메모리를 같은 외장 GPU 분할 구조로 계산하는 것도 맞지 않습니다."
        ]
      },
      {
        "title": "SSD에 담으면 메모리를 무한히 늘릴 수 있을까요?",
        "paragraphs": [
          "실험적인 SSD 경로는 전용 체크포인트와 패치가 필요한 mmap 방식 등을 사용합니다. 필요한 테이블 부분을 조회하도록 구현한 경로이지, 일반적인 운영체제 스왑이 빨라졌다는 뜻은 아닙니다. 기본 런타임에 옵션 하나를 추가하면 항상 되는 기능도 아닙니다.",
          "테이블뿐 아니라 모델 전체, 다운로드 임시 파일과 변환 공간이 필요합니다. 필요한 디스크 여유는 실제 배포 파일을 기준으로 계산해야 합니다. 어떤 실험의 저장공간 숫자를 다른 양자화와 체크포인트에 그대로 적용하면 설치 도중 공간이 부족할 수 있습니다."
        ]
      },
      {
        "title": "첫 실행과 다음 실행이 다른 이유",
        "paragraphs": [
          "SSD에서 처음 읽은 내용은 운영체제 페이지 캐시에 남을 수 있습니다. 반복 조회 때 RAM에서 읽으면 다음 실행이 빨라질 수 있지만, 메모리 압박으로 캐시가 밀려나면 다시 디스크를 읽어야 합니다. 따뜻해진 캐시 상태만으로 항상 같은 속도를 기대할 수는 없습니다.",
          "첫 실행과 반복 실행을 따로 기록하고, 평소 함께 사용하는 앱을 켠 상태에서도 확인하세요. 저장장치 읽기가 계속 늘거나 출력이 자주 끊긴다면 용량은 확보했어도 일상적으로 쓰기 좋은 구성인지는 다시 판단해야 합니다."
        ]
      },
      {
        "title": "장비를 사기 전에 재현 경로가 있어야 합니다",
        "paragraphs": [
          "커뮤니티 결과를 참고한다면 모델 파일, 패치 버전, 테이블 위치와 MTP 여부까지 한 묶음으로 봅니다. 실행 명령만 복사하고 전용 파일이 빠지면 같은 구성이 아닙니다. 원래 정상 실행되던 환경은 남겨두고 별도로 시험하는 편이 좋습니다.",
          "오프로드는 없던 선택지를 열어줄 수 있지만, 새 장비 구매의 근거로 쓸 때는 재현 가능성이 중요합니다. 실험을 즐기는 목적과 매일 안정적인 도구가 필요한 목적은 다릅니다. 작은 모델을 여유 있게 쓰는 대안도 함께 두고, 큰 모델에서만 얻는 결과가 추가 복잡성을 감수할 만큼 필요한지 확인하세요."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/acceleration-stage-map.webp",
        "alt": "프리필 단계의 SpecPrefill, 디코드 단계의 MTP·초안 모델·Prompt Lookup, 용량 확장의 PLE RAM 및 SSD 오프로드 분기 지도",
        "caption": "가속과 오프로드는 작동하는 추론 단계가 다르므로 프리필 TTFT 단축, 디코드 토큰 가속, 가중치 용량 분할을 명확히 구분해야 합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/ple-storage-tiers.webp",
        "alt": "GPU VRAM의 코어 LM, 시스템 RAM의 PLE 임베딩 테이블, 고속 NVMe SSD mmap 스트리밍 계층별 메모리 적재 구조 다이어그램",
        "caption": "PLE 오프로드는 디코드 속도 향상이 아닌 대용량 임베딩 테이블을 RAM이나 NVMe SSD로 분할 적재하여 GPU VRAM 한계를 넘는 용량 확장 기술입니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/ple-page-cache-warmup.webp",
        "alt": "NVMe SSD mmap 오프로드 환경에서 첫 접근(Cold I/O)과 OS 페이지 캐시 적재 후(Warm)의 지연 시간 차이를 나타낸 다이어그램",
        "caption": "SSD 오프로드는 초기 접근 시 디스크 I/O 지연이 발생하지만, OS 페이지 캐시가 웜업되면 반복 조회 지연이 크게 줄어듭니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/specprefill-ttft-guide",
    "slug": "specprefill-ttft-guide",
    "title": "SpecPrefill로 긴 입력의 TTFT 줄이기",
    "description": "SpecPrefill이 긴 입력에서 첫 토큰 시간(TTFT)을 줄이는 원리와 Mac(oMLX)·NVIDIA 실험 경로, 답변 품질 가변성 및 대략적 추정치 기준을 설명합니다.",
    "headline": "긴 프롬프트에서 핵심 토큰을 선별해 첫 토큰 대기 시간을 단축하는 실험적 최적화입니다.",
    "category": "speed",
    "categoryLabel": "답변 속도와 가속",
    "term": "SpecPrefill",
    "alternateName": "Speculative Prefill",
    "plainSummary": "PDF를 넣었더니 첫 답변이 나오기까지 오래 걸립니다. 답변이 시작된 뒤에는 빠르니, 그 앞의 기다림만 줄이고 싶습니다. SpecPrefill은 본 모델이 처리할 입력을 선별하는 방법입니다. 다만 덜 읽어서 빨라졌다면 필요한 내용도 남아 있는지 함께 확인해야 합니다.",
    "buyerNote": "긴 문서 요약이나 대규모 코드 분석에서 첫 응답 대기를 줄이는 실험적 기술입니다. 작업과 문서에 따라 효과와 답변 품질이 다를 수 있어 사전 검증이 권장됩니다.",
    "keyPoints": [
      "SpecPrefill은 긴 입력의 프리필 단계에서 첫 토큰 대기 시간(TTFT)을 줄이는 실험적 기술입니다.",
      "Mac 환경에서는 oMLX, NVIDIA 환경에서는 호환 런타임을 통해 실험 경로를 제공합니다.",
      "실험적 최적화로 효과와 답변 품질에 차이가 있을 수 있으며, 사이트의 수치는 대략적인 추정치입니다."
    ],
    "sections": [
      {
        "title": "긴 입력을 처리하는 일이 먼저 있습니다",
        "paragraphs": [
          "모델은 요약문을 쓰기 전에 질문과 문서를 처리합니다. 이 프리필 단계가 오래 걸리면 화면에는 한동안 답변이 보이지 않습니다. SpecPrefill은 작은 모델 등의 도움으로 중요한 토큰을 가려 본 모델이 처리할 양을 줄이려는 방식입니다.",
          "본 모델의 일은 줄지만 선별하는 시간은 추가됩니다. 짧은 질문에서는 줄일 입력 자체가 적어 이득이 작을 수 있습니다. 그래서 첫 답변이 늦었다는 사실만으로 켜기보다, 평소 긴 입력에서 기다림이 큰지부터 확인합니다."
        ]
      },
      {
        "title": "같은 문서를 다시 읽는 캐시와는 다릅니다",
        "paragraphs": [
          "프롬프트 캐시는 이미 계산한 공통 앞부분을 재사용합니다. SpecPrefill은 이번 입력에서 처리할 부분을 고릅니다. 이전 계산을 되쓰는 것과 입력을 선별하는 것은 다르며, 답변 내용에 미치는 영향도 따로 봐야 합니다.",
          "비교할 때 한쪽만 캐시가 남아 있다면 SpecPrefill 효과를 분리하기 어렵습니다. 모델과 문서를 맞추고 캐시 상태를 기록하세요. 첫 토큰까지의 시간과 답변을 이어 쓰는 디코드 속도도 별개로 남기는 편이 좋습니다."
        ]
      },
      {
        "title": "맥에서도 앱과 모델 조합을 확인합니다",
        "paragraphs": [
          "맥에서는 oMLX의 지원 경로를 확인할 수 있습니다. NVIDIA 역시 현재 실행 프로그램과 모델이 해당 실험 기능을 지원해야 합니다. 하드웨어 이름만으로 모든 조합에 같은 옵션을 적용할 수는 없습니다.",
          "먼저 기능을 끈 상태에서 정상 답변을 확인하고, 현재 버전의 지원 설정으로 바꿉니다. 초기 실행부터 여러 가속을 동시에 켜면 어느 변화가 효과를 냈는지 알기 어렵습니다. 이 사이트의 예상 체감도 모든 조합의 실측 보장은 아닙니다."
        ]
      },
      {
        "title": "빠진 한 줄 때문에 다시 읽는다면",
        "paragraphs": [
          "문서에서 금액은 맞게 찾았는데 예외 조건을 놓쳤다고 해봅시다. 자연스럽고 빠른 답변이어도 그 결과를 그대로 쓸 수는 없습니다. 토큰 선별 과정에서 필요한 부분이 빠질 수 있기 때문에 속도와 별도의 내용 점검이 필요합니다.",
          "정답을 알고 있는 날짜·숫자·예외 조건을 질문에 포함해 켜기 전후를 비교하세요. 중요한 정보가 문서 앞쪽뿐 아니라 중간과 뒤쪽에 있을 때도 확인합니다. 요약문이 그럴듯하다는 이유만으로 품질이 유지됐다고 판단하지 않는 것이 핵심입니다."
        ]
      },
      {
        "title": "줄어든 시간과 다시 확인할 시간을 함께 봅니다",
        "paragraphs": [
          "첫 답변이 빨라졌어도 결과를 의심해 원문을 다시 훑는 시간이 늘면 전체 작업은 빨라지지 않을 수 있습니다. 반대로 대략적인 분류나 초벌 요약에서 내용 차이가 허용 범위 안이라면 유용한 선택지가 될 수 있습니다.",
          "모든 문서에 공통으로 적용하기보다 검증한 작업부터 쓰세요. 중요한 계약이나 수치 확인은 원문과 별도로 대조해야 합니다. 기술을 켜는 것이 목적은 아닙니다. 문서를 읽고 판단하는 일을 더 수월하게 만드는 설정만 남기면 됩니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/specprefill-token-selection.webp",
        "alt": "경량 초안 모델이 긴 프롬프트에서 핵심 토큰만 선별하여 메인 모델의 프리필 연산량을 줄이고 TTFT를 단축하는 과정 다이어그램",
        "caption": "작은 모델이 먼저 읽고, 고른 부분을 본 모델에 전달합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/specprefill-ttft-compare.webp",
        "alt": "긴 문맥 프롬프트에서 일반 전체 프리필과 SpecPrefill 핵심 토큰 선별 프리필의 첫 토큰 지연(TTFT) 단축 폭을 비교한 다이어그램",
        "caption": "줄어드는 부분은 답변 전의 대기 시간입니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/specprefill-quality-check.webp",
        "alt": "SpecPrefill 프롬프트 토큰 선별 적용 전후의 답변 품질 보존율과 원문 참조 일치도를 점검하는 A/B 검증 다이어그램",
        "caption": "켜기 전과 후에 같은 질문을 보내 숫자와 조건이 빠지지 않았는지 비교합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/memory-bandwidth-vs-compute",
    "slug": "memory-bandwidth-vs-compute",
    "title": "LLM 메모리 대역폭과 연산 성능 차이",
    "description": "로컬 LLM에서 메모리 대역폭과 GPU 연산 성능이 프리필, 단일 사용자 디코드와 배치 처리에 각각 어떻게 영향을 주는지 설명합니다.",
    "headline": "같은 GPU 성능표라도 토큰을 하나씩 만들 때와 긴 입력을 읽을 때 병목이 다릅니다.",
    "category": "speed",
    "categoryLabel": "답변 속도와 가속",
    "term": "메모리 대역폭",
    "alternateName": "Memory Bandwidth",
    "plainSummary": "GPU의 AI 연산 성능이 훨씬 높은데 로컬 모델은 생각만큼 빨라지지 않습니다. 사양표를 잘못 본 걸까요? 계산할 준비가 되어 있어도 모델 가중치가 도착하기를 기다릴 수 있습니다. ‘얼마나 많이 계산하나’와 ‘얼마나 빨리 가져오나’를 나누면 이 차이가 보입니다.",
    "buyerNote": "단일 사용자 채팅이 목적이면 GPU 코어 수와 AI TOPS만 보지 말고 메모리 대역폭과 같은 모델의 실제 생성 속도를 함께 보세요.",
    "keyPoints": [
      "단일 사용자 디코드는 메모리 대역폭 병목이 되기 쉽습니다.",
      "프리필과 큰 배치는 연산 자원을 더 많이 활용합니다.",
      "TOPS나 코어 수 하나로 전체 LLM 속도를 예측할 수 없습니다."
    ],
    "sections": [
      {
        "title": "계산 장치 앞에도 기다림이 있습니다",
        "paragraphs": [
          "모델은 많은 가중치를 읽으며 다음 토큰을 만듭니다. 한 사람이 토큰을 하나씩 받을 때는 계산 장치가 처리할 자료를 메모리에서 가져오는 일이 속도를 제한할 수 있습니다. 초당 가져올 수 있는 데이터 양이 메모리 대역폭입니다.",
          "같은 이유로 메모리 용량과 대역폭도 구분해야 합니다. 용량이 크면 모델을 담기 쉽지만, 그 가중치를 읽는 속도가 함께 커지는 것은 아닙니다. 큰 모델이 실행된다는 장점과 답변이 빠르다는 장점은 따로 확인해야 합니다."
        ]
      },
      {
        "title": "숫자로 감을 잡아보겠습니다",
        "paragraphs": [
          "가중치 20GB를 토큰마다 한 번 읽고 실효 대역폭이 400GB/s라고 단순화하면, 읽기만으로 약 0.05초가 듭니다. 그 역수는 초당 약 20회입니다. 실제 제품의 측정값이 아니라 대역폭이 제약이 되는 이유를 보여 주는 가상 계산입니다.",
          "여기에는 계산·캐시 접근·프로그램 비용이 빠져 있고, MoE처럼 모든 가중치를 매번 쓰지 않는 구조도 있습니다. 따라서 이 식으로 실제 tok/s를 단정할 수는 없습니다. 이론 대역폭을 그대로 넣어 구매 성능을 약속하는 것도 피해야 합니다."
        ]
      },
      {
        "title": "긴 문서를 읽을 때는 계산 모양이 달라집니다",
        "paragraphs": [
          "프리필에서는 여러 입력 토큰을 함께 처리할 수 있습니다. 단일 토큰을 순서대로 만들 때보다 계산을 묶어 GPU 자원을 활용할 여지가 큽니다. 이때는 연산 성능의 차이가 더 잘 드러날 수 있습니다.",
          "여러 요청을 배치로 묶는 서버도 조건이 다릅니다. 그래서 짧은 대화에서 비슷했던 장비가 긴 문서 처리에서는 차이를 보일 수 있습니다. TOPS 하나나 메모리 대역폭 하나를 모든 작업의 대표 점수로 쓰기 어려운 이유입니다."
        ]
      },
      {
        "title": "양자화하면 읽을 양은 줄어듭니다",
        "paragraphs": [
          "가중치를 낮은 비트로 저장하면 메모리에서 옮길 양이 줄어들 수 있습니다. 하지만 압축된 표현을 계산에 쓰는 처리와 커널 효율도 영향을 줍니다. 파일이 절반이 됐으니 속도는 두 배라는 계산으로 끝낼 수는 없습니다.",
          "제조사의 이론 사양과 실제 활용률도 다릅니다. 모델 구조·실행 프로그램·양자화 형식·냉각 조건이 바뀌면 같은 장비에서도 결과가 달라집니다. 사양표는 후보를 이해하는 출발점이고 같은 조건의 실행 결과가 다음 확인 자료입니다."
        ]
      },
      {
        "title": "어느 숫자를 먼저 볼지 정합니다",
        "paragraphs": [
          "혼자 긴 답변을 받는 작업이 많다면 적재 가능 여부 뒤에 디코드를 봅니다. 긴 문서를 읽히거나 여러 요청을 처리한다면 프리필과 처리량도 따로 봐야 합니다. 가속 기능을 켠 기록과 기본 기록을 섞지 않는 것도 중요합니다.",
          "비싼 GPU가 기대보다 빨라지지 않았다면 무조건 더 높은 등급을 찾기 전에 어디서 기다리는지 살펴보세요. 필요한 것은 더 많은 메모리일 수도, 더 좋은 실행 경로일 수도 있습니다. 병목을 찾으면 사양표에서 다음으로 볼 칸이 달라집니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/p07-decode-stream.webp",
        "alt": "출력 토큰 하나를 만들 때마다 모델 가중치가 메모리에서 계산 장치로 흐르는 그림",
        "caption": "단일 사용자 디코드는 같은 가중치를 반복해서 읽기 때문에 메모리 대역폭의 영향을 크게 받습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p07-prefill-matrix.webp",
        "alt": "많은 입력 토큰을 넓은 계산 격자에서 한꺼번에 처리하는 프리필 행렬 계산 그림",
        "caption": "프리필은 입력 토큰을 병렬로 처리하므로 긴 입력에서는 연산 장치의 계산 능력을 더 적극적으로 활용합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p07-roofline-bottleneck.webp",
        "alt": "메모리 운반대와 계산 장치 가운데 더 느린 쪽이 전체 속도를 제한하는 병목 그림",
        "caption": "실제 속도는 메모리 공급과 계산 처리 중 먼저 한계에 닿는 쪽에서 결정되므로 TOPS만으로 비교할 수 없습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/vram-and-unified-memory",
    "slug": "vram-and-unified-memory",
    "title": "로컬 LLM VRAM·통합 메모리 용량 계산 가이드",
    "description": "12B·27B·35B·70B급 로컬 LLM에 필요한 VRAM과 통합 메모리를 양자화, 런타임 여유, KV 캐시와 문맥 길이까지 포함해 판단하는 방법입니다.",
    "headline": "표시 메모리보다 모델과 캐시에 실제로 쓸 수 있는 용량이 중요합니다.",
    "category": "memory",
    "categoryLabel": "메모리와 모델",
    "plainSummary": "모델 파일이 20GB인데 그래픽카드 메모리는 24GB입니다. 4GB가 남으니 충분할 것 같죠. 그런데 대화를 길게 하자 메모리가 부족해질 수 있습니다. 파일을 담는 공간 말고 무엇이 더 필요한지부터 살펴보겠습니다.",
    "buyerNote": "원하는 모델이 간신히 들어가는 용량보다 한 단계 여유 있는 구성이 안전합니다. 맥의 통합 메모리도 전부 LLM만 쓰는 것은 아닙니다.",
    "keyPoints": [
      "가중치 크기에 런타임과 KV 캐시 여유를 더합니다.",
      "통합 메모리도 운영체제와 앱이 함께 사용합니다.",
      "GPU 여러 장의 VRAM은 자동으로 하나가 되지 않습니다."
    ],
    "sections": [
      {
        "title": "파일 하나만 담으면 끝나는 게 아닙니다",
        "paragraphs": [
          "20GB라는 숫자는 설명을 위한 예입니다. 실제 모델은 양자화 방식과 파일 구성에 따라 크기가 달라집니다. 우선 이 파일을 메모리에 올리는 데 공간이 필요합니다.",
          "여기에 실행 프로그램의 작업 공간과 대화의 계산 기록도 더해집니다. 이 기록을 KV 캐시라고 부릅니다. 남은 4GB 전체를 대화에 쓸 수 있다고 계산하면 안 되는 이유입니다."
        ]
      },
      {
        "title": "그런데 왜 처음에는 잘 돌아갔을까요?",
        "paragraphs": [
          "처음 보낸 질문이 짧았다면 캐시도 작았을 수 있습니다. 이후 긴 문서를 넣거나 대화를 이어 가면 보관할 계산 기록이 늘어납니다. 모델 파일은 그대로인데 실행 중 메모리는 달라질 수 있는 겁니다.",
          "그래서 ‘모델을 불러오는 데 성공했다’와 ‘내 작업을 끝까지 처리했다’를 구분해야 합니다. 평소 넣을 문서와 답변 길이로 실행해 보고, 그때 가장 많이 쓴 메모리를 확인하세요."
        ]
      },
      {
        "title": "PC에 RAM을 더 꽂으면 해결될까요?",
        "paragraphs": [
          "전용 그래픽카드가 있는 PC라면 시스템 RAM과 GPU의 VRAM은 별도 공간입니다. RAM을 늘려도 그래픽카드의 VRAM 용량이 늘지는 않습니다.",
          "일부 실행 프로그램은 모델을 RAM에 나눠 담을 수 있습니다. 다만 두 메모리 사이를 오가거나 CPU가 계산하는 시간이 추가될 수 있어, 실행 가능해지는 것과 빠르게 쓸 수 있는 것은 별개의 문제입니다.",
          "맥의 통합 메모리는 CPU와 GPU가 같은 메모리를 사용하는 구조입니다. 대신 운영체제와 다른 앱도 그 공간을 씁니다. 따라서 맥의 32GB와 그래픽카드의 32GB를 모델 전용 공간이 같은 것처럼 비교할 수는 없습니다."
        ]
      },
      {
        "title": "GPU 두 장도 그냥 더하면 안 됩니다",
        "paragraphs": [
          "24GB 카드 두 장을 꽂으면 메모리의 물리적인 합은 48GB입니다. 하지만 실행 프로그램이 모델을 두 카드에 나눠 올릴 수 있어야 그 공간을 활용합니다.",
          "카드마다 필요한 작업 공간도 남겨야 하고, 나눈 계산 결과를 주고받는 시간도 듭니다. ‘48GB를 확보했다’는 숫자만으로 한 장짜리 48GB GPU와 같은 조건이라고 볼 수 없습니다."
        ]
      },
      {
        "title": "용량을 고를 때는 이 순서로 보세요",
        "paragraphs": [
          "받을 모델 파일을 정하고, 실제로 쓸 입력 길이로 메모리를 계산합니다. 그다음 실행 중 작업 공간과 다른 앱이 사용할 여유를 남깁니다. 모든 모델에 통하는 하나의 여유 비율보다는 해당 조합의 실행 기록을 확인하는 편이 낫습니다.",
          "이미 필요한 공간이 충분하다면 메모리를 더 늘리는 것만으로 답변이 빨라지지는 않습니다. 그때부터는 같은 모델의 생성 속도와 첫 토큰 시간을 비교하세요. 메모리 부족을 해결하려는 구매인지, 대기 시간을 줄이려는 구매인지부터 나누면 선택이 명확해집니다.",
          "용량을 낮추면 나중에 후회할까 봐 처음부터 큰 구성을 고르고 싶을 수 있습니다. 특히 구매 후 메모리를 바꾸기 어려운 장비라면 그 걱정은 이유가 있습니다. 다만 아직 쓰려는 모델도 정하지 않은 상태에서 가장 큰 용량부터 고르면, 무엇을 위해 비용을 더 내는지 확인하기 어렵습니다.",
          "지금 사용할 모델과 꼭 해보고 싶은 다음 작업을 하나씩 적어 보세요. 두 가지가 모두 들어가는지 살펴보는 것으로 시작하면 됩니다. 언젠가 나올 모든 모델을 위해 오늘 장비를 살 수는 없지만, 적어도 이번에 하려던 일을 못 하는 장비를 고를 가능성은 줄일 수 있습니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/p08-vram-unified.webp",
        "alt": "전용 VRAM 구조와 CPU·GPU가 함께 쓰는 통합 메모리 구조를 나란히 비교한 그림",
        "caption": "전용 VRAM은 GPU 가까이에 있고 통합 메모리는 CPU와 GPU가 한 저장 공간을 공유하지만 표시 용량 전부가 가용하지는 않습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p08-separate-pools.webp",
        "alt": "그래픽카드 VRAM과 시스템 RAM이 분리되고 두 저장 공간 사이에 전송 경로가 놓인 그림",
        "caption": "전용 GPU PC는 시스템 RAM이 많아도 모델의 핵심 부분이 VRAM을 넘으면 전송 비용이나 큰 속도 저하가 생길 수 있습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p08-headroom.webp",
        "alt": "표시 메모리에서 운영체제, 런타임, KV 캐시와 안전 여유를 차례로 덜어 내는 그림",
        "caption": "장비 비교에서는 명목 용량이 아니라 실제 모델 적재에 쓸 수 있는 가용 용량을 기준으로 봐야 합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/kv-cache",
    "slug": "kv-cache",
    "title": "LLM KV 캐시란? 문맥 메모리와 속도 이해",
    "description": "KV 캐시가 이전 토큰의 어텐션 key와 value를 저장해 반복 계산을 줄이는 원리와 문맥 길이, 메모리 사용량, 양자화의 관계를 설명합니다.",
    "headline": "이전 토큰의 계산 상태를 보관해, 새 토큰마다 과거 전체를 다시 계산하지 않게 합니다.",
    "category": "memory",
    "categoryLabel": "메모리와 모델",
    "term": "KV 캐시",
    "alternateName": "Key-Value Cache",
    "plainSummary": "모델 파일은 그대로인데 대화가 길어질수록 메모리가 늘어납니다. 새 모델을 받은 것도 아닌데 왜 공간이 더 필요할까요? 답변을 이어 쓰기 위해 보관하는 계산 기록이 있기 때문입니다. 이 KV 캐시를 이해하면 긴 대화에서 생기는 메모리 부족도 설명할 수 있습니다.",
    "buyerNote": "대화를 길게 하거나 여러 사람이 함께 쓰려면 모델 파일이 들어간 뒤에도 KV 캐시용 메모리가 남아 있어야 합니다.",
    "keyPoints": [
      "KV 캐시는 모델 가중치와 별도의 실행 중 메모리입니다.",
      "입력과 출력 토큰이 늘수록 일반적으로 커집니다.",
      "캐시 양자화는 메모리를 줄이지만 짧은 문맥에서는 느릴 수 있습니다."
    ],
    "sections": [
      {
        "title": "앞부분을 매번 처음부터 계산하지 않으려고",
        "paragraphs": [
          "다음 토큰을 만들려면 앞에서 읽고 쓴 내용을 참고해야 합니다. 이미 처리한 부분을 매번 다시 계산하면 낭비가 큽니다. KV 캐시는 어텐션에 필요한 key와 value 상태를 보관해 이 반복을 줄입니다.",
          "채팅 내용을 텍스트로 복사해 둔 파일과는 다릅니다. 모델의 여러 층에서 쓰는 계산 상태이며, 사용자가 보는 몇 줄의 문장보다 많은 공간이 필요할 수 있습니다. 대화창에 남은 글자 수만으로 캐시 용량을 바로 알 수 없는 이유입니다."
        ]
      },
      {
        "title": "짧게 물을 때는 몰랐던 비용",
        "paragraphs": [
          "처음에는 짧은 질문 한 개라 여유가 있었을 수 있습니다. 긴 문서를 넣고 답변을 계속 받으면 입력과 출력의 계산 상태가 늘어납니다. 같은 모델도 문맥 길이, 구조와 캐시 정밀도에 따라 메모리 사용량이 달라집니다.",
          "여러 대화를 동시에 실행하면 각 요청의 상태도 필요합니다. 모델 가중치를 한 번 올렸다고 나머지 사용자는 공간을 거의 쓰지 않는 것은 아닙니다. 팀 서버를 준비한다면 한 사람의 최대 문맥과 동시 요청 수를 함께 맞춰야 합니다."
        ]
      },
      {
        "title": "모델을 Q4로 받았는데 캐시는 왜 그대로일까요?",
        "paragraphs": [
          "가중치 양자화와 KV 캐시 양자화는 다른 설정입니다. Q4 모델을 받았더라도 캐시는 다른 정밀도로 저장할 수 있습니다. 지원되는 경우 캐시를 8비트나 4비트로 줄여 긴 문맥에 필요한 공간을 아낄 수 있습니다.",
          "대신 변환과 계산 비용이 추가되거나 작업에 따라 품질 차이가 생길 수 있습니다. 메모리가 충분한 짧은 대화에서 무조건 빠른 설정이라고 볼 수는 없습니다. 같은 문서의 답변과 속도를 확인하면서 필요한 만큼만 바꾸세요."
        ]
      },
      {
        "title": "오래된 기록을 지우면 끝날까요?",
        "paragraphs": [
          "캐시에 상한을 두고 오래된 상태를 버리는 방식도 있습니다. 공간을 제한할 수 있지만 초반의 세부 정보가 더 이상 직접 참조되지 않을 수 있습니다. 모델이 원래 가까운 문맥만 보는 구조인지, 프로그램이 임의로 기록을 잘랐는지는 구분해야 합니다.",
          "대화 초반의 조건을 나중에 다시 묻는 작업이라면 이 차이가 중요합니다. 메모리 사용량이 줄었다고 성공으로 끝내지 말고, 처음 전달한 숫자나 요청이 답변에 유지되는지 확인해야 합니다."
        ]
      },
      {
        "title": "메모리 부족이 알려주는 다음 선택",
        "paragraphs": [
          "캐시 때문에 부족하다면 모델 전체를 바꾸기 전에 입력 길이와 동시 요청, 캐시 정밀도를 점검할 수 있습니다. 반대로 늘 긴 문서가 필요하고 압축 뒤에도 원하는 품질을 얻지 못한다면 더 큰 메모리의 이유가 분명해집니다.",
          "장비를 고를 때 파일이 들어간다는 말 다음에 ‘대화를 얼마나 이어갈 수 있나’를 붙여보세요. 처음 인사에 답하는 장비가 아니라, 실제 작업이 끝날 때까지 함께 갈 수 있는 구성을 찾는 것입니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/kv-cache-concept.webp",
        "alt": "긴 입력에서 계산한 키와 값을 서랍에 저장하고 다음 토큰 생성 때 다시 꺼내 쓰는 KV 캐시 그림",
        "caption": "KV 캐시는 앞선 입력의 계산 값을 보관해 다시 계산하는 일을 줄이며, 문맥이 길어질수록 보관 공간도 커집니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p09-cache-growth.webp",
        "alt": "답변 토큰이 늘어날 때마다 키와 값 카드가 짝을 이뤄 캐시 서랍에 쌓이는 그림",
        "caption": "각 토큰은 레이어별 키와 값을 남기므로 문맥 길이, 레이어 수와 동시 요청 수가 커질수록 KV 캐시가 빠르게 늘어납니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p09-kv-quant.webp",
        "alt": "정밀한 KV 캐시와 더 적은 비트로 압축한 작은 KV 캐시를 나란히 비교한 그림",
        "caption": "KV 캐시 양자화는 긴 문맥의 메모리를 줄일 수 있지만 지원 커널과 품질, 속도 변화를 함께 확인해야 합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/prompt-cache-prefix-cache",
    "slug": "prompt-cache-prefix-cache",
    "title": "프롬프트 캐시·Prefix Cache가 줄이는 시간",
    "description": "반복되는 시스템 프롬프트와 공통 문서의 계산 상태를 재사용하는 프롬프트 캐시와 prefix cache가 TTFT를 줄이는 조건과 한계를 설명합니다.",
    "headline": "앞부분이 완전히 같을 때 이미 계산한 프리필을 다시 쓰는 기술입니다.",
    "category": "memory",
    "categoryLabel": "메모리와 모델",
    "term": "프롬프트 캐시",
    "alternateName": "Prompt Cache / Prefix Cache",
    "plainSummary": "같은 문서로 두 번째 질문을 했더니 첫 번째보다 훨씬 빨리 답합니다. 장비가 갑자기 빨라진 걸까요? 앞서 계산한 부분을 다시 썼을 수 있습니다. 프롬프트 캐시는 반복 작업의 기다림을 줄여주지만, 무엇이 같아야 재사용할 수 있는지 알아야 효과를 유지할 수 있습니다.",
    "buyerNote": "개인 채팅보다 긴 공통 지침을 반복하는 업무용 도구에서 효과가 큽니다. 이 기능 하나보다 런타임의 안정성과 메모리 용량을 먼저 보세요.",
    "keyPoints": [
      "공통 접두 토큰의 KV 상태를 재사용합니다.",
      "프롬프트 앞부분이 달라지면 재사용 구간이 짧아집니다.",
      "디코드 tok/s보다 프리필과 TTFT를 줄이는 기능입니다."
    ],
    "sections": [
      {
        "title": "답변이 아니라 앞부분의 계산을 다시 씁니다",
        "paragraphs": [
          "긴 공통 지침과 문서를 매번 보내는 도구를 생각해봅시다. 마지막 질문만 달라져도 앞부분을 계속 새로 처리하면 같은 일을 반복합니다. Prefix Cache는 공통 접두 구간의 KV 상태를 찾아 재사용합니다.",
          "이전 답변을 그대로 돌려주는 응답 캐시와는 다릅니다. 새로운 질문과 답변은 여전히 계산해야 합니다. 줄어드는 것은 주로 공통 입력을 처리하는 시간이며, 첫 토큰 뒤 생성 속도가 같은 비율로 빨라지는 것은 아닙니다."
        ]
      },
      {
        "title": "뜻이 같아도 토큰이 다르면 달라집니다",
        "paragraphs": [
          "프로그램은 대체로 처음부터 이어지는 토큰의 일치를 봅니다. 공백, 채팅 템플릿과 도구 정의가 달라져도 앞부분이 바뀔 수 있습니다. 사람에게 같은 문서처럼 보여도 캐시를 재사용하지 못할 수 있습니다.",
          "매번 변하는 날짜나 요청 정보를 앞에 두면 뒤의 긴 공통 지침까지 일치 구간이 이어지지 않을 수 있습니다. 고정 내용을 앞에, 변하는 질문을 뒤에 배치하는 구조를 검토하되 지시의 의미나 필요한 정보까지 바꾸지는 마세요."
        ]
      },
      {
        "title": "저장해 두는 공간도 필요합니다",
        "paragraphs": [
          "공통 문서가 하나라면 관리가 단순하지만 종류가 많아지면 캐시가 차지하는 메모리도 커집니다. 공간이 부족하면 오래 쓰지 않은 상태를 내보내므로, 전에 빨랐던 질문이 다음에는 다시 오래 걸릴 수 있습니다.",
          "여러 사람이 같은 서버를 쓰는 경우에는 사용자·모델·설정이 맞는 상태만 재사용되어야 합니다. 서로 다른 조건의 계산 기록을 섞는 기능이 아닙니다. 앱이 어떤 단위로 캐시를 구분하고 지우는지 확인하는 것이 운영의 일부입니다."
        ]
      },
      {
        "title": "첫 실행과 반복 실행을 따로 재보세요",
        "paragraphs": [
          "처음 읽는 문서로 한 번, 같은 문서의 질문을 바꿔 다시 한 번 실행해봅니다. 각각 첫 토큰까지의 시간과 새로 처리한 입력, 재사용한 입력을 기록합니다. 준비 실행 이후 같은 조건 세 번의 중앙값도 비교하면 결과를 이해하기 쉽습니다.",
          "캐시가 남은 장비와 비어 있는 장비의 숫자를 섞으면 하드웨어 차이처럼 보일 수 있습니다. 순수 입력 처리 성능과 실제 반복 업무의 체감은 둘 다 유용하지만, 다른 측정입니다. 어떤 상황을 비교했는지 결과 옆에 남겨야 합니다."
        ]
      },
      {
        "title": "반복하는 문서가 있다면 장비보다 먼저 볼 것",
        "paragraphs": [
          "매번 같은 규칙을 보내는 에이전트나 하나의 문서에 여러 질문을 하는 도구라면 캐시가 도움이 될 수 있습니다. 반대로 짧고 매번 다른 질문에는 효과가 작을 수 있습니다. 모든 용도에 같은 배율로 반영할 수는 없습니다.",
          "지금 장비가 느리다고 느꼈다면 공통 문서를 매번 새로 처리하고 있는지도 살펴보세요. 이미 계산한 것을 다시 쓰는 것만으로 충분해질 수 있습니다. 다만 모델이 읽지 않은 새 자료의 첫 처리까지 사라지는 것은 아니므로, 새 문서에서도 기다릴 만한지는 따로 확인해야 합니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/p10-prompt-context-cache.webp",
        "alt": "공통 시스템 프롬프트와 문서 계산 결과를 저장해 여러 질문에서 재사용하는 캐시 그림",
        "caption": "프롬프트 캐시는 같은 접두사의 계산 결과를 다시 쓰지만, 모델과 양자화가 달라지면 같은 캐시를 공유할 수 없습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p10-prefix-branch.webp",
        "alt": "하나의 긴 공통 접두사에서 여러 질문 가지가 갈라져 각 답변으로 이어지는 그림",
        "caption": "긴 시스템 지시와 문서를 공통 접두사로 고정하면 여러 질문이 같은 계산 구간을 재사용할 수 있습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p10-cache-invalidation.webp",
        "alt": "앞부분이 정확히 같은 입력은 캐시를 쓰고 초반 토큰이 바뀐 입력은 다시 계산하는 그림",
        "caption": "접두사 캐시는 앞에서부터 토큰이 정확히 일치해야 하므로 날짜나 사용자별 문구는 가능한 뒤쪽에 두는 편이 유리합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/llm-quantization",
    "slug": "llm-quantization",
    "title": "LLM 양자화란? Q4·Q8·FP16 선택 기준",
    "description": "로컬 LLM의 가중치를 Q4·Q8 등 낮은 비트로 줄일 때 메모리, 속도와 품질이 어떻게 달라지는지와 양자화 형식 선택 기준을 설명합니다.",
    "headline": "비트를 줄이면 더 큰 모델이 들어가지만, 모든 Q4가 같은 크기와 품질은 아닙니다.",
    "category": "memory",
    "categoryLabel": "메모리와 모델",
    "term": "LLM 양자화",
    "alternateName": "LLM Quantization",
    "plainSummary": "같은 모델인데 다운로드 목록에는 Q4, Q8과 여러 이름이 붙어 있습니다. 작은 파일을 받으면 답변도 그만큼 나빠질까요? 큰 파일을 받으면 무조건 좋은 선택일까요? 용량을 줄이면서 무엇을 잃을 수 있는지, 그리고 내 작업에서 그 차이를 어떻게 확인할지 보겠습니다.",
    "buyerNote": "처음에는 Q4로 원하는 모델이 잘 돌아가는지 확인하세요. 중요한 코드나 계산에서 차이가 느껴질 때 Q8 또는 더 높은 정밀도를 검토하면 됩니다.",
    "keyPoints": [
      "가중치 양자화와 KV 캐시 양자화는 별개입니다.",
      "같은 4비트 표기도 블록 크기와 혼합 정밀도가 다릅니다.",
      "품질 손실은 모델과 작업별로 직접 확인해야 합니다."
    ],
    "sections": [
      {
        "title": "단어가 아니라 모델의 숫자를 줄입니다",
        "paragraphs": [
          "모델 가중치는 많은 숫자로 저장됩니다. 양자화는 이 숫자의 표현을 더 적은 비트로 바꿔 파일과 메모리 부담을 줄입니다. 문장을 삭제해 요약하는 압축이 아니며, 일반적으로 원래 숫자를 완전히 똑같이 복원하는 방식도 아닙니다.",
          "단순 가정으로 숫자 하나의 표현을 16비트에서 4비트로 줄이면 그 부분은 4분의 1이 됩니다. 실제 파일에는 보조 정보와 더 높은 정밀도로 남긴 부분도 있어 정확히 같은 비율로 줄지는 않습니다. 다운로드 크기를 직접 확인해야 하는 이유입니다."
        ]
      },
      {
        "title": "같은 Q4 이름 안에서도 다릅니다",
        "paragraphs": [
          "어떤 가중치를 더 정밀하게 남기는지, 묶음을 어떻게 나누는지에 따라 결과가 달라집니다. Q4_K_M, AWQ, GPTQ와 MLX의 4비트 표기를 하나의 파일처럼 취급할 수는 없습니다. 실행 프로그램이 지원하는 형식부터 확인합니다.",
          "모델 크기뿐 아니라 변환본에 필요한 토크나이저와 템플릿, 비전이나 MTP 구성 요소가 포함됐는지도 봐야 합니다. 파일이 작아진 이유가 양자화인지, 필요한 기능이 빠진 것인지도 구분해야 합니다."
        ]
      },
      {
        "title": "메모리에 들어오는 순간의 차이가 큽니다",
        "paragraphs": [
          "높은 정밀도에서는 일부가 RAM으로 넘어가던 모델이 낮은 정밀도에서 GPU에 들어갈 수 있습니다. 이 경우 전송 부담을 줄여 체감이 크게 좋아질 여지가 있습니다. 가중치를 읽을 양 자체가 줄어드는 이점도 있습니다.",
          "반대로 이미 여유 있게 들어가는 모델은 압축 표현을 처리하는 비용과 커널 효율에 따라 속도 차이가 작거나 예상과 다를 수 있습니다. 파일이 절반이면 생성 시간도 절반이라는 계산 대신 같은 앱과 장비에서 비교하세요."
        ]
      },
      {
        "title": "내가 신경 쓰는 실수를 골라서 봅니다",
        "paragraphs": [
          "전체 벤치마크 점수 변화가 작아도 내 작업에서는 중요한 차이가 날 수 있습니다. 코드의 실행 결과, 문서 속 금액이나 조건, 도구 호출의 형식처럼 정답을 확인할 수 있는 항목을 준비하세요. 자연스러운 문장만으로 정확도를 판단하기는 어렵습니다.",
          "Q4와 Q8에 같은 질문을 보내고 오류가 반복되는지 봅니다. 한 번의 답변 차이는 생성의 변동일 수도 있으므로 여러 사례가 필요합니다. 큰 모델의 낮은 정밀도와 작은 모델의 높은 정밀도 중 어느 쪽이 나은지도 작업별로 달라질 수 있습니다."
        ]
      },
      {
        "title": "높은 비트가 주는 안심에도 가격이 있습니다",
        "paragraphs": [
          "Q8을 쓰려면 더 큰 메모리를 사야 하는 상황이라면, 그 차이가 실제로 필요한지 먼저 확인해보세요. Q4에서 자주 하는 일이 충분히 잘된다면 높은 정밀도를 위해 장비를 키울 이유가 줄어듭니다. 반대로 중요한 실수가 줄어든다면 추가 비용의 이유가 생깁니다.",
          "모델 가중치와 KV 캐시 정밀도는 별도입니다. 두 설정을 한꺼번에 바꾸지 말고 비교한 파일과 설정을 남기세요. 가장 큰 파일을 소유하는 것보다 내가 신뢰하고 검토하며 쓸 수 있는 결과를 얻는 것이 선택의 기준입니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/quantization-concept.webp",
        "alt": "촘촘한 모델 가중치를 몇 단계의 값으로 묶어 더 작은 격자로 줄이는 양자화 과정 그림",
        "caption": "양자화는 가중치를 더 적은 단계로 묶어 파일과 메모리를 줄이지만, 압축이 강할수록 손실 가능성도 커집니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p11-bit-depth.webp",
        "alt": "가중치 표현 단계가 촘촘한 원본에서 중간 단계와 거친 단계로 줄어드는 그림",
        "caption": "비트 수가 낮아질수록 저장 크기는 줄지만 같은 4비트라도 그룹 크기와 보정값 방식에 따라 결과가 달라집니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p11-quality-memory.webp",
        "alt": "모델 크기와 메모리 절감, 답변 품질 보존 사이의 균형을 저울처럼 보여 주는 그림",
        "caption": "가장 작은 파일보다 자주 하는 작업의 품질을 유지하면서 장비 메모리에 여유 있게 들어가는 양자화를 고르는 편이 낫습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/moe-vs-dense",
    "slug": "moe-vs-dense",
    "title": "MoE와 Dense LLM 차이: 총·활성 파라미터",
    "description": "Mixture of Experts 모델의 총 파라미터와 토큰마다 활성화되는 파라미터가 왜 다르며 로컬 장비의 메모리와 토큰 속도에 어떤 영향을 주는지 설명합니다.",
    "headline": "일부 전문가만 계산해도 전체 전문가의 가중치는 메모리에 있어야 합니다.",
    "category": "memory",
    "categoryLabel": "메모리와 모델",
    "term": "Mixture of Experts",
    "alternateName": "MoE",
    "plainSummary": "모델 설명에는 전체 35B, 활성 3B 같은 숫자가 함께 나옵니다. 다운로드할 때는 큰 모델인데 실행할 때는 작은 모델이라는 뜻일까요? 반은 맞지만 이 말만 믿고 장비를 고르면 메모리가 부족할 수 있습니다. 보관하는 규모와 매번 계산하는 규모를 따로 읽어보겠습니다.",
    "buyerNote": "모델 이름의 “3B 활성”만 보고 3B 모델처럼 가볍다고 생각하면 안 됩니다. 장비를 고를 때는 실제 Q4 파일 크기와 총 파라미터를 먼저 보세요.",
    "keyPoints": [
      "Dense는 대부분의 가중치를 매 토큰 사용합니다.",
      "MoE는 라우터가 일부 전문가만 선택해 계산합니다.",
      "활성 파라미터는 계산량 지표이지 필요한 메모리 용량이 아닙니다."
    ],
    "sections": [
      {
        "title": "Dense는 대부분의 가중치를 사용합니다",
        "paragraphs": [
          "밀집형 모델은 토큰을 만들 때 대부분의 가중치를 거칩니다. 같은 계열과 조건이라면 모델이 커질수록 담을 공간과 처리할 일이 함께 늘어나는 방향으로 이해할 수 있습니다. 물론 실제 속도는 양자화와 실행 프로그램의 영향도 받습니다.",
          "MoE는 여러 전문가 블록을 두고 토큰마다 일부를 선택합니다. 다만 각 전문가가 국어·수학처럼 사람이 정한 한 과목을 맡는다는 뜻은 아닙니다. 학습된 라우터가 계산 경로를 고르는 구조입니다."
        ]
      },
      {
        "title": "두 숫자는 서로 다른 질문에 답합니다",
        "paragraphs": [
          "총 파라미터는 전문가와 공유 부분을 합친 규모입니다. 활성 파라미터는 한 토큰에서 실제로 쓰는 부분의 규모입니다. 전자는 파일과 메모리를, 후자는 토큰당 계산 부담을 이해하는 단서가 됩니다.",
          "활성 부분만 저장해 두면 되지 않느냐고 생각할 수 있습니다. 하지만 다음 토큰에서는 다른 전문가가 선택될 수 있습니다. 전체 가중치를 접근 가능한 곳에 보관해야 하며, 일부를 느린 저장 위치에 둔다면 가져오는 시간까지 고려해야 합니다."
        ]
      },
      {
        "title": "숫자가 커도 빠를 수 있는 이유",
        "paragraphs": [
          "한 토큰에서 읽고 계산할 부분이 작고 런타임의 전문가 처리가 효율적이라면, 총규모가 더 작은 Dense보다 빠르게 생성할 수 있습니다. 그래서 모델 이름의 B 숫자만으로 속도 순서를 정하면 맞지 않을 수 있습니다.",
          "이것은 항상 성립하는 법칙은 아닙니다. 라우팅과 불규칙한 메모리 접근 비용이 있고, 장비가 계산을 얼마나 잘 묶는지도 영향을 줍니다. 같은 양자화와 작업에서 프리필·디코드 결과를 직접 비교하는 단계가 남아 있습니다."
        ]
      },
      {
        "title": "큰 총규모가 답변의 승자를 정하지는 않습니다",
        "paragraphs": [
          "전문가가 많다고 내가 하는 문서 요약이나 코드 수정에서 항상 유리하다고 단정할 수 없습니다. 학습 데이터, 모델 설계와 지시를 따르는 능력이 함께 작용합니다. 전체와 활성 수치 중 어느 하나를 지능 점수처럼 읽지 마세요.",
          "한 모델은 빨라도 오류가 많고 다른 모델은 조금 느려도 수정이 덜 필요할 수 있습니다. 가능하면 실제로 사용할 질문으로 결과를 확인한 뒤 속도를 비교하세요. 모델을 고른 뒤 그 모델이 편하게 들어가는 장비를 찾는 순서가 덜 헷갈립니다."
        ]
      },
      {
        "title": "메모리는 넉넉한데 느리다면",
        "paragraphs": [
          "큰 통합 메모리로 적재 문제를 해결했더라도 대역폭이나 실행 경로가 생성 속도를 제한할 수 있습니다. 반대로 빠른 GPU라도 가중치가 VRAM을 넘으면 오프로드로 이점을 잃을 수 있습니다. 용량과 속도는 따로 통과해야 하는 조건입니다.",
          "MoE라는 이름 자체를 구매 이유로 삼기보다, 원하는 모델의 전체 파일·캐시·실제 생성 결과를 함께 보세요. 숫자 두 개를 이해하는 목적은 복잡한 사양을 외우는 것이 아니라, 작은 활성 수치만 믿고 잘못된 장비를 고르지 않는 데 있습니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/moe-routing-concept.webp",
        "alt": "여러 전문가 모듈 가운데 입력 토큰에 맞는 일부 전문가만 선택해 통과시키는 MoE 라우팅 그림",
        "caption": "MoE는 모든 전문가를 메모리에 올려두되 각 토큰을 계산할 때는 선택된 일부 전문가만 사용합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p12-expert-routing.webp",
        "alt": "색이 다른 토큰들이 라우터를 거쳐 각자 선택된 전문가 두 곳으로 나뉘어 들어가는 그림",
        "caption": "라우터는 토큰마다 관련성이 높은 소수 전문가를 고르며, 선택이 몰리면 특정 전문가가 병목이 될 수 있습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p12-total-active.webp",
        "alt": "저장된 전체 전문가 묶음과 한 토큰 계산에 실제로 활성화되는 일부 전문가를 비교한 그림",
        "caption": "계산량은 활성 파라미터에 가깝지만 메모리 적재에는 전체 가중치가 필요하므로 두 수치를 따로 봐야 합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/context-window-kv-cache",
    "slug": "context-window-kv-cache",
    "title": "LLM 컨텍스트 길이·RoPE·슬라이딩 윈도",
    "description": "모델의 최대 컨텍스트 길이가 무엇을 뜻하며 긴 문맥이 프리필 시간과 KV 캐시, RoPE 확장, 슬라이딩 윈도와 답변 품질에 미치는 영향을 설명합니다.",
    "headline": "최대 토큰 수는 넣을 수 있다는 뜻이지, 끝까지 잘 기억한다는 보장은 아닙니다.",
    "category": "memory",
    "categoryLabel": "메모리와 모델",
    "term": "컨텍스트 윈도",
    "alternateName": "Context Window",
    "plainSummary": "긴 문서를 넣으려고 컨텍스트를 최대값까지 올렸는데 오히려 느려지거나 실행이 안 됩니다. 모델은 큰 문맥을 지원한다는데 왜 그럴까요? 지원하는 길이, 내 장비가 담을 길이, 내용을 제대로 활용할 길이는 같은 숫자가 아닙니다.",
    "buyerNote": "광고된 최대 128K·256K보다 평소 실제로 넣을 문서 길이를 기준으로 장비를 고르세요. 긴 문맥을 드물게 쓴다면 최고 사양을 살 필요가 없습니다.",
    "keyPoints": [
      "컨텍스트는 입력과 이미 생성한 출력 토큰을 함께 셉니다.",
      "길어질수록 프리필 시간과 KV 캐시 부담이 커집니다.",
      "RoPE 확장과 슬라이딩 윈도는 서로 다른 해결 방법입니다."
    ],
    "sections": [
      {
        "title": "문서만 세는 예산이 아닙니다",
        "paragraphs": [
          "시스템 지침, 이전 대화, 검색해서 넣은 문서와 현재 질문이 모두 입력에 들어갑니다. 생성하는 답변에도 공간이 필요합니다. 설정한 문맥을 원문으로 가득 채우면 원하는 길이의 답변을 만들 여유가 부족할 수 있습니다.",
          "토큰은 글자 수와 정확히 같지 않습니다. 한국어 문서의 장수를 그대로 고정 토큰으로 환산하기보다 실제 앱에서 입력 길이를 확인하는 편이 좋습니다. 채팅 화면에 보이지 않는 도구 설명과 템플릿도 포함될 수 있습니다."
        ]
      },
      {
        "title": "큰 숫자를 켜면 준비할 공간도 달라집니다",
        "paragraphs": [
          "긴 입력을 처리하려면 프리필 시간이 들고 계산 상태를 유지할 메모리도 필요합니다. 프로그램에 따라 최대 문맥을 위한 공간을 미리 잡거나 필요할 때 늘릴 수 있습니다. 그래서 입력이 짧아도 설정값 자체가 적재 가능 여부에 영향을 줄 수 있습니다.",
          "먼저 평소 문서와 답변을 넣을 길이로 시작하세요. 정상 실행 뒤 더 긴 문서로 늘리며 피크 메모리와 첫 토큰 시간을 봅니다. 처음부터 최대값을 선택하면 어떤 지점에서 부족해졌는지 찾기도 어렵습니다."
        ]
      },
      {
        "title": "더 길게 넣을 수 있어도 모두 잘 쓰는 것은 아닙니다",
        "paragraphs": [
          "입력 자체가 허용되는 것과 문서 중간의 작은 조건을 정확히 찾는 것은 다릅니다. 알고 있는 숫자나 예외를 앞·중간·뒤에 놓고 확인하면 단순히 대답이 자연스러운지보다 유용한 점검이 됩니다.",
          "RoPE 확장은 위치를 표현하는 범위를 조정하는 방법이지 모델의 이해력을 자동으로 높이는 옵션은 아닙니다. 권장하지 않은 확장 설정은 짧은 질문에도 영향을 줄 수 있습니다. 모델이 안내하는 범위와 실행 프로그램 지원을 먼저 따르세요."
        ]
      },
      {
        "title": "오래된 부분을 버리거나 필요한 부분만 넣습니다",
        "paragraphs": [
          "슬라이딩 윈도는 가까운 문맥을 중심으로 보는 방식입니다. 모델 설계에 포함된 경우와 앱이 임의로 오래된 캐시를 잘라내는 경우는 다릅니다. 캐시를 줄이면 초반의 세부 내용을 나중에 직접 참고하기 어려울 수 있습니다.",
          "문서에서 관련 부분을 검색해 넣는 방법도 있습니다. 입력과 기다림을 줄일 수 있지만 검색 단계에서 필요한 자료를 놓치지 않아야 합니다. 문서 전체를 넣는 방식과 검색해서 넣는 방식은 각각 실패할 지점이 있으므로 결과를 확인해야 합니다."
        ]
      },
      {
        "title": "가장 긴 문서는 얼마나 자주 다루나요?",
        "paragraphs": [
          "일 년에 한 번 쓸 최장 문서를 기준으로 장비 전체를 키울 것인지, 평소 작업을 빠르게 할 것인지 생각해보세요. 드문 작업에서 기다리거나 나눠 처리할 수 있다면 필요한 메모리가 달라질 수 있습니다.",
          "반대로 매일 긴 자료를 연결해 질문한다면 큰 문맥의 여유가 실제 편의가 됩니다. 광고된 최대 숫자가 아니라 내 문서 길이와 필요한 답변을 기준으로 계산하세요. 더 큰 창을 얻는 것보다 그 안에서 중요한 내용을 잃지 않는 것이 먼저입니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/p13-context-budget.webp",
        "alt": "시스템 지시, 대화, 첨부 문서와 출력 여유가 하나의 한정된 문맥 띠를 나눠 쓰는 그림",
        "caption": "문맥 창은 입력과 출력이 함께 쓰는 예산이므로 문서를 많이 넣을수록 답변에 남길 토큰 공간이 줄어듭니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p13-truncation.webp",
        "alt": "고정된 문맥 창을 넘은 오래된 대화가 잘려 나가고 최근 대화와 요약만 남는 그림",
        "caption": "최대 문맥을 넘으면 오래된 토큰을 버리거나 요약해야 하므로 표시된 최대 길이가 항상 유효 기억 길이는 아닙니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p13-memory-growth.webp",
        "alt": "입력이 길어질수록 더 큰 KV 캐시 서랍이 필요하고 첫 출력까지 시간이 늘어나는 단계 그림",
        "caption": "긴 문맥은 모델 가중치 크기를 바꾸지 않지만 KV 캐시와 프리필 계산량을 함께 늘립니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/gguf-vs-mlx",
    "slug": "gguf-vs-mlx",
    "title": "GGUF와 MLX 모델 형식, 무엇이 다른가",
    "description": "로컬 LLM에서 GGUF와 MLX용 모델 파일이 어떤 런타임 생태계에 맞는지, 양자화 표기와 변환 호환성을 어떻게 확인해야 하는지 설명합니다.",
    "headline": "형식은 파일 확장자보다 어떤 런타임과 커널로 실행할지를 정하는 선택입니다.",
    "category": "runtime",
    "categoryLabel": "실행 프로그램과 확장",
    "term": "GGUF",
    "alternateName": "GGUF model format",
    "plainSummary": "모델 이름은 같은데 한쪽은 GGUF 파일, 다른 쪽은 MLX 폴더입니다. 더 작은 것을 받으면 될까요? 다운로드를 다시 하는 시간을 줄이려면 파일보다 먼저 실행할 앱을 정해야 합니다. 두 배포 방식은 같은 원본을 다른 실행 환경에서 쓰기 위한 선택입니다.",
    "buyerNote": "윈도우·리눅스와 NVIDIA GPU라면 GGUF 지원 여부를, 맥이라면 MLX와 GGUF 중 실제 사용할 앱이 무엇을 지원하는지 먼저 확인하세요.",
    "keyPoints": [
      "GGUF는 GGML·llama.cpp 계열의 모델 배포 형식입니다.",
      "MLX 모델은 Apple Silicon용 MLX 실행 생태계에 맞춰집니다.",
      "파일 형식과 양자화 정밀도는 같은 개념이 아닙니다."
    ],
    "sections": [
      {
        "title": "모델 이름만 맞으면 열리는 것은 아닙니다",
        "paragraphs": [
          "프로그램은 가중치뿐 아니라 모델 구조와 토큰화 방식도 이해해야 합니다. GGUF는 llama.cpp 계열에서 널리 쓰는 배포 형식입니다. 가중치와 메타데이터 등을 담지만 새 구조를 모두 자동 지원하는 만능 파일은 아닙니다.",
          "MLX용 배포본은 Apple Silicon의 MLX 실행 환경에 맞춘 모델과 설정 파일을 사용합니다. 엄밀히 말하면 GGUF라는 컨테이너와 MLX라는 실행 생태계를 비교하는 것입니다. 파일 확장자를 바꾸는 것만으로 서로 바뀌지 않습니다."
        ]
      },
      {
        "title": "먼저 현재 앱이 어떤 경로를 쓰는지 봅니다",
        "paragraphs": [
          "윈도우·리눅스에서 llama.cpp 계열 앱을 쓸 계획이라면 지원되는 GGUF를 찾는 것이 자연스럽습니다. 맥에서 MLX 기반 앱을 쓴다면 그 앱이 권장하는 MLX 배포본부터 확인합니다. 맥에서도 GGUF 경로를 사용할 수 있으므로 운영체제 하나로 무조건 결정되지는 않습니다.",
          "같은 화면의 앱이 두 경로를 모두 제공해도 실제 엔진과 지원 옵션은 다를 수 있습니다. 파일 크기만 보지 말고 사용할 기능과 런타임 버전을 확인하세요. 아직 모델을 받지 않았다면 이 확인으로 큰 파일을 다시 내려받는 일을 줄일 수 있습니다."
        ]
      },
      {
        "title": "Q4라는 표시도 형식과는 별개입니다",
        "paragraphs": [
          "GGUF 안에는 여러 정밀도가 들어갈 수 있고 MLX 배포본에도 다양한 양자화가 있습니다. 같은 4비트라고 같은 방식으로 숫자를 줄였다는 뜻은 아닙니다. 파일 크기와 품질·실행 속도도 완전히 같다고 볼 수 없습니다.",
          "두 경로를 비교할 때는 같은 원본 모델과 비슷한 정밀도, 같은 입력 길이를 맞추세요. 서로 다른 채팅 템플릿이 결과를 바꿀 수도 있습니다. 모델 이름과 tok/s 두 값만 남기면 나중에 차이의 이유를 찾기 어렵습니다."
        ]
      },
      {
        "title": "텍스트는 되는데 이미지나 MTP가 안 된다면",
        "paragraphs": [
          "변환본에 추가 가중치가 빠졌거나 실행 프로그램이 해당 기능을 아직 처리하지 못할 수 있습니다. 일반 답변이 된다는 것은 그 경로 하나를 확인한 것입니다. 비전 입력, 도구 호출과 MTP는 따로 지원 범위를 봐야 합니다.",
          "분할 파일이라면 필요한 조각을 모두 받아야 하고 별도 인코더가 요구될 수도 있습니다. 처음에는 텍스트 질문으로 정상 작동을 확인한 뒤 기능을 추가하세요. 문제를 해결하려고 정상 파일을 모두 지우고 시작할 필요는 없습니다."
        ]
      },
      {
        "title": "오래 쓸 파일을 고르는 방법",
        "paragraphs": [
          "두 형식 중 하나가 언제나 우월하다는 결론보다 현재 앱에서 안정적으로 열리고 필요한 기능을 쓰는지가 중요합니다. 그 조건을 만족한 뒤 평소 질문의 결과와 첫 토큰·디코드·메모리를 비교합니다.",
          "좋은 설정을 찾았다면 파일 버전과 앱 버전을 기록해두세요. 업데이트 뒤에도 돌아갈 기준이 생깁니다. 모델을 다운로드하는 시간이 아니라 실제로 문서를 정리하고 코드를 고치는 시간이 늘어나는 선택이면 충분합니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/p14-gguf-mlx-runtime.webp",
        "alt": "같은 원본 모델이 GGUF와 MLX 형식으로 변환되어 서로 다른 실행 경로를 통과하는 그림",
        "caption": "파일 형식은 단순 확장자가 아니라 양자화 방식과 런타임 기능, 사용할 수 있는 최적화 경로를 함께 결정합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p14-portability-paths.webp",
        "alt": "휴대성 높은 모델 파일이 여러 CPU·GPU 어댑터로 퍼지고 전용 형식은 통합 메모리 칩으로 바로 이어지는 그림",
        "caption": "GGUF는 다양한 장비에서 열기 쉽고 MLX는 Apple Silicon의 전용 경로를 활용하기 좋다는 차이가 있습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p14-feature-support.webp",
        "alt": "같은 모델 파일을 여는 두 런타임이 양자화, 캐시와 MTP 기능을 서로 다르게 지원하는 그림",
        "caption": "가중치가 파일에 있어도 런타임이 새 아키텍처와 특수 헤드를 이해하지 못하면 해당 기능을 사용할 수 없습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/multi-gpu-tensor-parallel",
    "slug": "multi-gpu-tensor-parallel",
    "title": "멀티 GPU·듀얼 GPU로 로컬 LLM 돌리기",
    "description": "GPU 두 장의 VRAM을 로컬 LLM에 활용하는 레이어 분할, 텐서 병렬과 파이프라인 병렬의 차이, PCIe·NVLink 통신 병목을 설명합니다.",
    "headline": "VRAM은 더할 수 있어도 속도는 카드 수만큼 자동으로 늘지 않습니다.",
    "category": "runtime",
    "categoryLabel": "실행 프로그램과 확장",
    "term": "텐서 병렬",
    "alternateName": "Tensor Parallelism",
    "plainSummary": "24GB GPU 두 장이면 48GB GPU 한 장을 대신할 수 있을까요? 메모리의 합은 같아 보여도 계산이 지나가는 길은 다릅니다. 중고 카드 한 장을 더 사기 전에, 내가 쓰려는 프로그램이 두 장에 일을 어떻게 나누는지부터 확인해보겠습니다.",
    "buyerNote": "큰 모델을 꼭 올려야 할 때는 도움이 되지만 설치·전력·발열이 늘어납니다. 관리 편의성을 우선하면 가능한 한 GPU 한 장에 모델이 들어가는 구성이 낫습니다.",
    "keyPoints": [
      "런타임이 모델과 캐시를 여러 GPU로 분할해야 합니다.",
      "텐서 병렬은 매 레이어에서 GPU 간 통신이 필요합니다.",
      "두 장 구성은 적재 용량 확대와 속도 향상을 따로 평가해야 합니다."
    ],
    "sections": [
      {
        "title": "두 카드가 보인다는 것과 함께 쓴다는 것",
        "paragraphs": [
          "운영체제가 GPU 두 장을 인식해도 앱이 한 장만 사용하면 나머지 메모리는 그 모델에 도움이 되지 않습니다. 실행 프로그램이 가중치와 캐시를 분할해야 합니다. 각 카드에는 자기 작업 공간도 남겨야 하므로 합계 전체를 모델 파일로 채울 수는 없습니다.",
          "따라서 카드부터 사고 설정법을 찾기보다 원하는 모델·형식의 다중 GPU 지원을 먼저 확인하세요. 같은 앱에서도 모델 구조에 따라 분할 경로가 다를 수 있습니다. 이미 확인된 실행 예시가 구매 후보를 좁히는 데 중요합니다."
        ]
      },
      {
        "title": "앞쪽 계산과 뒤쪽 계산을 나눕니다",
        "paragraphs": [
          "모델의 앞부분을 한 카드에, 뒷부분을 다른 카드에 담는 레이어 분할을 생각해볼 수 있습니다. 한 토큰의 계산이 카드들을 차례로 거치므로 중간 결과를 넘겨야 합니다. 두 카드가 항상 동시에 바쁘게 일하는 것은 아닙니다.",
          "여러 요청이 있으면 단계 사이의 빈 시간을 활용할 여지가 있지만 혼자 한 답변을 받을 때는 효과가 다를 수 있습니다. 이 방식의 용량 이점과 단일 요청 속도 이점을 나누어 보는 이유입니다."
        ]
      },
      {
        "title": "한 층의 계산을 함께 나눌 수도 있습니다",
        "paragraphs": [
          "텐서 병렬은 한 층에서 하는 계산을 여러 GPU가 나눠 맡고 결과를 교환합니다. 계산을 병렬로 줄일 수 있는 대신 통신이 반복됩니다. 연결이 느리면 계산을 나눈 이점이 전송 시간에 가려질 수 있습니다.",
          "PCIe 세대와 실제 레인 수, GPU 사이 연결 구조를 확인하세요. NVLink 지원 여부도 카드와 구성에 따라 다릅니다. 두 장의 이론 대역폭을 더해 토큰 속도도 두 배라고 계산하는 방식으로는 이 차이가 보이지 않습니다."
        ]
      },
      {
        "title": "같은 모델을 두 번 올리는 것은 다른 선택입니다",
        "paragraphs": [
          "모델이 한 장에 들어간다면 각 GPU에 하나씩 올리고 요청을 나눌 수도 있습니다. 이 경우 여러 사용자를 받는 데 도움이 될 수 있지만, 한 요청이 사용할 수 있는 메모리가 합쳐지거나 한 답변이 두 배 빨라지는 것은 아닙니다.",
          "개인용 대형 모델 하나가 목적인지, 여러 앱의 요청을 동시에 처리하려는지 정해야 합니다. 같은 카드 두 장을 사도 분할과 복제 중 어느 구성을 쓰느냐에 따라 두 번째 카드가 하는 일이 달라집니다."
        ]
      },
      {
        "title": "가격표에 빠진 본체 조건까지 봅니다",
        "paragraphs": [
          "슬롯이 두 개 있어도 카드 두께 때문에 함께 장착하지 못할 수 있습니다. 전원공급장치, 케이블, 냉각과 케이스 공간도 확인해야 합니다. 장시간 동작할 공간의 소음과 전력 역시 카드 가격 밖에 있는 비용입니다.",
          "큰 모델을 꼭 실행해야 한다면 이런 복잡성을 감수할 이유가 있습니다. 한 사람이 이미 들어가는 모델을 조금 더 빠르게 쓰려는 경우라면 단일 카드 대안과 전체 비용을 비교하세요. 메모리의 합을 확보하는 것과 매일 다루기 편한 컴퓨터를 만드는 것은 별개의 확인입니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/multi-gpu-batching.webp",
        "alt": "단일 GPU와 서로 통신하는 듀얼 GPU에서 여러 길이의 요청을 캐시 블록에 배치하는 비교 그림",
        "caption": "GPU를 늘리면 메모리와 처리량을 키울 수 있지만 장비 사이 통신과 요청 배치 방식이 새 변수로 생깁니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p15-sharding-model.webp",
        "alt": "하나의 큰 모델을 두 GPU 메모리에 나누어 담고 부분 계산 결과를 합치는 그림",
        "caption": "런타임이 레이어나 텐서를 명시적으로 분할해야 두 GPU의 메모리를 한 모델에 활용할 수 있습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p15-interconnect-bottleneck.webp",
        "alt": "두 GPU가 좁은 다리와 넓은 다리로 중간 계산 결과를 주고받는 속도 차이 그림",
        "caption": "각 GPU가 빨라도 PCIe나 인터커넥트가 느리면 결과 교환이 병목이 되어 카드 수만큼 속도가 늘지 않습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/flashattention-pagedattention",
    "slug": "flashattention-pagedattention",
    "title": "FlashAttention과 PagedAttention 차이",
    "description": "이름이 비슷하지만 다른 문제를 푸는 FlashAttention과 PagedAttention이 어텐션 계산, KV 캐시 메모리 관리와 서버 처리량에 미치는 영향을 설명합니다.",
    "headline": "하나는 어텐션 계산을 효율화하고, 다른 하나는 KV 캐시를 페이지처럼 관리합니다.",
    "category": "runtime",
    "categoryLabel": "실행 프로그램과 확장",
    "term": "PagedAttention",
    "alternateName": "Paged KV Cache Attention",
    "plainSummary": "설정 목록에 FlashAttention과 PagedAttention이 보입니다. 둘 다 빠르게 해준다면 하나만 켜도 될까요? 이름이 비슷하지만 하나는 계산 중 데이터 이동을, 다른 하나는 대화용 메모리 배치를 다룹니다. 어느 문제를 해결하는지 알면 옵션을 훨씬 덜 헷갈리게 볼 수 있습니다.",
    "buyerNote": "개인용 장비 구매에서는 지원 여부만 확인하면 충분합니다. 두 기술의 이름이 있다고 해서 짧은 채팅 속도가 크게 빨라진다고 보기는 어렵습니다.",
    "keyPoints": [
      "FlashAttention은 어텐션 커널의 메모리 이동을 줄입니다.",
      "PagedAttention은 KV 캐시를 고정 블록으로 나눠 관리합니다.",
      "둘은 대체 관계가 아니며 동시에 쓰일 수 있습니다."
    ],
    "sections": [
      {
        "title": "긴 입력에서 중간 데이터를 옮기는 비용",
        "paragraphs": [
          "어텐션은 입력의 각 부분이 다른 부분을 참고하도록 계산합니다. 긴 문맥에서는 중간 결과를 메모리에 쓰고 다시 읽는 비용도 커질 수 있습니다. FlashAttention은 계산을 묶고 순서를 조직해 이런 메모리 이동을 줄이는 방식입니다.",
          "중요한 문장을 골라 나머지를 버리는 SpecPrefill과는 다릅니다. 같은 어텐션 계산을 더 효율적으로 수행하려는 경로입니다. 따라서 이름에 빠르다는 의미가 있다는 이유만으로 입력 선별이나 양자화와 같은 기능이라고 보면 안 됩니다."
        ]
      },
      {
        "title": "여러 대화의 빈 공간을 줄이는 문제",
        "paragraphs": [
          "서버에는 길이가 서로 다른 요청이 들어옵니다. 대화마다 큰 연속 공간을 미리 확보하면 쓰지 않는 공간이나 배치하기 어려운 틈이 생길 수 있습니다. PagedAttention은 KV 캐시를 블록으로 나눠 필요한 만큼 관리하는 방식입니다.",
          "운영체제의 페이지 관리와 비슷한 아이디어지만 GPU 메모리가 자동으로 무한해지거나 SSD를 VRAM처럼 쓰게 되는 것은 아닙니다. 남은 공간을 더 효율적으로 활용하는 것이지 모델 가중치 자체를 줄이는 기능은 아닙니다."
        ]
      },
      {
        "title": "하나가 다른 하나를 대신하지 않습니다",
        "paragraphs": [
          "계산 커널과 캐시 관리가 푸는 문제가 다르므로 한 런타임에서 함께 활용될 수 있습니다. 프리필에 어떤 커널을 쓰고 생성 중 캐시를 어떻게 관리하는지는 별도로 볼 항목입니다. 둘 중 승자를 고르는 비교는 목적에 맞지 않습니다.",
          "지원 여부는 GPU와 모델 구조·양자화·앱 버전에 따라 달라집니다. 자동 선택되는 경로가 있을 수 있으므로 강제 옵션을 넣기 전에 현재 로그를 확인하세요. 이름이 메뉴에 있다는 사실보다 실제 선택된 실행 경로가 중요합니다."
        ]
      },
      {
        "title": "혼자 짧게 물을 때와 서버에서 다릅니다",
        "paragraphs": [
          "짧은 대화 하나에서는 페이지 관리로 아낄 공간이 크지 않을 수 있습니다. 여러 요청과 긴 문맥에서는 같은 메모리에 더 많은 상태를 담는 가치가 커집니다. 서버의 총 처리량 향상을 개인 채팅의 속도 배율로 옮길 수는 없습니다.",
          "FlashAttention 역시 장문 프리필과 짧은 디코드에서 같은 효과를 보장하지 않습니다. 첫 토큰 시간, 피크 메모리와 동시 요청별 처리량을 나누어 재야 어느 부분이 좋아졌는지 알 수 있습니다."
        ]
      },
      {
        "title": "옵션을 더 넣기 전에 결과 하나를 남깁니다",
        "paragraphs": [
          "정상 실행되는 기본 설정으로 평소 입력의 결과를 저장하세요. 그다음 지원되는 경로를 바꿔 속도와 메모리가 개선되는지 확인합니다. 실행 실패나 이상한 출력이 생긴다면 다시 기준으로 돌아갈 수 있어야 합니다.",
          "장비를 살 때도 기능 이름의 개수보다 원하는 모델에서 확인된 결과를 봅니다. 새로운 용어를 모두 외우는 것이 목적은 아닙니다. 긴 문서에서 기다리는지, 여러 대화의 메모리가 부족한지 말할 수 있다면 필요한 설정을 찾는 출발점은 충분합니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/p16-flash-tiled-attention.webp",
        "alt": "큰 어텐션 행렬을 작은 타일로 나눠 계산 장치 가까이에서 반복 처리하는 그림",
        "caption": "FlashAttention은 전체 중간 행렬을 멀리 저장하지 않고 작은 타일 단위로 계산해 메모리 이동을 줄입니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p16-paged-cache.webp",
        "alt": "길이가 다른 여러 요청을 고정 크기 KV 캐시 페이지에 빈틈 적게 나눠 담는 그림",
        "caption": "PagedAttention 계열 관리는 요청마다 큰 연속 공간을 잡지 않고 필요한 페이지를 배정해 메모리 낭비를 줄입니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p16-memory-io.webp",
        "alt": "어텐션 계산이 메모리까지 여러 번 왕복하는 경로와 타일 처리로 왕복을 줄인 경로를 비교한 그림",
        "caption": "핵심은 계산 횟수만이 아니라 느린 메모리로 중간 데이터를 쓰고 다시 읽는 횟수를 줄이는 데 있습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/continuous-batching",
    "slug": "continuous-batching",
    "title": "Continuous Batching과 단일 사용자 속도",
    "description": "연속 배칭이 길이가 다른 LLM 요청을 실행 중인 배치에 넣고 빼며 서버 처리량을 높이는 방식과 단일 사용자 지연과의 차이를 설명합니다.",
    "headline": "여러 요청을 계속 묶어 GPU를 채우는 기술이지, 한 사람의 답을 항상 더 빠르게 만드는 기능은 아닙니다.",
    "category": "runtime",
    "categoryLabel": "실행 프로그램과 확장",
    "term": "연속 배칭",
    "alternateName": "Continuous Batching",
    "plainSummary": "서버가 초당 수백 토큰을 만든다는데 내 답변은 그보다 훨씬 천천히 나옵니다. 거짓 기록일까요? 여러 사람의 토큰을 합친 처리량일 수 있습니다. 연속 배칭을 이해하려면 서버 전체가 한 일과 한 사람이 기다린 시간을 나누어 봐야 합니다.",
    "buyerNote": "혼자 쓰는 로컬 LLM이라면 핵심 구매 기준이 아닙니다. 가족·팀이 함께 쓰거나 여러 앱을 한 서버에 연결할 때 중요합니다.",
    "keyPoints": [
      "완료된 요청 자리에 새 요청을 즉시 넣습니다.",
      "총 처리량과 개별 요청 지연은 다른 지표입니다.",
      "MTP와 추측 디코딩 지원은 단일·배치 경로가 다를 수 있습니다."
    ],
    "sections": [
      {
        "title": "먼저 끝난 요청의 자리를 활용합니다",
        "paragraphs": [
          "짧은 답변과 긴 답변을 한 묶음으로 처리하면 짧은 쪽이 먼저 끝납니다. 고정된 묶음에서는 남은 요청을 기다리는 동안 자원을 충분히 쓰지 못할 수 있습니다. Continuous Batching은 완료된 요청을 빼고 대기 중인 요청을 넣어 실행을 이어갑니다.",
          "새로운 요청이 계속 들어오는 서버에서 GPU의 빈 시간을 줄이는 것이 목적입니다. 혼자 질문 하나를 보냈을 때 무조건 빨라지도록 만드는 스위치는 아닙니다. 동시에 진행할 일이 있는 환경에서 먼저 생각해볼 기능입니다."
        ]
      },
      {
        "title": "전체 100토큰과 내 100토큰은 다릅니다",
        "paragraphs": [
          "가상 예로 열 요청이 각각 초당 10토큰씩 받으면 합계는 초당 100토큰입니다. 한 사람이 초당 100토큰으로 답을 받는 상황과 같지 않습니다. 실제 서버는 요청마다 속도가 다를 수 있지만 두 지표를 구분하는 원리는 같습니다.",
          "많은 일을 완료하는 배치 서버라면 총 처리량이 중요합니다. 사람과 대화하는 도구라면 첫 토큰까지의 시간과 토큰 사이 간격도 중요합니다. 총 tok/s가 올라도 채팅이 답답해졌다면 목적에 맞는 개선인지 다시 봐야 합니다."
        ]
      },
      {
        "title": "공유하는 모델과 따로 필요한 캐시",
        "paragraphs": [
          "여러 요청이 하나의 모델 가중치를 사용해도 대화마다 KV 상태가 필요합니다. 긴 입력이 많은 요청을 동시에 받으면 메모리가 빠르게 소진될 수 있습니다. 최대 요청 수와 문맥 길이를 각각 최대로 설정하는 것이 좋은 출발점은 아닙니다.",
          "페이지형 캐시 관리와 공통 접두사 재사용은 여유를 활용하는 데 도움이 될 수 있습니다. 하지만 없는 메모리를 만들어주지는 않습니다. 피크 사용량과 대기열을 보며 실제 요청에 맞게 제한을 조정해야 합니다."
        ]
      },
      {
        "title": "한 사람의 최적 설정을 그대로 복사하면",
        "paragraphs": [
          "MTP나 초안 모델은 후보를 만들고 검증하며 캐시를 갱신합니다. 단일 요청에서 잘 되던 구현이 서로 다른 길이의 여러 요청에서도 같은 경로를 지원하는지 확인해야 합니다. 설정창에는 켜져 있어도 배치에서는 다른 경로로 실행될 수 있습니다.",
          "채팅과 백그라운드 문서 처리를 한 서버에 같이 올린다면 두 작업이 경쟁하는 상황도 시험하세요. 혼자 측정한 최고 속도만으로는 가족이나 동료가 함께 쓸 때의 경험을 설명할 수 없습니다."
        ]
      },
      {
        "title": "사용자가 가장 오래 기다린 순간을 봅니다",
        "paragraphs": [
          "서버 평가에는 평균뿐 아니라 지연이 큰 요청도 남겨야 합니다. 대부분 빨라도 가끔 한참 멈추는 도구는 대화에 쓰기 불편할 수 있습니다. 입력 길이와 출력 길이, 동시 요청 수를 기록해야 그 순간을 재현할 수 있습니다.",
          "혼자 쓰는 로컬 AI라면 작은 동시 요청 수에서 시작해도 됩니다. 여러 에이전트가 실제로 함께 일할 때 제한을 늘리고 결과를 보세요. GPU를 최대한 바쁘게 만드는 것보다 사용자가 필요한 답을 제때 받는 것이 서버의 역할입니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/p17-arrival-scheduler.webp",
        "alt": "서로 다른 시각에 도착한 요청을 스케줄러가 실행 중인 배치의 빈칸에 계속 넣는 그림",
        "caption": "연속 배칭은 모든 요청이 모일 때까지 기다리지 않고 실행 중 비는 슬롯에 새 요청을 곧바로 채웁니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p17-throughput-latency.webp",
        "alt": "많은 요청을 효율적으로 처리하는 혼잡한 처리량 경로와 한 요청이 바로 가는 지연 우선 경로의 비교 그림",
        "caption": "전체 tok/s가 높아져도 개별 요청은 차례를 나누므로 첫 토큰과 다음 토큰 사이의 대기 시간이 늘 수 있습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p17-batch-slots.webp",
        "alt": "완료된 시퀀스가 실행 슬롯에서 빠지고 대기 중인 새 요청이 즉시 그 자리를 채우는 그림",
        "caption": "길이가 다른 요청의 완료 시점을 따라 슬롯을 재사용하면 고정 배치에서 생기는 빈 계산 자원을 줄일 수 있습니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/local-image-generation-guide",
    "slug": "local-image-generation-guide",
    "title": "로컬 이미지 생성 가이드: 내 PC로 할 수 있는 작업",
    "description": "로컬 이미지 생성으로 시안, 제품 이미지, 포스터와 참고 이미지 편집을 하는 방법과 해상도·장수·메모리에 따른 장비 선택 기준을 설명합니다.",
    "headline": "한 장을 오래 기다리기보다 시안을 빠르게 좁히고 마지막 결과에 자원을 쓰는 편이 좋습니다.",
    "category": "generation",
    "categoryLabel": "이미지·영상 생성",
    "plainSummary": "머릿속에는 원하는 이미지가 있는데 한 문장으로 설명하기는 어렵습니다. 한 장을 만들어 보고 조명을 바꾸고 구도를 다시 고르다 보면 조금씩 가까워집니다. 로컬 이미지 생성용 장비를 고를 때는 완성작 한 장보다 이 수정 과정을 얼마나 편하게 반복할 수 있는지가 중요합니다.",
    "buyerNote": "가끔 한 장만 만든다면 최고 사양부터 볼 필요가 없습니다. 여러 시안을 계속 뽑거나 큰 이미지를 편집한다면 VRAM 여유와 생성 시간을 함께 확인하세요.",
    "keyPoints": [
      "텍스트 생성보다 해상도와 생성 장수가 메모리 사용량을 크게 바꿉니다.",
      "낮은 해상도 시안과 고해상도 최종 출력을 나누면 기다림을 줄일 수 있습니다.",
      "제품 사진과 공개 전 디자인을 장비 안에서 처리할 수 있습니다."
    ],
    "sections": [
      {
        "title": "처음부터 완성작이 나와야 하는 것은 아닙니다",
        "paragraphs": [
          "가령 작은 제품의 소개 이미지를 만든다고 해봅시다. 배경을 밝게 할지 어둡게 할지, 제품을 가운데 둘지 한쪽에 둘지 아직 정하지 못했습니다. 이 단계에서는 큰 최종 이미지보다 방향을 비교할 여러 시안이 먼저 필요합니다.",
          "한 장이 마음에 들지 않으면 무엇이 다른지 적고 프롬프트나 참고 이미지를 바꿉니다. 모델·시드·설정을 저장해두면 바꾼 요소를 비교하기 쉽습니다. 다만 실행 환경이나 설정이 달라지면 같은 시드도 완전히 같은 결과를 보장하지는 않습니다."
        ]
      },
      {
        "title": "작게 확인하고 필요한 부분에 시간을 씁니다",
        "paragraphs": [
          "지원되는 작은 해상도로 구도를 시험한 뒤 마음에 드는 결과를 크게 다듬을 수 있습니다. 틀린 방향의 시안을 높은 해상도로 계속 계산하는 시간을 줄이려는 순서입니다. 모든 모델이 모든 해상도에서 같은 구도를 유지하는 것은 아니므로 최종 결과는 다시 확인해야 합니다.",
          "손이나 제품의 일부만 잘못됐다면 부분 수정이 가능한 경로를 검토합니다. 이미지를 입력해 형태를 유지하거나 특정 영역을 다시 만드는 기능이 지원되는지 봅니다. 모델을 바꾸는 것보다 지금 결과를 고치는 편이 나을 때도 있습니다."
        ]
      },
      {
        "title": "모델 하나만 받으면 끝날까요?",
        "paragraphs": [
          "생성 모델 외에 프롬프트를 처리하는 텍스트 인코더와 잠재 표현을 이미지로 바꾸는 VAE 등이 필요할 수 있습니다. 배포에 따라 함께 들어 있거나 따로 받아야 합니다. 모델 본체 파일 크기만으로 디스크와 VRAM 요구량을 계산하면 빠지는 항목이 생깁니다.",
          "실행 앱이 모델 구조와 양자화를 지원하는지 확인하고, 먼저 짧은 기본 워크플로로 한 장을 완성해보세요. 처음부터 여러 확장 기능을 붙이면 실패했을 때 어디서 문제가 생겼는지 알기 어렵습니다."
        ]
      },
      {
        "title": "한 장은 되는데 네 장은 안 되는 이유",
        "paragraphs": [
          "이미지 크기와 동시에 만드는 장수가 늘면 중간 작업 공간도 달라집니다. 네 장을 한꺼번에 만드는 배치가 부족하다면 한 장씩 순서대로 생성하는 방법부터 시험할 수 있습니다. 처리량과 필요한 순간 메모리를 나누어 봐야 합니다.",
          "이미 가진 장비에서 작은 시안을 반복하는 것이 충분하다면 바로 업그레이드할 필요는 없습니다. 반대로 매일 여러 후보를 비교하는데 기다림 때문에 시도를 줄이게 된다면 더 빠른 생성 시간이 실제 가치를 가질 수 있습니다."
        ]
      },
      {
        "title": "제품 사진이라면 마지막 검토가 남습니다",
        "paragraphs": [
          "생성된 조명과 배경이 좋아도 제품의 버튼·로고·비율이 달라지면 실제 제품을 설명하는 이미지로 곧바로 쓸 수 없습니다. 글자가 있다면 철자와 숫자를 따로 확인하고, 필요한 부분은 편집 도구에서 정확하게 넣는 방법도 있습니다.",
          "원본을 내 장비에서 처리하도록 구성할 수 있지만 모든 앱이 자동으로 외부 연결을 하지 않는 것은 아닙니다. 다운로드·공유·확장 기능의 연결을 확인하세요. 공개 전 자료라면 파일 저장 위치와 접근 가능한 사람도 함께 봐야 합니다."
        ]
      },
      {
        "title": "비교 화면에서는 기다림을 먼저 경험해보세요",
        "paragraphs": [
          "사이트의 이미지 체험은 등록된 샘플을 예상 시간에 맞춰 보여줍니다. 브라우저가 선택한 장비로 새 이미지를 실제 생성한 결과는 아닙니다. 장비 후보끼리 같은 모델·크기의 대기를 비교하는 용도로 사용하세요.",
          "장비를 산 뒤에는 만들고 싶은 이미지 하나를 끝까지 다듬어보세요. 몇 번의 수정이 필요하고 어느 단계가 가장 오래 걸리는지 알게 됩니다. 그 경험이 쌓이면 다음 장비를 고를 때도 ‘가장 빠른 GPU’ 대신 내가 자주 멈추는 작업을 줄일 구성을 찾을 수 있습니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/local-image-jobs.webp",
        "alt": "한 대의 로컬 워크스테이션에서 썸네일, 제품 이미지, 포스터와 참고 이미지 변형 결과가 만들어지는 작업실 그림",
        "caption": "로컬 이미지 생성은 한 가지 그림만 만드는 도구가 아니라 시안, 제품 컷, 포스터와 이미지 변형을 같은 장비에서 반복하는 작업입니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/local-image-resolution-batch.webp",
        "alt": "큰 이미지 한 장과 작은 시안 여러 장을 접촉 인화지처럼 나란히 놓아 해상도와 생성 장수 차이를 보여 주는 그림",
        "caption": "해상도와 한 번에 만드는 장수를 높이면 필요한 시간과 작업 메모리가 함께 늘어나므로 시안과 최종 출력을 나눠 만드는 편이 효율적입니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/local-image-offline-workspace.webp",
        "alt": "네트워크 선을 분리한 작업실에서 참고 이미지가 로컬 컴퓨터를 거쳐 보관함에 저장되는 과정 그림",
        "caption": "참고 파일과 결과물을 장비 안에서 처리할 수 있다는 점은 민감한 제품 이미지나 공개 전 디자인을 다룰 때 로컬 생성의 실용적인 장점입니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/flux-qwen-local-image-models",
    "slug": "flux-qwen-local-image-models",
    "title": "FLUX·Qwen 이미지 모델, 로컬 작업별 선택법",
    "description": "FLUX.2 Klein·Dev와 Qwen-Image-2512를 빠른 시안, 글자 표현, 참고 이미지 편집과 정밀 결과 기준으로 구분해 설명합니다.",
    "headline": "가장 좋은 모델 하나보다 자주 하는 작업에 맞는 도구 두세 개가 더 쓸모 있습니다.",
    "category": "generation",
    "categoryLabel": "이미지·영상 생성",
    "plainSummary": "FLUX와 Qwen의 예시 이미지는 모두 좋아 보입니다. 그런데 내 제품 사진이나 포스터에서도 같은 결과를 얻을 수 있을까요? 모델을 고를 때는 남이 고른 완성작보다 내가 자주 실패하는 장면을 나란히 만들어보는 편이 도움이 됩니다.",
    "buyerNote": "모델 크기가 커질수록 결과가 항상 비례해 좋아지지는 않습니다. 작은 모델로 시안을 만들고 필요한 작업만 큰 모델로 마무리할 수 있는 구성이 실용적입니다.",
    "keyPoints": [
      "FLUX.2 Klein은 빠른 시안과 가벼운 편집에 어울립니다.",
      "Qwen-Image-2512는 글자와 사실적인 장면을 함께 다룰 때 살펴볼 만합니다.",
      "FLUX.2 Dev 같은 큰 모델은 메모리와 실행 경로를 먼저 확인해야 합니다."
    ],
    "sections": [
      {
        "title": "어떤 결과를 만들어야 하는지 먼저 정합니다",
        "paragraphs": [
          "제품의 형태를 유지하며 배경을 바꾸는 일과 글자가 있는 포스터를 처음 만드는 일은 다릅니다. 참고 이미지 입력이나 부분 수정이 필요한지부터 정하면 실행 경로를 좁힐 수 있습니다. 같은 계열 이름 안에서도 배포본과 지원 작업은 다를 수 있습니다.",
          "사이트에 있는 FLUX.2 Klein·Dev와 Qwen-Image 계열은 비교의 출발점입니다. 더 큰 이름을 최종 정답으로 두지 말고, 필요한 작업이 가능한 파일과 워크플로를 먼저 확인하세요. 현재 앱이 지원하는지도 함께 봐야 합니다."
        ]
      },
      {
        "title": "포스터라면 분위기보다 철자를 먼저 봅니다",
        "paragraphs": [
          "색과 구도가 잘 나와도 행사 날짜나 제품명이 틀리면 사용할 수 없습니다. 요청한 문구가 정확한지, 작은 글자가 읽히는지 실제 크기로 확인합니다. 글자 표현의 평판이 좋은 모델이어도 특정 문구의 성공을 보장하지는 않습니다.",
          "중요한 문장은 배경만 생성한 뒤 편집 도구로 직접 넣을 수 있습니다. 한 번에 전부 생성하려고 수십 번 다시 시도하는 것과 어느 쪽이 빠른지 비교해보세요. 모델이 모든 단계를 맡아야 한다는 조건은 없습니다."
        ]
      },
      {
        "title": "참고 사진을 넣었다면 남아야 할 것을 정합니다",
        "paragraphs": [
          "제품의 로고와 버튼 위치, 사람의 얼굴처럼 바뀌면 안 되는 요소를 먼저 정합니다. 원래 사진을 많이 닮았다는 느낌만으로는 작은 왜곡을 놓칠 수 있습니다. 조명을 바꿀 때 형태까지 달라지는지 나란히 확인하세요.",
          "이미지 입력을 추가하면 필요한 인코더나 중간 메모리도 달라질 수 있습니다. 텍스트만으로 만든 한 장의 속도를 참고 이미지 여러 장을 넣는 편집 시간으로 사용하면 맞지 않을 수 있습니다. 비교할 작업 조건부터 같게 맞춥니다."
        ]
      },
      {
        "title": "작은 모델과 큰 모델에 역할을 나눌 수 있습니다",
        "paragraphs": [
          "빠르게 방향을 찾는 데는 작은 모델이 편할 수 있고, 특정 장면을 다듬는 데는 다른 모델이 더 나은 결과를 줄 수 있습니다. 다만 모델을 바꾸면 시안의 구도가 그대로 유지되지 않을 수 있습니다. 이미지 조건부 생성과 확대 기능의 지원을 확인하세요.",
          "처음부터 두세 모델을 모두 상주시킬 필요도 없습니다. 순서대로 불러 쓰는 시간과 메모리를 비교해보세요. 자주 바꾸지 않는다면 적재 대기는 감수할 수 있지만, 하루 종일 전환한다면 그 시간이 작업 흐름에 영향을 줍니다."
        ]
      },
      {
        "title": "성공한 한 장만 비교하지 않습니다",
        "paragraphs": [
          "같은 장면을 몇 번 만들어 실제로 쓸 수 있는 결과가 얼마나 나오는지 확인해보세요. 한 장은 빨리 나오지만 계속 수정해야 한다면 전체 작업은 길어질 수 있습니다. 최종 이미지의 품질과 후보를 고르는 시간을 함께 봅니다.",
          "사이트의 시간 비교는 생성 대기의 예상치입니다. 내 프롬프트의 성공률까지 계산하지는 않습니다. 원하는 장면이 나오는 모델을 먼저 남기고, 그 모델을 편하게 반복할 장비를 고르는 순서가 과한 구매와 불필요한 다운로드를 줄일 수 있습니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/local-image-model-toolbox.webp",
        "alt": "속도, 글자 표현, 참고 이미지 편집과 정밀 묘사를 위한 서로 다른 네 가지 도구가 놓인 작업대 그림",
        "caption": "이미지 모델은 하나의 순위로 고르기보다 빠른 시안, 글자 표현, 편집과 정밀 묘사 가운데 자주 할 작업에 맞춰 고르는 편이 정확합니다.",
        "width": 1672,
        "height": 941,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/local-image-poster-text.webp",
        "alt": "포스터의 제목 영역과 이미지 영역을 정교하게 조정하는 편집 작업을 글자 모양 블록으로 보여 주는 그림",
        "caption": "글자가 들어간 포스터는 그림의 분위기뿐 아니라 글자 모양, 배치와 여백을 함께 봐야 하므로 텍스트 표현에 강한 모델이 유리합니다.",
        "width": 1672,
        "height": 941,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/local-image-reference-editing.webp",
        "alt": "여러 참고 사진에서 색, 구도와 재질 요소를 가져와 한 장의 새 이미지로 합치는 무드보드 그림",
        "caption": "참고 이미지 편집에서는 단순 생성 속도보다 입력 이미지를 몇 장 받을 수 있는지와 형태를 얼마나 안정적으로 유지하는지가 중요합니다.",
        "width": 1672,
        "height": 941,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/local-video-generation-guide",
    "slug": "local-video-generation-guide",
    "title": "로컬 영상 생성 가이드: 텍스트·이미지에서 영상 만들기",
    "description": "Wan 2.2와 MiniMax 같은 최신 로컬 영상 모델로 텍스트나 정지 이미지에서 짧은 영상을 만드는 방법과 해상도·프레임·사운드에 따른 장비 선택을 설명합니다.",
    "headline": "이미지 여러 장을 만드는 것보다 시간 축 계산이 더해져 메모리와 시간이 크게 늘어납니다.",
    "category": "generation",
    "categoryLabel": "이미지·영상 생성",
    "plainSummary": "사진 한 장은 마음에 들게 만들었는데 움직이기 시작하니 얼굴이나 제품 모양이 달라집니다. 로컬 영상 생성은 프레임을 많이 만드는 것만으로 끝나지 않습니다. 여러 순간에 걸쳐 같은 장면을 유지해야 하므로, 짧은 컷 하나를 끝까지 확인하는 것부터 시작하는 편이 좋습니다.",
    "buyerNote": "만들 모델·해상도·프레임 수를 정하고 해당 워크플로의 피크 메모리를 확인하세요. 용량이나 GPU 개수만으로 영상 실행 범위를 보장할 수는 없습니다.",
    "keyPoints": [
      "사진을 움직이게 만드는 이미지-투-비디오가 텍스트 전용보다 의도를 맞추기 쉽습니다.",
      "초당 프레임과 영상 길이가 늘수록 메모리 사용량이 급증합니다.",
      "오디오가 함께 생성되는 모델은 소리와 장면의 일치도를 함께 확인해야 합니다."
    ],
    "sections": [
      {
        "title": "몇 초짜리 컷 하나를 정해봅니다",
        "paragraphs": [
          "가령 제품 사진에 카메라가 조금 다가가는 장면을 만들려고 한다고 해봅시다. 처음에는 그 한 동작만 확인합니다. 제품 회전과 배경 변화, 큰 카메라 이동을 한꺼번에 요구하면 어떤 조건에서 형태가 무너졌는지 알기 어렵습니다.",
          "텍스트만으로 새 장면을 만드는 경로와 이미지를 시작 조건으로 쓰는 경로도 다릅니다. 이미 잘 고른 사진이 있다면 이미지 입력이 가능한 모델부터 볼 수 있습니다. 입력 사진이 있다고 모든 프레임의 형태가 보장되는 것은 아닙니다."
        ]
      },
      {
        "title": "재생 시간과 기다린 시간을 나눕니다",
        "paragraphs": [
          "5초짜리 결과 영상은 완성 뒤 5초 동안 재생된다는 뜻입니다. 그것을 생성하는 데 걸린 시간과 다릅니다. 프레임 수, 해상도, 모델과 스텝이 달라지면 생성 시간도 달라집니다.",
          "예를 들어 24fps로 5초를 재생하면 표시되는 프레임은 120개입니다. 하지만 모델이 내부에서 처리하는 시간 축은 압축이나 보간 등 워크플로에 따라 달라집니다. 120장의 독립 이미지를 만든 시간으로 영상 생성 비용을 단순 계산할 수는 없습니다."
        ]
      },
      {
        "title": "움직임을 먼저, 큰 해상도는 그다음",
        "paragraphs": [
          "지원되는 짧은 길이와 작은 해상도에서 피사체가 끝까지 유지되는지 봅니다. 첫 장면만 좋고 중간에서 형태가 바뀌면 큰 해상도로 다시 만드는 것으로 해결되지 않을 수 있습니다. 동작을 줄이거나 다른 입력 조건을 시험할 이유가 생깁니다.",
          "원하는 움직임을 찾은 뒤 해상도와 길이를 바꾸세요. 이때도 구도와 움직임이 같다는 보장은 없으므로 다시 재생해 확인합니다. 시드·프롬프트·모델·설정을 함께 저장하면 어떤 수정이 도움이 됐는지 돌아볼 수 있습니다."
        ]
      },
      {
        "title": "소리와 편집도 완성 과정에 들어갑니다",
        "paragraphs": [
          "모든 영상 모델이 오디오를 함께 만드는 것은 아닙니다. 지원되는 경로라면 소리가 움직임과 맞는지, 원치 않는 음성이 들어가는지 따로 확인합니다. 무음 결과에 필요한 소리를 후반 작업으로 붙이는 방법도 있습니다.",
          "짧은 컷을 여러 개 만들었다면 편집 프로그램에서 이어 붙이고 색과 소리를 맞춥니다. 생성 버튼 한 번으로 긴 완성 영상을 얻는 목표보다, 실제로 쓸 수 있는 몇 초를 만드는 목표가 문제를 나누어 보기 쉽습니다."
        ]
      },
      {
        "title": "GPU 메모리만으로 모든 영상이 되지는 않습니다",
        "paragraphs": [
          "같은 VRAM에서도 모델 파일과 정밀도, 해상도·프레임 수·오프로드에 따라 실행 범위가 달라집니다. 두 GPU를 쓴다면 해당 워크플로가 그 분할을 지원해야 합니다. 메모리 합계만으로 실행 시간을 계산하지 마세요.",
          "한 편을 만드는 시간뿐 아니라 다시 만드는 횟수도 생각해야 합니다. 매일 컷을 여러 개 제작하는 경우와 가끔 개인 사진을 움직이는 경우는 기다릴 수 있는 시간이 다릅니다. 이 차이가 장비에 추가 비용을 쓸 이유를 만듭니다."
        ]
      },
      {
        "title": "사이트 체험과 실제 생성은 구분합니다",
        "paragraphs": [
          "사이트에서는 예상 시간이 지난 뒤 준비된 영상 샘플을 재생합니다. 선택한 장비가 지금 그 영상을 실시간 생성하거나 프롬프트를 새로 해석하는 것은 아닙니다. 장비 사이의 대기를 비교하는 체험입니다.",
          "구매를 결정하기 전에는 목표 모델의 실제 워크플로로 같은 길이와 해상도의 결과를 확인하세요. 짧은 컷 하나라도 끝까지 형태가 유지되고 다시 만들기에도 기다릴 만하다면, 그 구성이 지금 하려던 작업의 출발점이 될 수 있습니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/local-video-photo-storyboard.webp",
        "alt": "정지 사진 한 장이 카메라 이동과 피사체 움직임이 다른 여러 영상 프레임으로 이어지는 스토리보드 그림",
        "caption": "이미지에서 영상으로 만드는 작업은 시작 프레임을 고정하고 움직임, 카메라와 영상 길이를 순서대로 정하면 실패를 줄일 수 있습니다.",
        "width": 1672,
        "height": 941,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/local-video-frame-cost.webp",
        "alt": "영상의 해상도와 길이가 늘어날수록 처리해야 할 프레임 묶음과 기다림이 커지는 과정을 보여 주는 그림",
        "caption": "영상 생성은 해상도뿐 아니라 프레임 수가 비용을 키우므로 5초 시안으로 움직임을 확인한 뒤 길이와 품질을 높이는 편이 현실적입니다.",
        "width": 1672,
        "height": 941,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/local-video-hardware-tiers.webp",
        "alt": "단일 16GB 그래픽카드부터 24GB, 48GB와 멀티 GPU 워크스테이션까지 영상 작업 범위를 비교한 작업실 그림",
        "caption": "16GB에서는 경량 모델과 오프로딩, 24GB에서는 720p급 경로, 더 큰 메모리에서는 오디오와 대형 영상 모델처럼 가능한 작업이 달라집니다.",
        "width": 1672,
        "height": 941,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/wan-minimax-local-video-models",
    "slug": "wan-minimax-local-video-models",
    "title": "Wan 2.2와 MiniMax 영상 모델, 로컬 작업별 선택법",
    "description": "Wan 2.2 TI2V-5B·T2V-14B와 MiniMax H3-Base의 특징, 카메라 모션, 오디오 동시 생성과 필요 메모리 기준을 설명합니다.",
    "headline": "가벼운 컷은 빠른 5B 모델로, 정밀한 움직임과 사운드는 14B와 복합 모델로 나눕니다.",
    "category": "generation",
    "categoryLabel": "이미지·영상 생성",
    "plainSummary": "영상 모델을 고르려는데 예시의 멋진 장면과 필요한 GPU 사양부터 눈에 들어옵니다. 하지만 내 사진을 움직이는 일과 아무 이미지 없이 장면을 만드는 일은 다릅니다. Wan과 MiniMax 계열을 비교할 때도 입력 방식과 완성해야 할 컷부터 정해보겠습니다.",
    "buyerNote": "작은 5B 모델은 16GB~24GB에서도 시도할 수 있지만, 14B 이상이나 사운드 포함 모델은 24GB 이상 VRAM 또는 오프로딩 설정이 필요합니다.",
    "keyPoints": [
      "Wan 2.2 5B는 가볍고 빠른 영상 시안 작업에 적합합니다.",
      "Wan 2.2 14B는 사용할 장면으로 움직임과 메모리를 함께 확인하세요.",
      "MiniMax H3-Base는 영상과 오디오를 함께 다루는 워크플로를 제공합니다."
    ],
    "sections": [
      {
        "title": "사진의 형태를 지켜야 하나요?",
        "paragraphs": [
          "실제 제품이나 정해진 인물이 있다면 이미지 입력을 받는 경로를 먼저 확인합니다. 텍스트 전용 파일에 이미지를 넣는 옵션을 추가한다고 같은 작업이 되지는 않습니다. 계열 이름뿐 아니라 정확한 체크포인트와 워크플로가 필요합니다.",
          "첫 컷과 마지막 컷을 지정하는 기능도 모델과 도구가 지원해야 합니다. 모든 모델이 같은 입력을 받는다는 가정으로 속도만 비교하면, 장비를 준비한 뒤 원하는 작업을 못 하는 경우가 생길 수 있습니다."
        ]
      },
      {
        "title": "Wan 2.2의 작은 구성부터 시험한다면",
        "paragraphs": [
          "TI2V-5B처럼 상대적으로 작은 가중치의 구성을 먼저 검토할 수 있습니다. 작은 파일이 주는 이점은 적재와 시험 부담을 줄일 수 있다는 점입니다. 내가 필요한 움직임의 품질까지 자동으로 만족한다는 뜻은 아닙니다.",
          "같은 사진으로 짧은 클립을 만들어 제품의 가장자리와 인물의 얼굴이 유지되는지 보세요. 모델이 로드됐어도 생성 중 작업 공간이 부족할 수 있습니다. 해상도와 프레임 수, 실제 피크 메모리를 함께 기록해야 합니다."
        ]
      },
      {
        "title": "14B로 올리기 전에 실패한 장면을 남깁니다",
        "paragraphs": [
          "작은 모델에서 원하는 장면을 얻지 못했다면 무엇이 부족했는지 구체적으로 봅니다. 손발이 바뀌는지, 배경이 흔들리는지, 요청한 카메라 이동을 따르지 않는지에 따라 비교할 결과도 달라집니다.",
          "큰 모델에도 같은 장면을 맡겨 그 문제가 줄었는지 확인하세요. 파일 크기가 늘었다는 사실만으로 구매 이유가 완성되지는 않습니다. 결과가 비슷하다면 더 큰 메모리와 생성 시간을 쓸 필요가 적을 수 있습니다."
        ]
      },
      {
        "title": "MiniMax 계열은 받을 수 있는 실행 경로부터",
        "paragraphs": [
          "서비스에서 볼 수 있는 기능과 로컬에서 내려받아 실행할 수 있는 체크포인트는 구분해야 합니다. 사이트에 등록된 모델 이름만 보고 내 앱에서도 같은 기능이 모두 된다고 판단하지 마세요. 배포 파일과 라이선스, 해당 실행 도구의 지원이 우선입니다.",
          "영상과 오디오를 함께 다루는 구성을 검토한다면 실제 로컬 경로가 오디오까지 지원하는지 확인합니다. 완성된 클립에서 소리와 움직임의 일치도 따로 봐야 합니다. 같은 이름의 서비스 데모는 내 장비의 실행 기록을 대신하지 않습니다."
        ]
      },
      {
        "title": "한 장비에서 반복할 수 있는 조건을 찾습니다",
        "paragraphs": [
          "모델·양자화·해상도·프레임 수를 고정하고 생성 시간과 메모리를 비교합니다. 오프로드 여부가 다른 기록은 그 차이를 남기세요. 작은 카드에서도 실행 가능할 수 있지만 반복 전송 때문에 오래 걸리는 경우가 있습니다.",
          "이 사이트의 샘플 재생은 예상 대기의 체험입니다. 모델별 작품 품질이나 내 프롬프트의 성공을 보장하는 비교는 아닙니다. 원하는 짧은 컷을 만들 수 있는 모델을 먼저 찾고, 그 컷을 하루에 몇 번 수정할지 생각하면 필요한 장비도 더 구체적으로 좁혀집니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/minimax-h3-audio-video.webp",
        "alt": "하나의 타임라인에서 영상 프레임과 좌우 스테레오 음파가 함께 만들어지는 오디오·비디오 생성 과정 그림",
        "caption": "H3-Base는 영상과 스테레오 오디오를 함께 생성하므로 무음 영상을 만든 뒤 소리를 별도로 붙이는 작업과 계산 구조가 다릅니다.",
        "width": 1672,
        "height": 941,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/minimax-h3-first-last-frame.webp",
        "alt": "첫 프레임과 마지막 프레임 사이를 여러 중간 장면과 카메라 이동이 연결하는 필름 스트립 그림",
        "caption": "첫·끝 프레임을 함께 주면 시작 모습과 도착 장면을 고정할 수 있지만 중간 움직임이 자연스러운지는 짧은 시안으로 먼저 확인해야 합니다.",
        "width": 1672,
        "height": 941,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/minimax-h3-multi-gpu.webp",
        "alt": "여러 GPU와 호스트 메모리가 하나의 768p 영상·오디오 생성을 나눠 처리하는 구조 그림",
        "caption": "H3-Base 소비자 GPU 실행은 그래픽 메모리 합산뿐 아니라 충분한 시스템 RAM, 오프로딩과 런타임 분산 지원까지 함께 준비해야 합니다.",
        "width": 1672,
        "height": 941,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/local-ai-generation-vram",
    "slug": "local-ai-generation-vram",
    "title": "이미지·영상 생성에 필요한 그래픽카드 메모리(VRAM)",
    "description": "이미지·영상 생성에서 모델 본체, 텍스트 인코더, VAE와 중간 작업 공간이 VRAM을 어떻게 쓰는지와 12GB부터 64GB+까지의 실행 범위를 설명합니다.",
    "headline": "모델 가중치만 계산하면 부족합니다. 텍스트 인코더와 VAE, 작업 버퍼까지 남아야 합니다.",
    "category": "generation",
    "categoryLabel": "이미지·영상 생성",
    "plainSummary": "모델 파일은 GPU에 들어갔는데 생성 버튼을 누른 뒤 메모리 오류가 납니다. 거의 다 된 것 같아 더 답답한 순간입니다. 이미지와 영상에서는 파일을 보관하는 공간 외에 생성 도중 커지는 작업 공간이 있습니다. 어느 단계에서 부족해지는지부터 나누어 보겠습니다.",
    "buyerNote": "같은 VRAM도 모델·해상도·장수·프레임 수에 따라 실행 범위가 다릅니다. 실제 워크플로의 최대 메모리와 오프로드 여부를 함께 확인하세요.",
    "keyPoints": [
      "본체 외에도 텍스트 인코더, VAE, 작업 버퍼가 VRAM을 함께 씁니다.",
      "오프로딩은 메모리 부족을 해결하지만 생성 시간을 크게 늘릴 수 있습니다.",
      "해상도와 영상 프레임 수가 늘수록 필요한 작업 공간이 커집니다."
    ],
    "sections": [
      {
        "title": "모델 본체 옆에도 필요한 구성 요소가 있습니다",
        "paragraphs": [
          "프롬프트를 처리하는 텍스트 인코더, 이미지를 픽셀로 바꾸는 VAE와 생성 중간의 데이터가 메모리를 사용합니다. 워크플로에 따라 이미지나 오디오용 구성 요소도 더해집니다. 모든 것이 동시에 올라오는지 순서대로 바뀌는지도 다를 수 있습니다.",
          "따라서 본체 파일이 12GB보다 작다는 이유만으로 12GB GPU에서 원하는 해상도가 된다고 결론 내릴 수는 없습니다. 로드할 때와 샘플링할 때, 마지막 이미지를 풀어낼 때의 메모리 정점이 다를 수 있습니다."
        ]
      },
      {
        "title": "처음에는 됐는데 해상도를 높이면",
        "paragraphs": [
          "가로와 세로를 각각 두 배로 늘리면 픽셀 면적은 네 배가 됩니다. 하지만 내부의 메모리와 시간은 모델의 압축·어텐션·타일 처리에 따라 달라져 정확히 네 배로 고정되지 않습니다. 면적이 커지면 작업 부담도 커진다는 출발점으로 이해하면 됩니다.",
          "같은 이유로 한 장을 만드는 것과 여러 장을 동시에 만드는 것은 다릅니다. 배치가 부족하면 우선 한 장씩 순서대로 시험할 수 있습니다. 여러 장의 총시간을 줄이려는 것인지, 한 장을 완성하려는 것인지 목적을 나누어 보세요."
        ]
      },
      {
        "title": "영상은 시간 축까지 함께 봅니다",
        "paragraphs": [
          "프레임 수가 늘어나면 여러 순간의 상태와 관계를 처리해야 합니다. 모델의 시간 압축 방식과 워크플로에 따라 내부 계산량이 다르므로, 영상 길이만으로 VRAM 요구량을 단정할 수는 없습니다.",
          "짧은 길이에서 시작해 해상도와 프레임 수를 하나씩 바꾸세요. 둘을 동시에 올렸다가 실패하면 무엇을 낮춰야 할지 알기 어렵습니다. 출력이 완료됐더라도 마지막 프레임까지 형태가 유지되는지 확인해야 합니다."
        ]
      },
      {
        "title": "RAM에 옮겨두면 실행할 여지는 생깁니다",
        "paragraphs": [
          "순서대로 사용하는 구성 요소를 RAM에 내리고 필요한 때 GPU에 올리는 오프로드가 있습니다. 작은 카드에서 모델을 실행할 수 있게 해줄 수 있지만 데이터 이동 시간이 더해집니다. 모델 전체가 매 스텝 이동하는지 일부 단계에서만 이동하는지에 따라 비용도 다릅니다.",
          "모든 오프로드가 같은 배율로 느려지는 것은 아닙니다. 실행 로그와 실제 시간을 보며 적재에 걸린 대기와 생성 중 대기를 나눠보세요. 시스템 RAM까지 부족해 디스크 스왑이 발생하는 상황은 또 다른 병목입니다."
        ]
      },
      {
        "title": "몇 GB가 정답인지 묻기 전에",
        "paragraphs": [
          "만들 모델과 작업, 해상도·장수·프레임 수를 먼저 정해야 합니다. 16GB는 이미지, 24GB는 영상처럼 용량만으로 모든 실행 범위를 나눌 수는 없습니다. 실제로 확인된 워크플로의 피크 메모리가 더 직접적인 자료입니다.",
          "이미 가진 장비에서 완성할 수 있다면 다음 질문은 기다릴 만한지입니다. 가끔 쓰는 작업은 오프로드를 받아들일 수 있고 매일 반복하는 작업은 메모리를 늘려 전송을 줄일 가치가 있을 수 있습니다. 오류 한 번 때문에 최고 사양으로 올라가기보다, 실제 부족한 공간이 어디였는지 먼저 찾아보세요."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/media-vram-packing.webp",
        "alt": "모델 가중치, 텍스트 인코더, VAE와 작업 공간을 그래픽 메모리 수납장에 차례로 넣는 그림",
        "caption": "이미지·영상 모델은 본체 가중치 외에도 텍스트 인코더, VAE와 중간 결과가 필요하므로 파일 크기만 보고 VRAM을 맞추면 부족할 수 있습니다.",
        "width": 1672,
        "height": 941,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/media-offload-bottleneck.webp",
        "alt": "그래픽카드 메모리와 시스템 메모리 사이의 좁은 전송 통로 때문에 생성 과정이 대기하는 오프로딩 병목 그림",
        "caption": "오프로딩은 적은 VRAM에서도 실행하게 해 주지만 단계마다 데이터를 옮기면 생성 시간이 크게 늘어날 수 있습니다.",
        "width": 1672,
        "height": 941,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/media-memory-tiers.webp",
        "alt": "크기가 다른 여섯 개의 메모리 수납장이 이미지 시안, 고품질 이미지, 짧은 영상과 오디오 영상 작업으로 이어지는 그림",
        "caption": "메모리 용량이 커질수록 단순히 빨라지는 것이 아니라 오프로딩 없이 실행할 수 있는 모델과 출력 범위가 넓어집니다.",
        "width": 1672,
        "height": 941,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/local-llm-tco",
    "slug": "local-llm-tco",
    "title": "로컬 LLM TCO: 1년·2년 총소유비용 계산법",
    "description": "로컬 AI 하드웨어 구매가에서 감가상각, 예상 매각가, 전기요금, 유지보수와 클라우드 구독 절감액을 합산해 실제 총소유비용을 계산하는 방법입니다.",
    "headline": "구매가에 전기요금을 더하고, 되팔 때 받을 금액을 뺍니다.",
    "category": "cost",
    "categoryLabel": "구매와 비용",
    "plainSummary": "장비값을 구독료로 나누어 보니 몇 년이면 본전을 찾을 것 같습니다. 그런데 그동안 구독을 정말 끊을 수 있을까요? 장비를 팔 때 남는 돈과 켜두는 동안 나가는 돈도 있습니다. 로컬 AI의 비용은 구매 가격 하나보다, 사고 쓰고 정리하는 전체 기간으로 계산해야 합니다.",
    "buyerNote": "AI 구독을 계속 유지할 예정이라면 구독료를 절감액으로 넣지 마세요. 1년과 2년 결과가 모두 납득되는 장비가 더 안전한 선택입니다.",
    "keyPoints": [
      "구매가에서 예상 매각가를 빼 기본 보유비용을 구합니다.",
      "전기·호스트·추가 부품과 유지 시간을 더합니다.",
      "실제로 끊을 구독과 클라우드 비용만 절감액으로 셉니다."
    ],
    "sections": [
      {
        "title": "구매한 금액이 모두 사라지는 것은 아닙니다",
        "paragraphs": [
          "장비를 사고 1년이나 2년 뒤 판매한다면 일부 금액을 회수할 수 있습니다. 반대로 계속 보유하면 그 금액은 당장 현금으로 돌아오지 않습니다. 그래서 보유비용을 계산할 때는 구매가에서 예상 매각가를 뺀 감가 비용과 실제 현금 지출을 구분합니다.",
          "예상 중고가격은 보장이 아닙니다. 상태, 메모리 구성, 신제품 출시와 거래 시점에 따라 달라집니다. 좋은 매각가를 가정한 한 가지 결과만 보지 말고, 더 낮게 팔리는 경우에도 감당할 만한지 살펴보세요."
        ]
      },
      {
        "title": "구독료는 실제로 줄어드는 만큼만 뺍니다",
        "paragraphs": [
          "로컬 모델이 생겨도 다른 서비스를 계속 구독할 수 있습니다. 작업 일부만 옮기거나 외부 서비스를 검증용으로 남겨둔다면 구독료 전액을 절감액으로 넣으면 안 됩니다. 로컬 장비가 대신할 수 있는 일과 여전히 필요한 일을 나누어 적어보세요.",
          "간단한 가상 예로 월 3만 원 지출을 실제로 없앤다면 1년 절감액은 36만 원, 2년은 72만 원입니다. 구독을 유지한다면 같은 항목의 절감액은 0원입니다. 장비 성능이 아무리 좋아도 이 계산의 출발점은 내 결제 변화입니다."
        ]
      },
      {
        "title": "전기요금은 최대 전력으로 하루를 곱하지 않습니다",
        "paragraphs": [
          "그래픽카드의 최대 소비전력과 컴퓨터 전체가 평소 쓰는 전력은 다릅니다. 하루 중 생성하는 시간, 대기하는 시간, 완전히 꺼두는 시간을 나누어 계산해야 합니다. GPU 단품 수치라면 CPU와 다른 부품의 전력도 별도로 들어갑니다.",
          "가정용 요금은 기존 사용량과 요금 구간의 영향을 받습니다. 사이트 계산은 입력 조건에 따른 예상치이므로 실제 고지서의 증가분과 같다고 보장할 수 없습니다. 24시간 서버를 계획한다면 생성할 때뿐 아니라 대기 전력도 중요한 항목입니다."
        ]
      },
      {
        "title": "GPU 한 장만 사는지 본체까지 사는지",
        "paragraphs": [
          "현재 PC에 카드를 추가하는 사람과 처음부터 본체를 맞추는 사람은 비용이 다릅니다. 전원공급장치 교체나 저장장치 추가가 필요하면 초기 비용에 넣습니다. 이미 가진 장비의 과거 구매가를 새 구매처럼 다시 더하는 것도 비교 목적에 따라 피해야 합니다.",
          "설정하고 관리하는 시간은 금액으로 매기기 어렵지만 없는 비용은 아닙니다. 설정 자체를 즐긴다면 취미의 일부일 수 있고, 업무 도구만 필요하다면 큰 부담일 수 있습니다. 누구의 시간을 같은 시급으로 가정해 결론을 낼 필요는 없습니다."
        ]
      },
      {
        "title": "1년과 2년 결과를 함께 보는 이유",
        "paragraphs": [
          "짧게 보유하면 초기 비용과 감가가 크게 보입니다. 오래 사용하면 실제로 없앤 구독료가 쌓이지만 전기요금과 유지비도 함께 늘어납니다. 어느 시점에 무조건 이득이라는 결론보다 내가 사용할 기간에서 결과가 어떤지 보는 편이 낫습니다.",
          "절감액이 기대보다 작게 나와도 로컬 장비를 살 이유가 사라지는 것은 아닙니다. 데이터를 내 환경에서 처리하고 직접 설정을 바꾸는 가치를 원할 수 있습니다. 다만 그 선택과 경제적으로 본전을 찾는다는 주장은 구분해야, 사용하면서 처음 계산을 후회할 가능성이 줄어듭니다."
        ]
      }
    ],
    "visuals": [
      {
        "src": "/guides/p18-tco-timeline.webp",
        "alt": "장비 구매부터 전기요금, 구독 절감과 중고 매각까지의 비용 흐름을 시간 순서로 놓은 그림",
        "caption": "TCO는 결제한 구매가만이 아니라 보유 중 비용, 실제 절감액과 마지막 잔존가치를 모두 포함합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 0
      },
      {
        "src": "/guides/p18-cashflow.webp",
        "alt": "장비 구입, 월별 전력·부품비, 구독 절감과 되팔 때의 금액을 한 소유 기간에 놓은 그림",
        "caption": "비용과 절감은 발생 시점이 다르므로 1년과 2년처럼 같은 기간을 정해 현금 흐름을 비교해야 합니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 1
      },
      {
        "src": "/guides/p18-break-even.webp",
        "alt": "로컬 장비 누적 비용 경로와 클라우드 구독 누적 비용 경로가 손익분기점에서 교차하는 그림",
        "caption": "두 누적 비용이 만나는 시점은 실제로 끊는 구독액과 매각가, 전기요금 가정에 따라 크게 달라집니다.",
        "width": 1536,
        "height": 1024,
        "afterSectionIndex": 2
      }
    ],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/qwen-3.8-27b-serving-recipe",
    "slug": "qwen-3.8-27b-serving-recipe",
    "title": "Qwen3.8-27B 장비별 설정: Mac oMLX·RTX llama.cpp",
    "description": "Qwen3.8-27B를 Mac과 RTX에서 실행할 때의 Q4 가중치, KV 캐시, 프리필 배치, MTP, 문맥 길이와 oMLX·llama.cpp 실행 명령을 장비별로 제공합니다.",
    "headline": "장비를 고르면 균형·생성 속도·긴 문맥 프로필과 확인 순서가 함께 나옵니다.",
    "category": "recipe",
    "categoryLabel": "모델별 실행 레시피",
    "term": "Qwen3.8-27B 서빙",
    "alternateName": "Qwen3.8-27B Local Serving Recipe",
    "plainSummary": "Qwen3.8-27B를 띄웠는데 다른 사람의 기록보다 느립니다. 같은 모델 이름이어도 파일과 문맥, 실행 앱이 다르면 출발점이 다를 수 있습니다. 여기서는 Mac의 oMLX와 RTX의 llama.cpp 설정을 먼저 구분하고, 어디서 기다리는지 확인하며 하나씩 조정합니다.",
    "buyerNote": "32GB급은 Q4와 짧은 문맥의 출발점이고, 48GB 이상은 긴 문맥과 다른 앱을 함께 쓸 여유가 늘어납니다. 메모리 용량만 보지 말고 선택 장비의 실제 프리필과 디코드 범위를 같이 확인하세요.",
    "keyPoints": [
      "Mac은 oMLX 메모리 가드와 모델별 MTP, RTX는 llama.cpp 배치·KV 캐시 설정을 따로 제공합니다.",
      "가중치 양자화와 KV 캐시 정밀도를 분리하고, 긴 문맥에서는 Q8 KV와 작은 프리필 배치를 검토합니다.",
      "균형 설정의 기준값을 저장한 뒤 한 항목씩 조정하고 세 번의 중앙값으로 유지 여부를 정합니다."
    ],
    "sections": [
      {
        "title": "내 파일과 실행 앱부터 맞춥니다",
        "paragraphs": [
          "장비 선택기에서 현재 장비를 고르면 사용할 경로와 명령을 볼 수 있습니다. 데스크톱에서는 호환되는 Q4 GGUF 또는 MLX 변환본을 기준으로 확인합니다. 약 17GB대라는 파일 크기 안내는 출발점일 뿐 실제 다운로드와 실행 점유를 확인해야 합니다.",
          "공식 BF16 모델 ID를 서버에 넘기는 경로는 같은 Q4 파일을 여는 것이 아닙니다. 27B 가중치만 단순 계산해도 약 54GB 규모이며 작업 공간이 더 필요합니다. 아래 공식 서버 예시를 24GB GPU의 Q4 명령처럼 복사하지 마세요.",
          "텍스트 질문부터 정상 실행한 뒤 이미지 입력과 추가 가속을 확인합니다. 첫 로드에서 모델 파일과 비전·MTP 지원을 동시에 바꾸면 어느 부분 때문에 실패했는지 찾기 어렵습니다."
        ]
      },
      {
        "title": "잘 되는 설정을 하나 남깁니다",
        "paragraphs": [
          "Mac oMLX와 RTX llama.cpp의 명령은 위 장비 선택기에 맞춰 사용합니다. 요청은 한 개로 두고 표시된 문맥에서 시작하세요. 더 큰 문맥이나 공격적인 메모리 설정으로 바로 넘어가기보다 정상 답변을 남기는 것이 먼저입니다.",
          "프리필, 첫 토큰까지의 시간, 디코드와 피크 메모리를 기록합니다. 준비 실행 한 번 뒤 같은 입력 세 번의 중앙값을 기준으로 쓰세요. 이후 프리필 청크나 캐시 정밀도를 바꿀 때 이 기록으로 돌아와 실제 이득을 판단합니다.",
          "아래 vLLM 명령은 공식 가중치를 담을 수 있는 별도 NVIDIA 서버 경로입니다. 선택기의 데스크톱 명령과 혼합하지 마세요. 서버는 우선 127.0.0.1에만 두고 다른 기기에서 접근시킬 계획이면 인증과 접근 제한을 별도로 준비합니다."
        ],
        "codeBlocks": [
          {
            "label": "공식 vLLM 서버 구동 (BF16 / FP8 대용량 메모리)",
            "code": "vllm serve Qwen/Qwen3.8-27B   --host 127.0.0.1   --port 8000   --max-model-len 8192   --gpu-memory-utilization 0.90",
            "caption": "공식 BF16 가중치와 런타임 여유가 확보된 NVIDIA 서버에서 127.0.0.1로 실행합니다."
          }
        ]
      },
      {
        "title": "서버가 켜진 것과 답변이 되는 것은 다릅니다",
        "paragraphs": [
          "모델 목록을 확인해 실제로 로드된 식별자를 요청에 넣습니다. oMLX는 이 가이드의 8000, llama.cpp는 8080처럼 선택한 명령의 주소를 사용해야 합니다. 아래 예시 주소와 다르면 그 부분을 맞춘 뒤 짧은 질문을 보내세요.",
          "답변이 조각으로 도착하는지, 생각 과정과 최종 답이 앱에서 구분되는지 확인합니다. 생각 토큰을 오래 생성하는 경우 화면에 최종 문장이 늦게 보일 수 있습니다. 이 시간을 순수 프리필로 잘못 기록하지 않도록 서버 로그도 함께 봅니다.",
          "기본 질문이 완료되면 평소 문서를 보내보세요. 짧은 인사말에서 나온 최고 tok/s보다 그 문서의 첫 답변과 완료 시간이 실제 사용에 더 가깝습니다."
        ],
        "codeBlocks": [
          {
            "label": "API 엔드포인트 헬스체크 및 챗 요청 검증",
            "code": "# 1. 로드된 모델 목록 확인\ncurl -N http://127.0.0.1:8000/v1/models\n\n# 2. OpenAI 호환 챗 완성 API 호출\ncurl -N http://127.0.0.1:8000/v1/chat/completions   -H \"Content-Type: application/json\"   -d '{\n    \"model\": \"<local-model-identifier>\",\n    \"messages\": [\n      {\"role\": \"user\", \"content\": \"로컬 LLM 서빙의 장점을 세 가지로 요약해줘.\"}\n    ],\n    \"temperature\": 0.6,\n    \"max_tokens\": 1024,\n    \"stream\": true\n  }'",
            "caption": "oMLX는 8000, llama.cpp는 8080 포트를 사용합니다. 실행한 런타임에 맞춰 주소를 바꿉니다."
          }
        ]
      },
      {
        "title": "느리다면 먼저 어느 구간인지 봅니다",
        "paragraphs": [
          "입력을 넣은 뒤 오래 기다리면 프리필 청크와 입력 길이, 캐시 상태를 확인합니다. 답변이 시작된 뒤 느리다면 CPU로 넘어간 가중치가 있는지, 메모리 압박이나 스왑이 생겼는지 봅니다. 두 문제를 MTP 단계 수 하나로 해결하려고 하면 원인을 놓칠 수 있습니다.",
          "지원되는 파일과 런타임에서 MTP를 켠 뒤에는 같은 질문으로 기본값과 비교합니다. 평균 승인 길이가 낮거나 검증 비용이 크면 켜도 이득이 없을 수 있습니다. 캐시 정밀도와 MTP를 한 번에 바꾸지 마세요.",
          "원하는 긴 문맥에서 메모리가 부족하다면 우선 요청 수와 길이를 줄여 돌아갈 기준을 확보합니다. 계속 필요한 작업에서만 한계가 반복되는지 확인한 뒤 상위 메모리 구성을 검토합니다."
        ]
      },
      {
        "title": "좋은 기록보다 계속 쓸 설정을 남깁니다",
        "paragraphs": [
          "코드 수정과 문서 요약을 모두 한다면 두 종류의 질문을 남겨보세요. 한쪽에서만 빨라지는 설정도 있습니다. 속도뿐 아니라 실제 결과의 오류와 실행 실패 여부를 함께 확인해야 합니다.",
          "마지막으로 모델 파일·앱 버전·문맥·가속 옵션을 저장합니다. 업데이트 뒤 문제가 생겨도 정상 구성을 되찾을 수 있습니다. 처음부터 가장 빠른 숫자를 찾기보다 내 작업이 끝까지 되는 설정을 만든 뒤 속도를 올리는 편이 유지하기 쉽습니다."
        ]
      }
    ],
    "visuals": [],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/qwen-3.8-flash-next-serving-recipe",
    "slug": "qwen-3.8-flash-next-serving-recipe",
    "title": "Qwen3.8-Flash-Next 최적 설정: 단일 DGX Spark SGLang 레시피",
    "description": "Qwen3.8-Flash-Next NVFP4를 DGX Spark 한 대에서 실행하는 SGLang 설정입니다. NVMe PLE mmap, 프리필 청크, 메모리 비율, NEXTN MTP와 262K 긴 문맥 구성을 구분합니다.",
    "headline": "단일 DGX Spark의 공개 실행 사례: 32K 속도 설정과 262K 긴 문맥 설정",
    "category": "recipe",
    "categoryLabel": "모델별 실행 레시피",
    "term": "Qwen3.8-Flash-Next 서빙",
    "alternateName": "Qwen3.8-Flash-Next Local Serving Recipe",
    "plainSummary": "단일 Spark에서도 Flash-Next가 빠르게 돌아간다는 실행 기록을 보면 같은 명령을 써보고 싶어집니다. 그런데 이 경로는 모델만 받는 것으로 끝나지 않습니다. 전용 압축본과 PLE SSD 패치, MTP와 백엔드 설정을 한 묶음으로 맞춰야 합니다. 무엇을 재현하는지부터 확인해보겠습니다.",
    "buyerNote": "DGX Spark 한 대에서 가능한 구성은 stock SGLang에 옵션 하나만 더한 형태가 아닙니다. NVFP4 체크포인트, GB10용 패치, 약 140GB의 NVMe 여유 공간이 모두 필요합니다. 설치 난이도보다 간편한 운영이 중요하면 더 작은 모델도 함께 비교하세요.",
    "keyPoints": [
      "단일 Spark 실측 구성은 mem fraction 0.85, prefill chunk 4,096, 32K 문맥을 사용합니다.",
      "262K 구성은 mem fraction 0.79와 prefill chunk 1,024로 프리필 순간 메모리를 낮춥니다.",
      "MTP steps 3과 draft tokens 4는 서로 다른 값이며, 가중치 NVFP4와 KV 캐시 BF16도 구분합니다."
    ],
    "sections": [
      {
        "title": "같은 모델 이름만으로는 같은 구성이 아닙니다",
        "paragraphs": [
          "이 경로는 Qwen3.8-Flash-Next의 특정 NVFP4 체크포인트를 사용합니다. 모든 텐서가 일괄 4비트라는 뜻은 아닙니다. 어텐션과 MTP 등 더 높은 정밀도로 유지하는 부분이 있어 전체 파일과 실제 적재를 확인해야 합니다.",
          "단일 Spark의 통합 메모리 안에서 가중치를 CPU 쪽으로 옮기는 것만으로 물리 공간이 늘지는 않습니다. 큰 PLE 테이블을 NVMe 파일에 두고 필요한 부분을 조회하는 전용 mmap 패치가 핵심입니다. 기본 SGLang에 플래그만 추가한 경로와 구분하세요.",
          "실험 파일과 스크립트는 버전과 내용을 검토하고 정상 환경과 분리해 준비합니다. 다운로드·변환용 임시 공간도 필요합니다. 아래 실행 묶음의 약 140GB 이상 여유 안내를 참고하되 현재 배포 파일에 필요한 총공간을 다시 확인하세요."
        ]
      },
      {
        "title": "32K 기록을 재현하는 출발점",
        "paragraphs": [
          "해당 실행 기록의 32K 구성은 TP 1, 메모리 비율 0.85와 프리필 청크 4,096을 사용합니다. 프리필은 Triton, 디코드는 trtllm_mha 경로를 구분하며 MTP는 NEXTN 3단계·top-k 1·draft token 4개 조건입니다.",
          "커뮤니티 보고값은 코드 디코드 중앙값 약 41.5 tok/s, 일반 문장 약 22.8 tok/s로 구분됩니다. 사이트가 직접 측정한 보편 성능은 아닙니다. 프리필 약 1,910 tok/s 역시 입력과 캐시 조건을 확인해야 하며, 다른 질문에도 그대로 적용하는 약속으로 읽으면 안 됩니다.",
          "준비 스크립트와 검증을 통과한 뒤 실제 요청은 한 개씩 보내 기준을 남깁니다. 서버의 최대 요청 허용값과 측정 중 동시에 보낸 요청 수는 다릅니다. Docker 바깥의 포트가 127.0.0.1에만 게시됐는지도 확인하세요."
        ],
        "codeBlocks": [
          {
            "label": "단일 DGX Spark 32K 실행",
            "code": "git clone https://github.com/hashd1ve/qwen38-flash-next-one-dgx-spark.git\ncd qwen38-flash-next-one-dgx-spark\n\n./scripts/download.sh\n./scripts/prepare.sh\nsed -i.bak 's/-p \"$PORT\":30000/-p \"127.0.0.1:$PORT:30000\"/' scripts/serve.sh\nMEMFRAC=0.85 PREFILL=4096 CTX=32768 ./scripts/serve.sh\npython3 verify.py",
            "caption": "Docker와 약 140GB 이상의 NVMe 여유 공간이 필요합니다."
          },
          {
            "label": "실제로 속도를 바꾼 핵심 SGLang 옵션",
            "code": "# Docker 포트는 127.0.0.1:30000에만 게시\n--tp-size 1\n--prefill-attention-backend triton\n--decode-attention-backend trtllm_mha\n--quantization modelopt_fp4\n--ple-offload-embedding\n--mamba-radix-cache-strategy extra_buffer\n--mem-fraction-static 0.85\n--chunked-prefill-size 4096\n--max-running-requests 4\n--speculative-algorithm NEXTN\n--speculative-num-steps 3\n--speculative-eagle-topk 1\n--speculative-num-draft-tokens 4\n--speculative-draft-model-quantization unquant",
            "caption": "PLE mmap 패치가 없는 stock SGLang에 이 플래그만 복사하면 같은 메모리 배치가 되지 않습니다."
          }
        ]
      },
      {
        "title": "문맥 숫자 하나만 키우지 않습니다",
        "paragraphs": [
          "긴 문맥 경로에서는 메모리 비율을 0.79로 낮추고 프리필 청크를 1,024로 줄여 임시 공간을 남깁니다. 262,144 설정이 허용된다는 사실과 그 길이의 내 문서가 안정적으로 처리된다는 사실은 다릅니다.",
          "먼저 작은 입력에서 정상 동작을 확인한 뒤 8K·32K·128K처럼 단계적으로 늘립니다. 각 길이에서 정답을 아는 문장을 중간에도 넣어 실제로 찾는지 확인하세요. 다른 GPU 작업을 줄이고 요청 한 개 조건으로 메모리와 첫 토큰 시간을 함께 봅니다.",
          "청크를 줄여 메모리 정점을 낮추면 짧은 입력의 처리량은 낮아질 수 있습니다. 긴 문맥이 필요하지 않다면 가장 큰 설정을 유지할 이유는 없습니다. 평소 길이의 결과로 돌아와 어느 프로필을 남길지 결정하세요."
        ],
        "codeBlocks": [
          {
            "label": "단일 DGX Spark 262K 실행",
            "code": "# 서버 주소: http://127.0.0.1:30000\ncd qwen38-flash-next-one-dgx-spark\nMEMFRAC=0.79 PREFILL=1024 CTX=262144 ./scripts/serve.sh\npython3 verify.py",
            "caption": "프리필 청크를 줄이는 대신 짧은 입력의 처리량은 낮아질 수 있습니다."
          }
        ]
      },
      {
        "title": "남의 숫자보다 느릴 때 확인할 순서",
        "paragraphs": [
          "체크포인트와 패치·컨테이너 버전을 먼저 확인하고 PLE 파일이 실제 NVMe 경로에 있는지 봅니다. 그다음 로그에서 프리필·디코드 백엔드와 MTP 가중치의 정밀도가 의도대로 선택됐는지 확인합니다. 후보 단계부터 무작정 늘리지 마세요.",
          "첫 디스크 접근과 페이지 캐시가 남은 반복 접근도 구분해야 합니다. 준비 직후의 숫자와 평소 여러 앱을 켜둔 상태의 숫자는 다를 수 있습니다. MTP를 끈 값과 켠 값을 코드·일반 문장 각각 같은 조건으로 기록합니다.",
          "실행이 자주 실패하면 속도보다 안정적인 기준을 먼저 복구합니다. 포트가 외부에 열려 있다면 접근 범위를 제한하고, 공유 서버로 바꿀 때는 별도의 인증과 방화벽을 준비해야 합니다."
        ]
      },
      {
        "title": "이 레시피로 얻고 싶은 결과",
        "paragraphs": [
          "특수 패치로 큰 모델을 한 대에 올리는 것은 의미 있는 실험입니다. 하지만 설정을 재현했다는 성취와 매일 편하게 쓸 도구를 얻었다는 결과는 다를 수 있습니다. 필요한 문서와 코드를 실제로 끝까지 처리해보세요.",
          "이미 한 대의 안정적인 설정에서 원하는 일이 된다면 두 대를 살 이유는 줄어듭니다. 더 긴 문맥이나 여러 요청이 꼭 필요하다면 그 조건으로 두 대와 비교합니다. 기록의 최고 속도보다 내 환경에서 반복되는 결과를 구매 판단에 사용하세요."
        ]
      }
    ],
    "visuals": [],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/gemma-4-12b-serving-recipe",
    "slug": "gemma-4-12b-serving-recipe",
    "title": "Gemma 4 12B 로컬 서빙 가이드: LM Studio·vLLM 16GB 레시피",
    "description": "Gemma 4 12B 모델의 16GB~24GB 단일 GPU 및 Mac 데스크톱 서빙 방법, Q4 GGUF 및 공식 google/gemma-4-12B-it 가중치 설정, 8K 안전 컨텍스트와 API 검증을 안내합니다.",
    "headline": "Q4 데스크톱 경로와 공식 체크포인트 경로를 나눈 12B 로컬 서빙",
    "category": "recipe",
    "categoryLabel": "모델별 실행 레시피",
    "term": "Gemma 4 12B 서빙",
    "alternateName": "Gemma 4 12B Local Serving Recipe",
    "plainSummary": "Gemma 4 12B를 작은 장비에서 써보려면 모든 기능을 한꺼번에 켜기보다 텍스트 답변 하나부터 확인하는 편이 좋습니다. 그 답이 정상적으로 끝나는 설정을 남기고, 긴 문서와 이미지·음성을 차례로 더해보겠습니다. 어디서 메모리와 기다림이 늘어나는지 찾는 과정입니다.",
    "buyerNote": "16GB 장비는 Q4 텍스트 요청의 시작점입니다. 이미지·오디오 입력, 긴 문맥, 다른 앱의 메모리 사용까지 고려하면 24GB 이상에서 운영 여유가 커집니다. 공식 BF16 경로는 32GB 이상을 기준으로 봅니다.",
    "keyPoints": [
      "Q4 양자화(약 7.5GB)로 16GB 장비에서도 단독 풀 오프로드 서빙이 가능합니다.",
      "공식 Transformers/vLLM 모델 ID는 google/gemma-4-12B-it이며 텍스트 서빙이 기준선입니다.",
      "LM Studio CLI를 통해 127.0.0.1:1234 포트로 로컬 엔드포인트를 개방합니다."
    ],
    "sections": [
      {
        "title": "Q4 파일인지 공식 가중치인지 확인합니다",
        "paragraphs": [
          "데스크톱에서는 현재 앱이 지원하는 GGUF 또는 MLX Q4 변환본을 선택합니다. 16GB급 장비라도 운영체제와 캐시 여유에 따라 실행 범위가 달라집니다. 받을 파일의 실제 크기를 확인하고 짧은 문맥에서 시작하세요.",
          "공식 google/gemma-4-12B-it의 BF16 가중치는 약 24GB 규모입니다. 아래 vLLM 예시는 이를 담을 더 큰 NVIDIA 환경의 경로로, Q4 데스크톱 명령과 다릅니다. 같은 모델 이름 때문에 두 경로의 메모리 조건을 섞지 마세요.",
          "처음에는 이미지나 음성 대신 짧은 한국어 질문을 씁니다. 텍스트 기준값을 얻은 뒤 지원되는 입력을 추가해야 어떤 기능에서 부담이 커졌는지 구분할 수 있습니다."
        ]
      },
      {
        "title": "LM Studio와 공식 서버 중 한 경로를 고릅니다",
        "paragraphs": [
          "LM Studio에서는 목록에서 확인한 실제 모델 식별자를 넣고 8K 문맥 예시로 시작합니다. 부족하다면 더 줄여 정상 적재부터 확인하세요. --gpu=max는 요청한 설정이며 실제로 어떤 부분이 GPU에 올라갔는지는 앱의 표시와 로그로 확인합니다.",
          "LM Studio의 서버 주소는 여기서 1234 포트, vLLM 예시는 8000입니다. 다른 명령의 주소를 섞지 마세요. LM Studio의 네트워크 제공 설정에서도 로컬 접근 범위를 확인하고, 다른 기기에 공개할 경우 인증과 방화벽을 먼저 준비합니다.",
          "프로그램이 켜졌다는 것만으로 모델이 준비된 것은 아닙니다. 적재 완료와 실제 문맥 설정을 확인한 뒤 질문을 보냅니다. 대기 중에 여러 요청을 겹쳐 보내면 첫 실행의 메모리 상태를 이해하기 어려워집니다."
        ],
        "codeBlocks": [
          {
            "label": "LM Studio CLI 로컬 서빙 (데스크톱 16GB~24GB)",
            "code": "# 1. 모델 목록 확인\nlms ls\n\n# 2. GPU 최대 오프로드 및 8K 컨텍스트로 모델 로드\nlms load <gemma-4-12b-identifier> --gpu=max --context-length=8192\n\n# 3. 로컬 서버 데몬 구동 (127.0.0.1:1234)\nlms server start --port 1234",
            "caption": "모델 적재 완료 후 서버 주소와 로컬 네트워크 제공 설정을 확인합니다."
          },
          {
            "label": "공식 vLLM 텍스트 서빙 (NVIDIA GPU)",
            "code": "vllm serve google/gemma-4-12B-it   --host 127.0.0.1   --port 8000   --max-model-len 8192   --gpu-memory-utilization 0.90",
            "caption": "32GB 이상 NVIDIA 환경에서 공식 instruction 가중치를 127.0.0.1:8000으로 서빙합니다."
          }
        ]
      },
      {
        "title": "짧은 한국어 답변으로 처음 확인합니다",
        "paragraphs": [
          "아래 요청의 모델 이름을 실제 식별자로 바꿉니다. 문장이 중간에 멈추는지, 요청한 언어로 답하는지 먼저 확인하세요. 스트리밍을 요청하면 조각이 도착하는 모습도 볼 수 있지만 정확한 tok/s는 런타임 측정값을 따로 사용합니다.",
          "준비 실행 뒤 같은 질문 세 번의 첫 토큰·생성 속도·피크 메모리를 기록합니다. 이어서 평소 요약할 문서로 바꾸어 차이를 봅니다. 간단한 자기소개가 된다는 사실만으로 긴 업무 문서도 충분하다고 결론 내리지는 않습니다.",
          "생성 결과의 품질도 함께 보세요. 짧은 질문에는 잘 답해도 날짜나 예외 조건을 놓칠 수 있습니다. 정답을 확인할 수 있는 문서 질문을 하나 남기면 설정 변경 뒤 비교하기 좋습니다."
        ],
        "codeBlocks": [
          {
            "label": "OpenAI 호환 API 테스트",
            "code": "curl -N http://127.0.0.1:1234/v1/chat/completions   -H \"Content-Type: application/json\"   -d '{\n    \"model\": \"<gemma-4-12b-identifier>\",\n    \"messages\": [\n      {\"role\": \"user\", \"content\": \"한국어로 자기소개를 간단히 작성해줘.\"}\n    ],\n    \"max_tokens\": 512,\n    \"stream\": true\n  }'",
            "caption": "127.0.0.1:1234 포트로 로컬 API 호출을 검증합니다."
          }
        ]
      },
      {
        "title": "이미지와 오디오를 추가할 때",
        "paragraphs": [
          "현재 모델 파일과 앱이 지원하는 입력인지 먼저 확인합니다. 한 종류씩 추가하고 메모리가 얼마나 늘었는지 보세요. 텍스트만 쓸 때 남던 공간이 인코더와 입력 처리에 사용될 수 있습니다.",
          "작은 메모리에서 실패한다면 문맥과 동시 요청 수를 먼저 낮춥니다. 캐시 정밀도나 오프로드를 바꿀 때도 한 항목씩 비교하세요. 이미 Q4인 모델에 다시 Q4를 고르는 식으로는 다른 원인의 부족을 해결하지 못합니다.",
          "매일 필요한 입력에서만 문제가 반복된다면 더 큰 메모리를 검토할 이유가 있습니다. 반대로 텍스트 작업이 충분하다면 멀티모달 최대 조건을 위해 장비 전체를 키울 필요는 없을 수 있습니다."
        ]
      },
      {
        "title": "작은 모델을 계속 쓰는 것도 선택입니다",
        "paragraphs": [
          "12B가 평소 문서를 충분히 처리하고 기다림도 괜찮다면 더 큰 모델로 올라가지 않아도 됩니다. 부족한 질문이 생겼을 때 그 질문을 다음 모델에 그대로 보내 비교하는 편이 차이를 알기 쉽습니다.",
          "안정적으로 쓴 파일과 앱 버전, 입력 길이를 저장하세요. 다시 설치하거나 업데이트할 때 돌아갈 기준이 됩니다. 작은 장비에서 성공한 작업 하나가 생기면 다음에 필요한 성능도 더 구체적으로 말할 수 있습니다."
        ]
      }
    ],
    "visuals": [],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/gemma-4-26b-a4b-serving-recipe",
    "slug": "gemma-4-26b-a4b-serving-recipe",
    "title": "Gemma 4 26B-A4B 서빙 가이드: 24GB~32GB MoE 레시피",
    "description": "총 25.2B 파라미터(3.8B 활성)의 Gemma 4 26B-A4B를 24GB~32GB 장비에서 실행하는 Q4 변환 경로와 공식 google/gemma-4-26B-A4B-it 서버 경로를 구분해 설명합니다.",
    "headline": "총 25.2B 상주와 3.8B 활성 연산, 24GB~32GB 데스크톱 MoE 서빙",
    "category": "recipe",
    "categoryLabel": "모델별 실행 레시피",
    "term": "Gemma 4 26B-A4B 서빙",
    "alternateName": "Gemma 4 26B-A4B Local Serving Recipe",
    "plainSummary": "Gemma 4 26B-A4B의 활성 규모는 작지만 모델 전체는 메모리에 있어야 합니다. 24GB급 장비에서 기대보다 느리다면 계산 설정보다 먼저 어디에 가중치가 올라갔는지 봐야 합니다. Q4 적재부터 확인한 뒤 문맥과 생성 속도를 조정해보겠습니다.",
    "buyerNote": "활성 파라미터가 3.8B라고 해서 4GB GPU에 돌릴 수 있는 것은 아닙니다. 25.2B 전체 가중치와 KV 캐시를 담을 수 있는 24GB~32GB 이상의 메모리 환경이 필요합니다.",
    "keyPoints": [
      "총 25.2B 가중치 상주를 위해 Q4 기준 약 16GB 이상의 가용 메모리가 필요합니다.",
      "3.8B 활성 수치는 토큰당 계산량을 설명하며 품질이나 실제 속도를 보장하는 수치가 아닙니다.",
      "초기 8K 보수적 컨텍스트와 127.0.0.1 로컬 바인딩으로 안전하게 시작합니다."
    ],
    "sections": [
      {
        "title": "활성 숫자와 내려받을 파일을 나눕니다",
        "paragraphs": [
          "이 모델은 약 25.2B 전체 중 토큰당 약 3.8B가 활성화되는 MoE입니다. 활성 부분만 받아 실행하는 것이 아니므로 전체 변환본의 크기를 확인합니다. 24GB VRAM이나 큰 통합 메모리에서도 캐시와 앱 몫을 남겨야 합니다.",
          "공식 BF16 체크포인트와 Q4 데스크톱 경로는 다릅니다. 공식 google/gemma-4-26B-A4B-it 예시는 더 큰 메모리의 NVIDIA 서버용입니다. Q4로 들어간 장비에서 공식 모델 ID만 바꿔 같은 용량을 기대하지 마세요.",
          "MoE를 지원하는 앱이어도 새 모델 구조와 양자화의 지원은 별도입니다. 먼저 파일의 권장 런타임을 확인하고 모델을 정상적으로 불러오는 것부터 시작합니다."
        ]
      },
      {
        "title": "문맥 8K와 요청 한 개를 출발점으로",
        "paragraphs": [
          "LM Studio의 실제 식별자를 확인해 아래 예시를 맞춥니다. 8K에서도 공간이 부족하다면 길이를 낮춰 적재부터 확인합니다. 가장 큰 문맥을 켜야 모델의 성능을 모두 쓴다는 뜻은 아닙니다.",
          "LM Studio는 이 예시에서 1234, vLLM은 8000 포트를 사용합니다. 주소와 모델 이름을 같은 경로로 맞추세요. 로컬 전용 접근 설정을 확인하고 외부에 제공할 계획이면 인증과 네트워크 제한을 별도로 준비합니다.",
          "실제 GPU 점유와 CPU에 남은 부분을 확인합니다. 가중치가 일부 넘어갔다면 낮은 활성 계산량이 있어도 전송 때문에 생성이 느릴 수 있습니다. 이 상태를 정상 GPU 적재 결과와 같은 조건으로 비교하지 마세요."
        ],
        "codeBlocks": [
          {
            "label": "LM Studio CLI 로컬 서빙 (24GB~32GB 데스크톱)",
            "code": "# 1. 로컬 모델 식별자 확인\nlms ls\n\n# 2. 호환 변환본을 8K 문맥으로 로드\nlms load <gemma-26b-a4b-identifier> --gpu=max --context-length=8192\n\n# 3. 로컬 서버 시작\nlms server start --port 1234",
            "caption": "24GB GPU 또는 Mac 36GB+ 환경에서 127.0.0.1 로컬 데몬을 실행합니다."
          },
          {
            "label": "공식 vLLM MoE 서빙 (고용량 NVIDIA)",
            "code": "vllm serve google/gemma-4-26B-A4B-it   --host 127.0.0.1   --port 8000   --max-model-len 8192   --gpu-memory-utilization 0.90",
            "caption": "공식 instruction 체크포인트는 Q4 데스크톱 경로보다 많은 메모리가 필요합니다."
          }
        ]
      },
      {
        "title": "밀집 모델과 비교할 때도 작업을 맞춥니다",
        "paragraphs": [
          "짧은 질문이 정상적으로 끝나면 평소 문서를 넣어봅니다. 준비 실행 뒤 같은 입력 세 번의 중앙값을 기록하고, 첫 토큰 시간과 디코드를 따로 남기세요. 토큰 수와 양자화가 다른 결과를 장비 성능 차이로 읽지 않는 것이 중요합니다.",
          "Dense 모델보다 빠를 수는 있지만 항상 그렇지는 않습니다. MoE 커널과 메모리 접근, 캐시 조건의 영향을 받습니다. 평균 활성 수치 하나로 실제 속도를 역산하지 말고 런타임의 실행 결과를 사용하세요.",
          "빠른 답변에서 중요한 조건이 빠지지 않았는지도 봅니다. 반복해서 쓸 질문 몇 개의 정답 확인이 최고 tok/s 하나보다 모델 선택에 도움이 됩니다."
        ],
        "codeBlocks": [
          {
            "label": "OpenAI 호환 챗 완성 호출 테스트",
            "code": "curl -N http://127.0.0.1:1234/v1/chat/completions   -H \"Content-Type: application/json\"   -d '{\n    \"model\": \"<gemma-26b-a4b-identifier>\",\n    \"messages\": [\n      {\"role\": \"user\", \"content\": \"MoE 아키텍처의 장점을 짧게 정리해줘.\"}\n    ],\n    \"max_tokens\": 512,\n    \"stream\": true\n  }'",
            "caption": "127.0.0.1 로컬 엔드포인트의 응답 지연과 생성 속도를 측정합니다."
          }
        ]
      },
      {
        "title": "문맥을 늘리다가 느려졌다면",
        "paragraphs": [
          "모델 본체는 그대로라도 KV 캐시와 임시 공간이 늘어날 수 있습니다. 동시 요청을 한 개로 두고 8K에서 필요한 길이까지 단계적으로 올리세요. 갑자기 느려지면 스왑과 메모리 압박, CPU 오프로드 여부를 먼저 확인합니다.",
          "지원되는 캐시 압축을 시험하더라도 가중치 정밀도와 동시에 바꾸지 마세요. 어느 변경이 품질이나 속도에 영향을 줬는지 알아야 합니다. 문제가 생기면 직전에 정상적으로 동작한 길이로 돌아가 비교합니다.",
          "상위 메모리의 가치는 한 번 모델을 켜는 데서 끝나지 않습니다. 평소 긴 입력과 다른 앱을 함께 써도 공간이 남는지까지 확인할 때 내게 필요한 옵션인지 판단할 수 있습니다."
        ]
      },
      {
        "title": "26B를 고른 이유로 돌아갑니다",
        "paragraphs": [
          "12B보다 더 좋은 결과가 필요한 질문이 있었는지, 그 차이를 이 모델에서 실제로 얻었는지 봅니다. 차이가 없다면 작은 모델을 여유 있게 유지하는 것도 가능합니다. 크기가 커졌다는 사실만으로 불편한 대기를 받아들일 필요는 없습니다.",
          "원하는 결과와 속도를 찾았다면 파일·버전·문맥·캐시 설정을 저장하세요. 모델의 가능성을 확인하는 단계에서 매일 쓰는 도구로 넘어가기 위한 마지막 작업입니다."
        ]
      }
    ],
    "visuals": [],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/qwen-3.6-35b-a3b-serving-recipe",
    "slug": "qwen-3.6-35b-a3b-serving-recipe",
    "title": "Qwen3.6 35B-A3B 서빙 가이드: vLLM·qwen3 파서 레시피",
    "description": "총 35B(3B 활성) Qwen3.6 35B-A3B MoE 모델의 24GB/32GB+ 메모리 조건, vLLM >= 0.19.0 reasoning parser 설정, MTP 고급 옵션 및 127.0.0.1 로컬 서빙 레시피를 정리합니다.",
    "headline": "Q4 데스크톱 경로와 vLLM 0.19.0+ 공식 멀티 GPU 경로",
    "category": "recipe",
    "categoryLabel": "모델별 실행 레시피",
    "term": "Qwen3.6 35B-A3B 서빙",
    "alternateName": "Qwen3.6 35B-A3B Local Serving Recipe",
    "plainSummary": "Qwen3.6 35B-A3B는 활성 3B라는 설명 때문에 작은 모델처럼 보일 수 있습니다. 하지만 24GB 장비에서는 전체 Q4 가중치를 올린 뒤 여유가 크지 않을 수 있습니다. 메모리를 맞추고 생각 과정과 최종 답변을 구분한 뒤, 내 질문에서 빨라지는 설정을 찾아보겠습니다.",
    "buyerNote": "24GB GPU에서는 메모리 여유가 거의 없습니다. 안정적인 대화와 긴 문맥을 원한다면 32GB 이상 메모리(RTX 32GB+, Mac 48GB/64GB)를 권장합니다.",
    "keyPoints": [
      "총 35B 가중치 적재로 24GB 환경은 타이트하며 32GB 이상 메모리가 안정적입니다.",
      "토큰당 약 3B 활성 수치는 계산량을 설명하지만 실제 품질과 속도는 별도 검증이 필요합니다.",
      "공식 권장 vLLM 0.19.0+ 및 qwen3 추론 파서 옵션과 127.0.0.1 바인딩을 적용합니다."
    ],
    "sections": [
      {
        "title": "24GB에서는 파일을 올린 뒤가 중요합니다",
        "paragraphs": [
          "호환 Q4 변환본은 약 20GB 안팎의 안내를 출발점으로 삼되 실제 파일을 확인합니다. 모델 가중치와 4K~8K 문맥의 캐시, 실행 공간이 함께 들어가야 합니다. GPU에 로드됐다는 메시지만으로 긴 대화까지 보장되지는 않습니다.",
          "32GB 이상에서도 다른 앱과 캐시를 위한 여유를 확인해야 합니다. 공식 체크포인트는 Q4 변환본과 용량이 다릅니다. 아래 멀티 GPU 예시와 데스크톱 파일을 여는 명령은 서로 다른 경로입니다.",
          "받을 모델과 실행 앱의 지원을 먼저 맞추세요. 정상 동작하던 파일이 있다면 보관하고 새 경로를 시험해야 문제 발생 시 비교할 기준이 남습니다."
        ]
      },
      {
        "title": "서버 예시의 GPU 수는 구매 권장이 아닙니다",
        "paragraphs": [
          "공식 vLLM 예시의 병렬 수는 장착된 장비와 메모리·지원 조건에 맞아야 합니다. 주석에 있는 8을 어떤 GPU 여덟 장이면 된다는 뜻으로 읽지 마세요. 데스크톱 Q4를 실행하려는 목적이면 LM Studio나 위 장비 선택기의 경로를 사용합니다.",
          "vLLM에서는 해당 모델을 지원하는 버전과 qwen3 추론 파서를 확인합니다. 이 예시는 vLLM 0.19.0 이상 안내를 출발점으로 두지만, 현재 설치된 버전에서 지원되는지가 실제 실행 조건입니다. 서버는 먼저 로컬 주소에만 둡니다.",
          "MTP는 기준 답변이 정상적으로 나온 뒤 지원되는 조합에서 추가합니다. 여러 옵션을 한번에 복사한 최고 기록보다, 기본값과 바뀐 항목이 남은 기록이 내 환경에서 원인을 찾기 좋습니다."
        ],
        "codeBlocks": [
          {
            "label": "vLLM 0.19.0+ 공식 체크포인트 (멀티 GPU)",
            "code": "GPU_COUNT=8 # 공식 예시는 8 GPU, 실제 구성에 맞춰 수정\nvllm 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",
            "caption": "공식 체크포인트는 장착된 GPU 수에 맞춰 텐서 병렬 크기를 지정합니다."
          },
          {
            "label": "LM Studio 데스크톱 서빙 (Q4 GGUF)",
            "code": "lms ls\nlms load <qwen-3.6-35b-identifier> --gpu=max --context-length=8192\nlms server start --port 1234",
            "caption": "32GB 이상 Mac 또는 고용량 GPU에서 LM Studio로 간편하게 로컬 데몬을 시작합니다."
          }
        ]
      },
      {
        "title": "생각하는 시간과 답변 쓰는 시간을 구분합니다",
        "paragraphs": [
          "추론 파서는 생각 과정과 최종 결과를 앱이 구분하도록 돕습니다. 화면에 최종 문장이 늦게 보일 때 이미 생각 토큰을 생성하고 있는지 확인하세요. 이를 전부 프리필로 기록하면 입력 처리 성능을 잘못 읽게 됩니다.",
          "같은 질문의 입력 길이와 최대 출력, 생각 설정을 맞춰 비교합니다. 준비 실행 뒤 세 번의 중앙값과 실제 출력 토큰 수를 남깁니다. 답변 길이가 크게 다른 두 실행의 완료 시간만 비교하면 생성 속도를 분리하기 어렵습니다.",
          "아래 테스트는 vLLM의 8000 주소입니다. LM Studio를 사용했다면 1234와 로드한 모델 식별자로 맞춥니다. 주소가 다르면 모델이 느린 문제가 아니라 다른 서버에 질문한 문제일 수 있습니다."
        ],
        "codeBlocks": [
          {
            "label": "추론 챗 완성 API 호출 테스트",
            "code": "curl -N http://127.0.0.1:8000/v1/chat/completions   -H \"Content-Type: application/json\"   -d '{\n    \"model\": \"Qwen/Qwen3.6-35B-A3B\",\n    \"messages\": [\n      {\"role\": \"user\", \"content\": \"파이썬으로 이진 탐색 함수를 작성하고 시간 복잡도를 설명해줘.\"}\n    ],\n    \"max_tokens\": 1024,\n    \"stream\": true\n  }'",
            "caption": "127.0.0.1:8000 엔드포인트로 추론 결과 및 사고 토큰을 검증합니다."
          }
        ]
      },
      {
        "title": "긴 문맥과 가속을 하나씩 올립니다",
        "paragraphs": [
          "24GB에서 여유가 적다면 요청을 한 개로 고정하고 짧은 문맥을 유지해봅니다. 이후 필요한 입력 길이로 늘릴 때 캐시와 피크 메모리를 확인합니다. 속도가 갑자기 떨어지면 스왑이나 CPU로 넘어간 가중치가 있는지 먼저 봅니다.",
          "지원되는 MTP를 켜면 평균 승인 길이와 디코드가 실제로 개선됐는지 확인합니다. 코드 한 종류에서 잘 나온 배율을 일반 글쓰기에도 적용하지 마세요. 캐시 정밀도와 프리필 청크도 개별적으로 비교해야 합니다.",
          "긴 입력의 대기만 문제라면 디코드 가속보다 입력 처리와 캐시를 살펴볼 이유가 있습니다. 어떤 구간이 느린지 적어두면 설정을 더 넣지 않고도 다음 실험을 좁힐 수 있습니다."
        ]
      },
      {
        "title": "실행이 됐으면 평소 할 일을 끝내봅니다",
        "paragraphs": [
          "테스트용 이진 탐색 코드만으로 충분히 검증됐다고 보지는 마세요. 실제 수정하려던 코드나 문서를 넣고 결과를 확인합니다. 원하는 답이 나오는지와 기다릴 만한지가 모두 맞아야 사용할 설정이 됩니다.",
          "그 상태의 모델 파일과 런타임, 문맥과 가속을 저장하세요. 더 큰 장비를 검토할 때도 이 조건이 비교 기준입니다. 이미 충분하다면 새 GPU 대신 현재 구성을 계속 쓰는 것도 이 레시피가 줄 수 있는 결과입니다."
        ]
      }
    ],
    "visuals": [],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/glm-5.3-flash-serving-recipe",
    "slug": "glm-5.3-flash-serving-recipe",
    "title": "GLM-5.3-Flash 서빙 가이드: 320B 서버급 MoE 레시피",
    "description": "총 320B(18B 활성) GLM-5.3-Flash 공식 체크포인트를 여러 가속기에서 서빙하는 vLLM·SGLang 설정과, 압축 변환본을 검토할 때의 메모리 조건을 구분합니다.",
    "headline": "총 320B 상주와 18B 활성 연산, 공식 체크포인트의 멀티 가속기 서빙",
    "category": "recipe",
    "categoryLabel": "모델별 실행 레시피",
    "term": "GLM-5.3-Flash 서빙",
    "alternateName": "GLM-5.3-Flash Local Serving Recipe",
    "plainSummary": "GLM-5.3-Flash의 활성 18B를 보고 단일 GPU 레시피를 찾았다면, 먼저 전체 320B 가중치를 어디에 둘지 확인해야 합니다. 이 글의 공식 서버 경로는 여러 가속기용입니다. 대용량 맥의 압축본 실험과 섞지 않고, 적재·분산·응답을 순서대로 확인합니다.",
    "buyerNote": "데스크톱 단일 GPU용 모델이 아닙니다. 256GB 통합 메모리도 공식 체크포인트 경로와 같은 뜻이 아니므로, 변환본 포맷·파일 크기·런타임 지원이 확인되기 전에는 적합 장비로 확정하지 않습니다.",
    "keyPoints": [
      "공식 체크포인트 서빙은 여러 고용량 가속기와 빠른 가속기 간 연결을 전제로 합니다.",
      "18B 활성 파라미터는 디코드 계산량이며 모델 적재 메모리 용량과는 무관합니다.",
      "공식 모델 ID(zai-org/GLM-5.3-Flash)와 vLLM/SGLang 텐서 병렬 구성을 사용합니다."
    ],
    "sections": [
      {
        "title": "공식 가중치와 압축본을 구분합니다",
        "paragraphs": [
          "zai-org/GLM-5.3-Flash의 공식 체크포인트를 SGLang이나 vLLM으로 실행하는 경로는 대형 모델을 담을 서버 환경이 전제입니다. 활성 규모는 토큰당 계산에 관한 숫자이며 전체 파일이 18B 모델처럼 작아지는 것은 아닙니다.",
          "커뮤니티 양자화 파일을 대용량 통합 메모리에 올리는 것은 별도의 경로입니다. 크기가 들어맞더라도 앱이 모델 구조를 지원하고 실제로 답변하는지 확인해야 합니다. 공식 서버 명령을 그대로 맥의 실행법으로 바꾸어 읽지 마세요.",
          "장비 선택기에 지원되지 않는 조합으로 표시되면 추정 메모리만 보고 명령을 강제로 실행하지 않습니다. 해당 경로의 재현 기록을 먼저 확보해야 합니다."
        ]
      },
      {
        "title": "가속기 수와 시작 문맥을 맞춥니다",
        "paragraphs": [
          "아래 GPU_COUNT는 실제 구성과 런타임의 병렬 지원에 맞춰야 합니다. 개수만 맞고 카드별 용량이 부족하면 적재되지 않습니다. 카드 사이 실제 연결과 통신 경로도 확인합니다.",
          "큰 네이티브 문맥을 바로 켜기보다 16K 예시처럼 낮춘 조건에서 적재를 확인합니다. 그 길이도 보편적으로 안전하다는 보장은 없으므로 가중치와 작업 공간의 합을 먼저 계산해야 합니다. 메모리 제한을 무작정 끝까지 올리는 것은 피하세요.",
          "서버는 먼저 127.0.0.1에만 둡니다. 조직 내 공유를 계획한다면 인증·접근 제한과 로그 처리 방침을 별도로 마련해야 합니다. 로컬 실행이라는 이유만으로 다른 사람의 접근까지 자동으로 제한되지는 않습니다."
        ],
        "codeBlocks": [
          {
            "label": "SGLang 분산 서빙 실행 (Multi-GPU 서버 노드)",
            "code": "GPU_COUNT=8 # 실제 물리 GPU 수로 수정\npython -m sglang.launch_server   --model-path zai-org/GLM-5.3-Flash   --tp \"$GPU_COUNT\"   --host 127.0.0.1   --port 8000   --context-length 16384",
            "caption": "SGLang을 이용해 127.0.0.1:8000 포트로 320B 분산 서빙을 시작합니다."
          },
          {
            "label": "공식 vLLM 분산 서빙 대안",
            "code": "GPU_COUNT=8 # 실제 물리 GPU 수로 수정\nvllm serve zai-org/GLM-5.3-Flash   --tensor-parallel-size \"$GPU_COUNT\"   --host 127.0.0.1   --port 8000   --max-model-len 16384   --gpu-memory-utilization 0.90",
            "caption": "vLLM 분산 서빙 시 127.0.0.1 로컬 격리 바인딩을 적용합니다."
          }
        ]
      },
      {
        "title": "모든 가속기가 맡은 일을 하는지 봅니다",
        "paragraphs": [
          "서버가 준비되면 짧은 질문으로 답변 완료와 스트리밍을 확인합니다. 각 GPU의 메모리와 실행 로그를 함께 보고 한쪽만 부족하거나 통신이 지연되는지 살펴보세요. 전체 평균만 보면 특정 노드의 문제를 놓칠 수 있습니다.",
          "준비 실행 뒤 같은 입력 세 번의 중앙값을 남기고 첫 토큰·디코드·피크 메모리를 구분합니다. 긴 문맥을 처리하는 구조라고 해서 어느 길이에서도 속도가 일정한 것은 아닙니다. 필요한 길이별로 결과를 따로 재야 합니다.",
          "여러 사용자를 받는다면 단일 요청 확인 뒤 동시 요청을 늘립니다. 총 처리량이 좋아져도 개별 요청의 대기가 길어지는지 따로 봅니다. 한 사람의 최고 속도와 서버 전체 성능은 다른 기록입니다."
        ],
        "codeBlocks": [
          {
            "label": "API 챗 완료 테스트",
            "code": "curl -N http://127.0.0.1:8000/v1/chat/completions   -H \"Content-Type: application/json\"   -d '{\n    \"model\": \"zai-org/GLM-5.3-Flash\",\n    \"messages\": [\n      {\"role\": \"user\", \"content\": \"대규모 분산 추론 환경의 이점을 정리해줘.\"}\n    ],\n    \"max_tokens\": 512,\n    \"stream\": true\n  }'",
            "caption": "127.0.0.1:8000 엔드포인트 응답을 테스트합니다."
          }
        ]
      },
      {
        "title": "적재 실패와 긴 문맥 실패를 나눕니다",
        "paragraphs": [
          "시작부터 가중치가 들어가지 않는다면 문맥을 조금 낮추는 것만으로 해결되지 않을 수 있습니다. 파일의 정밀도와 분할 경로, 카드별 메모리를 먼저 확인합니다. 기본 적재 뒤 긴 입력에서만 실패하면 캐시와 프리필 임시 공간을 살펴봅니다.",
          "16K에서 더 긴 입력으로 늘릴 때는 중간에 정답을 아는 정보를 넣어 실제로 찾아내는지 확인합니다. 요청이 끝났다는 사실과 필요한 내용을 활용했다는 사실은 다릅니다. 메모리와 함께 결과의 정확도도 기록하세요.",
          "설정을 바꿔 실패했다면 직전 정상 구성을 복구하고 한 항목씩 비교합니다. 여러 가속기의 환경을 동시에 바꾸는 것보다 원인 한 개를 찾는 편이 재현 가능한 개선에 가깝습니다."
        ]
      },
      {
        "title": "이 크기가 필요한 이유를 남깁니다",
        "paragraphs": [
          "대형 모델의 운영은 장비 구매 뒤에도 버전과 분산 상태를 관리하는 일이 남습니다. 작은 모델에서 부족했던 구체적인 작업을 이 모델로 해결하는지 확인해야 그 비용을 설명할 수 있습니다.",
          "한 사람의 문서·코딩 도구를 시작하는 목적이라면 더 작은 모델이 충분할 수 있습니다. 반대로 팀의 특정 작업에서 결과 차이가 뚜렷하다면 그 작업을 검증 기준으로 삼으세요. 서버를 켜는 데 성공한 다음에는 실제 업무 하나를 끝내보는 단계가 필요합니다."
        ]
      }
    ],
    "visuals": [],
    "updatedAt": "2026-09-06"
  },
  {
    "url": "https://localai.co.kr/guides/deepseek-v4-flash-serving-recipe",
    "slug": "deepseek-v4-flash-serving-recipe",
    "title": "DeepSeek-V4-Flash 서빙 가이드: 304B 분산 레시피",
    "description": "총 304B(13B 활성) DeepSeek-V4-Flash-0731의 공식 4×GB300 vLLM 경로와 SGLang 경로, 16K 시작 문맥 및 로컬 API 확인 절차를 정리합니다.",
    "headline": "총 304B 상주와 13B 활성 연산, 4×GB300급 공식 분산 서빙",
    "category": "recipe",
    "categoryLabel": "모델별 실행 레시피",
    "term": "DeepSeek-V4-Flash 서빙",
    "alternateName": "DeepSeek-V4-Flash-0731 Local Serving Recipe",
    "plainSummary": "DeepSeek-V4-Flash를 직접 운영하려고 공식 예시를 열면 4×GB300 같은 서버 구성이 나옵니다. GPU 네 장이라는 숫자만 복사하면 같은 조건이 되는 것은 아닙니다. 이 레시피는 공식 서버 경로의 전제를 유지하면서 무엇부터 확인해야 하는지 설명합니다.",
    "buyerNote": "공식 체크포인트는 소비자용 GPU나 256GB 통합 메모리를 전제로 하지 않습니다. 커뮤니티 압축본은 실험 경로로만 보고 파일 크기, 변환 방식, 런타임 지원을 각각 확인합니다.",
    "keyPoints": [
      "총 304B 공식 체크포인트의 vLLM 예시는 4×GB300 노드와 전문가 병렬을 사용합니다.",
      "공식 모델 ID(deepseek-ai/DeepSeek-V4-Flash-0731)와 멀티 가속기 분산 병렬을 사용합니다.",
      "단일 소비자 GPU 레시피가 아니며 127.0.0.1 로컬 바인딩을 전제로 합니다."
    ],
    "sections": [
      {
        "title": "13B 활성과 304B 전체를 구분합니다",
        "paragraphs": [
          "이 모델의 활성 규모는 한 토큰에서 사용하는 경로를 설명합니다. 전체 가중치를 소비자 GPU 한 장에 넣을 수 있다는 뜻이 아닙니다. 공식 deepseek-ai/DeepSeek-V4-Flash-0731과 커뮤니티 압축본의 파일·런타임 조건도 다릅니다.",
          "공식 vLLM 예시는 단일 4×GB300 노드와 전문가 병렬을 사용합니다. 임의의 GPU 네 장으로 교체한 뒤 같은 명령을 쓰는 경로가 아닙니다. 메모리뿐 아니라 커널과 연결 조건을 확인해야 합니다.",
          "큰 통합 메모리에 압축본을 담는 실험은 이 공식 레시피와 분리해 검토하세요. 적재 예상치만으로 해당 모델 구조의 실행 지원까지 보장되지는 않습니다."
        ]
      },
      {
        "title": "공식 경로에서도 작은 문맥부터 시작합니다",
        "paragraphs": [
          "아래 예시는 데이터 병렬 4와 전문가 병렬, DSpark 구성을 포함합니다. 옵션 이름을 하나씩 다른 엔진으로 옮기는 명령이 아니라 지원되는 서버 환경의 묶음입니다. 초기 문맥은 16K로 제한해 기본 적재와 답변부터 확인합니다.",
          "명령의 원격 코드 실행 옵션은 모델 저장소의 코드를 실행할 수 있으므로 사용할 버전과 내용을 확인해야 합니다. 정상 환경을 보존하고 재현 가능한 버전을 남겨두세요. 최신 파일을 받았다는 것만으로 기존 환경과 같지 않을 수 있습니다.",
          "서버 주소는 127.0.0.1을 유지합니다. 외부나 조직 네트워크에 열 계획이라면 인증과 프록시·방화벽을 별도로 구성해야 합니다. 기본 로컬 실행 예시는 공유 서버의 보안 구성을 대신하지 않습니다."
        ],
        "codeBlocks": [
          {
            "label": "vLLM 공식 분산 서빙 (Multi-GPU 서버 노드)",
            "code": "vllm serve deepseek-ai/DeepSeek-V4-Flash-0731   --host 127.0.0.1   --port 8000   --trust-remote-code   --data-parallel-size 4   --enable-expert-parallel   --kv-cache-dtype fp8   --block-size 256   --moe-backend deep_gemm_mega_moe   --attention-config '{\"use_fp4_indexer_cache\": true}'   --speculative-config '{\"method\":\"dspark\",\"num_speculative_tokens\":7,\"draft_sample_method\":\"greedy\"}'   --max-model-len 16384   --gpu-memory-utilization 0.90",
            "caption": "공식 4×GB300 vLLM·DSpark 구성을 16K 문맥과 127.0.0.1 바인딩으로 시작합니다."
          }
        ]
      },
      {
        "title": "답변 조각과 실제 생성량을 확인합니다",
        "paragraphs": [
          "짧은 요청을 보내 조각이 도착하고 마지막에 응답이 정상 종료되는지 확인합니다. 준비 실행 뒤 같은 입력 세 번의 첫 토큰 시간과 디코드를 기록하고 실제 출력 길이도 함께 남깁니다. 화면에서 잠깐 빠르게 보인 구간만 측정값으로 쓰지 마세요.",
          "DSpark의 후보 수락과 실제 시간도 함께 확인합니다. 많은 후보를 제안했다는 숫자보다 검증을 통과한 길이와 전체 완료 시간이 중요합니다. 다른 질문에서는 효과가 달라질 수 있으므로 실제로 운영할 요청을 포함해야 합니다.",
          "여러 요청을 동시에 처리할 계획이라면 단일 요청 기준 뒤에 별도 부하 테스트를 합니다. 총 tok/s와 각 사용자의 대기는 분리해 기록해야 서버 운영 목적에 맞는 설정을 고를 수 있습니다."
        ],
        "codeBlocks": [
          {
            "label": "로컬 챗 완성 스트리밍 테스트",
            "code": "curl -N http://127.0.0.1:8000/v1/chat/completions   -H \"Content-Type: application/json\"   -d '{\n    \"model\": \"deepseek-ai/DeepSeek-V4-Flash-0731\",\n    \"messages\": [\n      {\"role\": \"user\", \"content\": \"DeepSeek-V4-Flash 분산 서빙 테스트.\"}\n    ],\n    \"max_tokens\": 512,\n    \"stream\": true\n  }'",
            "caption": "127.0.0.1:8000 엔드포인트의 스트리밍 응답을 점검합니다."
          }
        ]
      },
      {
        "title": "메모리 합계만 보지 않습니다",
        "paragraphs": [
          "가속기별 가중치와 캐시, 전문가 부하가 의도대로 배치됐는지 확인합니다. 전체에 공간이 남아도 한쪽이 부족하면 실행이 실패할 수 있습니다. 연결 문제나 특정 가속기의 대기가 전체 결과에 영향을 줄 수도 있습니다.",
          "긴 문맥은 단계적으로 늘립니다. 모델의 최대 지원 길이가 실제 서버에서 바로 쓸 설정은 아닙니다. 피크 메모리와 첫 토큰 시간을 재고 문서 중간의 정보를 정확하게 찾는지도 확인합니다.",
          "설정을 바꾼 뒤 문제가 생기면 기본 길이와 정상 버전으로 돌아가 원인을 분리하세요. 새로운 가속 설정을 더하는 것이 적재나 분산 오류의 해결책이 되는 것은 아닙니다."
        ]
      },
      {
        "title": "직접 운영해서 얻을 결과가 있어야 합니다",
        "paragraphs": [
          "이 규모에서는 모델을 실행하는 것 외에 관리와 복구, 전력과 공간도 함께 고려합니다. 어떤 업무에서 작은 모델보다 나은 결과를 얻을지, 여러 사용자를 얼마나 처리해야 할지 정해야 장비의 이유가 분명해집니다.",
          "개인용 컴퓨터에서 로컬 AI를 시작하려는 사람에게 이 구성이 최소 사양은 아닙니다. 작은 모델로 할 일을 먼저 끝낼 수 있습니다. 큰 서버가 필요해졌다면 그때의 구체적인 실패 사례와 요청량을 이 레시피의 검증 기준으로 가져오세요."
        ]
      }
    ],
    "visuals": [],
    "updatedAt": "2026-09-06"
  }
]