tildaslashalef/nuclis는 Zig로 작성하고 Metal 백엔드를 붙인 로컬 LLM 추론 엔진이다. 2026-11-01 커밋(177daa1c, https://github.com/tildaslashalef/nuclis/commit/177daa1cd71b1fd3c4e3271bf360839a5b101df7)은 한 클라이언트 Muon이 보고한 세 가지 문제를 함께 다룬다. Muon은 `0.12.0-dev+990ba6c`에서 셋을 모두 확인했다고 적었다. 첫째는 프롬프트가 전부 캐시된 요청이 `500 model_failed EmptyPrompt`로 실패하던 문제다. Gemma 4는 툴 결과로 끝나는 렌더에서 생성 프롬프트가 없어 캐시 종료 표시가 요청 전체를 덮었고, 같은 요청을 다시 보내면 채울 토큰이 남지 않았다. 이제 `Completer`가 표시 직전 토큰을 보관해 세션을 한 칸 되돌린 뒤 그 토큰을 다시 넣어 logits를 얻는다. 되돌릴 수 없는 경우(드로프터가 로드돼 앞 토큰을 모르는 상태)에는 세션을 초기화하고 프롬프트 전체를 다시 프리필한다.
둘째는 `nemotron-asr-0.6b`가 lookahead 3에서 최종 전사문의 마지막에 'plus'를 열 번 반복한 문제다. RNN-T의 greedy 루프가 한 인코더 행에서 같은 단어 시작 조각을 계속 낸 결과였다. 이제 한 행에서 단어 시작 조각이 연속으로 두 번 나오면 그 행을 끝낸다. 이 규칙은 조각이 U+2581로 시작하는 단어 시작 토큰에만 걸고, 단어 안의 조각 반복은 허용한다. CPU의 `Decoder.decodeRow`와 Metal의 `Stream.decode` 양쪽에 함께 들어갔다. `scripts/api-check.py`에는 같은 요청을 세 번 보내고 사용자 메시지와 툴 메시지로 각각 끝나는 경우를 확인하는 `check_again`이 추가됐다.
셋째로 `reasoning_effort: "minimal"`이 생겼다. `low`와 같은 방식으로 렌더되지만 사고 과정 예산의 절반에서 닫혀, 기본 사고 예산 1,024토큰 기준 512토큰에서 끝난다. 커밋에 붙은 측정치는 Muon의 실제 `tasks_add` 요청으로, `gemma-4-26b-a4b`에서 프롬프트 4종에 시드 4개씩을 붙여 `none` 요청 직후에 보낸 결과다. `low`는 32번 중 31번이 도구 호출이나 되묻기로 응답했고 중앙값 시간은 14–20초였다. `minimal`은 512토큰에서 28/32와 10초, 256토큰에서 20/32와 5.5초였다. 256에서는 도구 호출의 3분의 1이 사라져 예산을 512로 정했다.
남은 한계도 커밋에 함께 적혀 있다. `minimal`은 32번 중 4번, 약 8분의 1의 도구 호출을 여전히 놓친다. Muon은 그 경우 `low`로 되돌아가며, `none` 요청 직후 첫 `low`는 시스템 블록이 달라 캐시 토큰을 하나도 재사용하지 못한다. 이 비용은 문서화만 됐고 아직 고쳐지지 않았다. 검사 결과 `make verify-auto`는 통과했지만 `make verify`는 71개 중 56개만 통과했고, 나머지 15개는 이 기기에 없는 모델(Muse, Bonsai, Saluki) 탓에 건너뛰었다. ASR 쪽도 60개 클립의 전사문은 lookahead 0·3·6·13에서 그대로였고 Metal WER은 6.52·6.11·6.44·6.36%로 유지됐다. CPU WER 게이트는 8.13%로, 한도 11% 안이었다. 한 클라이언트의 실사용 보고를 좁혀서 닫은 수정이니, 남은 품질 격차는 별도로 기다려야 한다.