탕제, 즈푸 RSI 첫 성과 발표

이수(一水) 2026-09-17 16:28:23 출처: 량쯔웨이(量子位)

GLM이 이미 GLM 구축에 참여하기 시작했다

칭화대학교 컴퓨터학과 교수이자 즈푸(智谱) 창립자인 탕제(唐杰)가 방금 그들이 내부적으로 관찰한 RSI 초기 사례 하나를 공유했다:

GLM-5.3이 구동하는 Infra Agent가 10만 장이 넘는 자국산 칩으로 구성된 클러스터에서 맨바닥에서부터 참여해 프로덕션급 추론 시스템 한 세트를 구축하고 최적화했다.

2주도 안 되어, 엔드투엔드 처리량이 초기 베이스라인의 3.2배로 끌어올려졌다.

핵심은, 이 뒤에 단순한 'AI가 코드를 작성'하는 것이 아니라는 점이다.

연산자 정밀도 문제부터 Python/C++ 크로스 레이어 동시성 병목, 나아가 Kernel 성능 최적화에 이르기까지, Agent는 이미 스스로 시스템 피드백을 읽고, 가설을 제기하고, 코드를 수정하고, 실험을 돌리고, 그 결과에 따라 계속 반복할 수 있다.

예를 들어 KV Transfer 시나리오에서 Python GIL로 인한 동시성 블로킹을 찾아내어, 단독 Prefill 대비 Prefill+KV Transfer의 20%를 넘는 성능 손실을 1% 이내로 줄였다; 또한 KDA Decode 연산자에서 계산을 재구성하여 1.71×의 성능 향상을 얻었다.

즉, 다소 '마트료시카' 같은 폐루프가 이미 나타난 것이다:

GLM이 GLM을 구동하는 시스템을 최적화하고, 이 최적화된 시스템이 다시 새로운 GLM을 계속 지탱한다.

탕제는 이를 한 문장으로 요약했다:

모델이 시스템을 최적화하고, 시스템이 모델을 지탱한다.

물론, 이것은 진정한 의미의 'AI가 완전히 자율적으로 자신의 후계자를 설계하고 학습시키는 것'과는 아직 거리가 멀다.

목표를 어떻게 정할지, 경계를 어떻게 그을지, 리스크를 어떻게 판단할지는 현재 여전히 인간 엔지니어가 담당하고 있다.

즈푸(智谱) 스스로도 그들은 아직 RSI를 실현하지 못했다고 분명히 강조했다.

그런데 이 글을 자세히 볼 만한 이유가 바로 여기에 있다:

RSI가 처음으로 매우 공학적이고, 심지어 이미 프로덕션 환경까지 진입한 초기 형태를 갖게 되었으며, '미래 언젠가 AI가 스스로 강해질 것'이라는 추상적 논의를 넘어섰다.

다음은 탕제가 공유한 기술 Blog 원문이다, enjoy.

"최근 가장 충격을 받은 순간"

GLM의 연구개발 과정에서, 모델은 때때로 우리를 놀라게 하고 심지어 불안하게 만드는 능력들을 창발적으로 드러냈다.

2025년 10월, 우리는 안전 능력 강화 연구를 시작했다.

당시의 판단은 매우 소박했다:

안전 능력은 코드 능력의 자연스러운 연장이며, 복잡한 코드를 읽어낼 수 있는 모델이라면 응당 코드 속 취약점도 이해할 수 있을 것이다.

우리는 그 이후의 흐름을 예상하지 못했다, 1년도 안 되어 보안 파트너들이 GLM을 사용하여 실제 코드베이스에서 수천 개의 취약점을 발견했다.

모델이 사이버 보안의 판도를 바꾸기 시작했고, 과거에는 존재하지 않던 위험도 가져왔다.

이러한 능력이 책임 있게 사용될 수 있도록, 우리는 이를 위해 신뢰 접근(受信访问) 계획을 설계하지 않을 수 없었다.

최근 가장 충격을 받은 순간은, 더 근본적인 변화에서 비롯되었다:

GLM이 점점 더 많이 인공지능 자체를 구축하는 데 참여하기 시작했다.

우리는 모델이 과거에는 시니어 Infra 팀이 몇 주 걸려야 완수할 수 있었던 인프라 작업 하나를 완료하는 것을 보았고, 이 작업이 차세대 모델의 학습 방식을 직접 바꿀 것임을 깨달았으며, 더욱 확신하게 되었다: 우리의 후계자는 바로 우리 손으로 만들어낸 AI라는 것을.

솔직히 말하자면, GLM-4.7 이전까지 우리 내부에서 GLM으로 코드를 작성하는 데는 다소 어쩔 수 없는 성분이 있었다, 어쨌든 자기 '친아들'이니까.

그때는 Coding의 PMF가 아직 오지 않았고, 오늘날 GLM-5.3은 모든 사람이 매일 떠날 수 없는 Coding 파트너가 되었으며, 한 걸음씩 우리를 대체해 나가고 있다.

이 추세가 이어진다면, 컴퓨팅 파워를 충분히 주고 시간을 충분히 준다면, 그 종착점은 완전히 자율적으로 자신의 후계자를 설계하고 학습시킬 수 있는 시스템이며, 이를 재귀적 자기 개선(Recursive Self-Improvement, RSI)이라고 부른다.

비록 우리가 아직 거기까지 가지는 못했지만, 그 초기 형태는 이미 나타났다.

이 글에 기록된 것이 바로 그중 하나의 초기 사례다.

밀집 피드백으로 Infra Agent의 추론 시스템 최적화를 견인하다

모델이 새 하드웨어에서 성공적으로 실행되게 하는 것부터, 프로덕션 트래픽을 안정적으로 지탱하는 고성능 추론 서비스 한 세트를 구축하는 것까지는 거대한 시스템 공학이다.

GLM-5.3-Flash의 출시 역시 이 과정을 거쳤다.

10만 장이 넘는 자국산 칩으로 구성된 클러스터에서, 맨바닥에서부터 완전한 프로덕션급 추론 서비스 한 세트를 구축했으며, GLM-5.3-Flash의 모든 온라인 추론이 이 시스템 위에서 실행된다.

이 작업은 쉽지 않았다.

이전에 아무도 이렇게 대규모의 자국산 칩 클러스터를 성공적으로 배포한 적이 없었고, 칩의 메모리 용량과 대역폭이 상대적으로 제한된 과제, 그리고 새 구조의 모델 1M 컨텍스트 윈도우와 멀티모달 요청을 지원해야 하는 필요에 직면했으며, 생태계는 미성숙하고 연산자는 완비되지 않았으며, 많은 문서는 기본적으로 추측에 의존해야 했다.

결국 이 일은 해냈다, 그것을 해낸 것은 한 팀이 아니라 GLM-5.3이 구동하는 Infra Agent였다.

이후의 이야기는 모두가 이미 알고 있다.

GLM-5.3-Flash는 익명 모델 'Ox-Alpha'로 OpenCode와 OpenRouter에서 실제 호출 검증을 받았다.

출시 1주일 만에 양 플랫폼에서 호출량이 가장 큰 모델이 되었고, 6일간 token 호출량이 62조를 넘었다.

이번에 우리는 일련의 공격적인 메모리 최적화를 시행했는데, 연산력으로 대역폭을 바꾸고, 통신으로 메모리를 바꾸는 등의 맞춤형 방안을 포함한다.

최종적으로 형성된 기술 스택은 여러 핵심 기술을 융합했다:

선형 어텐션과 LM Head를 위한 노드 내 텐서 병렬화, ReplaySSM, W8A8 양자화, INT8/FP8/BF16 혼합 정밀도 캐시 양자화, 그리고 Layer Split 등이다.

이를 바탕으로 우리는 추가로 Encode–Prefill–Decode(EPD 분리형 아키텍처)를 도입하여, 엔드투엔드 서비스 성능 약 3배 향상을 실현했으며, 하드웨어 활용 효율과 단일 Token 비용 모두 주류 NVIDIA GPU와 상당한 수준에 도달했다.

Infra Agent가 참여한 피드백 폐루프가 전체 최적화 과정을 관통했기 때문에, GLM-5.3-Flash는 2주도 안 되는 시간에 모델 적응에서 프로덕션 사용 가능으로의 도약을 완수했고, 최종적으로 엔드투엔드 처리량을 초기 베이스라인의 3배로 끌어올렸다.

그림 1은 GLM-5.3-Flash가 최초 실행에서 정식 출시에 이르기까지의 성능 진화 경로를 보여준다.

△그림 1: GLM-5.3 Flash의 성능 진화

이 과정에서 우리는 점차 깨달았다, Infra Agent의 공학적 효과를 결정하는 것은 모델 자체의 코드 생성과 추론 능력만이 아니라, 시스템이 그것에 지속적으로 유효하고 원인을 귀속할 수 있는 피드백을 제공할 수 있는지에 더 달려 있다는 것을.

코드베이스는 정적 컨텍스트만 제공할 수 있지만, 추론 시스템에서의 정밀도 이상, 성능 퇴화, 또는 성능 최적화 목표가 기대에 미치지 못하는 것은 흔히 연산자 구현, 병렬 전략, 통신 동작, 메모리 관리와 서비스 스케줄링 등 여러 계층의 동적 상호작용에서 비롯된다.

Agent가 전체 코드베이스를 이해할 수 있다 해도, 한 번 수정한 뒤 얻은 피드백이 단지 '정밀도 테스트 미통과', 'TTFT 30% 증가' 또는 '출력 처리량 20% 감소'에 불과하다면, 그것은 여전히 문제가 어느 계층에서 발생했는지, 현재 가설이 왜 성립하지 않는지, 그리고 다음 단계에서 무엇을 검증해야 하는지 판단하기 어렵다.

엔드투엔드 지표는 Agent에게 '결과가 나빠졌다'고 말해줄 수는 있지만, '왜 나빠졌는지'를 설명할 수는 없다.

따라서 Agent의 코드 작성 및 수정 능력을 강화하는 동시에, 우리는 더 근본적인 시스템 문제 하나를 해결해야 한다:

어떻게 희소한 엔드투엔드 결과를, 세밀하고 원인 귀속이 가능하며 다음 단계 행동을 직접 지도할 수 있는 공학적 피드백으로 전환할 것인가?

이것이 바로 고효율 Infra Agent 피드백 폐루프 구축의 관건이다.

엔드투엔드 지표에서 원인 귀속 가능한 피드백으로

전통적인 추론 시스템 최적화에서 테스트, 로그, 성능 분석 도구와 마이크로 벤치마크가 없는 것은 아니지만, 이들은 흔히 서로 다른 도구와 공학 단계에 분산되어 있다.

경험 많은 엔지니어는 한 번의 부하 테스트 결과에 따라 다음 관측 수단을 선택하고, 연산자 출력, 실행 타임라인, 통신 이벤트 또는 스레드 상태를 점차 점검하며, 서로 다른 도구에서 나온 정보를 연결한다.

Agent의 경우, 이러한 관측과 검증 수단이 직접 접근하고 반복 실행할 수 있는 워크플로로 조직되지 않는다면, 실제로 사용 가능한 피드백은 여전히 희소하다.

그것은 처리량이 목표에 도달하지 못했다는 것은 알 수 있지만, 더 나아가 판단할 수는 없다:

- 특정 연산자의 실행 시간이 너무 긴 것인지, 아니면 연산 장치가 유휴 대기 상태에 있는 것인지?

- KV Transfer 자체의 성능이 부족한 것인지, 아니면 상위 스케줄링이 제때 전송을 추진하지 못한 것인지?

- 어떤 최적화가 어떤 입력 형상에 유효하고, 또 어떤 조건에서 퇴화가 발생하는지?

단일한 엔드투엔드 지표로는 이러한 질문에 답할 수 없다.

이를 위해 우리는 정확성 테스트, 실행 로그, 실행 Trace, 런타임 이벤트, 마이크로 벤치마크와 엔드투엔드 지표를 Agent의 반복流程에 포함시키고, 완전한 시스템 최적화 과정을 국부적으로 관측하고 검증할 수 있는环节으로 분해했다.

연산자 수준 비교는 수치 정확성을 검증하는 데, 마이크로 벤치마크는 특정 입력 조건에서의 국부 성능을 측정하는 데, 실행 Trace와 런타임 이벤트는 계산, 대기와 통신 사이의 시간 관계를 제시하는 데 사용된다.

Agent는 현재 가설에 따라 상응하는 검증 수단을 선택할 수 있으며, 매번 수정한 뒤에 완전한 서비스 배포와 엔드투엔드 부하 테스트를 기다릴 필요가 없다.

우리는 이러한 조직 방식을 '밀집 피드백'이라고 부른다.

여기서 '밀집'은 Agent에게 가능한 한 많은 로그와 지표를 입력한다는 뜻이 아니라, 피드백이 세 가지 특징을 지닌다는 것을 강조한다.

첫째, 피드백은 충분히 국부적이어야 한다.

그것은 가능한 한 구체적인 엔진 시작 파라미터, 수정된 코드, 연산자, 입력 조건, 스레드, 실행 구간 또는 코드 경로와 연관되어, Agent가 문제 범위를 좁히도록 도와야 한다.

예를 들어, '융합 최적화 도입 후 모델 정밀도 하락'보다, 특정 요청이 최적화 전후에 가진 출력 차이를 특정하는 것이 Agent가 최소 재현을 구성하고 원인을 분석하는 데 더 도움이 된다.

둘째, 피드백은 낮은 비용으로 제때 얻을 수 있어야 한다.

Agent가 가설 하나를 제기하고, 수정을 한 번 실행하고, 또는 대조 실험 한 세트를 구성할 때마다, 상응하는 검증 진입점이 있어야 한다.

연산자 테스트나 국부 마이크로 벤치마크로 답할 수 있는 문제는 매번 완전한 서비스 배포와 엔드투엔드 부하 테스트를 기다릴 필요가 없다.

더 짧은 검증 주기는 Agent가 제때 방향을 수정하고, 무효 가설에 대한 투입을 줄이도록 도울 수 있다.

셋째, 피드백은 객관적 검증을 지원해야 한다.

수정이 올바른지, 성능이 개선되었는지는 참조 구현, 테스트 결과와 비교 가능한 실험 지표로 판단해야 한다.

실행 신호는 Agent가 후보 원인을 제기하도록 도울 수 있지만, 현상 간의 상관관계만으로 근본 원인을 확인할 수는 없으며, 변수를 통제한 대조 실험을 통해 특정 경로에 대한 수정이 기대한 변화를 만들어냈는지 검증해야 한다.

이 세 가지 특징이 함께 피드백이 실행 가능성을 갖는지를 결정한다:

정확성 피드백은 '제대로 계산되었는가'에 답하고, 시스템 동작 피드백은 '시간 소모가 어디에 있는가'를 특정하며, 성능 피드백은 '어떤 방안이 어떤 조건에서 더 나은가'를 판단한다.

검증 수단은 고정된 순서로 실행될 필요가 없으며, 오히려 현재 가설과 부합해야 하여, 매 라운드 실험이 하나의 명확한 질문에 답할 수 있게 한다.

국부 검증과 엔드투엔드 테스트는 이 과정에서 서로 다른 책무를 맡는다:

전자는 이르게 오류 또는 무효 수정을 배제하고, 계속 추진할 가치가 있는 후보 방안을 선별하는 데 사용되며; 후자는 국부 이익이 실제 서비스 이익으로 전환될 수 있는지, 그리고 방안이 실제 워크로드 아래에서 새로운 퇴화를 초래하지는 않는지를 확인하는 책임을 진다.

위의 사고를 둘러싸고, GLM-5.3 Flash의 출시 과정은 엔지니어, Infra Agent와 실험 환경이 함께 구성한 최적화 폐루프 한 세트를 형성했다:

엔지니어는 목표와 시스템 경계를 정의하고, Agent는 분석, 가설과 수정을 담당하며, 실험 환경은 계층적이고 제때 이루어지며 검증 가능한 피드백을 제공한다.

이 셋이 함께, 원래 엔지니어의 경험에 의존해 연쇄적으로 이루어지던 진단 과정을, Agent가 지속적으로 실행할 수 있는 공학 워크플로로 전환한다.

△그림 2: 밀집 피드백 기반 Infra Agent 최적화 폐루프

이 진화 과정은 처리량 성장을 직접 추동하는 성능 최적화를 포함할 뿐만 아니라, 즉시 처리량 향상으로 나타나지는 않지만 시스템이 올바르고 안정적으로 출시될 수 있는지를 결정하는 결함 수정도 포함한다.

아래에서 세 가지 사례를 골라, 밀집 피드백이 어떻게 Agent가 '제대로 계산함'을 보장하고, '왜 빠르게 돌지 못하는가'를 설명하며, 나아가 '어떻게 더 빠르게 돌릴 것인가'를 탐색하도록 돕는지 각각 설명한다.

정확성 피드백: Agent는 모델이 제대로 계산되었는지 안다

추론 성능 최적화는 반드시 수치 정확성을 전제로 해야 한다.

Agent의 경우, 검증은 추론 엔진이 실제로 어떤 계산을 수행했는지 명확히 하는 것에서 시작한다.

상위 병렬 전략은 연산자의 입력 분할, 실행 경로와 결과 조합 방식을 바꾼다; 하나의 연산자가 비분할 조건에서의 출력을 검증하는 것만으로는 실제 배포에서의 동작을 충분히 커버하지 못한다.

이를 위해 우리는 추론 엔진 병렬 전략에서 연산자 구현으로의 매핑을 구축하여, 시스템 수준의 배포 설정을 Agent가 항목별로 검증할 수 있는 연산자 작업으로 전환했다.

이 매핑은 Agent가 명확히 하도록 돕는다:

하나의 병렬 구성이 어떤 연산자들을 포함하고, 입력이 어떻게 분할되며, 어떤 계산 경로가 비분할 구현과 대조되어야 하는지를.

이를 바탕으로, 우리는 Agent가 서로 다른 병렬 분할과 비분할 경로에 대해 정밀도 비교를 수행하도록 조직했다.

동일한 입력 세트에 대해, 계산 의미와 출력 위치를 정렬한 뒤, 서로 다른 실행 방식이 만들어낸 결과가 수치 오차 요구를 충족하는지 검사한다.

이렇게 하여 병렬 구성, 연산자 경로와 오차 결과가 서로 연관된다.

테스트가 일단 편차를 드러내면, Agent는 상응하는 분할 방식과 계산 경로에서 계속 점검할 수 있으며, 전체 모델에서 다시 위치 파악을 시작할 필요가 없다.

바로 이러한 연산자 검증 과정에서, 우리는 KDA 연산자 컨텍스트 병렬(Context Parallel, CP) 경로의 정밀도 문제를 발견했다.

CP와 비CP 결과 사이의 편차는, 점검 중점이 병렬 실행이 도입한 상태 전파와 병합 계산으로 떨어지게 했다.

CP 분할은 서로 다른 컨텍스트 분片의 상태를 병합해야 하며, 그 핵심 계산은 다음과 같이 단순화될 수 있다:

M = tl.dot(M_chunk, M) # 각 분片의 상태 변환을 병합 S_next = tl.dot(M, S) + H # 후속 분片의 초기 상태를 갱신

원래 구현에서, tl.dot은 FP32 입력을 받더라도 기본적으로 TF32 계산을 채택하여 성능을 높인다. 낮은 계산 정밀도는 오차가 변환 병합과 상태 갱신에서 계속 누적되게 하며, 장컨텍스트에서 더욱 뚜렷해진다.

修复方法: 이 두 계산 지점에 input_precision="tf32x3"를 명시적으로 지정하여, 세 번의 TF32 Tensor Core 연산을 조합해 더 높은 정밀도의 결과를 만들어내고, 누적 오차를 줄이면서도 Tensor Core의 성능 이점을 최대한 유지하는 것이다.

이 사례에서 피드백 환경의 역할은 문제가 나타나기 전부터 이미 시작된다.

병렬 전략에서 연산자로의 매핑이 검증 대상을 확정하고, 분할 경로와 비분할 경로의 대조가 수치 편차를 드러내며, 계산 정밀도 분석이 편차의 출처를 설명하고, 회귀 테스트가 수정에 대한 지속적인 검증 근거를 제공한다.

Agent에게 이 경로는 시스템 차원의 병렬 설계를 실행하고 추적할 수 있는 정확성 과제로 전환한다.

국소 검증 이후, 후보 구현은 여전히 목표 배포 환경으로 돌아가 모델 수준의 정밀도와 서비스 성능에 대한 최종 검수를 완료해야 한다.

관련 정밀도 수정은 Flash Linear Attention 업스트림에 이미 병합되었으며, 자세한 내용은 PR #1180을 참조하라.

시스템 동작 피드백: KV Transfer의 동시성 병목 위치 파악

시스템 수준의 성능 문제에 있어 명확한 테스트 시나리오와 성능 제약은 Agent가 이상을 판단하고 분석 방향을 선택하는 출발점이다.

우리의 추론 최적화 엔지니어는 Agent를 위해 단독 Prefill, Prefill + KV Transfer, 단독 Decode 등의 테스트 시나리오를 정의하여 서로 다른 실행 단계 및 그 조합이 성능에 미치는 영향을 분리해냈고, 각 시나리오에 대한 수용 조건을 설정했다.

예를 들어, 동일한 workload에서 단독 Prefill을 기준으로 할 때 Prefill + KV Transfer의 성능 차이는 5%를 넘지 않아야 한다.

그러나 Agent는 테스트에서 일부 시나리오의 성능 차이가 20%를 초과하는 것을 발견했다.

이 피드백은 조사 범위를 KV Transfer 도입 이후의 추가 오버헤드와 동시성 상호작용으로 좁혀주었다.

Agent는 이어서 KV Transfer의 타임라인을 심층 분석하여 하나의 이상 징후를 발견했다.

이들 시나리오에서 KV Transfer의 Python 측 실행은 DeepEP dispatch/combine의 호출 구간과 전혀 겹치지 않았다.

이 현상으로 인해 Agent는 DeepEP와 Mooncake Transfer의 동시성 관계를 점검하기 시작했고, 호출 체인을 따라 Python/C++ 경계로 들어갔다.

우리가 사용한 DeepEP v1.2.1에서는 intranode_dispatch와 intranode_combine 모두 Python GIL을 명시적으로 해제하지 않으며, 그중 dispatch는 수신 token 수를 얻어야 할 때 CPU에서 GPU가 관련 정보를 반환하기를 기다리기도 한다.

핵심은 C++로 진입한다고 해서 자동으로 GIL이 해제되는 것은 아니라는 점이다.

이렇게 락을 보유한 호출 구간 동안, 같은 프로세스 내에서 Mooncake Transfer를 담당하는 Python 스레드는 제때 GIL을 획득할 수 없었고, 전송 작업의 스케줄링과 제출이 따라서 지연되어 KV Transfer가 이후 계산과 겹칠 수 있는 기회가 줄어들었다.

하위 전송이 비동기 실행 능력을 갖추고 있더라도, 상위 제출이 막히면 기대한 병렬성이 충분히 발생할 수 없다.

소스 코드에는 직접적인 대조 사례도 하나 있다.

같은 버전의 internode_dispatch는 이미 GIL을 명시적으로 해제하고 있으며, 주석은 이렇게 하는 이유가 CPU 대기 기간에 다른 스레드의 KV Transfer를 막지 않기 위함이라고 설명한다.

이는 intranode 경로에 대한 Agent의 판단을 더욱 뒷받침한다.

수정의 핵심은 관련 C++ 실행 구간에서 GIL을 해제하여 Mooncake Transfer의 Python 스레드가 제때 작업을 진행할 수 있게 하는 것이다.

수정 효과는 타임라인과 기존 성능 제약을 동시에 통해 검증해야 한다.

전자는 스케줄링과 전송이 중첩 실행 기회를 얻었는지 점검하고, 후자는 이 변화가 실제 서비스 성능을 개선했는지 판단한다.

동일한 테스트 조건에서 수정 후 Prefill + KV Transfer와 단독 Prefill의 성능 차이는 1% 미만이었다.

△그림 3: KV Transfer 동시성 병목의 발견과 수정

이 사례에서 성능 제약은 먼저 '기대에 미치지 못함'을 명확한 테스트 편차로 전환하고, 타임라인은 다시 조사 방향을 두 컴포넌트의 동시성 관계로 수렴시키며, 최종적으로 코드 분석이 GIL 보유 범위를 찾아낸다.

조밀한 피드백은 이로써 엔드투엔드 성능, 계층을 넘나드는 실행 동작, 구체적 구현을 연결하여 Agent의 매 단계 분석에 근거를 제공한다.

성능 피드백: 연산자 최적화를 기존 경험에서 출발시키고 시스템 성능 향상으로 전환하기

연산자 최적화는 두 가지 문제를 해결해야 한다. 한 번의 최적화가 유효한지 어떻게 판단할 것인가, 그리고 최적화 방향은 어디에서 오는가.

첫째, 연산자 성능은 반드시 추론 엔진의 실제 실행 환경에서 평가되어야 한다.

예를 들어, 계산 Kernel이 더 많은 자원을 점유하면 자체 소요 시간은 줄어들 수 있지만 KV Transfer Kernel의 실행 공간을 압축하여 결국 전체 파이프라인을 느려지게 할 수 있다.

따라서 Agent는 연산자 소요 시간만 주목하는 것이 아니라, 목표 Workload, 자원 제약, 작업 중첩, 엔드투엔드 이익을 결합하여 올바른 최적화 목표를 세워야 한다.

둘째, 방대한 최적화 경험이 SGLang, Flash Linear Attention, DeepGEMM 등의 프로젝트에 있는 수작업 Kernel 속에 암묵적으로 담겨 있다.

Agent는 이 코드들로부터 최적화 기법과 그 적용 조건을 추출하여 현재 연산자와 목표 하드웨어에 맞는 후보 방안을 만들고, 실험을 통해 실제 효과를 검증해야 한다. 기존 코드가 최적화 방향을 제공하고, 시스템 피드백이 최적화가 실제로 성립하는지 판단한다.

우리는 GLM-5.3이 구동하는 Infra Agent가 서로 다른 코드베이스, 프로그래밍 언어, 하드웨어 플랫폼의 기존 Kernel에서 최적화 경험을 학습하고, 증분 실험과 제거 실험을 통해 이를 적용 조건, 변환 방식, 자원 제약, 검증 증거를 포함하는 '최적화 골격'으로 정제하도록 했다.

새로운 연산자를 마주하면, Agent는 이 골격들을 출발점으로 삼아 Profiling과 계층적 테스트를 결합해 타일링, 메모리 접근, 자원 할당 전략을 다시 확정하고, 검증을 통과한 수정과 그 적용 조건은 계속 골격 라이브러리로 환류된다.

엔지니어는 주로 목표와 제약을 정의하고, 수치 의미, 동시성 동작, 온라인 리스크와 관련된 핵심 수정을 심사하는 역할을 맡는다.

△그림 4: 대표적 KDA Decode 연산자의 기본 구현에서 프로덕션 버전까지의 성능 진화

그림 4는 대표적인 KDA Decode 연산자의 성능 진화 과정을 보여준다.

ReplaySSM을 도입해 연산으로 저장을 대체하면서 연산자 실행 시간이 처음으로 길어졌고(v1은 v0 대비), Agent가 수행한 나눗셈 최적화는 v1의 실행 시간을 9.6% 단축했다.

나아가 '계산이 핵심 병목'이라는 피드백 정보를 얻은 뒤, Infra Agent는 원래 구현이 V 차원을 따라 타일링되어 동일한 FP32 정규화와 게이팅 계산이 네 번 반복 실행된다는 점을 발견했다.

이 타일들을 동일한 스레드 블록으로 병합하고, 미리 일괄 계산하여 중간 결과를 공유함으로써 일부 병렬도를 희생하는 대가로 중복 계산을 근원에서 제거하여 1.71×의 성능 향상을 얻었다.

이 사례에서 GLM-5.3이 구동하는 연산자 Agent는 기존 구현에서 최적화 경험을 추출하고, 이 경험을 다시 자신의 추론을 떠받치는 연산자에 적용했다.

그것은 골격을 출발점으로 항목별로 튜닝하고, 계층적 검증으로 매 단계의 존폐를 판단하며, 엔드투엔드 성능으로 실제 가치를 판단하고, 검증을 통과한 경험을 골격 라이브러리로 환류한다.

모델은 이로써 자신의 추론 시스템 최적화에 참여했고, 매번上线하며 축적된 경험은 다시 다음 최적화에 필요한 엔지니어 투입을 줄여주었다.

피드백이 행동을 이끌게 하고, 실험이 가설을 검증하게 하라

세 사례는 공통적으로 피드백의 가치는 양에 있는 것이 아니라, Agent가 현재 문제에 답하도록 도울 수 있는지에 있음을 보여준다.

구조가 결여된 대량의 로그는 핵심 신호를 가릴 수 있고, 관측 범위가 불완전한 Profiling은 잘못된 귀인을 초래할 수 있으며, Microbenchmark에서 성립하는 최적화가 반드시 엔드투엔드 이익으로 전환되지는 않는다.

따라서 피드백 환경을 구축하려면 테스트, 로그, 성능 데이터를 제공하는 것뿐만 아니라, 각 관측 유형이 어떤 판단을 뒷받침할 수 있는지, 어떤 경계가 존재하는지, 그리고 어떤 결론이 추가 실험을 통해 확인되어야 하는지를 명확히 해야 한다.

엔지니어는 이 과정에서 세 가지 핵심 책임을 진다.

최적화 목표와 시스템 제약을 정의하고, Agent가 직접 사용할 수 있는 피드백 환경을 구축하며, 시스템 아키텍처, 비동기 동시성, 온라인 리스크와 관련된 핵심 수정을 심사하는 것이다.

이를 바탕으로 Agent는 가설을 제기하고 수정을 구현하며 실험을 수행한 뒤, 피드백에 따라 현재 방안을 유지하거나 수정하거나 부정한다. 정확성, 안정성, 엔드투엔드 성능이 함께 최종 수용 기준을 구성한다.

GLM-5.3 Flash의 上线 과정을 돌아보면, 연산자 정밀도 결함, Python과 C++ 경계를 넘나드는 동시성 문제, 그리고 핵심 연산자의 성능 최적화가 각각 서로 다른 층위의 엔지니어링 과제에 대응한다.

국소 테스트, 계층 간 관측, 계층적 Benchmark를 통해 원래 모호했던 이상 현상은 점차 검증 가능한 엔지니어링 가설로 전환되었고, 복잡한 시스템 문제도 일련의 관측 가능하고 실험 가능하며 귀인 가능한 반복 과정으로 분해되었다.

바로 이러한 피드백 폐루프 속에서 Agent의 코드 및 추론 능력이 비로소 검증 가능한 엔지니어링 진전으로 전환된다.

GLM-5.3이 구동하는 Infra Agent는 추론 인프라 구축에 참여하며, 엔지니어와 Agent가 함께 최적화한 시스템은 다시 GLM-5.3 Flash가 안정적으로 사용자를 향해 서비스를 제공하도록 뒷받침한다.

이번 실천은 시스템 엔지니어링 주기를 진정으로 단축하는 것이 더 강력한 모델 능력만이 아니라, 모델이 지속적으로 피드백을 얻고 판단을 검증하며 행동을 수정할 수 있게 하는 Agent 엔지니어링 폐루프라는 것을 보여준다.

물론 우리는 아직 재귀적 자기 개선에 도달하지 못했다.

목표를 선택하고 경계를 설정하며 리스크를 판단하는 것은 여전히 사람의 일이며, 우리는 상당한 기간 동안 이 선은 사람이 지켜야 한다고 생각한다.

하지만 2주, 3배, 10만 카드라는 숫자들은 이 선이 우리가 조금 느리기를 바란다고 해서 느려지지 않으리라는 것을 말해준다.

(전문 끝)

참고 링크:

https://x.com/jietang/status/2100482019088060470