TechToast

프록시를 붙인 뒤 생긴 세 가지 — 0.3% 지연, 서버 두 개, 카드가 사라짐

처리량이 0.3%밖에 안 떨어졌습니다. 프록시를 붙이는 대가가 그 정도라고 생각했죠. 아닌 게 정답에 가까웠습니다. 0.3%는 거의 공짜였고, 진짜 어렵기는 뒤에서 생긴 세 가지였습니다. 연구실에서 모델을 쓰는 사람들마다 키를 나눠 주고, 누가 얼마를 썼는지 집계하고 싶어졌습니다. vLLM이 기본으로 가진 멀티 키는 인증만 되고 토큰 사용 로그가 남지 않아서, 집계를 하려면 한복판에 프록시를 하나 세워야 했습니다. 붙이기 전 벤치는 선명했습니다. 같은 스트리밍 생성을 직결로 돌리면 29.6 tok/s, 프록시 경유로 돌리면 29.5 tok/s였습니다. 첫 토큰까지 걸리는 시간은 5~7ms 늘었고, 프록시 자체 오버헤드는 응답 헤더로 재니 p50 2.0ms였습니다. 노이즈 수준이라서 그냥 붙였습니다. 0...

수업 챗봇 QA를 자동으로 증식시켰는데 아무것도 안 늘었습니다

오전 7시의 약속 — 위키가 스스로 자라기로 했습니다우리 연구실에는 학생의 질문을 수업 위키에서 검색해서 답해주는 챗봇이 있습니다. 흠은 처음부터 뻔했습니다. 위키에 없는 것을 물리면 조용해진다는 점이지요. 답을 모르니 모른다고 할 수밖에 없는데, 그걸 그냥 둘 수가 없어서 위키가 스스로 먹이를 먹이는 파이프라인을 만들었습니다. 매일 아침 7시, 제가 출근하기 전에 어제의 채팅 로그를 소화시키는 크론 잡입니다. 약속은 한 줄입니다. 한 번 나온 질문은 위키에 남아서, 다음에 같은 걸 물은 학생은 바로 답을 받는다는 것이지요. 흐름은 이렇습니다. 학생 질문을 모아서 수업 자료 관련인 것만 고른 뒤, 위키에서 검색을 걸어 봅니다. 점수가 충분히 높게 나오면 그 페이지의 '자주 묻는 질문' 절로 승격시키고, ..

10월 26일 새벽, 음성 봇이 "28배" 빨라졌다고 보고했습니다. 첫음성이 3.75초 걸리던 것이 0.13초가 됐다는 겁니다. 저는 그 보고를 믿고 front 모델 교체까지 밀었습니다. 음성으로 답하는 모델 전체를 갈아끼우는 결정이었지요. 그런데 같은 날 낮에, 그 봇은 오히려 3배 느려졌다며 원복했습니다. 0.13초는 거짓이었고, 원인은 모델 서버를 방금 다시 켠 직후에 잰 것이었습니다.범인은 모델이 아니라 배선이었습니다문제 자체는 실물이었습니다. 음성 어시스턴트가 답을 꺼내기까지 첫음성만 3.75초, 한 문장 전체로 4.7초가 걸렸습니다. 무거운 모델을 얹어놔서 느린 줄 알았지요. 27B는 이름 그대로 270억 파라미터가 전부 계산에 참여하는 Dense 모델이었으니까요. 그런데 헬스체크 응답을 열어..

매일 돌던 크론 4개가 5일 연속으로 실패했고, 실행 로그에는 17건이 남아 있었습니다. 그런데 그 사이에 제가 받은 알림은 0건이었습니다. 추정치가 아니라 로그 데이터를 직접 훑어서 나온 숫자이고, 크론 설정을 점검하다가 우연히 열어본 날에야 비로소 알게 됐습니다. 그날 열어보지 않았더라면, 이 침묵은 열흘은 더 이어졌을 가능성이 큽니다. 알림이 사라진 게 아니라, 실패를 세는 장치가 없었습니다대상은 세컨드브레인 유지를 맡은 크론 4개였습니다. 하루의 세션을 증류하는 것, 인덱스 파이프라인을 지키는 워치독, 아침에 온몸을 정비하는 것, 밤에 지식을 승격시키는 것 — 매일 빠짐없이 도는 것들이었습니다. 10월 26일부터 네 개가 한꺼번에 쓰러졌고, 로그에 남은 오류는 전부 한 줄로 똑같았습니다. 모델 서..

LISTEN 상태의 accept 큐에, 응답을 못 받은 소켓 406개가 쌓여 있었습니다. systemd에는 active로 뜨고 포트도 열려 있었으니, 겉보기엔 정상이었거든요. 그런데 curl에는 답이 하나도 나오지 않았습니다. 상태는 정상이었는데, 일만 하지 않은 겁니다.active였는데, 아무도 대답하지 않았습니다문제였던 건 늘 쓰던 웹 대시보드 서비스였습니다. systemd에는 active로 뜨고, 연결을 기다리는 포트는 LISTEN 상태, 표로는 완벽했거든요. 그런데 curl로 요청을 보내면, 아무 대답 없이 시간만 흘러 타임아웃이 났습니다. ss로 소켓 상태를 들여다보니, 사건의 크기가 나왔습니다. LISTEN 포트의 수신 대기열인 Recv-Q에 406개가 쌓여 있었고, 이미 끊긴 연결이 CLOS..

정부 R&D 과제의 1단계 단계보고서를 제출하기 직전에, 마지막 점검을 기계에게 시켰습니다. 과제는 영상 품질을 평가하는 AI를 개발하는 것이고, 수정본을 PDF로 렌더하면 87쪽, 파일로 14.6MB쯤 되는 문서입니다. 이미 다른 심사자의 1차 검토를 받아서 그 지적은 전부 반영한 상태였기에 마음은 반쯤 편했습니다. 반쯤이라고 쓴 데는 이유가 있습니다. 여기서 사람의 고질적인 문제가 나옵니다. 자기가 쓴 글을 눈으로 읽으면 뇌가 자동으로 고쳐서 봅니다. 방금 고쳐놓은 자리는 고쳤다는 기억이 먼저 와서 틀린 게 안 보입니다. 워드프로세서로 쓴 자기 원고를 교정하면 오타가 안 보이는 것과 같은 이치라, 마지막 점검은 원고에 기억이 없는 존재에게 넘기는 편이 정직합니다.검토에게 넘긴 다섯 가지기계에게 문서를..

단일 디코드 27.2 tok/s. 리모트 서버를 같은 벤치 스크립트로 다시 돌려본 결과입니다. GPU 카드 한 장뿐인 워크스테이션에서 같은 조건으로 재보니 46.7이 나왔습니다. 리모트 서버는 L40 세 장이 올라간 기계이고, 워크스테이션은 PRO 6000 96GB 한 장입니다. 카드 수에서도, 총 VRAM(48GB×3, 합계 144GB)에서도 리모트가 이기는데 속도에서 졌습니다. 병목은 GPU가 아니었습니다.같은 조건으로 재측정하니 차이가 드러났습니다감으로 비교한 것이 아닙니다. 같은 27B 모델을 두 기계에 같은 스크립트로 돌리고 숫자를 나란히 세웠습니다. 왼쪽 열은 L40 두 장을 Tensor Parallel로 묶어 돌리는 현행 프로덕션이고, 오른쪽 열은 카드 한 장에 NVFP4 양자화와 DFLAS..

2026-10-25, GB10 듀얼(128GB 통합메모리를 나누는 두 노드에서 vLLM 1M 컨텍스트를 서빙 중)에서 서비스가 낮에 두 번, 저녁에 한 번 죽었습니다. 부팅 후 6일 넘게 아무 탈 없이 돌던 스택인데, 그날 코드도 모델도 설정도 한 줄 건드리지 않았습니다. GPU 연산 오류도 모델 오류도 흔적이 없었어요. 범인은 메모리를 지키려고 켜둔 감시 데몬 earlyoom이었습니다. NVIDIA 공식 셋업이 기본으로 넣어준 녀석이에요. earlyoom의 일은 단순합니다. 가용 메모리가 2% 아래로 떨어지면 "나쁜 점수(badness)"가 가장 높은 프로세스를 먼저 끝내는 것. 메모리를 지키는 파수꾼이고, 보통 기계에서는 아주 합리적인 선입니다. 그런데 통합메모리 머신에서는 그 2%가 평상시 가동 영..

문패 배터리를 밤새 충전했는데 아침에 잔량이 93%로 떠 있었습니다. 100%가 아닙니다. 충전 회로도 깨지고 보드 ADC도 고장 난 건가 싶어서 멀티미터와 USB 전력 테스터를 끌어다 붙였는데, 결론부터 말씀드리면 하드웨어는 할 일을 하고 있었고 틀린 쪽은 전부 제가 잡은 가정들이었습니다. 이 기기는 1편에서 e-paper로 바꾼 바로 그 문패입니다. 제 워크스테이션이 그린 비트맵을 문패가 받아서 문에 띄우고, 자기 배터리 전압은 보드 ADC로 읽는 구조죠. 1편을 쓰고 나서 잔량 표시가 자꾸 이상해서 파고들었고, 하나씩 실측으로 고쳐간 과정을 아래 순서 그대로 적어봅니다. 먼저 무너진 가정, "완충 = 4.2V"처음엔 보드 ADC를 의심했습니다. 멀티미터로 배터리 전압을 직접 재서 비교해보니 보드가 ..

검사실 쪽 Windows 워크스테이션 하나가 아팠습니다. 원격 데스크탑 접속이 어느 날부터 안 열려서, 결국 SSH로만 상태를 확인해야 했어요. SSH는 열리니 기계가 완전히 죽지는 않았지만, 짐을 옮길 문은 계속 닫혀 있었어요. 그 컴퓨터가 아픈 데에는 뒤에 또 다른 사정이 있었지만, 그날의 진짜 본업은 따로 있었습니다. 영상 데이터 이관이요. 현장 폐쇄망 안의 이미징 스토리지에 폴더 11개, 합계 3.19TB가 담겨 있었고, 연구실 워크스테이션 드라이브로 통째로 옮겨야 했습니다. 예전에는 원격 데스크탑으로 접속해서 탐색기를 끌어다 복사하는 방식으로 이런 일을 처리했습니다. 그런데 대용량 폴더를 옮기면 부하가 심하게 걸려서 컴퓨터가 다운되는 일이 반복됐어요. 그래서 죽어도 이어지는 구조가 필요했습니다...