Together AI가 서비스 트래픽이 바뀔 때마다 코딩 에이전트가 모델의 추론 코드를 다시 최적화하는 시스템 Together Compiler(TKCC)를 공개했다. 이 회사의 서버리스 엔드포인트 일부에서는 이미 가동 중이며, 한 번 맞춘 엔진은 시간이 지나면 뒤처지므로 튜닝을 멈추지 말아야 한다는 것이 회사의 주장이다.
제공 방식은 Together 고객 대상 제한적 베타다. 회사가 직접 측정한 결과로는 SemiAnalysis InferenceX의 AgentX 작업에서 공개된 최고 설정보다 초당 토큰 수(TPS)가 최대 2.6배 높았다. 설정 하나당 걸린 시간은 24시간 미만, 사용한 노드는 모델당 최대 2개였다.
작동 방식
Together Compiler는 서버 실행 명령, 트래픽 특성, 하드웨어 구성을 입력으로 받는다. 에이전트가 더 빠른 순전파(forward pass) 코드를 제안하면 상주 엔진이 각 후보를 측정하고, 가장 빠른 코드가 서빙 엔진에 반영된다. 트래픽 분포가 달라지면 이 과정이 다시 돌아간다.
회사가 든 이유는 트래픽이 가만히 있지 않는다는 점이다. 한 나라의 프롬프트 길이는 약 97K 토큰으로 다른 곳의 70K보다 길었고, 한 고객의 입력 길이 P90은 3일 만에 18K에서 33K 토큰으로 늘었다. 무작위 데이터로 맞춘 커널도 문제였다. 무작위 입력은 실제 트래픽보다 전문가 혼합 전문가를 13~38% 더 많이 활성화했다. 에이전트가 짠 Top-k 커널은 무작위 데이터에서 20µs였지만 70K 컨텍스트의 실제 데이터에서는 최대 62ms가 걸렸다.
보통의 에이전트 루프는 실험마다 vLLM, SGLang, TensorRT-LLM을 다시 띄운다. Together AI는 MiniMax M3.1 Flash를 TensorRT-LLM에서 시작하는 데 761초가 걸린다고 측정했다. Together Compiler는 엔진을 한 번만 띄우고, 에이전트가 RPC로 후보 코드를 보내면 서버가 순전파 함수 포인터를 교체하고 CUDA 그래프를 다시 캡처한다.
측정은 두 단계로 나눈다. 빠른 단계는 12개 층만 돌려 후보를 걸러내고, 느린 단계는 60개 층으로 실제 분포에서 이득을 확인한다. 두 단계를 쓰면 느린 단계만 쓸 때보다 후보를 8.1배 많이(1,354개 대 168개) 시험했고, 7.2% 더 빠른 해법도 찾았다. 엔진을 매번 재시작하는 방식과 비교한 에이전트 실험 처리량은 252배라고 회사는 밝혔다.
에이전트가 시작하기 전에는 비용 모델이 텐서·전문가·데이터·컨텍스트 병렬 배치를 순위 매긴다. 사양서 수치, 마이크로벤치마크, 실측 순전파, 실측 전문가 쏠림, 요청 길이 불균형을 함께 쓴다. Kimi K3에서는 이 방식으로 TPS가 최대 24% 높은 운영 배치를 찾았다.
측정 결과
| 모델(하드웨어) | Together Compiler | InferenceX 최고 설정 |
|---|---|---|
| MiniMax M3.1 Flash (B200) | 1,111 | 633 |
| DeepSeek v4.1 Flash (GB300) | 1,205 | 943 |
| GLM 5.3 (B200) | 417 | 329 |
| Kimi K3 (GB300) | 450 | 423 |
| GLM 5.3 (MI355X) | 480 | 463 |
MiniMax M3.1 Flash는 B200에서 1.8배로 가장 크게 올랐다. 비용 모델이 기준 설정의 TP4 대신 TP8을 골라, 메모리 병목인 디코딩에서 GPU당 가중치 이동량이 절반으로 줄었다. 반대로 GLM 5.3의 MI355X 결과는 463에서 480 TPS로 약 4% 오르는 데 그쳤다. 시험 대상은 Kimi K3, GLM 5.3, MiniMax M3.1 Flash, DeepSeek v4.1 Flash, Llama 1B였고 하드웨어는 NVIDIA B200·B300·GB300·H100, AMD MI355X, AWS Trainium2였다.
Llama 1B를 배치 크기 1로 돌렸을 때는 Hazy Research의 메가커널, Mirage, CUDA 그래프 기준선보다 최대 1.7배 빨랐다. 거대 언어 모델이 아닌 과학 모델 8개는 출력이 비트 단위로 같은 채 1.5~6.4배 빨라졌다. Claude Code의 /goal 기능은 1.2~4.4배를 냈지만 AIFS-ENS 2.0에서는 실패했다.
전문가 지식보다 단순한 지시가 나았다
전문가가 정리한 지식 베이스를 에이전트에 줬더니 12시간 뒤 속도 향상이 25~31% 낮았다. 순전파를 가능한 한 빠르게 만들라고만 지시한 단순 에이전트가 전문가 전략을 앞섰고, 10회 시도 후 앙상블 점수는 6.2배 대 4.9배였다. 맞춤 로깅 구조가 도구 호출의 최대 43%를 차지하기도 해서, 지금은 중간 표현 대신 엔진 소스 코드를 그대로 에이전트에 준다고 한다.
비슷한 시도와 비교하면 범위가 다르다. Marktechpost가 정리한 비교표에서 Cursor와 NVIDIA의 멀티 에이전트 시스템은 독립 CUDA 커널 235개를 대상으로 27개 B200 GPU에서 3주간 돌려 1.38배(기하평균)를 냈고 235개 중 149개에서 앞섰다. AMD GEAK은 개별 Triton 커널을 다루며 최대 2.59배 속도 향상을 냈다. Apple의 RSI-Inference Bench는 에이전트를 채점하는 벤치마크다. Together Compiler는 서빙 엔진 안의 순전파 전체를 대상으로 한다.
출처
이 기사는 아래 자료를 바탕으로 정리했습니다. 제목을 누르면 원문이 새 창으로 열립니다.