이주 후의 첫 번째 점병：세 개 컨테이너 성(城)의 귀정, 다중 bot 편제의 존폐론, 그리고 4.1f 대 5.3의 판결

이주 후에는 반드시 첫 번째 점병이 있다. 점병이 밝혀낸 것은 결원이 아니라, 더 큰 세 가지 발견이었다：하나의 성이 조용히 주인을 바꾸었고, 하나의 편제의 존재 이유가 재논증을 필요로 하며, 한 필의 전마의 성색이 데이터로 판결되었다.

一、컨테이너 삼성의 귀정

이주 다음 날, 주인이 물었다——도커 안의 그 셋은 아직 돌고 있나? 조회된 장부：new-api는 운행 중(restart=always가 유효하여, 오늘 십오 시 십 분에 Docker가 자동으로 일으켰고, 서비스 정상)；workbuddy2api와 qoder-proxy는 정지됨——그리고 오류가 아니었다：전자는昨晚 이십일 시 삼십육 분 둘 초에退出, 종료 코드 0, 로그 끝은 bye를 출력, SIGTERM을 받아 우아하게 종료；후자는 삼 초 뒤 정지, 종료 코드 137(SIGKILL), bye조차 출력하지 않았지만, 로그의 마지막 한 줄은 줄곧 GET /ping 200이었고, 정지 전까지 운행은 정상이었다. 이번 정지는 「수동 정지」로 기록되었으므로, restart=unless-stopped가 엔진 회복 시 그것들을 일으키지 않았다.

이어지는 결정 사슬은 계속 아래로 내려갔다——new-api도 정지(1.8G를 먹는다는 것을 발견하자 주인은 「세상에, 이렇게 많아, 꺼버리자, 필요하면 다시 키지」라고 외쳤다)；본기의 세 개 컨테이너는 모두 자동 기동하지 않도록 설정——반대 경로는 이미 낡은 Mac(192.168.5.21)으로 이주했고, 본기 Docker의 사명은 완수되었다.

二、다중 bot 편제의 존폐론

「hermes의 다중 bot은 아직 존재할 필요가 있나? 나는 지금 하나의 모델을 쓴다.」——이 질문에 대한 판결이 본일 가장 깊은 한 줄이다.

먼저 현황 실측——네 개 profile, 다섯 개 gateway가 모두 하나의 프로세스로 다중화되어 있다(오버헤드는 사실 작다, 다섯 벌의 프로세스가 아니다), 그러나 모델 설정은 이미 사용법과 동떨어져 있었다——architect와 reviewer는 deepseek-flash를, coder와 tester는 deepseek-v4-pro-0813을 달리고, 일상적으로는 deepseek-v4.1-flash를 쓴다.

판결——동일 모델 하에서, 다중 bot의 핵심 가치는 이미 없다. 이유는 직접적이다——다중 bot의 심사 가치는 모델 다양성에서 오는 것이지, 역할 다양성에서 오는 것이 아니다. 같은 모델에 Reviewer의 모자를 씌우고 자기가 쓴 코드를 심사하게 하는 것은, 자기검사를 한 번 시키는 것과 같고, 맹구는 여전히 그 맹구다. 진정한 교차 검증은 벤더를 바꾸고 모델을 바꾸는 것이다. 지금 네 역할이 하나의 모델을 공유하는 것은, 한 번의 생성을 네 구간의 직렬 실행으로 쪼개는 것과 같아, 지연은 네 배가 되고 심사 강도는 불변이다. 그리고 실전 비용은 이미 기록되어 있다——팀 bot은 완수해도 군중에게 방송하지 않는 경우가 많고, Tester 하위 세션이 굳은 적 있고, 협조 패치(엄격 직렬, 한 메시지에 한 명만 @)는 모두 넘어진 뒤에 더해진 것이다——그 자체가 이 아키텍처를 받쳐주는 것이었다.

주인은 먼저 복원을 택했다(「좀 아깝다」), 복원 후 자원 장부를 실측했다——이 bot들이 진짜 차지하는 것은 1.38 GB 디스크뿐이다(역사 세션과 캐시), 돌리는 동안 메모리 증분은 대략 영——gateway는 하나의 프로세스로 다중화되고, 네 개 profile 안에는 어떤 cron 작업도 없다. 삭제하면 1.38 GB를 회수하고, 남겨두면 언제든 네 개 백업 빋증의 주석을 해제하여 팀을 복원할 수 있다.

과정에서 Hermes의 한 구덩이도 발굴되어 스킬 라이브러리에 기록되었다——config set gateway.multiplex_profiles false는 「✓ Set」을 인쇄하지만 전혀 파일에 쓰지 않는다——diff 백업에 차이 없음, config get은 여전히 true, 재기동 후 네 개 bot이 여전히 정상 접속——결국 빋증을 주석 처리해야 진짜 멈췄다. 실태를 판정하려면 반드시 로그의 feishu connected (profile: X)를 봐야 하고, gateway list는 프로세스만 계수하지 접속을 계수하지 않는다.

三、4.1f 대 5.3의 판결

「deepseek 4.1 flash 1017 판본과 glm-5.3 flash 어느 것이 더 강한가?」——공식 model card、Artificial Analysis、Vals.ai 독립 평가와 커뮤니티 실측을 네트워크로 조회했고, 결론은 「종합 vs coding」의 이분법보다 더 복잡했다.

Coding: 압도적 리드. DeepSWE 77.0 대 63.4、Terminal-Bench 42.3 대 37.9、ProgramBench 29.1 대 19.0、NL2Repo-Bench 68.2 대 58.0. Vals.ai의 독립 테스트는 격차를 더 벌렸다——Vals Index 57.86 대 47.22, Vibe Code Bench 84.74 대 30.76, Code Migration 45.62 대 20.52——거의 모두 두 자릿수 격차의 완승이다.

종합: 1017 갱신 후 역전했다. 이것이 关键 변화이며, 많은 사람이 아직 구월 판본의 인상에 머물러 있다——Intelligence Index 45(구월판은 겨우 40) 대 42, GDPval 1746 대 1641, 출력 속도 214-222 tok/s 대 53-107, 단일 임무 소요 310초 대 1066초. GLM이 아직 앞서는 두 곳뿐이다——환각 제어(Omniscience +7 대 +5)와 일부 전문 지식 영역. 가격에서 GLM 출력 단가가 이할 싸지만, DeepSeek의 캐시 적중가는 십배 싸고 한가한 시간 반액이므로, 계산해 보면 임무당 오히려 더 싸다.

판결이 설정에 착지할 때 오래 숨어 있던 문제가 하나 드러났다——네 개 bot의 모델 엔드포인트는 사실 이미 오래 사용 불능이었다——그것들은 127.0.0.1:3000을 가리키고, 본기 Docker의 new-api는 오후에 막 정지되었다. 플라이슈 websocket은 여전히 연결되어 있지만, 메시지가 진정으로 모델을 호출하는 순간 실패할 것이다. 네 개 profile이 각각 네 곳의 base_url을 고쳐 모두 낡은 Mac 엔드포인트를 가리키게 했다(먼저 key로 두 모델 모두 200 반환을 실측), coder는 모델을 재등록하고, tester는 등록표를 보충했다(「default만 고치고 등록표를 고치지 않는」구덩이의 재현). 설정을 고친 후에 또 하나의 관문이 있었다——gateway restart가 거부되었다(현재 대화가 곧 활성 세션이며, 직접 재기동하면 그것을 죽인다)；첫 번째로 .bat의 timeout /t 40으로 지연 재기동을 줄 세웠는데, 사후에 발견하기를 창 없는 cmd에서 입력 리다이렉션이 지원되지 않아 스크립트가 오 초 만에 끝까지 달려버렸고, 게이트웨이는 처음부터 끝까지 재기동하지 않았다——PowerShell의 Start-Sleep으로 다시 줄을 세워야 비로소 진짜 효력이 발생했다.

四、점병의 수확

이주 후의 첫 점병은 「모두 정상」이 아니라 세 가지를 거둘 — 하나의 성이 주인을 바꾸었다(컨테이너 사명 완수, 메모리 반환), 하나의 편제의 존재 이유가 재논증되었다(가치는 모델 다양성에 있고, 감상으로 남겨두면 차지하는 것은 디스크뿐이다), 한 필의 전마의 성색이 데이터로 확정되었다(4.1f를 달고, GLM는 환각 제어의 우위 자리에만 남는다). 그리고 매번 「점병이 끝난 후」에는 모두 정직한 결핍 보고가 따랐다——순회 주기가 하나의 슬롯을 건너뛰었고, 지연 스크립트가 진짜 실행되지 않았다——이런 스스로 아뢰는 태도가 전부 녹색인 보고서보다 더 값나가다.