Question 1

MTPLX가 유휴 세션이 여전히 KV cache를 보유한 상태에서 매 재시도마다 507 메모리 제한 오류를 반환할 때 어떻게 해결해야 하나요?

Accepted Answer

MTPLX 2.12.1 이상으로 업그레이드한 다음(2.12.2가 최신 검증 릴리스입니다) MTPLX 서버를 다시 시작하세요. uv/CLI 설치의 경우 uv tool upgrade mtplx를 실행하고, 앱 설치의 경우 MTPLX를 종료한 후 다시 실행하세요. mtplx --version으로 확인하세요.

2.12.1+에서는 메모리 한도에 근접한 요청을 거부하기 전에 엔진이 자체 버퍼 풀을 해제한 다음, 현재 생성 중이 아닌 대화의 RAM 복사본을 축출하며, 가장 오래된 것과 SSD에 저장된 대화를 먼저 선택합니다. 활성 생성은 절대 축출되지 않습니다. 메모리가 여전히 확보되지 않으면 507 응답이 무엇이 메모리를 점유하고 있는지, 언제 재시도가 성공할 수 있는지를 식별합니다.

이전 버전에서의 임시 해결 방법: 유휴 세션을 중지하거나 MTPLX 서버를 다시 시작하여 라이브 KV 캐시를 해제하거나, 구성된 컨텍스트 크기를 줄이거나, 더 작은 모델을 사용하세요. 128 GB Mac에서는 2.12.1+가 기본 한도를 90 GiB로 설정하여 기본 메모리 여유 공간도 늘립니다.

Question 2

Why does MTPLX crash with HTTP 507 / out-of-memory on long prompts with Qwen3.8-27B hybrids on a 64GB Mac, and how to fix it?

Accepted Answer

This is a known bug in MTPLX 2.11.3: for non-QSA hybrid models (Qwen3.8-27B family with linear_attention + full_attention layers), the memory planner priced the prefill transient at 0 bytes/token, so it admitted a 262K context window whose actual prefill peak measured ~79 GiB — exceeding the 64 GiB machine and triggering allocation failures and HTTP 507 for clients. The #393 fix had only covered Flash-Next/QSA geometry.

**Fix:** Upgrade to MTPLX 2.12.1. The memory check now prices every request at its largest moment, including full-width rows while 4-bit paged KV pages are filled (a 250K-token prompt previously projected at 7.6 GiB actually needed 20.1 GiB). Memory pressure trims now also reach the session cache: a trim halves what the cache actually holds instead of targeting half its budget (which caused 421 consecutive no-op trims), while sparing conversations that are actively generating.

**Expected side effect after upgrading:** the planner now advertises smaller, honest max windows — e.g. ~60K tokens on a 48GB MacBook — instead of an overcommitted 262K. This is correct behavior, not a regression.

**Workarounds on 2.11.3 (not a fix):** cap the window at or below the dense-decode ceiling (15% of RAM ÷ 65,536 bytes/token ≈ 157K tokens on 64 GiB), and set `MTPLX_SESSION_BANK_MAX_BYTES=4G`, `MTPLX_SESSION_BANK_MAX_ENTRIES=12`, `MTPLX_MEMORY_LIMIT_BYTES=54G`, `MTPLX_CLEAR_CACHE_EVERY=auto`. Deep prompts may still shed by design.

Question 3

MTPLXApp이 실행될 때마다 Hermes config.yaml에서 memory, providers, delegation, auxiliary 같은 섹션을 삭제하지 못하게 하려면 어떻게 해야 하나요?

Accepted Answer

이 문제는 MTPLXApp 1.0.4 (build 10012)가 `~/.hermes/profiles/mtplx/config.yaml`을 고정된 템플릿으로부터 다시 생성하면서 앱이 인식하는 키만 보존하기 때문에 발생합니다. 해당 버전에는 공식 수정 사항이 없습니다. `chflags uchg`를 사용하지 마세요. 재작성은 막아주지만 MTPLX가 "Messaging needs repair"를 표시하고 세션 시작을 거부하게 됩니다. 효과적인 임시 해결책은 macOS LaunchAgent를 사용해 구성 파일을 감시하고, 재작성이 발생할 때마다 누락된 YAML 섹션을 즉시 다시 병합하는 것입니다. 1. yq를 설치합니다: ```bash brew install yq ``` 2. 사용자 지정 Hermes 설정을 저장합니다. 예를 들어 `~/.hermes/profiles/mtplx/custom-config.yaml`: ```yaml memory: provider: honcho providers: {} delegation: {} auxiliary: {} model: max_tokens: 8192 ``` 3. `~/bin/restore-mtplx-config.sh`를 생성합니다: ```bash #!/bin/bash set -euo pipefail CFG="$HOME/.hermes/profiles/mtplx/config.yaml" SNIP="$HOME/.hermes/profiles/mtplx/custom-config.yaml" TMP="$(mktemp)" [ -f "$CFG" ] || exit 0 [ -f "$SNIP" ] || exit 0 yq eval-all '. as $item ireduce ({}; . * $item)' "$CFG" "$SNIP" > "$TMP" if cmp -s "$TMP" "$CFG"; then rm -f "$TMP" else mv "$TMP" "$CFG" fi ``` 실행 가능하게 만듭니다: ```bash chmod +x ~/bin/restore-mtplx-config.sh ``` 4. `~/Library/LaunchAgents/local.mtplx-config-restore.plist`를 생성하되, `/Users/you`를 실제 홈 디렉터리로 바꿉니다: ```xml Label local.mtplx-config-restore ProgramArguments /bin/bash /Users/you/bin/restore-mtplx-config.sh WatchPaths /Users/you/.hermes/profiles/mtplx/config.yaml RunAtLoad ``` 5. 로드합니다: ```bash launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/local.mtplx-config-restore.plist ``` 이미 로드되어 있는 경우, 먼저 `launchctl bootout gui/$(id -u)/local.mtplx-config-restore`를 사용한 다음 다시 bootstrap하세요. 영구적인 애플리케이션 수정 방법은 MTPLXApp이 전체 파일을 다시 빌드하는 대신 기존 YAML을 그대로 유지(round-trip)하면서 자체 관리 키만 덮어쓰도록 하는 것입니다. 해당 수정이 출시될 때까지는 WatchPaths 에이전트가 실행을 거듭해도 사용자가 추가한 Hermes 섹션을 보존해 줍니다.

Question 4

MTPLX에서 툴 호출 후 이미지를 보낼 때 "vision requests must not use the session bank without content-keyed ids" 오류를 어떻게 수정하나요?

Accepted Answer

이것은 MTPLX 2.12.0의 버그입니다: 비전/이미지 메시지가 tool-call/tool-result 턴 뒤에 오면 스트리밍 chat completions가 실패하지만, 동일한 요청은 스트리밍 없이 작동합니다. 임시 해결 방법으로 /v1/chat/completions에서 "stream": false로 요청을 보내거나, 가능하다면 OpenAI 호환 클라이언트/프로바이더 구성에서 스트리밍을 비활성화하세요. 스트리밍을 활성화한 상태로 재시도해도 해결되지 않습니다. 이미지와 도구 기록은 그대로 유지하고, 수정된 MTPLX 릴리스가 나올 때까지 스트리밍만 끄세요.

Question 5

128GB Apple Silicon Mac에서 RAM이 아직 남아 있는데도 mtplx "insufficient memory: prompt projects against the engine's 96.0 GiB limit" 오류를 해결하려면 어떻게 해야 하나요?

Accepted Answer

96 GiB 값은 현재 사용 중인 RAM 용량이 아니라 mtplx의 사전 점검(preflight) 메모리 예산입니다. 먼저 Apple의 GPU wired-memory 상한을 늘리세요: `sudo sysctl iogpu.wired_limit_mb=124518`. 그런 다음 더 작은 호스트 예약 값으로 mtplx를 다시 시작하세요. 변수 이름이 `*_BYTES`이므로 `6G` 대신 원시 바이트 값을 사용해야 합니다. 6 GiB 예약의 경우: `MTPLX_HOST_MEMORY_ALLOWANCE_BYTES=6442450944 mtplx serve --model Youssofal/Qwen3.8-Flash-Next-MTPLX-Optimized-Speed --model-id mtplx-flash-next-optimized-quality --host 0.0.0.0 --port 8080 --api-key my-secret-key`. 재시작 후 보고되는 엔진 한도가 96 GiB보다 높은지 확인하세요. 요청이 여전히 추정치를 약간 초과하고 macOS 스왑과 성능 저하를 감수할 수 있다면 `mtplx serve` 명령에 `--allow-swap`을 추가하세요. 대안으로는 q8 KV 양자화 활성화, 프롬프트 길이 줄이기, 또는 새 대화 시작이 있습니다.

MTPLX

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트