V100 서버를 운용 중인 변호사의 업데이트입니다. 상황이 정리된 후 제가 실제로 무엇을 실행하게 되었는지 묻는 분들이 몇 분 계셔서 공유합니다. 여전히 변호사이고, 여전히 Claude Code를 통해 모든 것을 구동하고 있으며, 여전히 제가 무엇을 하고 있는지 완전히 확신하지는 못하지만 — 이제는 작동합니다. 지난번보다는 나은 상태죠.

먼저, 하드웨어가 계획대로 갖춰졌습니다. 마지막 2개의 V100이 들어왔으므로, 제가 약속했던 "최종 형태"가 실현되었습니다: Threadripper Pro 기반의 12개 V100-SXM2 32GB 구성입니다. GPU {4,5,8,9}는 Board A, {6,7,10,11}은 Board B, {0,1}은 NVLink 쌍, 그리고 한 카드가 16GB인 {2,3}은 혼합 쌍으로 구성됩니다. 모델을 두 개의 서로 다른 NVLink 보드에 나누어 배치하면 처리량(throughput)이 급격히 떨어집니다(보드 간 이동은 NVLink가 아닌 PCIe/NUMA 방식이기 때문입니다). 그래서 저는 모든 모델을 하나의 보드 내에 유지합니다. 비싼 대가를 치르고 배운 교훈입니다.

그리고 네, 결국 굴복하여 두 번째 박스를 구축했습니다. EPYC 7302P, 512GB RAM, 4x RTX 3090 + 2x V100-PCIe 구성입니다. 중년의 위기는 예정대로 진행 중입니다.

더 큰 변화는 로컬 모델에 대해 vLLM 사용을 포기했다는 점입니다. vLLM이 나빠서가 아니라, 제가 실제로 원하는 모델들이 MoE GGUF 형식이기 때문입니다. Volta 아키텍처에서 vLLM은 해당 모델들을 돌리기에 막다른 길입니다(FP8/AWQ/Marlin은 모두 SM75+를 요구하며, GPTQ 커널은 7.0에서 작동하지 않습니다). 저는 전체 시스템을 llama.cpp(메인라인 — 최근 빌드에서 제 긴 프롬프트를 망가뜨리던 Gemma 채팅 파서 버그가 마침내 수정되었습니다)로 옮겼습니다.

제 첫 번째 게시물이 암시했던 것과는 정반대인 부분이 여기 있습니다: V100에서는 Dense 모델이 함정입니다. MoE만이 사용 가능한 속도를 확보할 수 있습니다. 대략적인 디코딩(decode) 수치입니다 — Q8 GGUF, Q4 KV 캐시(KV cache), flash-attn 활성화, 4개 카드 보드 1개 사용, 실제 초안 작성 프롬프트(5개 토큰 정도의 "hello"가 아닌 수천 토큰의 컨텍스트) 기준입니다:

따라서 122B/10B-active 추론 모델 (reasoning model)은 4개의 V100에서 약 50 tok/s로 작동합니다. 이는 제 첫 번째 포스트에서 vLLM으로 관리했던 32B Dense 모델보다 빠르며, 긴 컨텍스트 (long context)에서도 그 속도를 유지합니다 (Dense 모델들이 한계에 부딪혔던 25k 토큰 이상까지 Gemma를 밀어붙여 보았습니다). 이 결과로 모든 관점이 바뀌었습니다. 저는 거대한 Dense 가중치 (weights)를 쫓는 것을 멈추고, MoE (Mixture of Experts)를 중심으로 시스템을 구축했습니다.

실제로 실행 중인 구성 (여러분이 요청하신 스택)은 다음과 같습니다:
단일 모델이 채팅에 답변하는 방식이 아닙니다. 법률 작업을 여러 로컬 모델로 라우팅 (routing)하는 오케스트레이터 (orchestrator)이며, 각 모델은 GPU를 두고 다투지 않도록 각자의 보드 (board)에 할당되어 있습니다. 가장 무거운 작업(접수부터 문서 완성까지의 전체 진술서 또는 신청서 작성)을 실행할 때는 두 박스에 걸쳐 16개의 GPU가 활성화됩니다:

• 주력 초안 작성 (Workhorse drafting) — Board A {4,5,8,9}의 Qwen3.6-35B-A3B
• 고난도 추론 + 중대한 초안 작성 (Heavy reasoning + high-stakes drafting) — Board B {6,7,10,11}의 Qwen3.5-122B-A10B

솔직한 부분입니다. 지난번 이 서브레딧(sub) 덕분에 정직함을 유지할 수 있었으니까요:

• 로컬 모델들은 인용(citation)과 날짜를 환각(hallucinate)합니다. 그것도 아주 자신만만하게 말이죠. 저는 적대적 검토자(adversarial reviewer) 외에도, 초안에 포함된 모든 인용, 날짜, Bates number를 실제 원본 자료와 대조하여 확인하고, 근거를 찾을 수 없는 모든 내용을 차단하는 검증기(verifier)를 구축해야 했습니다. 로컬 초안 작성은 이봉성(bimodal)을 띱니다. 때로는 스스로 지어내는 것을 올바르게 거부하지만, 때로는 날짜가 포함된 연대기 전체를 날조하면서 동시에 아무것도 지어내지 않았다고 맹세하기도 합니다. 해당 게이트(gate)와 저의 확인 없이는 최종 문서에 절대 손을 대지 못하게 했습니다.

• 제가 발견한 가장 멍청한 버그는 제 파이프라인(pipeline) 자체가 약 79% 오염되어 있었다는 점입니다. 증거 번들(evidence bundle)을 구축하는 기능이 이전의 자체 출력물을 마치 의뢰인의 증거인 양 긁어모으고 있었고, 그 결과 모델들이 이전에 자신이 작성한 쓰레기(slop)를 바탕으로 "근거 제시(grounding)"를 하고 있었습니다. 한 번은 RTX 3060을 Bates number로 인용하기도 했는데, 뭐, 그럴 수도 있죠. 빌더(builder)가 자신의 꼬리를 먹지 않도록 수정하고 이를 깨끗이 지웠습니다. 만약 RAG 또는 에이전트(agent) 파이프라인을 실행 중이라면, 컨텍스트 윈도우(context window)에 실제로 무엇이 들어있는지 확인해 보세요. 제 것은 거울의 방(hall of mirrors) 같았고, 저는 전혀 모르고 있었습니다.

• 또한, 로컬 전용(local-only)으로 실행하라고 명령했을 때 클라우드 모델로 조용히 전환(fallback)하는 것을 거부하도록 만들었습니다. 특정 단계를 로컬에서 수행할 수 없다면, 제 뒤에서 Anthropic에 전화를 거는 대신 모델이 직접 그 이유를 명시하도록 했습니다.

여전히 첫 번째 포스트에서 원했던 바로 그것, 즉 저처럼 글을 쓰고 지루한 양식 채우기나 패턴 작업을 처리하는 모델을 원하고 있습니다. 이제 목표에 더 가까워졌습니다. 현재 시스템은 제 편집 사항을 수정 데이터 (correction data)로 캡처하고 있으며, 이는 진정한 미세 조정 (fine-tune) 데이터셋의 시작입니다. 아직 QLoRA를 실행하지는 않았습니다. 따라서 동일한 질문들이 남아 있으며, 진심으로 조언을 구합니다:

• 이 하드웨어 (V100, bf16 미지원, FA2 미지원)에서 QLoRA를 수행할 때, 35B-A3B MoE 베이스 모델을 선택해야 할까요, 아니면 실제로 학습 가능한 약 14B 밀집 (dense) 모델을 미세 조정하고 무거운 서빙 (serving)을 위해 MoE를 유지하는 것이 더 현명할까요?
• Volta 아키텍처에서 MoE를 서빙하는 분들 중 llama.cpp보다 빠른 것을 발견하신 분이 계신가요 — ik_llama인가요, 아니면 다른 것인가요? 그리고 Q4보다 더 나은 긴 문맥 (long-context) KV 스토리가 있을까요?
• 모든 작업에 35B 모델을 그냥 돌릴 수 있는데도 50 tok/s 속도로 122B-A10B 모델을 계속 유지하고 있는 제가 바보 같은 짓을 하고 있는 걸까요?

제가 무엇을 잘못하고 있는지 알려주세요.