llama.cpp MoE CPU 오프로딩, GPU 전송의 조정 가능한 대안 추가
llama.cpp는 11월 7일 풀 리퀘스트 #30966을 병합해, 선택된 전문가 캐시 미스를 항상 해당 전문가를 전송하는 방식 대신 CPU에서 실행할 수 있도록 했다. am17an이 기여한 llama.cpp MoE CPU 오프로딩 업데이트에는 개별 머신에서 균형을 조정하는 스크립트도 포함된다. 이 변경의 중요성은 속도 향상이 보장된다는 데 있지 않고, 선택지를 제공한다는 데 있다.
MoE는 mixture of experts의 약자로, 생성된 텍스트의 단위인 각 토큰마다 선택된 신경망 구성 요소를 활성화하는 모델을 뜻한다. 이러한 구성 요소를 전문가라고 부른다. 자주 사용되는 전문가를 GPU 메모리에 유지하면 도움이 되지만, 누락된 전문가는 여전히 어딘가에서 처리해야 한다. 새 옵션은 그 작업이 수행되는 위치를 바꾼다.
핵심 경쟁 구도는 CPU 연산과 GPU 실행을 위한 전문가 가중치, 즉 모델이 사용하는 저장된 수치값의 전송 사이에 있다. Strata는 문서에서 이미 이 균형을 조정하는 방법을 설명하고 있어 유용한 비교 대상이다. 그래픽 메모리 용량을 넘어서는 모델을 실행하는 사람들에게 실질적인 질문은 실제 환경에서 어느 경로가 더 빨리 끝나는가이다.
llama.cpp MoE CPU 오프로딩의 변화
이번 업데이트는 캐시 미스를 연산과 데이터 이동 중 하나를 선택하는 스케줄링 결정으로 만든다.
캐시는 필요한 프로세서 가까이에 재사용 가능한 데이터를 보관한다. 요청된 데이터가 없을 때 캐시 미스가 발생한다. 여기서 누락된 데이터는 모델 응답을 생성하는 과정인 추론 중 필요한 전문가에 속한다.
새 동작은 해당 전문가의 필요성을 없애지 않는다. 대신 그 연산을 완료하는 또 다른 방법을 만든다. 전송을 피하는 것과 모델 작업을 건너뛰는 것은 근본적으로 다른 주장이라는 점에서 이 구분은 중요하다.
병합된 CPU 대체 경로에는 이러한 절충을 보여 주는 작성자 제공 예시가 포함돼 있다. 6,464 MiB 캐시에서는 CPU 비중이 0에서 0.95로 바뀌면서 생성 속도가 초당 24.2토큰에서 47.6토큰으로 상승했다. 19,392 MiB 캐시에서는 같은 설정이 각각 초당 65.5토큰과 54.1토큰을 기록했다.
MiB는 메비바이트를 뜻하는 이진 메모리 용량 단위다. 이 결과는 다른 머신에서 독립적으로 재현된 결과가 아니라 작성자 예시에 보고된 측정값이다. 이는 실행 방식 변경과 함께 조정 기능에도 주목할 만한 이유를 보여 준다.
작은 캐시 결과만 본 독자는 상당한 개선을 확인할 것이다. 큰 캐시 비교만 본 독자는 성능 저하를 확인할 것이다. 이 설정은 나머지 구성과 상호작용하므로, 두 관찰 모두 이 이야기의 일부다.
유용한 결론은 “CPU 오프로딩이 더 빠르다”보다 좁다. 리소스 배분이 달라지면 어느 실행 경로가 더 나은지도 달라질 수 있다. 제약된 구성에 도움이 되는 설정이 GPU 가까이에 더 많은 전문가 데이터를 유지할 때는 오히려 역효과를 낼 수 있다.
이는 애호가들이 최적화 주장을 해석하는 방식도 바꾼다. 인상적인 결과는 유망한 메커니즘을 보여 줄 수 있지만, 모두에게 적용할 기본값을 확립하지는 않는다. 개선이 어디에서 나타나고 어디에서 사라지는지 설명할 때 근거는 더 유용해진다.
소프트웨어 인터페이스에 요구되는 책임도 달라진다. 엔진이 최적값이 머신에 따라 달라지는 선택지를 제공한다면, 사용자는 이를 고르는 데 도움을 받아야 한다. 그렇지 않으면 유연성을 추가하는 것이 잘못된 설정을 선택할 기회를 하나 더 만드는 결과가 될 수 있다.
애플리케이션 개발자에게 이 변화는 또 하나의 배포 변수로 이해해야 한다. llama.cpp를 사용하는 애플리케이션에 보편적인 성능 수준을 보장하지는 않는다. 애플리케이션은 자체 요청 패턴에서 계속 평가해야 한다.
이 병합의 즉각적인 의미는 주요 프로젝트에 추가 실행 경로가 생겼다는 것이다. 특정 설치 환경에서 성능을 향상하는지는 여전히 실증적으로 확인해야 할 문제다.
제한된 VRAM에서는 전송 시간이 성능 예산의 일부가 된다
가장 큰 영향을 받는 사용자는 모델을 그래픽 메모리와 시스템 메모리에 걸쳐 배치하는 사람들이다.
VRAM은 그래픽 프로세서에 연결된 메모리다. 시스템 RAM은 컴퓨터의 주 작업 메모리다. 설치 환경이 둘 다에 의존할 경우 성능 논의는 이들의 관계를 고려해야 한다.
모델을 불러올 수 있는지는 시작점일 뿐이다. 독자들은 답변이 얼마나 빨리 시작되는지, 얼마나 안정적으로 도착하는지, 컴퓨터가 계속 사용 가능한지도 궁금해한다. 용량 수치만으로는 이런 질문에 답할 수 없다.
로컬 코딩 어시스턴트를 평가하는 개발자를 생각해 보자. 어시스턴트는 요청을 읽고, 응답을 생성하며, 이후의 편집을 처리해야 한다. 중단 없는 생성 중 측정된 결과는 그 경험의 일부만 설명한다.
이는 보고된 벤치마크가 아니라 예시 배포 시나리오다. 목적은 새 옵션이 부각하는 결정을 식별하는 데 있다. 관련 질문은 전문가 실행 방식을 바꾸는 것이 개발자의 전체 상호작용을 개선하는가이다.
문서 분석에도 비슷한 구분이 적용된다. 사용자는 상당한 분량의 원본 자료를 제출한 뒤 여러 짧은 후속 질문을 할 수 있다. 가장 유용한 구성은 다른 테스트에서 속도만 극대화하기보다 이런 패턴을 지원해야 한다.
디코드는 모델이 출력을 점진적으로 생성하는 단계를 뜻한다. 프리필은 입력 프롬프트를 처리하는 단계를 뜻한다. 한 단계의 개선이 다른 단계의 개선을 보장하지 않으므로, 이 단계들은 별도로 측정할 필요가 있다.
하드웨어를 비교하는 구매자에게 이는 그래픽 메모리 용량을 완전한 성능 예측으로 취급하지 말아야 한다는 근거가 된다. 용량은 여전히 중요하지만, 그 용량 안에서 동작하는 소프트웨어의 행태도 중요하다. 전체 구성을 면밀히 검토해야 한다.
로컬 AI 서비스를 유지하는 사람들에게는 압박이 더 직접적이다. 배포하는 설정에 대해 방어 가능한 설명이 필요하다. 더 빨라 보이는 시스템의 명령어를 복사하는 것만으로 해당 명령어가 자신의 환경에 적합하다는 사실이 입증되지는 않는다.
따라서 실질적인 평가는 선호하는 매개변수가 아니라 워크로드에서 시작해야 한다. 코딩 세션, 문서 대화 또는 반복되는 서비스 요청은 테스트에 목적을 부여한다. 그러면 성능은 그 목적이 충족되는 정도를 측정하는 기준이 된다.
개인 실험과 공동 배포 사이에도 차이가 있다. 애호가는 가끔 재조정하는 일을 소프트웨어 사용의 일부로 받아들일 수 있다. 팀에는 동료가 재현할 수 있고 결과가 바뀔 때 조사할 수 있는 설정이 필요하다.
이 때문에 구성 기록은 가치가 있다. 검색 가능한 지식 기반을 구축하는 팀은 배포 노트와 함께 테스트 조건을 보존할 수 있다. 기록은 맥락 없는 명령어를 저장하기보다 워크로드와 결과를 설명해야 한다.
더 넓은 의미는 간단하다. 소프트웨어는 기존 하드웨어를 활용하는 더 많은 방식을 제공할 수 있지만, 그러한 선택에는 근거가 필요하다. 더 많은 사용 가능한 제어 항목이 자동으로 더 나은 배포로 이어지지는 않는다.
전문가를 옮기기보다 미스를 계산하는 편이 나을 수 있는 이유
관련 비교 대상은 각 완전한 실행 경로에 필요한 시간이다.
프로젝트의 전문가 캐시 동작에 따르면 캐시된 전문가는 디바이스에서 실행된다. 캐시가 가득 차면 --moe-cache-cpu-share가 CPU 연산에 사용할 미스의 비율을 선택한다. 다른 미스는 디바이스로 전송되며, 초기 미스는 여전히 캐시를 채우기 위해 업로드된다.
문서는 빠른 시스템 메모리와 느린 전송을 포함해 CPU 작업에 유리한 조건을 설명한다. 또한 디바이스 전송에 사용할 수 있도록 유지되는 호스트 메모리인 고정 메모리가 이점을 줄일 수 있다고 경고한다. 명시된 최적값은 머신, 모델, 캐시 크기에 따라 달라진다.
이 설명은 특정한 해석을 뒷받침한다. 이 기능은 연산 비용뿐 아니라 데이터에 도달하는 비용도 다룬다. 프로세서를 산술 능력만으로 판단하면 실행 경로의 일부를 빠뜨리게 된다.
비유하자면 대용량 파일을 어디에서 처리할지 결정하는 일과 같다. 더 빠른 머신으로 보내면 연산이 완료되기 전에 전송이 추가된다. 그것이 가치 있는지는 대상 장비의 속도만이 아니라 전체 작업에 달려 있다.
이 비유에는 한계가 있지만 결정을 명확히 해 준다. 더 빠른 대상이라고 해서 그곳에 도달하는 데 시간이 걸릴 때 더 이른 결과를 보장하지는 않는다. 반대로 이동을 피한다고 해서 로컬 처리가 더 오래 걸리는 경우 성공을 보장하지도 않는다.
캐시는 모든 작업이 동일하게 아니라 누락된 데이터를 대상으로 결정을 내리기 때문에 또 다른 차원을 더한다. 재사용 행태가 다른 구성은 캐시 밖에 남는 작업을 바꾼다. 이 때문에 CPU 비율 수치에는 주변 맥락이 필요하다.
이것이 캐시 히트율, 즉 캐시된 데이터로 처리된 요청의 비율이 불완전한 목표인 이유이기도 하다. 더 높은 비율은 바람직하게 들린다. 하지만 궁극적으로 사용자에게 중요한 것은 응답에 걸리는 시간이다.
최적화 지표는 사용자 대면 결과를 대체하기보다 설명해야 한다. 구성이 중간 측정값을 개선하면서 응답을 더 느리게 만든다면, 그 중간 측정값은 변경을 정당화하지 못한다. 같은 논리는 반대 방향에도 적용된다.
여기서의 상대는 여전히 데이터 이동과 CPU 실행이다. 이를 CPU가 일반적으로 GPU보다 우수하다는 주장으로 바꿀 필요는 없다. 이번 업데이트는 더 큰 추론 과정 내부의 특정 배분 결정을 다룬다.
이러한 틀은 이 이야기를 모델 지능의 변화와도 분리한다. 실행 위치를 선택하는 것은 더 나은 추론, 더 강한 코딩 능력 또는 더 정확한 답변의 증거가 아니다. 그러한 결과에는 다른 평가가 필요하다.
따라서 낮은 VRAM 사용자를 위한 llama.cpp MoE CPU 오프로딩의 매력은 조건부이면서도 구체적이다. 누락된 전문가 작업을 처리할 또 다른 방법을 제공한다. 이 옵션이 유용한지는 결과 응답 시간이 결정한다.
분석적 교훈은 이 패치를 넘어선다. 작업을 완료하는 전체 경로를 측정하라. 구성 요소 사양은 기대치를 알려 줄 수 있지만, 배포된 시스템을 관찰하는 일을 대체할 수는 없다.
조정 스크립트는 구성을 측정된 결정으로 만든다
이 스크립트는 실행 옵션을 권고안으로 바꾸면서도 측정 성능과 예측 성능을 구분한다.
함께 제공된 캐시 조정 스크립트는 반복적인 서버 실행을 통해 캐시 크기와 CPU 비율을 평가한다. 머신의 동작을 모델링하고 추가 조합을 예측한다. 선택 규칙은 가장 빠른 모델링 결과의 5% 이내에서 가장 낮은 CPU 비율을 우선한다.
코드에는 타이밍 모델이 관측값과 얼마나 잘 일치하는지 확인하는 검사도 포함돼 있다. 불일치가 임계값을 초과하면 일반적인 권고안을 제시하는 대신 진단 메시지와 함께 종료한다. 이는 도구의 신뢰도에 유용한 경계를 설정한다.
관측과 예측의 차이는 강조할 가치가 있다. 측정 결과는 실행 중 실제로 일어난 일을 설명한다. 예측은 관측값에 맞춘 가정을 사용해 측정하지 않은 결과를 추정한다.
어느 범주도 배포에 본질적으로 충분하지는 않다. 측정값은 대표성이 없는 작업을 설명할 수 있다. 예측값은 이를 구축하는 데 사용된 조건 밖의 동작을 놓칠 수 있다. 유용한 평가는 둘 다를 사람들이 실제로 사용하려는 애플리케이션과 연결한다.
스크립트의 가치는 구조화된 출발점을 제공한다는 데 있습니다. 사용자는 임의의 설정 조합을 구성하는 대신 권장 사항을 검토할 수 있습니다. 이는 결과를 보편화하지 않으면서도 추측에 의존하는 일을 줄여 줍니다.
또한 성능 논의의 틀을 더 명확하게 만듭니다. 모든 사람이 어떤 CPU 비중을 사용해야 하는지 묻는 대신, 사용자는 권장 사항이 자신의 워크로드에 맞는지 물을 수 있습니다. 후자의 질문은 검토하기가 더 쉽고, 답을 얻었을 때 더 많은 정보를 제공합니다.
Strata는 관련 경쟁 맥락을 제공합니다. 하드웨어 보정 제어 기능에는 전문가 전송 비율과 CPU 워커 조정이 포함됩니다. 해당 문서는 사용자의 머신에서 설정을 측정하고 기준을 충족하는 개선 사항을 유지하는 방식을 설명합니다.
이는 구현이나 성능이 동등하다는 뜻이 아니라, 접근 방식이 유사하다는 점을 보여 줍니다. 두 설명 모두 하드웨어 의존적 선택이 측정의 이점을 얻는다는 점을 인정합니다. 어느 설명도 두 엔진 간의 통제된 직접 비교 결과를 제시하지는 않습니다.
소스 토론이 이 아이디어를 Strata와 명시적으로 비교하기 때문에 이 구분은 중요합니다. 그 비교는 보정 수준에서는 타당합니다. 그러나 llama.cpp가 특정 구현을 복사했거나 다른 엔진의 속도와 일치한다는 사실을 입증하지는 않습니다.
엔진 유지 관리자에게 보정은 제품 측면의 질문도 제기합니다. 성능 중 얼마나 많은 부분이 사용자가 어떤 제어 기능이 존재하는지 아는 데 의존해야 할까요? 전문적인 탐색이 필요한 기능은 설계대로 작동하더라도 실질적인 부담을 부과합니다.
인터페이스 개발자에게 권장 사항에는 설명이 필요합니다. 사용자는 기본값, 측정된 설정, 추정치를 구분할 수 있어야 합니다. 이러한 범주를 동일하게 제시하면 이후 문제 해결이 더 어려워집니다.
튜닝이 복잡성을 없앤다고 약속할 필요는 없습니다. 더 설득력 있는 역할은 복잡성을 검토 가능하게 만드는 것입니다. 사용자가 조건을 이해하고 결과를 검증할 수 있을 때 권장 사항은 가치가 생깁니다.
이것이 실행 변경 사항과 보정을 함께 제공하는 더 강한 의미입니다. 이 프로젝트는 새 동작을 선택할 방법을 제공하고 있으며, 그 선택을 전적으로 시행착오에 맡기지 않습니다.
초기 열기는 중요한 검증 공백을 남긴다
병합된 기능은 검증됐지만, 소비자용 시스템 전반의 일반적인 속도 향상은 검증되지 않았다.
원래의 커뮤니티 성능 토론에는 열의와 함께 더 명확한 안내를 요청하는 의견도 담겨 있습니다. 한 댓글 작성자는 전문가 캐싱과 전송 병목 현상을 더 잘 파악할 수 있게 해 달라고 요청합니다. 또 다른 작성자는 일반적인 사용 환경에서 튜너의 출력을 어떻게 해석해야 하는지 묻습니다.
기여자의 응답에는 적절한 단서가 붙어 있습니다. Am17an은 스크립트가 최적에 가까울 수 있는 매개변수를 제공한다고 설명하며, 자동 모드를 향한 작업도 논의합니다. 이는 개발 방향이지, 구성이 해결됐다는 증거는 아닙니다.
이 반응들은 서로 다른 성공 기준을 보여 줍니다. 개발자는 추가된 실행 경로를 가치 있게 볼 수 있습니다. 숙련된 사용자는 튜닝 데이터에 접근할 수 있는 점을 중요하게 여길 수 있습니다. 로컬 어시스턴트를 설치하는 사람은 둘을 연구하지 않고도 합리적으로 작동하기를 바랄 수 있습니다.
이러한 기대는 양립할 수 있지만 서로 대체할 수는 없습니다. 패치는 첫 번째 요구를 충족하면서 다른 요구에는 추가 작업을 남길 수 있습니다. 보도는 모든 개선 사항에 같은 수준의 완성도를 부여하기보다 이 차이를 보존해야 합니다.
벤치마크 근거에도 명확한 경계가 필요합니다. 작성자가 제공한 예시는 테스트할 가치가 있는 동작을 보여 준다는 점에서 유용합니다. 하지만 특히 이 글의 핵심이 구성이 다르게 작동한다는 점이라면, 독립적인 재현을 대체하지는 못합니다.
공정한 비교는 조사 중인 실행 설정만 바꾸면서 모델과 워크로드를 동일하게 유지해야 합니다. 그렇지 않으면 겉보기에 보이는 개선이 다른 차이에서 비롯됐을 수 있습니다. 이는 공개된 예시에 대한 의혹이 아니라 방법론적 요구 사항입니다.
가중치를 저장하는 데 사용되는 수치 정밀도를 낮추는 모델 양자화 역시 비교에서 일관되게 유지해야 합니다. 이를 바꾸면 실험 자체가 달라집니다. 익숙한 모델 이름으로 제시되는 서로 다른 모델 파일에도 같은 주의가 적용됩니다.
사용자 경험은 생성 속도만으로는 충분히 평가할 수 없습니다. 시작 시의 짧은 지연과 출력 중 반복되는 멈춤은 사람마다 다르게 영향을 미칩니다. 평균값은 둘 중 어느 쪽도 가릴 수 있으므로, 보도는 측정값이 무엇을 나타내는지 설명해야 합니다.
머신 활동도 주목할 필요가 있습니다. 로컬 어시스턴트는 다른 애플리케이션과 컴퓨터를 공유하는 경우가 많습니다. 다른 작업이 없는 시스템에서 선택한 구성은 어시스턴트가 실제로 실행될 조건에서 확인해야 합니다.
이러한 고려 사항이 기능을 무효화하는 것은 아닙니다. 유용성을 판단하는 데 필요한 근거를 정의할 뿐입니다. 신중한 입장은 유망한 메커니즘의 이점이 일반적인 주장으로 확대되기 전에 관련 조건에서 테스트해야 한다는 것입니다.
따라서 가장 유용한 커뮤니티 보고에는 성과가 없었던 결과도 포함될 것입니다. 성능을 떨어뜨리는 설정은 최적화의 경계를 파악하는 데 도움이 됩니다. 그런 보고가 없다면 독자는 유리한 예시를 규칙으로 오해할 가능성이 더 큽니다.
현재로서는 llama.cpp MoE CPU 오프로딩에 대해 신중한 결론을 내릴 수 있습니다. 사용자는 평가할 가치가 있는 또 하나의 선택지를 갖게 됐습니다. 이용 가능한 근거만으로는 모든 제한된 시스템에 CPU 참여를 극대화하라고 권할 수 없습니다.
재현성, 통합 튜닝, 애플리케이션 결과를 지켜봐야 한다
다음 이정표는 이러한 유연성이 일상적인 사용에서 신뢰할 수 있는 성능으로 이어지는지를 보여줘야 한다.
첫 번째 신호는 명확히 설명된 구성 전반에서의 독립적인 재현입니다. 보고에는 정확한 모델 파일, 소프트웨어 버전, 워크로드, 설정을 명시해야 합니다. 그 가치는 다른 사람이 비교를 이해하고 반복할 수 있게 하는 데 있습니다.
전송 제약이 있는 구성에서 일관된 성능 향상이 나타난다면 새 실행 경로의 근거는 강화될 것입니다. 결과가 일관되지 않는다고 해서 자동으로 이를 무효화하는 것은 아닙니다. 오히려 더 나은 진단과 더 좁은 범위의 권장 사항이 중요해집니다.
두 번째 신호는 별도 스크립트에서 통합 구성 지원으로의 이동입니다. 11월 7일 자동 튜닝 제안에서 am17an은 모델별 설정을 선택하는 더 광범위한 도구를 제안합니다. 기여자 angt는 더 나은 벤치마킹 기반을 지지하며 가능한 캐시 매개변수 명령을 논의합니다.
이는 제안과 토론이지, 출시된 범용 튜닝 인터페이스가 아닙니다. 이 상태는 분명하게 유지돼야 합니다. 중요한 발전은 관련 측정을 접근 가능하게 만들고 권장 사항의 적용 범위를 설명하는 구현일 것입니다.
통합 지원이 도입된다면 기능의 사용성 측면은 강화될 것입니다. 구성이 계속해서 별도 출력을 해석해야 하는 방식이라면, 숙련된 사용자는 여전히 유연성을 누릴 수 있습니다. 기술 지식이 적은 사용자에게는 부담이 더 크게 남을 것입니다.
세 번째 신호는 완전한 애플리케이션 내부에서의 평가입니다. 코딩 어시스턴트와 문서 도구는 설정이 사용자가 수행하는 상호작용을 개선하는지 보고해야 합니다. 이는 응답 지연, 지속적인 사용, 현실적인 세션 전반의 동작을 살펴보는 것을 뜻합니다.
애플리케이션 수준의 이점은 이 업데이트를 고립된 생성 결과보다 더 중요한 변화로 만들 것입니다. 미약하거나 일관되지 않은 이점은 그 관련성을 특정 워크로드로 좁힐 것입니다. 어느 결과든 개발자에게 단일 헤드라인 속도 수치보다 더 나은 정보를 제공합니다.
이러한 신호는 순서대로 읽어야 합니다. 재현은 메커니즘이 어디에서 도움이 되는지 확립합니다. 통합 튜닝은 사용자가 그 이점에 얼마나 쉽게 접근할 수 있는지 결정합니다. 애플리케이션 결과는 사람들이 실제로 중요하게 여기는 경험을 개선하는지 보여 줍니다.
Strata와의 비교도 이 틀 안에 속합니다. 유용한 미래 비교는 공개된 조건에서 정의된 작업을 기준으로 두 엔진을 평가할 것입니다. 관련 없는 커뮤니티 결과만으로 승자를 선언하는 방식으로 시작해서는 안 됩니다.
앞으로 몇 달 동안 가장 강력한 근거는 기술적 투명성과 실질적 관련성을 결합할 것입니다. 설정이 많아지는 것 자체가 목표는 아닙니다. 목표는 사용자가 자신의 작업에 안정적으로 도움이 되는 구성을 선택하도록 돕는 것입니다.
llama.cpp MoE CPU 오프로딩을 고려하는 독자는 배포 환경에서 답이 필요한 질문부터 시작해야 합니다. 코딩 세션, 문서 대화 또는 다른 반복 작업에서 대기 시간을 줄여 주는가? 기준선을 유지하고 조건을 보존한 뒤 완전한 상호작용을 비교하세요. 특히 워크로드가 테스트와 다를 때는 튜너의 권장 사항을 검증해야 할 후보로 취급하세요. 성능이 개선되는 구성만큼 성능이 저하되는 구성도 신중하게 공유하세요. 이러한 보고는 폭넓게 유용한 기본값과 특정 머신에 적합한 선택지를 구분하는 데 도움이 됩니다. 다른 사람의 CPU 비중 설정을 채택하기 전에, 그 결과가 실제로 무엇을 측정했는지 그리고 그 측정이 자신의 사용 환경을 대표하는지 물어보세요.
