Gpu

에이전트가 같은 말을 반복하기 시작했을 때 처음에는 요청이 먹통이 된 줄 알았습니다. 툴 콜(tool call)이 나와야 할 자리에 모델이 max_tokens 제한까지 줄기차게 같은 문장만 반복하거나, 툴 콜에 필요한 JSON 형식을 끝내 완성하지 못한 채 의미 없는 잡담만 늘어놓고 있었거든요. 어느 쪽이든 토큰 예산만 낭비하고 가끔은 타임아웃까지 발생하며 에이전트 루프 전체를 말아먹기 일쑤였습니다. 당시 저는 B2B로 납품하는 비즈니스 인텔리전스(BI) AI를 만들고, 그 위에 에이전트를 얹는 일을 하고 있었습니다. 고객사 데이터가 외부로 나갈 수 없어서 클라우드 API는 쓸 수가 없었습니다. OpenAI도 Anthropic도 안 됐죠. 모델을 우리 하드웨어에 직접 띄워 서빙하거나, 아니면 기능을 포기하거나, 둘 중 하나였습니다. 이렇게 직접 서빙하면 클라우드 API가 알아서 처리해 주던 양자화(quantization), 서빙 프레임워크, 추측 디코딩(speculative decoding)을 전부 손수 다뤄야 합니다. 설정값 하나하나가 다 제 몫이고, 그만큼 제가 망가뜨릴 여지도 컸습니다. ...

서론 동일한 GPU 두 개를 같은 장비에 꽂고 똑같은 워크로드를 돌려보면, 종종 두 번째 GPU가 뒤처지는 현상을 보게 됩니다. 모델도 같고 드라이버도 같으며 데이터마저 동일한데 처리량(throughput)은 다르게 나타나는 것이죠. 발열 문제도 아니고 BIOS 프로파일 설정이 잘못된 것도 아닙니다. 사실 두 번째 GPU는 버스 수준에서 자원을 제대로 공급받지 못하고 있는 상태인데, 그 원인은 GPU 카드 자체가 아닌 다른 곳에 있습니다. 우리 대부분은 드라이버나 커널 모듈 위에서 작업하기 때문에 x86 시스템이 CPU, RAM, 그리고 PCIe 장치 간에 데이터를 실제로 어떻게 이동시키는지 들여다볼 일이 거의 없습니다. 하지만 처리량 비대칭 문제를 디버깅하거나, 인터럽트 선호도(interrupt affinity)를 튜닝하거나, 도대체 왜 irqaffinity가 중요한지 의문이 들기 시작하는 순간, 하드웨어 토폴로지는 더 이상 추상적인 개념으로 머물지 않게 됩니다. ...