코드 보조에서 추론 인프라 최적화로, GLM Infra Agent의 현재 단계
들어가며
지푸의 창업자이자 수석과학자인 탕제와 GLM 팀은 GLM-5.3-Flash 출시 과정에서 진행한 내부 엔지니어링 사례를 공개했습니다. GLM-5.3으로 구동되는 Infra Agent는 모델 적용, 추론 시스템 진단, 연산자 및 서비스 성능 개선에 참여했습니다. 팀의 설명에 따르면 작업 대상은 10만 장이 넘는 중국산 칩으로 구성된 클러스터였으며, 엔드투엔드 처리량은 2주가 채 되지 않아 초기 기준선의 약 3배에 도달했습니다.
이번 사례의 의미는 단순한 성능 수치에만 있지 않습니다. 그동안 대규모 언어 모델은 주로 엔지니어의 코드 작성을 돕는 도구로 사용됐습니다. 이번에는 모델이 자신을 실행하는 추론 인프라를 수정하고, 테스트와 실행 관측 결과를 다음 개선의 근거로 활용했습니다. GLM 팀은 이를 재귀적 자기개선, 즉 RSI의 초기 형태로 설명하면서도 완전한 RSI에는 아직 도달하지 않았다고 선을 그었습니다.
핵심 내용
- 운영 수준의 인프라 작업에 참여했습니다. Agent는 모델 적용, 시스템 진단, 커널 개선, 서비스 성능 조정을 수행했습니다.
- 코드 생성보다 피드백 설계가 중요했습니다. 정확성 테스트, 로그, 실행 Trace, 런타임 이벤트, 마이크로벤치마크, 엔드투엔드 지표를 반복 작업에 연결했습니다.
- 서로 다른 계층의 문제를 다뤘습니다. KDA 컨텍스트 병렬 경로의 수치 정확성 문제, KV Transfer와 DeepEP 사이의 동시성 병목, 분할 전략을 바꾼 연산자 최적화가 대표 사례입니다.
- 인간의 감독은 여전히 핵심입니다. 엔지니어는 목표와 제약을 정하고 실험 환경을 구축했으며, 수치 의미론과 동시성, 운영 위험에 관련된 변경을 검토했습니다.
밀도 높은 피드백이 필요한 이유
엔드투엔드 처리량이 떨어졌다는 사실만으로는 원인을 알기 어렵습니다. GLM 팀은 최적화 과정을 독립적으로 관찰하고 반복 검증할 수 있는 작은 작업으로 나눴습니다. 연산자 비교는 병렬 구현이 올바른지 확인하고, 실행 Trace는 계산과 통신, 대기 중 어디에서 시간이 소모되는지 보여줍니다. 마이크로벤치마크는 특정 입력 형태와 부하에서 개선안이 유효한지 확인하는 데 사용됩니다.
여기서 말하는 밀도 높은 피드백은 로그를 무작정 많이 제공한다는 뜻이 아닙니다. 피드백이 수정된 코드, 특정 연산자, 입력 조건, 스레드 또는 실행 구간과 연결돼 있어야 하고, 짧은 시간 안에 얻을 수 있어야 하며, 통제된 비교 실험으로 검증 가능해야 합니다. Agent는 이 정보를 바탕으로 가설을 세우고 코드를 수정한 뒤 실험을 수행하고, 결과에 따라 방안을 채택하거나 수정하거나 폐기할 수 있습니다.
공개된 사례를 보면 컨텍스트 병렬과 비병렬 경로를 비교하는 과정에서 KDA의 수치 오차가 드러났습니다. KV Transfer의 성능 저하는 Python과 C++ 경계에서 GIL이 유지되는 방식, 그리고 DeepEP와의 동시 실행 관계를 조사하는 계기가 됐습니다. 또 다른 사례에서는 기존 분할 방식 때문에 정규화와 게이트 계산이 반복되고 있다는 점을 Agent가 찾아냈고, 계산 배치를 바꿔 대상 연산자에서 1.71배의 성능 향상을 얻었다고 팀은 설명했습니다.
의미와 한계
이번 실천은 AI Agent의 역할이 코드 자동완성에서 복잡한 시스템 최적화로 확장될 수 있음을 보여줍니다. 추론 병목은 연산자, 메모리, 통신, 스케줄링, 스레드, 서비스 구조의 상호작용에서 발생할 수 있습니다. 따라서 더 나은 코드 생성만으로는 충분하지 않으며, 관측 결과를 행동으로 연결하고 검증을 반복할 수 있는 환경이 필요합니다.
다만 이번 공개가 AI가 스스로 차세대 모델을 설계하고 학습할 수 있다는 뜻은 아닙니다. 목표를 선택하고 경계를 정하며 위험을 판단하는 일은 여전히 사람의 몫입니다. 현재 단계는 모델이 자신을 지원하는 시스템을 개선하고, 개선된 시스템이 다시 모델 서비스를 뒷받침하는 협업 루프로 이해하는 편이 정확합니다. 이것이 완전한 RSI로 발전할지는 추가적인 검증이 필요합니다.
출처: InfoQ 中文
댓글
로그인 상태 확인 중…
댓글 불러오는 중…