Qwen 27B·35B 병렬 운용, 대형 모델 하나보다 나을까

로컬 AI 장비를 고를 때 흔히 생기는 질문이 있다. Qwen 27B와 35B를 동시에 띄우는 편이 나을까, 같은 자원으로 더 큰 모델 하나를 돌리는 편이 나을까. 답은 매개변수 합계가 아니라 실제 작업이 동시에 진행되는지에 달려 있다.

27B와 35B는 크기만 다른 모델이 아니다

여기서 비교할 모델은 Qwen3.5-27B와 Qwen3.5-35B-A3B다. 이름만 보면 35B가 27B의 상위 모델처럼 보인다. 하지만 두 모델은 계산 구조부터 다르다.

Qwen 공식 모델 카드에 따르면 27B는 64개 층을 갖춘 Dense 모델이다. 추론할 때 270억 개 매개변수 전체를 사용한다. 반면 35B-A3B는 총 350억 개 가운데 토큰마다 약 30억 개만 활성화하는 MoE 모델이다. 256개 전문가 중 라우팅된 8개와 공유 전문가 1개가 동작한다. (huggingface.co)

35B-A3B는 저장할 가중치가 더 많지만 토큰당 계산량은 작다. 27B는 대체로 느리고 무겁게 계산하는 대신 복잡한 지시와 긴 문맥에서 유리할 여지가 있다. Qwen이 공개한 평가에서도 27B가 MMLU-Pro, IFEval, LongBench v2에서 35B-A3B보다 높은 점수를 기록했다. 모든 실제 작업에서 우세하다는 보장은 없다. 그래도 35B라는 숫자만으로 품질을 판단하면 안 되는 이유는 분명하다. (huggingface.co)

써본 사람들 사이에서도 35B-A3B는 응답 속도가 좋고 좁은 작업에 적합하다는 반응이 많다. 엄격한 형식 준수나 여러 도구를 잇는 작업에서는 27B를 선호한다는 의견도 함께 나온다.

두 모델을 띄워도 일이 직렬이면 이득이 없다

병렬 운용의 가치는 두 요청이 실제로 겹칠 때 생긴다. 27B가 저장소 구조를 분석하는 동안 35B-A3B가 테스트나 문서 초안을 만드는 구성이라면 처리량이 늘어난다. 한 모델의 답을 기다린 뒤 다른 모델을 호출하는 워크플로에서는 두 모델이 메모리만 차지한다.

Claude Code 같은 코딩 에이전트도 한 세션 안에서는 계획, 도구 호출, 결과 확인이 순차적으로 이어지는 경우가 많다. 서브에이전트나 독립 작업 큐를 명시적으로 사용하지 않으면 GPU가 둘이어도 한쪽이 쉬는 시간이 길어진다. 방 논의에서 상위 GPU 구성이 기대만큼 활용되지 않을 수 있다는 의견도 이 지점을 가리킨다.

같은 모델에 요청을 여러 개 보내는 방식은 별개의 문제다. Ollama는 OLLAMA_NUM_PARALLEL로 모델당 병렬 요청 수를 조절한다. 다만 병렬 수가 늘면 각 요청의 문맥을 위한 메모리도 증가한다. 공식 FAQ는 2K 문맥 네 개를 병렬 처리하면 8K에 해당하는 문맥 메모리가 필요하다고 설명한다. (ollama.readthedocs.io)

긴 저장소를 읽는 에이전트에서는 KV cache가 모델 가중치 못지않게 중요하다. Hugging Face 문서도 입력 배치와 KV cache가 같은 메모리 예산을 두고 경쟁한다고 설명한다. 가중치 두 개가 간신히 들어간다는 계산만으로 동시 운용 가능 여부를 판단하면 OOM이나 급격한 속도 저하를 만나기 쉽다. (huggingface.co)

가장 단순한 구성은 GPU마다 서버를 하나씩 두는 방식이다

두 개의 독립 GPU가 있다면 각 GPU에 모델 서버를 하나씩 고정하는 구성이 이해하기 쉽다. 27B 서버는 계획과 코드 검토를 맡는다. 35B-A3B 서버에는 검색 결과 정리나 제한된 수정 작업을 맡긴다.

llama.cpp에서는 다음 순서로 구성할 수 있다.

• GPU 0에서 CUDA_VISIBLE_DEVICES=0 llama-server -m qwen27.gguf --port 8081 -c 32768 -np 1을 실행한다.
• GPU 1에서는 CUDA_VISIBLE_DEVICES=1 llama-server -m qwen35-a3b.gguf --port 8082 -c 32768 -np 1을 실행한다.
• 오케스트레이터가 작업 종류에 따라 8081과 8082로 요청을 보낸다.
• 실제 최대 입력 길이에 맞춰 -c를 올리고 GPU 메모리 최고치를 다시 측정한다.

Ollama를 쓴다면 OLLAMA_MAX_LOADED_MODELS=2와 OLLAMA_NUM_PARALLEL=1로 시작하는 편이 안전하다. Q4 계열 기준으로 Ollama가 표시하는 모델 크기는 27B가 약 17GB, 35B-A3B가 약 24GB다. 여기에 KV cache와 실행 버퍼가 붙는다. 따라서 24GB GPU 한 장에 35B-A3B를 올릴 때는 양자화 수준과 문맥 길이를 낮춰 여유 공간을 남겨야 한다. (ollama.com)

큰 모델 하나를 여러 GPU에 나눠도 속도가 두 배가 되지는 않는다

더 큰 단일 모델은 한 요청의 품질을 높이거나 모델 자체가 한 GPU에 들어가지 않을 때 의미가 있다. vLLM도 한 GPU에 모델이 들어가면 분산 추론을 피하고 들어가지 않을 때 단일 노드의 tensor parallel을 쓰도록 안내한다. (docs.vllm.ai)

llama.cpp의 기본 다중 GPU 방식은 층과 KV cache를 나누는 layer 모드다. row는 가중치 행을 병렬로 나눈다. tensor는 가중치와 KV를 함께 분할하지만 아직 실험 기능으로 표시돼 있다. GPU 사이의 PCIe 전송이 추가되므로 카드 수와 생성 속도가 비례하지 않는다. (github.com)

한 요청만 처리한다면 더 큰 모델을 두 GPU에 나누는 구성이 자연스럽다. 독립된 두 요청이 계속 들어온다면 GPU마다 별도 모델을 두는 편이 통신 부담을 줄이고 전체 완료량을 높일 수 있다. 여러 에이전트를 운용한 사용자들 사이에서도 단일 답변 속도보다 동시에 끝나는 작업 수가 크게 늘었다는 평가가 있다. 반면 긴 프롬프트의 prefill이 다른 요청을 지연시킨다는 불만도 나온다.

구매 전에는 같은 작업 묶음으로 두 구성을 재야 한다

비교용 프롬프트는 짧은 산수 문제가 아니라 실제 저장소 작업이어야 한다. 오류 수정, 테스트 작성, 긴 파일 분석, 도구 호출을 각각 5회 이상 실행한다. 첫 토큰 대기 시간, 초당 토큰, 전체 완료 시간, 성공률, 최대 VRAM을 함께 기록한다.

A 구성에서는 27B와 35B-A3B를 별도 GPU에 두고 두 작업을 동시에 보낸다. B 구성에서는 더 큰 모델 하나에 같은 작업을 순차 또는 동시 배치한다. 단일 요청의 최고 품질이 중요하면 B가 이길 수 있다. 작은 팀의 코드 검토와 문서화가 계속 겹친다면 A의 총처리량이 더 중요해진다.

GPU 코어 수보다 먼저 확인할 숫자는 동시에 살아 있는 독립 작업의 수다. 그 값이 대부분 1이라면 두 중형 모델은 과잉 구성이다. 꾸준히 2 이상이라면 대형 모델 하나가 오히려 병목이 된다.