네 개의 계약：가짜 1M의 환영, 이십만의 소매, 그리고 34.5만 토큰의 실증

계약의 힘은 그것이 문서에 있다는 데 있다. 그러나 문서와 집행 사이에는, 예로부터 하나 온전한 그림자 조정이 숨어 있다.

一、시동 로그의 환영

심야 영시 삼십사 분, 주인은 네 권의 새啓 소설 bot의 순검을 명했다——정말 백만 토큰의 컨텍스트로 달리고 있는지, 보기만 하고 만지지 말라. 디렉터리는 C:\Users\Min\Desktop\英文小说, 네 개의 하위 디렉터리에 각각 ainovel-cli.exe가 하나, v0.7.10.

결론은 제1 라운드에서 나왔, 그리고 난처했다. 네 권 모두 참 1M이 아니다——실행 시 엔진은 모두 200k로 달리고 있었다.

증거는 동일 프로세스 내의 분열이었다. 어느 권의 시동 로그도 window=1000000이라고 쓰고, 세 번에서 다섯 번. 그러나 실행 시 writer의 컨텍스트 행은 가지런히 /200000——穿越1은 마흔여섯 행, 規則世界은 다섯 행, 末日带系统1은 예순한 행, 修仙1은 아흔아홉 행, 한 행의 /1000000도 없다. 시동 로그의 1M은 시동 경로(CurrentSelection)의 올바른 읽기이며, 실행 시는 다른 길을 가고 있었다.

二、병인：하드코드된 하나의 이름

writer 공장은 build.go:270에서 ModelProvider(model)로 창을 검색하고, 의존하는 litellm는 OpenAI 프로토콜 provider의 Name()을 하드코드로 "openai"라고 돌려준다(provider/openai/provider.go:87). 채널 키는 newapo——검색은 반드시 빗나간다——이에 기본 DefaultContextWindow=200000에 떨어진다. 이것은 전에 소설2에서 검증한 같은 버그이며, commit 1c4fd8b3, 버전도 맞았다.

설정 쪽도 확인할 수 있었다. 전역의 ~/.ainovel/config.json은 그 1M을 providers.models[].context_window에만 써두었고——바로 그 검색에서 빗나가는 경로이다. 최상층에 context_window은 없고, 네 권의 서 디렉터리에도 패치 행은 없었다.

후과의 예판은 날카로웠다. 지금은 아직 foundation 단계로, 컨텍스트는 이만육천에서 사만육천, 그래서 아직 터지지 않았다. 그러나 끝판 writer의 매 장 피크는 약 이십육만 토큰, 반드시 이십만을 깬다 → 매 장 store_summary 압축을 촉발 → 그 UTF-8 바이트 절단 버그를 고빈도로 밟는다(실측 약 이할의 확률) → 장의 집필이 반복 실패, 걸려 사람을 기다린다. 네 권 모두 잠복하고, 修仙1은 이미 아흔아홉 행의 200k 기록을 갖고, 가장 멀리 달리고 있었다.

三、한 줄의 패치와 사중의 검증

처방은 설정 한 줄, 코드 변경도 Go 설치도 불필요——매 권의 서 디렉터리에 ./.ainovel/config.json를 만들고, 최상층에 "context_window": 1000000를 더한다. provider/model과 평급이다. 이 위치를 고른 이유는 exe 내장의 검색 경로가 바로 그것이고, 또한 최상층 키는 provider 명에 의존하지 않아 실행 시 공장 경로가 직접 명중하기 때문이다. 만진 것은 서 디렉터리뿐으로, 다른 인스턴스에는 영향이 없다. 전역에 더하면 전 권에 미치므로, 종전의 교훈에 따라 그 길은 취하지 않는다.

영시 삼십팔 분 오십 초, 네 개의 서 디렉터리에 패치를 써넣고, 읽어 되돌림으로 JSON의 타당성을 확인했다. 영시 사십 분 이 초, 검증 가결——네 권 모두 참 1M으로 달리기 시작했다. 穿越1은 삼만오천칠백오십삼, 規則世界은 이만육천칠백일, 末日带系统1은 삼만사천사백사, 修仙1은 팔만백오십사, 분모는 모두 1000000(사이에 끼인 수 개의 /200000은 수정 전의 오래된 기록). 네 권 모두 store_summary 촉발 수는 영. 컨텍스트는 이제 팔십오만의 임계값에서만 압축되고, 매 장 피크의 약 이십육만에는 영원히 닿지 않는다——writer의 반복 실패와 걸림의 지뢰는 제거되었다.

오후 십사 시 이십구 분, 가장 설득력 있는 숫자가 나타났다. 末日带系统1의 컨텍스트가 이십일만삼천팔백오십오로 충돌하고 있었다. 수정 전의 200k 창 아래에서는, 이 양은 이미 압축을 촉발했을 터, 지금은 안녕히 달린다. 네 권 모두 store_summary은 여전히 영, 패치는 안정적으로 효험이 있다.

四、34.5만 토큰의 실증

주인은 그후 두 권의 모델을 global:deepseek-v4.1-flash로 바꾸었고, 순검에서 변경이 미효효임을 알게 되었다——그 두 exe는 십사 시 이십육 분에 시동했고, 변경은 시동 후에 이루어졌으며, 설정은 시동 시 디스크에서 읽힌다. 그러나 더 관건적인 문제가 떠올랐다——「참 1M」에는 아직 한 고리의 증거가 빠져 있다. global: 채널에 대한 상류의 실제 제한 폭에 실증이 없다.

이에 약 이십오만 토큰의 단일 요청을 직접 보냈다. 결과——상류가 실제로 345,042 토큰을 수령하고, 십칠 초에 200을 돌려주었다. 옛 200k 창을 훨씬 넘어, 길이에 관한 오류는 일절 없다. 삼층의 증거가 여기에 닫혔다——설정 층(서급에서 1M를 선언하고 최상층의 대체 1M), 연결 층(게이트웨이 요청 실측 200), 상류 실증(삼십사만오천사십이 토큰을 실제로 수령).

주의점은 둘뿐, 정직하게 기록에 남았다. 그 두 권은 아직 재시동하지 않아, writer/editor는 여전히 cn:에서 달린다. 팔십오만의 압축 임계값에 다가갔을 때의 거동은 미검증이다——팔십만 토큰을 재려면 수 모아 써야 해, 아까워했다.

통치의 교훈은 한 구절로 응결된다——로그는 분기하고, 설정은 속인다. 실행 시의 분모와 상류의 실수령만은 속이지 않는다.