Hugging Face, 새로운 LFM2.5 인코더 추가… 장문 컨텍스트 CPU 추론에서 ModernBERT와 경쟁

Hugging Face는 8,192토큰 입력을 처리하면서 장문 컨텍스트 CPU 속도에서 ModernBERT에 도전하는 Liquid AI의 인코더 모델 두 종을 추가했다. 이번 출시는 문서 규모의 언어 처리가 항상 GPU나 생성형 모델을 필요로 하지는 않는다는 구체적인 주장을 검증 대상으로 올려놓는다.

Liquid AI는 자사의 2억3,000만 파라미터 인코더가 테스트한 CPU에서 8,192토큰 포워드 패스를 약 28초 만에 완료한다고 밝혔다. 회사 비교에서 ModernBERT-base는 90초 이상이 걸렸다. 이처럼 보고된 격차는 LFM2.5와 ModernBERT의 경쟁을 단순한 벤치마크 정확도가 아니라 배포 경제성의 문제로 만든다.

이 결과가 중요한 이유는 인코더가 분류, 라우팅, 추출, 콘텐츠 조정, 개인정보 탐지 등 지속적으로 발생하는 워크로드를 조용히 처리하기 때문이다. 이러한 시스템은 유입되는 모든 문서나 메시지를 검사하는 경우가 많다. 따라서 개별 작업이 소규모로 보이더라도 느린 모델은 상당한 인프라를 소모할 수 있다.

Liquid AI는 모델 가중치, 평가 하니스, 모델 카드 및 CPU 전용 데모를 공개했다. 다만 핵심 성능 수치는 여전히 공급업체가 직접 수행한 결과다. 프로세서 구성과 최적화된 런타임 지원을 포함한 중요한 배포 세부 사항은 더 폭넓은 독립 테스트가 필요하다.

Hugging Face, 공개 가중치 LFM2.5 인코더 두 종 추가

이번 출시는 Liquid AI의 디코더 아키텍처를 장문 문서와 일반 컴퓨팅 하드웨어를 위해 설계된 두 개의 작업 중심 인코더로 전환한다.

Liquid AI는 2026년 7월 28일 Hugging Face에서 LFM2.5-Encoder-230M과 LFM2.5-Encoder-350M을 출시했다. 두 모델 모두 최대 8,192토큰 컨텍스트를 지원하며 회사의 LFM2 하이브리드 아키텍처를 사용한다.

인코더는 입력을 읽고 분류, 검색, 추출 또는 토큰 수준 결정에 사용할 문맥적 표현을 생성한다. 인과적 언어 모델과 달리 주된 목적은 왼쪽에서 오른쪽으로 다음 토큰을 생성하는 것이 아니다.

이 차이는 비용과 동작 방식 모두를 결정한다. 지원 티켓 라우터는 응답을 작성하는 것이 아니라 목적지를 선택해야 한다. 개인정보 필터는 유창한 문단을 생성하는 것이 아니라 민감한 구간을 찾아야 한다.

Liquid AI는 이러한 더 좁은 작업에 맞춰 기존 230M 및 350M 디코더 백본을 조정했다. 인과적 어텐션 마스크를 양방향 어텐션으로 교체해 각 토큰이 양쪽의 텍스트를 모두 고려할 수 있게 했다. 또한 대칭 패딩을 통해 아키텍처의 짧은 컨볼루션을 비인과적으로 만들었다.

학습에는 선택된 토큰을 가리고 주변 문맥을 바탕으로 모델이 이를 예측하게 하는 마스크드 언어 모델링이 사용됐다. Liquid AI는 학습 중 토큰의 30%를 마스킹했다고 밝혔다.

회사는 2단계 일정을 사용했다. 초기 학습은 대규모 웹 코퍼스에서 1,024토큰 시퀀스를 대상으로 진행됐다. 두 번째 단계에서는 사실성, 법률 및 다국어 성능을 강화하기 위한 데이터로 컨텍스트를 8,192토큰까지 확장했다.

230M 모델 카드에 따르면 이 모델은 약 2억2,970만 개의 파라미터를 보유한다. 350M 버전은 약 3억5,450만 개를 포함한다. 두 모델 모두 히든 크기는 1,024이며, 65,536개 항목의 어휘를 갖는다.

모델 카드에 따르면 두 모델은 15개 언어를 지원한다. 여기에는 영어, 스페인어, 프랑스어, 아랍어, 힌디어, 일본어, 베트남어 및 중국어가 포함된다.

Liquid AI는 더 작은 모델을 엄격한 지연 시간 및 메모리 제약 환경에 맞춰 배치한다. 더 큰 버전은 정확도 중심 선택지로 제시한다. 두 모델 모두 프로덕션용 분류기, 라우터 또는 추출 시스템이 되기 전에 작업별 파인튜닝이 필요하다.

즉시 사용할 수 있는 애플리케이션으로 LFM2.5 인코더를 설명할 때 이 단서는 중요하다. 기본 모델은 언어 표현을 제공하지만, 조직은 출력 헤드를 붙이고 목표 작업에 맞춰 학습해야 한다.

모델은 Liquid AI의 LFM Open License v1.0을 사용한다. 이를 공개 가중치라고 부르는 것은 개발자가 학습된 파라미터를 다운로드하고 실행할 수 있음을 의미한다. 그렇다고 이번 출시가 표준적인 허용형 소프트웨어 라이선스를 사용한다는 뜻은 아니다.

Hugging Face는 배포 지점, 모델 카드, 커뮤니티 토론 및 데모를 제공한다. Liquid AI는 아키텍처, 가중치, 평가 및 구현을 제공한다. 이 구조는 실험을 쉽게 만드는 한편 핵심 성능 주장에 대한 책임은 모델 개발사에 남긴다.

따라서 즉각적인 변화는 분명하다. 개발자는 이제 GPU 우선 생성이 아니라 CPU 배포를 중심으로 설계된 장문 컨텍스트 인코더 두 종을 다운로드할 수 있다.

장문 컨텍스트 CPU 추론이 진짜 기회인 이유

핵심 기회는 더 작은 챗봇이 아니라 완전한 업무 문서를 검사할 수 있는 더 저렴한 의사결정 계층이다.

프로덕션 언어 시스템은 문장 생성을 전혀 필요로 하지 않는 수많은 작업을 수행한다. 요청에 레이블을 지정하고, 정책 위반을 탐지하며, 감성을 분류하고, 엔터티를 식별하고, 문단 순위를 매기며, 어느 대형 모델이 프롬프트를 받을지 결정한다.

이러한 작업은 사용자에게 보이는 챗봇 응답보다 훨씬 더 자주 실행될 수 있다. 에이전트 플랫폼은 생성 전에 여러 안전 규칙에 따라 프롬프트를 평가할 수 있다. 전달 전에는 결과를 다시 분류할 수도 있다.

모든 단계를 대규모 생성형 모델로 실행하면 지연 시간과 하드웨어 수요가 늘어난다. 예측 가능한 레이블이나 토큰 구간이 필요한 작업에 가변적인 출력을 도입할 수도 있다.

파인튜닝된 인코더는 다른 경로를 제공한다. 관련 텍스트를 한 번의 포워드 패스로 읽고 작업별 점수를 반환한다. 모델은 각 문서를 외부 서비스로 전송하지 않고 로컬 프로세스 내부에 머무를 수 있다.

컨텍스트 길이는 이 과정이 완전한 원문을 볼 수 있는지를 결정한다. 오래된 인코더는 대개 더 짧은 시퀀스를 중심으로 설계돼 개발자가 계약서, 대화 기록 또는 지원 스레드를 청크로 나누도록 강제했다. 청킹은 판단의 의미를 바꾸는 증거와 그 판단을 분리할 수 있다.

8,192토큰 창이 모든 장문 문서를 포괄하지는 않는다. 하지만 전통적인 512토큰 BERT 배포보다 훨씬 더 많은 텍스트를 처리한다. 이 차이는 청킹과 주변 집계 로직을 줄일 수 있다.

Liquid AI는 CPU 전용 Hugging Face Spaces로 이 접근법을 보여준다. 데모는 프롬프트 라우팅, 정책 린팅, 맞춤법 검사 및 개인식별정보 탐지를 다룬다.

PII 데모는 16개 언어에서 40가지 정보 유형을 탐지한다고 알려졌다. 정책 린팅은 자유 텍스트로 제공된 규칙에 대해 토큰의 점수를 매긴다. 프롬프트 라우팅은 전체 프롬프트를 사용자가 정의한 라우팅 카테고리와 비교한다.

이러한 데모는 Liquid AI가 공략하려는 워크로드를 보여준다. 즉, 결과가 제한적이고 인프라 비용이 반복적으로 발생하는 대용량 이해 작업이다.

로컬 정책 필터는 특히 에이전트 시스템과 관련이 있다. 필터는 애플리케이션과 같은 환경 내에서 작동할 수 있어 내부 텍스트를 다른 원격 엔드포인트에 노출할 필요를 줄인다.

같은 논리는 로컬 기술 문서에도 적용된다. 검색 가능한 지식 베이스를 구축하는 팀은 생성된 답변이 나타나기 전에 분류, 추출 및 검색 단계를 필요로 한다.

CPU 배포는 이러한 단계가 실행될 수 있는 장소를 넓힌다. 개발자 노트북, 애플리케이션 서버 또는 엣지 기기에서 별도 가속기를 확보하지 않고도 모델을 실행할 수 있다.

다만 “CPU에서 실행된다”는 말이 모든 규모에서 즉각적이거나 저렴하다는 뜻은 아니다. 28초 패스는 계약서 한 건에는 실용적일 수 있지만 대화형 인터페이스에는 부적합할 수 있다. 배치 처리량도 단일 문서 지연 시간과는 다르다.

더 강한 주장은 운영 유연성이다. 팀은 데이터가 이미 있는 위치에 특화된 언어 처리를 배치하고, 실제로 생성이 필요한 작업에만 GPU나 원격 모델을 사용할 수 있다.

이러한 역할 분담은 모든 언어 작업에 범용 추론을 판매하는 공급업체에 압박을 가한다. 더 작은 인코더가 요구 사항을 처리할 수 있는지 측정하기 전에 대형 언어 모델을 기본값으로 선택하는 팀에도 압박이 된다.

LFM2.5와 ModernBERT의 차이는 아키텍처에 달려 있다

Liquid AI가 보고한 속도 우위는 하이브리드 백본이 모든 레이어에 완전한 어텐션을 적용하지 않기 때문에 입력 길이가 길어질수록 커진다.

ModernBERT는 8,192토큰 컨텍스트에서 효율적인 양방향 인코딩을 목표로 한다는 점에서 가장 명확한 경쟁 상대다. 2024년 말 출시된 이 모델은 더 긴 입력, 현대 하드웨어 및 개선된 학습을 위해 BERT 설계를 업데이트했다.

원래의 BERT 연구는 양방향 사전학습을 언어 이해의 기반으로 확립했다. 이후 ModernBERT는 이 접근법을 현재의 배포 요구에 맞춘 아키텍처 및 학습 업데이트와 결합했다.

Liquid AI는 다른 경로를 택한다. LFM2는 그룹드 쿼리 어텐션과 게이트형 짧은 컨볼루션 블록을 교차 배치한다. 어텐션은 시퀀스 전반의 정보를 연결하는 반면, 짧은 컨볼루션은 더 낮은 계산 오버헤드로 인접 토큰에 집중한다.

이 하이브리드 구조는 입력이 길어질수록 중요해진다. 완전한 셀프 어텐션은 시퀀스 전체의 위치를 비교하므로 길이에 따라 계산 부담이 빠르게 증가한다. 컨볼루션 레이어는 작업의 더 많은 부분을 지역적 이웃으로 제한한다.

Liquid AI는 어텐션을 제거하지 않는다. 대신 아키텍처가 전체 비용을 지불하는 빈도를 줄인다. 모델은 여전히 멀리 떨어진 위치 간 정보를 교환하면서 많은 레이어는 더 저렴한 지역 연산으로 처리할 수 있다.

인코더 용도로 Liquid AI는 이러한 지역 연산을 양방향으로 만들었다. 대칭 패딩은 컨볼루션이 현재 토큰의 앞뒤 이웃을 모두 반영하게 한다. 완전 어텐션 레이어에도 양방향 마스크가 적용된다.

이 메커니즘이 LFM2.5와 ModernBERT 비교의 핵심 근거를 만든다. Liquid AI는 하이브리드 시퀀스 처리가 경쟁력 있는 이해 성능을 보존하면서 장문 입력 지연 시간의 증가를 늦출 수 있다고 본다.

출시 결과에 따르면 LFM2.5-Encoder-230M은 모든 CPU 시퀀스 길이에서 테스트된 모델 중 가장 빨랐다. 그 우위는 8,192토큰 한도에서 가장 뚜렷해졌다.

Liquid AI는 이 길이에서 더 작은 LFM2.5 모델이 약 28초가 걸렸다고 보고했다. ModernBERT-base는 90초 이상이 걸려, 언급된 3.7배 우위를 만들었다고 설명한다.

회사는 Apple GPU에서 더 좁은 양상을 관찰했다. ModernBERT-base는 약 1,000토큰 미만에서 앞섰다고 알려졌다. Liquid AI의 인코더는 약 2,000토큰부터 앞서기 시작했다.

이 교차점은 그 절충을 보여준다. 장문 입력에 최적화된 아키텍처 선택이 짧은 입력에서도 선두를 보장하지는 않는다. 많은 프로덕션 분류 요청은 여전히 2,000토큰보다 훨씬 짧다.

파라미터 수 역시 단순한 속도 비교를 복잡하게 만든다. ModernBERT-base는 약 1억4,900만 개의 파라미터를 포함하는 반면, Liquid AI의 더 작은 인코더는 약 2억3,000만 개를 포함한다. LFM2.5 모델은 더 크지만 장문 CPU 시퀀스에서는 더 빠르다고 보고됐다.

따라서 이 벤치마크는 파라미터 수 이상을 시험한다. 커널 동작, 메모리 접근, 시퀀스 길이, 런타임 구성 및 프로세서 특성은 모두 측정된 지연 시간에 영향을 준다.

이 메커니즘을 통해 설명한 LFM2.5 인코더는 어텐션 기반 모델을 보편적으로 대체하는 모델이 아니다. 혼합된 시퀀스 연산이 장문 컨텍스트 CPU 워크로드에 더 잘 맞는다는 주장이다.

개발자는 실제 입력 분포를 기준으로 벤치마크해야 한다. 짧은 메시지가 대부분인 시스템은 법률 계약서나 긴 대화 기록을 처리하는 시스템과 다른 아키텍처 선택을 선호할 수 있다.

미세 조정 후에는 전체 파이프라인 시간도 측정해야 한다. 토크나이징, 배치 처리, 출력 헤드, 후처리, 데이터 전송은 모델 단독 순전파에서 보인 이점을 바꿀 수 있다.

벤치마크 품질은 경쟁력 있지만, 증거에는 한계가 있다

Liquid AI는 신뢰할 만한 재현성 패키지를 제시했지만, 그 결과만으로 CPU, 런타임 또는 특수 작업 전반의 프로덕션 성능이 확정되는 것은 아니다.

회사는 GLUE, SuperGLUE 및 다국어 분류 스위트에서 가져온 17개 작업에 걸쳐 14개 모델을 평가했다. 각 모델은 작업별로 완전 지도 미세 조정을 거쳤다.

Liquid AI는 분리된 5개 무작위 시드의 평균값을 보고했다. 여러 시드를 사용하면 유난히 유리한 학습 실행 한 번이 순위를 결정할 위험을 줄일 수 있다.

350M 인코더는 보고된 17개 작업 평균 81.02로 4위에 올랐다. 그보다 앞선 모델은 XLM-R XL, ModernBERT-large, XLM-R large였다.

XLM-R XL은 83.06으로 선두를 차지했으며, 35억 개의 파라미터를 포함한다. ModernBERT-large는 3억 9,500만 개 파라미터로 81.68점을 기록했다. XLM-R large는 5억 6,000만 개로 81.34에 도달했다.

LFM2.5-Encoder-230M은 79.29로 6위에 올랐다. ModernBERT-base는 78.19로 7위였다. 이 평균은 Liquid AI의 인코더가 해당 규모에서 경쟁력을 유지한다는 주장을 뒷받침한다.

하지만 모든 작업에서 일관되게 선도한다는 것을 보여주지는 않는다. ModernBERT-base는 여러 개별 벤치마크에서 230M LFM2.5 모델을 앞섰고, Liquid AI가 앞선 항목도 있었다.

통합 순위는 서로 다른 평가 유형도 함께 묶는다. 작업에는 자연어 추론, 패러프레이즈 탐지, 감성 분석, 의미적 유사도, 다국어 분류가 포함된다.

평균은 일반적인 역량을 비교하는 데 도움이 되지만, 특정 배포에서 중요한 지표를 가릴 수 있다. 정책 시스템에는 관련 없는 감성 작업에서의 순위가 아니라 거짓 음성과 보정이 중요하다.

Liquid AI는 평가 하니스를 공개해 재현 기회를 높였다. 이 저장소에는 보고된 비교와 연관된 다운스트림 미세 조정 코드와 구성도 포함되어 있다.

그렇더라도 공개 코드가 독립적인 확인과 같지는 않다. Liquid AI는 학습 절차, 비교 설정, 집계 방법, 추론 환경을 선택했다.

CPU 지연 시간 주장은 가장 큰 미해결 의문을 안고 있다. 공개 글은 시퀀스 길이와 경과 시간을 설명하지만, 테스트한 CPU 구성을 명확하게 밝히지는 않는다.

이 누락은 해석에 영향을 준다. 노트북 프로세서, 클라우드 서버 CPU, 메모리 채널, 명령어 세트, 스레드 수, 전력 제한은 매우 다른 동작을 만들어낼 수 있다.

현재 로딩 안내도 trust_remote_code=True를 사용하며, 이는 저장소 제공 코드가 Transformers 라이브러리를 통해 실행되도록 허용한다. 엄격한 소프트웨어 통제를 적용하는 조직은 배포 전에 해당 코드를 검토해야 한다.

모델 카드는 성숙한 ONNX 또는 OpenVINO 배포 경로를 제시하지 않는다. 이러한 런타임은 CPU 추론, 양자화 및 크로스플랫폼 서빙을 최적화하는 팀에 중요한 경우가 많다.

양자화 성능도 또 다른 미해결 과제다. 공개된 비교는 저정밀도 변환 후 LFM2.5가 어떻게 동작하는지, 또는 동일한 상대적 이점이 유지되는지를 확립하지 못한다.

이번 릴리스에는 지속적 동시성을 다루는 프로덕션 증거도 부족하다. 긴 시퀀스 하나를 처리하는 것은 지연 시간을 측정하지만, 상시 작동하는 분류기에는 처리량, 테일 지연 시간, 메모리 사용량, 부하 상황에서의 안정성이 필요하다.

정확도에도 같은 주의가 필요하다. 벤치마크 미세 조정만으로는 조직의 계약서, 안전 규칙, 고객 언어 또는 개인정보 범주에서의 성능을 확립할 수 없다.

LFM2.5와 ModernBERT를 평가하는 팀은 동일한 하드웨어와 최적화된 설정으로 두 모델을 모두 재현해야 한다. 실제 워크로드의 짧은 문서, 중간 길이 문서, 최악의 경우 문서를 테스트해야 한다.

평가에는 실패 비용도 포함돼야 한다. 현재 시스템이 잡아내는 민감 식별자를 놓친다면, 더 빠른 PII 탐지기의 가치는 거의 없다. 라우팅 모델 역시 요청을 부적절한 다운스트림 도구로 보내지 않아야 한다.

이러한 한계가 릴리스를 무효화하는 것은 아니다. 이는 유망한 아키텍처 결과와 배포 결정 사이의 차이를 정의한다.

Hugging Face 개발자가 다음으로 주목해야 할 것

세 가지 신호가 이번 릴리스가 실용적인 CPU 표준이 될지, 아니면 흥미로운 벤더 벤치마크로 남을지를 결정할 것이다.

첫 번째 신호는 독립적인 하드웨어 재현이다. 개발자에게는 공개된 스레드 수와 메모리 구성과 함께 Apple silicon, 주류 x86 노트북, 서버 프로세서 전반의 결과가 필요하다.

재현은 8,192토큰 엔드포인트 이상을 측정해야 한다. 실제 데이터셋에는 길이가 혼재하므로 백분위 지연 시간과 시간당 처리 문서 수가 더 명확한 운영 관점을 제공한다.

독립 테스트에서도 큰 장문 컨텍스트 이점이 유지된다면 Liquid AI의 아키텍처 주장은 더 강해진다. 동일한 런타임 최적화 후 격차가 줄어든다면, 헤드라인 수치의 상당 부분은 구현 선택으로 설명될 가능성이 크다.

두 번째 신호는 최적화된 런타임 지원이다. ONNX 내보내기, OpenVINO 통합, 안정적인 양자화 레시피, 네이티브 라이브러리 지원은 실험적 Python 환경을 넘어 모델을 더 쉽게 운영하게 해줄 것이다.

이러한 추가 기능은 하이브리드 백본이 널리 배포된 CPU 툴체인에 잘 매핑되는지도 시험할 것이다. 맞춤형 즉시 실행에 의존하는 모델은 우수한 벤치마크 결과에도 불구하고 도입 마찰에 직면할 수 있다.

성공적인 8비트 또는 그보다 낮은 정밀도의 배포는 로컬 추론 논리를 강화할 것이다. 작업 정확도를 허용 가능한 범위 안에 유지하면서 메모리를 줄이고 처리량을 높일 수 있다.

반대 결과는 비교를 약화할 것이다. ModernBERT와 다른 확립된 인코더는 성숙한 최적화 경로의 혜택을 받으므로, 원시 아키텍처 속도가 최선의 배포 시스템을 보장하지는 않는다.

세 번째 신호는 작업 수준의 도입이다. Hugging Face 다운로드 수는 초기 지표를 제공하지만, 공개된 미세 조정과 재현 가능한 사례 연구가 더 중요하다.

유용한 증거에는 조직 규칙으로 측정한 정책 필터, 현실적인 식별자를 대상으로 테스트한 다국어 PII 시스템, 지속적인 애플리케이션 트래픽에서 작동하는 라우터가 포함될 수 있다.

개발자는 거짓 양성률, 거짓 음성률, 보정, 메모리 사용량, 테일 지연 시간을 살펴봐야 한다. 이러한 지표는 모델이 리더보드 순위가 아니라 시스템 자체를 개선하는지 보여준다.

Liquid AI의 미세 조정 예제는 팀에 분류 작업의 출발점을 제공한다. 다음 단계는 아키텍처를 설계하지 않은 사용자들의 증거다.

경쟁사 대응도 이러한 신호 안에서 또 다른 단서를 제공할 것이다. ModernBERT 구현은 최적화된 커널을 확보할 수 있으며, 다른 장문 컨텍스트 인코더는 하이브리드 또는 희소 처리 방식을 채택할 수 있다.

생성형 모델 벤더도 더 저렴한 분류 엔드포인트로 대응할 여지가 있다. 그러나 원격 서비스는 여전히 데이터 전송, 연결성, 로컬 제어의 제약에 직면하며, 온디바이스 인코더는 이를 피할 수 있다.

지식 근로자에게 이러한 발전은 로컬 문서 정리를 더 빠르고 비공개적으로 만들 수 있다. 계약서, 녹취록, 메모, 지원 이력은 어떤 텍스트도 통제된 환경 밖으로 나가기 전에 분류할 수 있다.

기업 구매자에게 이번 릴리스는 더 날카로운 조달 질문을 제기한다. 각 언어 작업에 생성형 추론이 필요한가, 아니면 특화 인코더가 더 낮은 인프라 요구로 필요한 결정을 제공할 수 있는가?

개발자에게 올바른 대응은 측정이다. 대표적인 테스트 세트를 구축하고, 정확도 임계값을 정의하고, 입력 길이 분포를 기록한 뒤, 배포 하드웨어에서 완전한 파이프라인을 비교하라.

Hugging Face는 LFM2.5의 두 변형과 지원 자료가 한곳에 제공되기 때문에 이러한 실험을 쉽게 만든다. 하지만 접근성이 검증을 대체해서는 안 된다.

Liquid AI는 명확한 기술적 명제를 제시했다. 아키텍처가 반복적인 전체 어텐션 작업을 제한한다면, 장문 컨텍스트 이해는 CPU에서도 가능할 수 있다. 그 벤치마크는 이 명제에 신뢰할 만한 초기 지지를 제공한다.

미해결 쟁점은 모든 모델이 동등한 최적화를 받은 후에도 독립 배포에서 이 이점이 재현되는지 여부다. 이 질문이 다음 테스트, 미세 조정, 프로덕션 보고의 물결을 이끌어야 한다.

팀이 긴 문서를 지속적으로 처리한다면, LFM2.5를 현재 워크로드를 처리하는 인코더와 비교하라. 실제 문서, 공개된 하드웨어, 작업별 오류 지표를 사용하라.

가장 중요한 결과는 또 하나의 평균 벤치마크 점수가 아닐 것이다. 작은 인코더가 전체 작업 컨텍스트를 검토하고, 정확도 요구사항을 충족하며, 데이터가 존재하는 곳에서 예측 가능하게 실행될 수 있다는 증거가 될 것이다.