보안 연구자 패트릭 매캐나가 9월 13일 올린 기록에 따르면 프론티어 API 에서 잘 돌던 35KB 프리프롬프트가 128GB 메모리 중 32GB 를 호스트에 주고 나머지로 27B 급 검열 해제(abliterated) 오픈 웨이트 모델을 올라마(Ollama)로 돌리는 환경에서는 65k 토큰 창의 14% 를 프롬프트만으로 차지했고, 몇 번의 상호작용 뒤 같은 도구 호출을 연달아 부르고 이미 읽은 파일을 다시 읽고 목표를 되뇌는 식으로 무너졌어요. 그가 적은 대처는 프롬프트를 문제 하나와 해법 하나짜리 단위로 쪼개고, 오픈코드(opencode)의 ~/.config/opencode/agents 에 선언형 에이전트로 정의하고, 올라마 컨텍스트 길이를 명시적으로 잡고, 세션 상태를 디스크에 기록하고, 단계당 도구 호출 수를 줄이고, '하지 마라' 대신 '이렇게 하라'로 지시를 바꾸는 것인데 모델 이름·양자화·구체 설정값·속도 수치는 글에 없어요. 해커뉴스(108점·댓글 59개)에서는 글이 원인을 제대로 풀지 않았다는 지적과 65k 창 자체가 너무 작다는 반론, 올라마 기본 컨텍스트가 4,096 토큰이라 명시 설정이 필수라는 확인, llama.cpp 나 vLLM 으로 갈아타라는 조언이 이어졌어요.
- FP8
- 가중치를 8비트 부동소수점으로 줄여 저장하는 양자화 형식
- MXFP4
- 블록 단위 배율을 붙인 4비트 부동소수점 양자화 형식. FP8 보다 메모리를 덜 쓴다
- API
- 프로그램끼리 기능을 주고받는 접점. 여기서는 클로드·오픈AI 의 원격 호출 창구
- FAQ
- 자주 묻는 질문을 모아 둔 공식 문서
로컬 모델로 에이전트를 돌리다 같은 도구 호출이 연달아 나오면 모델을 탓하기 전에 컨텍스트 창 설정부터 보세요. 올라마 공식 문서가 기본값을 4,096 토큰으로 적어 두었고, 이 글의 저자와 댓글 실사용자들이 65k 로 잡은 값조차 코딩 에이전트에는 모자라다고 적었어요. 창을 키우고도 남는 문제는 프롬프트를 목표 하나짜리로 쪼개고 단계마다 새 세션으로 시작하는 쪽이 검증된 대처예요.
- 해커뉴스 토론 — 글이 원인을 풀지 않았고 65k 창이 너무 작다는 반론 가장 위 댓글은 이 글을 '호스팅 모델 100만 토큰 창에서 돌던 프롬프트가 로컬 65k 창에서 깨졌다'는 한 줄로 줄이면서 앤트로픽 모델의 25만 토큰 창도 답답했고 보안 작업에 65k 는 모자란다고 적었고, 다른 댓글은 35KB 프롬프트라면 어떤 모델에서도 초점이 흐린 프롬프트라며 계획을 먼저 세운 뒤 단계마다 새 세션으로 돌리라고 했어요. 저자는 주말 내내 실험하고 급히 올렸다며 후속 글을 약속했어요. Hacker News
- 해커뉴스 토론 — 다른 서빙 엔진과 하드웨어 배분 조언 올라마 대신 llama.cpp 를 쓰라는 댓글과 함께, R9700 두 장에 큐원(Qwen) 27B 밀도 모델을 FP8 로 올리면 26만 토큰 창으로 세션 2~3개를 초당 60~80 토큰에, MXFP4 로 올리면 세션 4~5개를 초당 150 토큰 넘게 돌린다는 수치가 올라왔고, 라이젠 AI MAX+ 395 라면 96GB 만 주지 말고 메모리 대부분을 추론에 주고 노트북에서 원격으로 붙으라는 조언이 붙었어요. 큐원 플래시 넥스트가 4,000달러 PC 에서 오푸스 4.5 에 견줄 만하다는 댓글도 있었어요. Hacker News
- 확인 — 올라마 공식 문서의 기본 컨텍스트 값과 설정 방법 올라마 공식 FAQ 는 기본 컨텍스트 창을 4,096 토큰으로 적어 두었고, 바꾸려면 OLLAMA_CONTEXT_LENGTH 환경변수로 서버를 띄우거나 대화 중 /set parameter num_ctx 를 치거나 API 요청에 num_ctx 를 넣어야 해요. 댓글에서 같은 하드웨어를 쓰는 다른 사용자는 LLM 의 조언대로 64k 로 잡았다가 그 조언이 이름만 비슷한 다른 설정 얘기였다는 걸 뒤늦게 알았다고 적었어요. Ollama 공식 문서