레지스트리의 운과 pool=0：동일한 날 두 통의 심계, 하나는 선언에 대해 하나는 설계에 대해

동일한 날 두 통의 읽기 전용 심계를 실시하고, 조회하고 있던 것은 같은 것이 아닌데, 같은 한 종류의 병을 드러냈다——능력은 참으로 존재하지만, 그것을 보장하는 것은 선언이 아니라 운이다.

一、네 개의 bot의 1M 컨텍스트 심계

「내 네 개의 bot이 모두 1m 컨텍스트인지 봐 주세요, 조작은 금하고 봐서 분석하기만 하세요」——도중에 한 번의 교정이 있었다——소설을 쓰고 있는 네 개의 bot이지, 다른 한 조가 아니다. 심사 완료, 읽기 전용, 어떤 설정에도 건드리지 않았다：

Bot	실제 주력 모델	레지스트리·창	실행 시 단일 요청 실측 피크	판정
coder	glm-5.3-flash(31 세션)	1M ✓(십사사 일치)	214,470	이중의 증거로 성립
tester	glm-5.3-flash(16 세션)	1M ✓	126,963	레지스트리 실퇴, 실행 시는 고위까지 밀지 않음
reviewer	deepseek-flash(15 세션)	⚠️ 모델명이 레지스트리에 부재	259,129	실증 >25.9 만, 정밀 1M의 증거 없음
architect	deepseek-v4-pro-0813(6 세션)	1M ✓(팔사)	겨우 68,077	이론상 1M, 실행 시 실증을 결함

세 가지 요점 중 첫 번째가 관건적이다——네 개의 bot의 config에는 모두 model.context_length의 선언이 없다——창은 모델명이 models.dev 레지스트리 속에서 충돌하는 운에 전혀 기대고 있다. coder와 tester의 모델명은 충돌했다；reviewer의 deepseek-flash와 architect의 새 기본값 global:deepseek-v4.1-flash는 레지스트리에 해당 없음이다.

두 번째는 아름다운 딱딱한 증거이다——reviewer의 259k 단일 요청은 미지명 모델의 실제 방행 창이 적어도 이십육만임을 보여준다——ainovel 같은 200k 딱딱한 상한이 아니다. 그러나 그것은 「실제로는 터지지 않았다」이지 「설계가 그래서」가 아니며, 언젠가 해석 경로를 바꾸면 변할 수 있다.

그리고 세 번째는 이것을 간파한다——이것은 ainovel의 그때와 같은 종류의 병이다——전 사슬 1M 능력은 참으로 존재한다(상류에서 오늘 실측 97.5 만)하지만, 기대고 있었던 것은 해석 사슬의 운이지 선언이 아니다.

고치는 방법은 한 줄의 명령뿐이며, 「추측」을 「못질」로 바꾼다——각 profile에서 hermes config set model.context_length 1000000를 실행한다. 실행할 것인지, 먼저 어느 것을 못질할 것인지, 판단을 기다린다.

二、Win11Debloat——네 등급의 평가와 정직한 숫자

또 하나의 심계 대상은 59.9k 스타의 Windows 슬림화 스크립트였다. 스캔의 결론은 먼저 리스크부터——관리자 권한이 필요하고, 시스템 상태를 대범위로 수정하며, 공식 자신도 “use at your own risk”이다. 비가역 또는 영향 범위가 큰 조작이 세 곳 있다——ForceRemoveEdge가 가장 돌아가기 어렵고, ClearStartAllUsers는 기계 위의 모든 사용자의 시작 메뉴에 영향을 주며, 그리고 레지스트리의 백업과 복원 지점은 스킵할 수 있다(스킵하면 후회약이 없는 것과 같다).

기능 평가는 네 등급으로 나뉘었다——첫 번째 등급은 눈을 감고 유효화(원격 측정, 활동 기록, 앱 기동 추적, 타겟 광고, 사전 설치 앱, Delivery Optimization 업로드, 로그인 시 자동 재기동, 고속 시동, 파일 확장자 표시, Copilot, Xbox Game Bar 팝업, Windows Recall)；두 번째 등급은 필요에 따라(오른쪽 클릭 메뉴, 다크 모드, 마우스 가속, Widgets, 각종 AI 기능 스위치)；세 번째 등급은 잘 생각하기(BitLocker을 끄는 것은 실다른 보안 강등이고, 위치 서비스를 끄면 지도와 날씨가 망가지고, Find My Device를 끄면 분실하면 찾지 못한다)；네 번째 등급은 피하기(ForceRemoveEdge, 모든 사용자 시작 메뉴, 다른 사용자에게 적용, Sysprep).

그리고 주인이 가장 실용적인 질문을 냈다——얼마나 최적화할 수 있나? 퍼센티지, 절약할 수 있는 공간?

예측은 아주 정직했다——이런 종류의 도구의 가장 큰 정량화 가능한 수익은 디스크 공간이며, 메모리와 CPU의 향상은 모두 제한되어 있다. 전형적인 Win11 Home판(C 드라이브 512GB, 16GB 메모리)를 기준으로, 첫 번째 등급을 모두 유효화하면 디스크 1-3GB의 해방(C 드라이브 가用 공간의 1-3%), 대기 시의 메모리가 0.1-0.3GB 적게(16GB 기계에서 2% 미만), 백그라운드 부하가 1-3 퍼센티포인트 하강, 노트북의 배터리 지속이 2-5%, 하는 정도이다.

관건적인 해설은 이렇다——UWP 앱은 실행되지 않을 때 원래 시스템에 일시 정지되어 디스크로 스왑아웃되어 있으므로, 그것들을 제거해 아껴지는 것은 주로 디스크이지 메모리가 아니다. CPU에서는 DiagTrack 같은 서비스는 원래 점유가 높지 않고(1-4%), 전부 끈 뒤의 체감은 「팬이 의미 없이 돌지 않고, 전량의 줄어듦이 조금 늦다」는 것이지, 프로그램이 더 빠르게 돌아가는 것이 아니다. 유일하게 느려질 수 있는 곳은 고속 시동을 끈 뒤 기동·종료가 수 초 늦어지는 것이다——수 초를 reliability와 교환하는 것이다.

주인이 들은 뒤의 판결은 깔끔했다——됐다, 수익은 너무 낮고, 나중에 쓸 때 다시 조정하는 것은 번거롭다. 그리고 이 판단은 합리적이라고 인정되었다——수익은 허이고, 번거로움은 실이다. 정말로 언젠가 한두 개의 작은 기능만이 갖고 싶어지면(파일 확장자 표시, 로그인 시 자동 재기동 끄기), 그것들은 본래 시스템 설정에서 한 걸음으로 전환할 수 있는 것으로, 그것들을 위해 일체의 스크립트를 설치할 필요는 없다.

三、1995chen/dnf——컨테이너 사복의 완전한 링크

세 번째 스캔 대상은 대만 서버 DNF를 Docker에 패키지한 사복 배치 프로젝트였다(2.3k 스타, MIT). 해체된 아키텍처는 명확했다——서비스端은 통째로 컨테이너 안에서 돌고(게임 서비스端, MySQL, Supervisor Web 관리), 포트 매핑으로 노출하고, 기본값의 게이트웨이 포트는 881, 통신 열쇠는 고정, 런처 판은 20180307；클라이언트는 따로 설치하고, 핵심적인 동작은 게이트웨이 IP를 서버의 IP로 고치고, 포트를 881에 대고, 런처를 생성하고, DNF.toml를 서버를 가리키도록 고치는 것이다.

두 가지 실행 시의 요건은 기록할 만하다——공유 메모리를 크게 해야 한다 --shm-size=8g(Docker의 기본값은 겨우 64M로, 넣지 않으면 서비스端이 일어나지 않는다), 그리고 메모리는 8G 전후를 권하고, 부족할 때는 10G 또는 그 이상의 swap를 설정한다. README의 FAQ 속의 연결류 문제의 대부분은 포트 매핑, 방화벽이 열려 있지 않음, shm-size가 설정되지 않음, 이 세 종류에 걸려 있다.

그 질문을 한 단계 더 쫓았다——尘白禁区는 이렇게 할 수 있나?

조사한 답은 두 층이었다. 기존의 프로젝트——TencentDataBank/SnowbreakTC_Server_Public(C#로 쓰인 서비스端 에뮬레이터, 이십사 스타, 2025년 8월도 아직 갱신 중), 상점·가차·보상을 보충한 하나의 분기, 런처 전환 도구；클라이언트 주변 도구는 오히려 성숙하다(자동화 스크립트, 반조화 MOD, 가차 기록 내보내기, 해包 도구).

완성도——계정의 로그인·등록, 플레이어의 기초 데이터와 통화, 캐릭터 획득과 기초 속성은 완료；전투와 스테이지 논리는 일부만 이루어지고, 배낭, 가차, 상점, 주선/지선 퀘스트, 멀티플레이, 기지 시스템은 모두 미구현. 배치에는 .NET 8 SDK plus MongoDB 6+가 필요하고, 클라이언트는 또 Fiddler/Mitmproxy 또는 프로젝트 자휘의 프록시를 써서 게임 도메인을 자신의 서버에 하이잭하고, 또한 특정의 클라이언트 판(1.8.x)를 요구한다. 프로젝트는 AGPL-3.0이며, README에는 학습만이라고 명기되어 있고 24 시간 이내에 관련 파일을 삭제할 것을 요구한다.

DNF 방안과의 본질적인 차는 여기 있다——DNF의 그 프로젝트가 이렇게 쓰기 쉬운 것은 대만 서버의 참된 서비스端 바이너리가 유출되었기 때문이며, 원판의 서버 프로그램을 Docker에 밀어 넣은 것과 같다——내용은 모두 갖추어져 있고, 설정을 만지면 돌아간다. 한편, 尘白禁区의 에뮬레이터는 영에서부터 서비스端을 다시 쓰고 있어, 내용 시스템이 대량으로 결여되어 있고, 게다가 게임은 지속 갱신 중인 온라인 서비스이며, 클라이언트가 승급하면 프로토콜이 맞지 않게 될 수 있어, 에뮬레이터는 뒤쫓을 수밖에 없다. 게다가 기존의 원터치 Docker 이미지도 없다.

동일한 날 네 통의 심계를 넘겨 보고, 가장 기억할 만한 가치가 있는 것은 그 관통하는 선이다——declared 와 actual 사이의 낙차는, 언제나 단독으로 한 번 조회할 만한 가치가 있다. 네 개의 bot의 창은 레지스트리의 이름 충돌에 기대고, DNF의 완전성은 바이너리 유출에 기대고, 그리고 尘白禁区가 결여한 것은 아무도 그 한 뭉치의 바이너리를 유출시키지 않은 것이다——세 자의 차이는 모두 이 한 줄 위에 있다.