DeepSeek V4.1 Flash 양자화: 초당 26토큰, 그러나 트레이드오프 존재

DeepSeek V4.1 Flash 양자화는 듀얼 RTX 3090에서 초당 26토큰에 도달한 것으로 전해지며, 대형 모델을 데스크톱 환경에서 실험할 수 있게 한다. 이 커뮤니티 빌드는 가중치당 2.6127비트를 사용하며, 이는 모델 파라미터에 할당되는 수치 저장 용량을 나타내는 지표다. 보고된 속도에는 상당한 메모리 요구량, 느린 로딩, 그리고 코딩 성능에 관한 미해결 의문이 따른다.

핵심 긴장은 압축과 실질적인 작업 처리 능력 사이에 있다. 보유한 하드웨어에 모델을 탑재하는 일은 중요하지만, 개발자에게는 궁극적으로 허용 가능한 대기 시간 안에 정확한 변경 사항을 제공하는 것이 필요하다. 생성 텍스트가 빠르게 스트리밍된다고 해서 에이전트가 프로그래밍 작업을 효율적으로 끝낸다는 의미는 아니다.

이 구분은 실험에 실용적인 기준점도 제공한다. 바로 Qwen이다. 작성자는 이미 Qwen 기반 로컬 구성을 매일 사용하고 있으며 DeepSeek는 실험으로 설명한다. 이는 기존 코딩 워크플로가 대체됐다는 증거가 아니라, 추가 배포 옵션에 관한 보고다.

DeepSeek V4.1 Flash 양자화, 다운로드 가능한 커뮤니티 빌드 공개

구체적인 진전은 상세한 자체 보고형 데스크톱 결과와 함께 공개된 커뮤니티 모델 릴리스다.

Reddit 사용자 whiteh4cker는 프로그래밍 및 에이전트형 작업을 위해 lxe의 dsx 엔진을 사용해 DeepSeek-V4.1-Flash-1017-dsx-2.6bit를 만들었다고 밝혔다. 에이전트형 작업이란 모델이 도구 호출이나 파일 편집 같은 행동을 지시할 수 있는 작업을 말한다. 로컬 추론 보고서는 이제 가중치가 업로드됐다고 전한다.

이 업데이트는 원래 게시물이 업로드가 아직 진행 중이라고 설명했기 때문에 중요하다. 사용할 수 있는 아티팩트가 생기면 다른 사용자가 이를 검토하고 재현할 수 있다. 다만 공개된 성능 수치가 작성자의 장비를 넘어 일반화된다는 점을 입증하지는 않는다.

연결된 양자화 모델 가중치 역시 이 릴리스와 기반 모델을 구분한다. DeepSeek는 원본 모델을 제공하고, 커뮤니티 기여자는 압축된 파생 버전을 제공한다. dsx 개발자는 이를 실행하는 엔진을 제공한다.

이 역할들은 서로 다른 종류의 근거를 수반한다. 모델 개발사의 성능 주장은 해당 릴리스와 평가 조건을 설명한다. 압축 작성자의 측정치는 특정 변환 결과를 설명한다. 엔진의 벤치마크는 소프트웨어 및 하드웨어 구성을 설명한다.

이러한 주장을 “DeepSeek 성능”에 관한 하나의 진술로 합치면 중요한 차이가 가려진다. 데스크톱 결과는 특수한 구현을 통해 실행되는 특정 압축 모델에 관한 것이다. 원본 릴리스와 연관된 모든 기능 또는 벤치마크 점수를 자동으로 물려받는 것은 아니다.

이 시점은 프로그래밍 품질을 특히 중요하게 만든다. DeepSeek는 2026년 10월 17일 1017 업데이트를 발표했다. 회사의 코딩 모델 업데이트는 프로젝트 개발, 더 빠른 작업 완료, 더 짧은 출력을 강조한다.

이러한 주장은 개발자가 로컬 코딩을 위해 이 스냅샷을 검토할 이유를 뒷받침한다. 그러나 압축 파생 버전을 검증하지는 않는다. 특히 작은 수치 변화가 긴 추론이나 도구 선택에 영향을 줄 수 있는 영역에서는 커뮤니티 변환본이 자체 근거를 확보해야 한다.

이 구분은 빌드 다운로드 여부를 결정하는 사람에게 실질적이다. 이용 가능 여부는 실험을 시작할 수 있는지를 답한다. 재현 가능한 벤치마크는 다른 장비에서도 유사하게 작동하는지를 답한다. 프로그래밍 평가는 이 실험이 일상 업무에 포함될 가치가 있는지를 답한다.

이 보고서는 첫 번째 질문을 진전시키고 두 번째 질문을 위한 단서를 제공한다. 세 번째 질문은 대체로 열어 둔다. 결과가 구성과 한계에 계속 연결되어 있다면, 이것만으로도 유용한 진전이다.

데스크톱에서 중요한 것은 그래픽 카드만이 아니다

그래픽 카드가 관심을 끌지만, 이 배포가 실용적인지 여부는 전체 시스템이 결정한다.

작성자는 듀얼 RTX 3090과 함께 192GB의 시스템 메모리를 사용한다고 보고했다. 압축 가중치는 187.6GB를 차지하며, Engram 테이블은 SATA SSD에서 203GB를 차지한다. Engram은 모델의 연산을 보완하는 학습된 조회 메모리 구성 요소다.

보고된 로딩 시간은 하드 디스크 드라이브에서 90~110분이다. 작성자는 댓글에서 이 디스크가 추론 전에 가중치를 메모리로 불러온다고 설명했다. 추론은 모델을 실행해 입력을 처리하고 출력을 생성하는 과정을 뜻한다.

이 설명은 쉽게 발생할 수 있는 오해를 막는다. 보고서는 생성 중에 회전식 디스크가 모든 모델 연산을 지속적으로 제공한다고 말하지 않는다. 시작 동작과 안정 상태 생성은 서로 다른 측정값이며, 업무를 수행하는 개발자에게도 다른 의미를 갖는다.

모델 서버를 계속 실행하는 사람에게 시작 시간은 가끔 발생하는 중단일 수 있다. 자주 재시작하거나, 모델을 전환하거나, 워크스테이션을 공유하는 사람에게는 경험을 좌우할 수 있다. 따라서 동일한 생성 속도 보고도 편의성에 관해 매우 다른 판단을 뒷받침한다.

압박은 이미 보유한 하드웨어로 로컬 배포를 평가하는 개발자에게 가해진다. 이들은 메모리 용량, 스토리지 배치, 시작 동작, 지속적인 응답성을 함께 고려해야 한다. 익숙한 그래픽 카드 이름만으로 주변 시스템까지 평범해지는 것은 아니다.

보고된 시스템은 로컬 모델을 주로 그래픽 메모리로 선택하는 흔한 구매 기준에도 의문을 제기한다. 시스템 메모리와 스토리지는 배포 예산의 일부다. 이들의 가용성이 어떤 모델 구성이 실현 가능한지 결정한다.

이것이 모든 사람이 작성자의 정확한 구성을 필요로 한다는 뜻은 아니다. 다만 그래픽 카드만 언급해서는 이 결과를 책임 있게 요약할 수 없다는 점을 보여 준다. 재현 가능한 설명에는 나머지 시스템 사양과 소프트웨어 설정도 필요하다.

운영 습관 역시 중요하다. 전용 워크스테이션은 작업 사이에 모델을 계속 사용할 수 있게 유지할 수 있다. 공유 데스크톱은 경쟁 애플리케이션과 워크로드를 수용해야 한다. 어느 상황도 토큰 처리율 헤드라인에는 드러나지 않지만, 설정이 실제로 유용해지는지에는 모두 영향을 준다.

프로그래밍 워크플로에서는 중단이 시작 시간에만 그치지 않는다. 개발자는 컨텍스트 설정을 바꾸거나, 실패한 프로세스를 복구하거나, 프로젝트 간에 이동해야 할 수 있다. 중요한 질문은 시스템이 업무 세션 전반에서 어떻게 작동하는가다.

이 때문에 이 실험은 호스팅 제공업체 전반에 폭넓은 압박을 입증하기보다, 벤치마크 보고 방식에 즉각적인 요구를 제기한다. 로컬 배포 주장은 전체 시스템을 설명해야 한다. 그렇지 않으면 독자는 결과가 자신의 자원과 맞는지 알 수 없다.

유용한 함의는 원격 서비스를 대체한다는 주장보다 좁다. 이 구성은 로컬 실험을 위한 구체적인 후보를 제공한다. 운영 요구 사항은 헤드라인에서 제거할 배경 정보가 아니라 결과의 일부로 남는다.

Engram은 질문을 모델 크기에서 데이터 배치로 옮긴다

기술적 기회는 연산과 저장된 정보를 서로 다른 자원으로 다루는 데서 나온다.

DeepSeek의 조건부 메모리 연구는 Engram을 짧은 토큰 시퀀스에 기반한 조회 메커니즘으로 설명한다. 토큰은 언어 모델이 처리하는 텍스트 단위다. 이 연구는 조건부 메모리를 조건부 연산을 보완하는 요소로 제시한다.

조건부 연산은 특정 입력에 대해 모델의 일부만 활성화한다. 전문가 혼합 아키텍처에서 이 부분에는 전문가라고 불리는 특화 파라미터 그룹이 포함된다. 더 넓게 보면 저장된 용량과 토큰마다 수행되는 작업은 반드시 함께 증가할 필요가 없다는 뜻이다.

이 데스크톱 실험에서 중요한 결과는 배치의 문제다. 어떤 정보가 그래픽 프로세서 가까이에 남아 있어야 하는가? 어떤 정보가 다른 위치에 있어도 되는가? 그 정보를 옮기거나 조회하는 데 얼마나 많은 대기 시간이 추가되는가?

이 질문들은 파일 크기만으로 응답성을 예측할 수 없는 이유를 설명한다. 큰 저장 구성 요소는 반복적인 산술 연산이 필요한 비슷한 크기의 구성 요소와 다르게 작동할 수 있다. 용량뿐 아니라 접근 패턴도 중요하다.

이 지점에서 압축과 아키텍처가 상호작용한다. 양자화는 모델 값을 저장하는 데 사용되는 수치 정밀도를 낮춘다. Engram은 설계의 다른 부분, 즉 조회를 통해 학습된 정보를 제공하는 방식에 관한 것이다. 둘 다 배포에 영향을 미치지만, 서로 바꿔 쓸 수 있는 기술로 취급해서는 안 된다.

더 낮은 가중치당 비트 수치는 압축 아티팩트의 한 측면을 설명한다. 전체 시스템의 메모리 사용량을 요약하지는 않는다. 또한 실행 중 모든 모델 구성 요소가 어떻게 표현되고 접근되는지도 보여 주지 않는다.

dsx 추론 엔진은 이 DeepSeek 모델을 위해 특별히 설계됐으며, NVIDIA의 그래픽 연산 플랫폼인 CUDA와 Rust를 사용한다. 문서는 그래픽 메모리, 시스템 메모리, 스토리지 전반의 배치를 설명한다. 이는 특정 아키텍처를 중심으로 한 특수한 엔지니어링이다.

이러한 특수화는 기회와 유지보수 의무를 함께 만든다. 엔진은 알려진 모델 동작을 중심으로 최적화할 수 있다. 그러면 사용자는 모델 업데이트, 변경된 파일, 또는 다른 설정이 해당 구현과 계속 호환되는지 확인해야 한다.

현재 문서는 이미지에 관한 원래 게시물의 관찰도 복잡하게 만든다. 게시물은 이미지 입력이 지원되지 않는 것으로 보였다고 말한다. 저장소는 이제 비전 관련 옵션을 나열하므로, 이 제한은 테스트된 빌드에 연결해 두어야 한다.

어느 관찰도 공개된 양자화 버전에서 신뢰할 수 있는 이미지 성능을 입증하지는 않는다. 소프트웨어 옵션은 노출된 기능의 근거다. 성공적인 멀티모달 평가는 전체 설정이 시각 작업을 올바르게 처리하는지 보여 줄 것이다.

에이전트가 스크린샷, 차트 또는 인터페이스 출력을 검사해야 하는 개발자에게 이는 중요하다. 텍스트 전용 프로그래밍 지원과 시각적 애플리케이션 테스트는 서로 다른 요구 사항을 부과한다. 긍정적인 텍스트 결과만으로 둘 다 판단할 수는 없다.

더 넓은 의미는 로컬 배포가 제기하는 질문의 변화다. 독자는 모델이 들어맞는지만 묻는 대신, 구성 요소가 어떻게 배치되는지도 물어야 한다. 그 답은 용량, 응답성, 기능 지원, 유지보수를 연결한다.

이는 아키텍처적 승리를 주장하지 않고도 실험을 기술적으로 흥미롭게 만든다. 이 실험은 구체적인 배포 경로를 보여 준다. 그 경로가 더 나은 프로그래밍 작업을 제공하는지는 별도로 측정 가능한 질문으로 남는다.

더 나은 압축 점수에도 코딩 품질은 미확정

평가는 이 빌드를 검토할 근거를 제공하지만, 프로그래밍 신뢰성은 여전히 확인되지 않았다.

작성자의 비교는 새 빌드의 KL 발산이 0.1972라고 보고한다. KL 발산은 확률 분포 간 차이를 측정하며, 여기서는 모델 출력을 참조값과 비교한다. 더 낮은 결과는 해당 평가에서 더 가까운 일치를 뜻한다.

같은 비교는 82.59%의 최상위 선택 일치율과 9.3626의 퍼플렉서티를 보고한다. 최상위 선택 일치율은 가장 높은 순위의 토큰 예측이 일치하는 정도를 추적한다. 퍼플렉서티는 평가 텍스트에 대한 예측 불확실성을 측정하며, 일반적으로 같은 테스트 내에서는 값이 낮을수록 예측이 더 우수함을 나타낸다.

이러한 측정치는 압축이 모델의 동작을 바꾸는지에 관한 것이다. 코딩 에이전트가 결함을 수정하는지는 직접 측정하지 않는다. 또한 기준 모델과의 모든 불일치가 의미 있는 실패를 초래한다는 사실도 입증하지 않는다.

이러한 구분은 양방향으로 작용한다. 토큰 하나가 바뀌어도 답변의 유용성은 그대로일 수 있다. 반면 중요한 의사결정 지점에서의 작은 변화는 에이전트를 잘못된 수정이나 불필요한 도구 호출로 이끌 수 있다.

따라서 프로그래밍은 압축에 까다로운 시험 환경을 제공한다. 모델은 일련의 의사결정 전반에 걸쳐 제약 조건을 유지해야 한다. 유용한 평가는 토큰 수준의 일치가 프로젝트 수준의 성공으로 곧바로 이어진다고 가정하기보다, 실제 작업 결과를 살펴봐야 한다.

이 스레드에는 dsx 개발자 lxe의 관련 경고가 담겨 있다.

> “제가 원래 모델을 만들었을 때 놀라웠던 점은 이 약 2비트 동적 양자화에서, 오로지 양자화 때문에 이 모델이 자기 판단에 더 확신을 못 갖게 되었고 어려운 작업에서는 풀 모델보다 CoT가 거의 두 배로 늘었다는 것입니다. API 문제와 프롬프트 템플릿은 배제했습니다. 당신의 bpw에서는 이런 현상이 전혀 없었나요?”

CoT는 모델이 생성하는 중간 추론 텍스트인 chain of thought를 뜻한다. 이는 개발자가 이전 압축 빌드에 대해 관찰한 내용이다. 새 릴리스에서 확인된 결함이라기보다, 테스트해 볼 가치가 있는 가설이다.

릴리스 작성자의 답변은 현재 확보된 근거의 한계를 보여 준다.

> “저는 몇 달 동안 직장에서 소프트웨어 개발을 위해 API를 통해 DeepSeek를 사용해 왔습니다. 웹 UI에서 최대 추론 설정으로 이 2.6 bpw 모델에 고대 중국을 배경으로 한 10문단 이야기를 쓰게 했습니다. API 버전과 비슷하게 동작했습니다. 과도하게 생각하지도 않았습니다. 다만 더 어려운 프롬프트로는 테스트하지 않았습니다.”

이 답변은 초기 동작 점검을 설명한다. 엔진 개발자가 제기한 더 어려운 프로그래밍 문제에는 답하지 않는다. 창작 글쓰기와 소프트웨어 수정은 계획, 정확성, 도구 사용 측면에서 서로 다른 요구를 부과한다.

다음으로 유용한 평가는 동일한 조건에서 완료된 프로그래밍 작업을 비교하는 방식일 것이다. 정확성, 추론 길이, 재시도 횟수, 경과 시간을 기록해야 한다. 더 많은 텍스트를 생성하는 모델은 더 나은 결과로 그 텍스트의 가치를 입증해야 한다.

기준 모델 자체의 보고 방식에도 문제가 있다. 독자는 어떤 모델 파일, 프롬프트, 평가 설정으로 비교가 이루어졌는지 알아야 한다. 그렇지 않으면 긍정적인 수치라도 작성자의 환경 밖에서는 해석하기 어렵다.

DeepSeek V4.1 Flash 양자화에는 그럴듯한 품질 근거가 있지만, 현재 그 주장은 대리 측정치와 제한적인 동작 피드백에 기반한다. 이 근거는 통제된 시험을 뒷받침한다. 까다로운 코딩 작업에서 원본 모델과 동등하다고 선언할 근거는 되지 않는다.

Qwen은 대기 시간의 상충 관계를 구체적으로 보여 준다

실용적인 비교 대상은 완전한 작업 시간으로 평가한 작성자의 기존 워크플로다.

작성자는 Qwen 기반의 로컬 환경을 매일 사용한다고 말한다. 연결된 듀얼 GPU Qwen 설정은 같은 그래픽카드 등급에서 Qwen3.8-Flash-Next를 배포하는 방법을 문서화한다. 공개된 구성은 서로 다르지만, 이는 Qwen을 관련 있는 대안으로 만든다.

같은 그래픽카드 이름을 사용한다고 해서 통제된 비교가 되는 것은 아니다. 모델, 메모리 구성, 서빙 소프트웨어, 테스트 작업량은 모두 다를 수 있다. 따라서 공개된 헤드라인 속도는 각각의 조건과 함께 해석해야 한다.

DeepSeek 게시물은 초당 170토큰의 프롬프트 처리 속도를 보고한다. 프리필(prefill)이라고도 하는 프롬프트 처리는 생성 전에 입력을 대상으로 수행하는 작업이다. 생성 속도는 그 이후 출력 토큰이 만들어지는 속도를 측정한다.

이 단계들은 서로 다른 종류의 대기 시간을 만든다. 느린 입력 처리는 첫 응답을 지연시킨다. 느린 생성은 응답이 시작된 뒤의 시간을 늘린다. 벤치마크 헤드라인이 후자만 강조하더라도 개발자는 둘 다 경험한다.

보고된 컨텍스트 설정은 262,144토큰이다. 컨텍스트 윈도는 입력과 출력에 사용할 수 있는 최대 토큰 예산이다. 그 용량을 선택했다고 해서 측정 중 전체 윈도 크기가 처리되었다는 뜻은 아니다.

이는 리포지터리 작업에서 중요한 차이다. 개발자는 짧은 오류 메시지를 제공할 수도 있고, 대량의 소스 파일을 제공할 수도 있다. 같은 서버도 이러한 요청에 따라 매우 다르게 느껴질 수 있다.

에이전트는 작업에 반복적인 교환이 포함될 수 있으므로 한 층을 더한다. 도구 결과를 읽고, 계획을 수정하며, 추가 정보를 요청한다. 전체 지연 시간은 한 번의 중단 없는 출력이 아니라 이 순서에 따라 달라진다.

이미 계산된 결과를 재사용하는 캐싱은 입력 처리 부담을 바꿀 수 있다. 그 이점은 요청 사이에 무엇을 재사용할 수 있는지에 달려 있다. 현실적인 비교는 모든 턴이 처음부터 시작한다고 가정하지 말고 이 동작을 명시해야 한다.

프롬프트 속도를 둘러싼 스레드의 이견은 이러한 상충하는 작업량을 반영한다. 가끔 대화형 요청을 테스트하는 사람은 무인 작업을 실행하는 사람과 설정을 다르게 평가할 수 있다. 생성 수치만으로는 이견을 해소할 수 없다.

따라서 Qwen 비교는 실제 작업에서 어떤 일이 일어나는지 물어야 한다. DeepSeek는 더 적은 재시도로 올바른 패치를 만들어 내는가? 추가 대기 시간은 더 나은 판단으로 이어지는가? 일상적인 작업에는 기존 환경이 여전히 더 나은 선택인가?

이 질문들은 압축된 용량 대 신뢰할 수 있는 완료라는 핵심 상충 관계를 유지한다. 모델 계열 간 근거 없는 경쟁으로 글이 흐르는 것을 막는다. 적합한 선택은 작업량에 따라 달라질 수 있다.

예를 들어 익숙하지 않은 리포지터리를 조사하는 개발자는 제공된 코드에 대한 유용한 해석이 필요하다. 좁은 범위의 수정을 하는 개발자는 지연이 거의 없는 정확한 실행이 필요하다. 모델 비교는 이러한 차이를 평균으로 지워 버리지 말고 보존해야 한다.

기존의 일상적 주력 환경은 이 실험에 가치 있는 기준선을 제공한다. 작성자에게는 빈자리를 채우는 것이 아니라 유지할 가치가 있는 워크플로가 있다. DeepSeek는 전환할 만큼 충분한 실질적 이점을 제공해야 한다.

세 가지 결과가 이 빌드가 일상적 주력 도구가 될지를 결정할 것이다

재현성, 프로그래밍 결과, 운영 안정성이 이 결과가 어느 정도의 비중을 가질지 결정할 것이다.

첫 번째 신호는 공개된 아티팩트를 독립적으로 재현하는 것이다. 다른 사용자는 정확한 파일, 엔진 리비전, 하드웨어, 설정을 식별할 수 있어야 한다. 그 결과 측정치는 시작 시간, 입력 처리, 생성을 구분해야 한다.

비슷한 결과가 나오면 보고된 동작이 원래 장비 밖에서도 유지된다는 신뢰가 높아진다. 다른 결과도 원인을 분리할 수 있다면 여전히 유용한 정보가 된다. 설명되지 않는 변동은 헤드라인의 유용성을 제한한다.

재현은 컨텍스트 주장도 명확히 해야 한다. 독자에게는 구성된 최대치와 함께 실제 입력 및 출력 길이가 필요하다. 이 정보는 큰 사용 가능 윈도와 큰 활성 작업량 전반에서 입증된 성능을 구분한다.

두 번째 신호는 안정적인 비교 조건에서 완료된 프로그래밍 작업이다. 동일한 작업을 압축 빌드와 적절한 기준 모델에서 실행해야 한다. 평가자는 프롬프트, 도구 접근 권한, 완료 기준을 유지해야 한다.

정확성은 속도와 함께 계속 드러나야 한다. 승인 검사를 통과하지 못하는 빠른 답변은 완료된 작업이 아니다. 반복적인 수정과 수동 보수를 피할 수 있다면 느린 답변도 가치가 있을 수 있다.

이 평가는 스레드에서 제기된 추론 우려도 다뤄야 한다. 더 긴 출력이 본질적으로 더 좋거나 나쁜 것은 아니다. 그 의미는 추가 계산이 더 신뢰할 수 있는 결과를 내는지에 달려 있다.

긍정적인 결과는 이 빌드의 자원 요구를 받아들여야 한다는 주장을 강화할 것이다. 약한 결과는 그 역할을 실험이나 선택된 작업량으로 좁힐 수 있다. 어느 결과든 현재의 근거를 개선할 것이다.

세 번째 신호는 작업 세션 전반에서 반복 가능한 운영이다. 시작, 복구, 메모리 압박, 기능 호환성은 성공적인 시연을 넘어 관찰할 필요가 있다. 제안된 워크플로가 이미지 지원에 의존하는 경우에는 이를 명시적으로 검증해야 한다.

안정성은 하루 내내 모델을 사용할 수 있다는 근거를 강화할 것이다. 빈번한 개입은 무인 에이전트에서의 매력을 약화시킬 것이다. 유지보수도 개발자의 주의를 소모하므로 이 판단은 벤치마크 성능과 함께 다뤄져야 한다.

앞으로 몇 달 동안 이 신호들은 향상된 토큰 속도 스크린샷을 하나씩 쫓는 것보다 더 명확한 경로를 제시한다. 다운로드 가능한 아티팩트를 재현 가능한 실행으로, 다시 유용한 작업으로, 이어서 지속적인 사용으로 연결한다. 각 단계는 서로 다른 도입 질문에 답한다.

현재 결과는 이 순서 안에서 고무적이다. 구체적인 압축 모델과 이례적으로 상세한 배포 사례를 제공한다. 가장 큰 기여는 추가 평가를 가능하게 한다는 점이다.

현재로서는 DeepSeek V4.1 Flash 양자화를 현재의 코딩 워크플로와 통제된 조건에서 비교할 후보로 다뤄야 한다. 구성을 보존하고 명확한 승인 검사를 갖춘 작업을 선택하라. 모델 자체의 실행 시간과 함께 대기, 검토, 출력 보수에 쓴 시간을 기록하라. 특히 불필요한 재시도와 처음에는 그럴듯해 보이는 잘못된 변경을 포함해 실패 사례도 비교에 남겨야 한다. 빌드가 필요한 기능을 지원하고 신뢰할 수 있는 결과를 낸다면, 메모리 및 로딩 요구 사항은 정보에 근거한 상충 관계가 된다. 그렇지 않더라도 향후 실험을 위한 유용한 경계를 얻게 된다. 일상적 주력 도구를 바꾸기 전에, 이 벤치마크가 열어 둔 질문을 던져야 한다. 로컬 모델이 허용 가능한 수준의 감독으로 실제 작업을 정확하게 끝내는가?