이 페이지는 영어 문서의 번역입니다. 명령, 식별자, 예제는 그대로입니다. 런타임 7.24.5 · SDK 2.6.9. 영어 원문

로컬 추론 측정: 2026년 9월 19일

상태: 활성

범위: 측정된 진단 스냅샷

최종 검토: 2026-09-19

담당: ax-code 런타임

로컬 접두사 수정 뒤의 완전한 여섯 조합 클라이언트 행렬은 새로운 AX Code와 OpenCode 재시험을 보십시오. 아래의 클라이언트 속도는 원래 조건에서의 역사적 관찰로 남습니다.

이 측정은 통합 메모리 128 GiB의 Apple M3 Max 한 대에서 로컬 응답 지연과 디코드 속도를 조사합니다. 하드웨어 자격 확인도, 모델 품질 평가도, 임의의 맥락 길이에서 초당 30–40토큰이라는 약속도 아닙니다. MTPLX와 oMLX 연결 지침은 로컬 런타임 가이드에 있습니다.

조건과 시간

• AX Code 소스는 v7.19.3에 기반합니다. OpenCode 1.18.31, AX Engine 7.4.0, MTPLX 2.11.3, oMLX 0.6.4(1d7826185c5b5b69b38b27cbe57d7597b7551fd7, 분리된 소스 설치)입니다.
• 한 번에 추론 백엔드는 하나입니다. 팬 제어는 기본값이며, 최대 팬이라는 주장은 없습니다. 모델 파일은 SMB 저장소에 있었습니다. MTPLX의 정확한 산출물 실행은 MTP 사이드카만 SSD에 준비했고, SHA-256을 검증했습니다.
• 정확한 산출물 재생은 AutomatosX/AX-Qwen3.8-27B-MLX-AXQ-6bit-MTP, 리비전 4d36d652c21590f6813495351c3baf5fca5b3831를 사용했습니다. 별도의 MTPLX Optimized-Speed 클라이언트 실행은 Youssofal/Qwen3.8-27B-MTPLX-Optimized-Speed를 사용했습니다. 전체 파일 크기는 비슷해도 서로 다른 모델 패키지입니다. 그 속도로 런타임만의 속도 향상을 분리할 수는 없습니다.
• 공통 재생 설정: temperature 0.55, top-p 1, top-k 0, seed 0, 생성 토큰은 최대 256개입니다. AX Engine과 MTPLX는 활성 MTP 깊이 3을 사용했습니다. 런타임 커널과 추측 샘플러는 다릅니다. 산출물 메타데이터는 깊이 1을 선언합니다. 여기서의 깊이 3은 명시적인 런타임 실험이며, 산출물 인증의 확장이나 새로운 기본 권고가 아닙니다. AX Engine은 고정 출력 네이티브 재생에서 EOS를 무시했습니다. MTPLX와 oMLX는 자신의 중지 규칙을 따릅니다.
• 네이티브 디코드 속도는 백엔드 디코드 카운터를 사용합니다. 전달된 속도는 (reported completion tokens - 1) / (last output payload time - first output payload time)입니다. 빈 이벤트와 keepalive는 출력으로 치지 않습니다. 이 경계는 서로 같지 않습니다.
• 첫 페이로드 지연에는 서버의 요청 준비, 캐시 복원과 프리필, 출력 전의 버퍼링이 포함됩니다. 전체 토큰을 요청 전체 시간으로 나눈 값은 다른 처리량 척도입니다. 도구 호출이 몰리는 구간은 첫 페이로드부터 마지막 페이로드까지의 디코드 추정에 적합하지 않습니다.

예를 들어 같은 MTPLX 30k 입력 재생은 네이티브 디코드 초당 13.99토큰을 측정했지만, 완전한 요청으로는 초당 1.13토큰이었습니다. 차가운 프리필이 약 209초를 썼기 때문입니다. 요청 전체 수치가 낮다는 사실만으로 디코드 엔진 실패라고 할 수는 없습니다.

정확한 가중치의 AX Engine과 MTPLX 재생

각 쌍은 같은 정수 입력 토큰 열을 받고 256토큰을 냈습니다. 아래 값은 단일 관측입니다. 시드가 같아도 생성된 토큰의 정체는 다를 수 있습니다.

MTPLX는 이 산출물에 Sustained 프로필을 사용했습니다. 30k AX Engine 요청은 따뜻했고 MTPLX는 차가웠으므로, 첫 토큰 시간으로 프리필 속도 비를 확정할 수 없습니다. 30k 입력에는 역사적인 단계 한도 지침이 들어 있고 진단용 산문을 만듭니다. 코딩 작업의 수용이 아닙니다. 18,643토큰 MTPLX 재생은 256토큰 뒤에 stop를 보고했고, length는 보고하지 않았습니다.

짧은 프롬프트는 비슷한 디코드 속도를 보입니다. 이 실행은 어느 백엔드가 보편적으로 더 빠르다거나, AX Code를 다른 백엔드로 바꾸면 고정된 속도 향상이 보장된다는 것을 보여 주지 않습니다.

MTPLX Optimized-Speed 위의 AX Code와 OpenCode

두 클라이언트는 같은 사용자 작업, 전체 프로젝트 지침, 허용된 도구 스키마 네 개를 받았습니다. 작업은 도구를 실행하지 않고 TypeScript LRU 캐시를 요청했습니다. 클라이언트별 프롬프트는 유지되었습니다. 기록 프록시는 샘플링을 맞추고, 사고를 끄고, 요청과 서버 상한을 1024토큰으로 두었습니다. 다음 응답은 정상적으로 완료되었습니다.

이 측정은 AX Code의 로컬 접두사 수정(42908b46a)보다 앞섭니다. AX Code는 더 많은 맥락을 보냈고 다른 코드를 만들었습니다. 토큰이 같은 클라이언트 오버헤드 비교도, 전후 결과도 아닙니다. 별도의 재생에서 자동으로 훑은 디렉터리 지도만 제거하면 입력이 30,717로 줄었지만, 관측된 디코드는 약 2%만 나아졌습니다. 디렉터리 지도 제거는 채택되지 않았습니다.

별도의 AX Engine 어댑터 행렬은 AX Code가 입력 토큰 33,225에서 전달 초당 9.44–11.56, OpenCode가 17,290에서 12.82–13.00을 보였습니다. 프롬프트 길이, 출력 내용, 캐시 상태, 256토큰 출력 상한이 위의 완전 응답 표와 다릅니다. 이것을 하나의 백엔드 속도 향상 비로 합치지 마십시오.

oMLX

oMLX 시험은 정확한 AXQ 산출물과 MLX 0.32.0의 분리된 설치를 사용합니다. qwen35_prefill와 decode_fast를 포함한 네이티브 커널 가져오기 검사 다섯 가지가 모두 통과했습니다. 텍스트만 불러오기가 명시적으로 선택되고, 맥락 창은 65,536이며, 동시성은 하나입니다.

처음의 Lightning MTP 시도는 HTTP 409를 반환했습니다. 시험이 oMLX가 요구하는 MTP 사이드카 가져오기 단계를 건너뛰었기 때문입니다. 이것은 설정 오류이며, AXQuant 지원이 없는 것이 아닙니다. AXQuant는 이미 정규 qwen3-next-mtp 계약을 제공했습니다. 현재 Hub 리비전 b0784088d4026ca569c5653e6e6243c501ef5fa9에는 MTP 텐서 15개를 나열하는 axquant_omlx_compat.json도 포함됩니다. 원래 재생 스냅샷은 그 주석보다 이릅니다.

MTP를 끈 기준선은 원래 산출물로 완료되었습니다.

이것은 MTP를 끈 결과이며, MTP를 켠 런타임과 비교하여 백엔드 고유의 속도 차이에 대한 증거로 쓰면 안 됩니다. 토크나이저 왕복과 서버 프롬프트 개수는 다른 재생 백엔드가 쓴 정수 입력과 맞았습니다.

수정된 MTP 실행은 따로 쓸 수 있는 사본에 oMLX 자신의 가져오기 도구를 사용합니다. 백본 샤드는 바뀌지 않습니다. 가져오기 도구는 사이드카 텐서 이름 15개에 language_model.를 더합니다. 각 텐서의 dtype, 형태, 페이로드 해시는 가져오기 전과 후가 같다고 검증되었습니다. 따라서 가져온 파일의 해시는 헤더가 바뀌었기 때문에 다릅니다. 원래 메타데이터와 공유 모델 스냅샷은 그대로입니다. MTP 깊이 3이 명시적으로 선택되고, 깊이별 드래프트와 수용 카운터가 실제 실행을 확인합니다.

짧은 결과는 이 AXQuant 팩이 가져온 뒤 oMLX Lightning MTP와 동작함을 확인합니다. 활성 MTP가 있어도 긴 맥락 디코드는 더 느린 채로 남습니다. 생성된 텍스트, 런타임 버전, 커널, 추측 정책이 다르므로, 런타임 사이의 차이를 모두 AX Code 탓으로 돌릴 수는 없습니다.

코딩 흐름 수용과 제외

로컬 접두사 수정 뒤, AX Code는 AX Engine과 MTPLX 모두에서 분리된 읽기 전용 작업을 마쳤습니다. 디렉터리와 TypeScript 파일 두 개를 읽고, 큐가 가득 찬 예외를 설명하고, 용량 7을 식별하고, 두 번째 파일에만 있는 표지를 반환하는 일입니다. 둘 다 성공적으로 종료했고 픽스처 바이트를 보존했습니다. 이후 AX Engine 호출은 입력 토큰 11,264개를 재사용했습니다. MTPLX는 11,264–12,032개를 재사용했습니다. 첫 요청 본문은 같았지만, 런타임 템플릿이 다른 토큰 수를 만들었습니다. 이것은 도구 흐름과 관측된 캐시 재사용을 검증하며, 패치로 인한 고정 속도 향상은 아닙니다.

새 공급자 ID도 소스 CLI에서 실시간 수용을 통과했습니다. omlx는 가져온 AXQ 팩과 명시적 tool_call: true를 사용했고, mtplx는 구성된 모델 항목이 없는 Optimized-Speed 팩을 사용했습니다. MTPLX는 네이티브 모델 목록에서 채팅 모델과 도구 능력을 발견했습니다. 두 실행 모두 파일 읽기 두 번을 성공하고, 기대한 예외, 용량, 파일에만 있는 표지를 반환했으며 픽스처 바이트는 바꾸지 않았습니다. 처음의 시스템과 사용자 접두사는 각 실행의 요청 세 개에 걸쳐 같게 남았습니다. oMLX는 8,192토큰을 재사용했습니다. MTPLX는 11,829토큰과 12,047토큰을 재사용했습니다. 이것은 기능 검사이며, 맞춘 성능 실행이 아닙니다. 런타임 사이의 벽시계 속도 향상은 주장하지 않습니다.

더 이전에 256토큰으로 잘린 AX Code 응답은 잘려서 복구에 들어갔습니다. 초당 약 51–58토큰의 반복 출력 속도는 새 생성 주장에서 제외합니다. 프로젝트 지침이나 도구 권한이 같지 않은 처음 실행도 제외합니다. Ollama와 LM Studio는 요청 구성만 살펴보았습니다. 그들에 대한 생성 속도 결과는 주장하지 않습니다.

일반적인 62토큰 프롬프트는 정확한 oMLX 완성 요청으로 공개되어 있습니다. 체크아웃 루트에서 사이드카를 가져온 뒤 MTP를 켜고 모델을 예열한 다음, 다음으로 보낼 수 있습니다.

curl --no-buffer http://localhost:8000/v1/completions \
  -H 'Content-Type: application/json' \
  --data-binary @docs/data/local-inference-short-request.json

요청의 모델 ID를 서버가 노출하는 ID로 바꿉니다. 파일에는 렌더링된 템플릿이 들어 있습니다. 채팅 템플릿이 두 번 적용되지 않도록 완성 엔드포인트를 사용합니다. 프롬프트 토큰 62개를 확인하고 마지막 사용량 이벤트를 보관합니다. 차가운 모델 로드와 예열은 따로 보고해야 합니다.

비공개 프로젝트 지침, 세션 프롬프트, 로컬 경로, 인증 세부 사항은 공개하지 않습니다. 정제한 측정 데이터에는 프롬프트 텍스트가 아니라 개수, 시간, 런타임 정체, 입력 해시가 들어 있습니다. 따라서 완전한 비공개 맥락 재생은 그 자체로 공개 재현 가능한 작업이 아닙니다. 새로운 비교에는 같은 모델 리비전, 토크나이저와 템플릿, 입력 ID, 출력과 중지 규칙, 샘플링, MTP 모드, 캐시 상태, 하드웨어, 직렬 실행을 사용합니다. 완전한 작업의 성공은 따로 보고합니다.

업스트림 계약: MTPLX 서버와 모델 가이드, oMLX 0.6.4. 그들이 공개한 벤치마크는 다른 하드웨어와 작업을 쓰며, 여기의 측정을 대체하지 않습니다.