218B 오픈 모델 Command A+, 두 장 H100의 계산서

AI 요약

• 무슨 일: Cohere가 218B total, 25B active sparse MoE 모델 Command A+를 Apache 2.0으로 공개했습니다.
  • W4A4 양자화 기준 2×H100 또는 1×B200 실행, 128K 입력 문맥, 64K 최대 생성을 내세웁니다.
• 의미: 오픈 모델 경쟁이 순위표보다 에이전트 추론비, 사설 배포, 툴 호출 조건으로 이동하고 있습니다.
• 주의점: 두 장 H100도 많은 팀에는 높은 장벽이고, 일부 North 평가는 LLM-as-a-judge 방식입니다.

Cohere가 2026년 5월 20일 Command A+를 공개했습니다. 표면적으로 보면 또 하나의 오픈 모델 릴리스입니다. 하지만 이번 발표에서 눈에 띄는 부분은 "가장 똑똑한 모델"이라는 주장보다 훨씬 실무적입니다. Cohere는 이 모델이 Apache 2.0 라이선스로 공개됐고, 218B 전체 파라미터 중 토큰마다 25B만 활성화하는 sparse Mixture-of-Experts 구조이며, W4A4 양자화 기준으로 두 장의 NVIDIA H100 또는 한 장의 B200에서 실행 가능하다고 설명합니다.

이 숫자 조합이 중요합니다. 기업 AI 팀이 에이전트를 실제 업무에 넣으려 할 때 가장 먼저 부딪히는 문제는 "모델이 충분히 똑똑한가"만이 아닙니다. 에이전트는 한 번 답하고 끝나는 챗봇보다 훨씬 많은 토큰을 씁니다. 문서를 읽고, 도구를 호출하고, 계획을 세우고, 실패를 되돌아보고, 다시 실행합니다. API 호출량은 예측하기 어렵고, 내부 문서와 고객 데이터는 외부로 보내기 어렵습니다. 그러면 자연스럽게 질문이 바뀝니다. 이 모델을 우리 인프라에서 돌릴 수 있는가. 어느 정도 GPU가 필요한가. 라이선스는 제품에 넣을 수 있는가. 툴 호출과 긴 문맥은 되는가.

Command A+는 바로 그 계산서에 답하려는 릴리스입니다.

218B지만 매번 218B를 쓰지는 않습니다

Cohere 공식 발표와 Hugging Face 모델 카드를 종합하면 Command A+의 핵심 스펙은 꽤 명확합니다. 모델명은 command-a-plus-05-2026이고, 라이선스는 Apache 2.0입니다. 구조는 sparse MoE입니다. 전체 파라미터는 218B지만, 토큰마다 활성화되는 파라미터는 25B입니다. 컨텍스트는 128K 입력, 64K 최대 생성입니다. 텍스트뿐 아니라 이미지 입력, reasoning, tool use를 지원한다고 설명합니다. 지원 언어는 48개이고, Hugging Face 모델 카드에는 Korean도 포함되어 있습니다.

여기서 MoE 구조는 단순한 모델 크기 자랑이 아닙니다. dense 218B 모델을 매 토큰마다 전부 계산하는 방식이라면 자체 호스팅의 문턱은 훨씬 높아집니다. Command A+는 128개 expert 중 일부를 선택하는 방식으로 전체 용량과 추론 비용 사이의 타협점을 잡습니다. Hugging Face 모델 카드는 토큰마다 8개 expert가 활성화되고 shared expert가 적용된다고 설명합니다. 이 구조 자체가 새롭다고 말하기는 어렵지만, Cohere가 기업용 에이전트 모델의 공개 배포판에 이 구조를 전면 배치했다는 점은 의미가 있습니다.

또 하나의 핵심은 양자화입니다. Cohere는 BF16, FP8, W4A4 세 가지 양자화 버전을 제시합니다. Hugging Face 모델 카드 기준 최소 GPU 요구사항은 BF16이 4×B200 또는 8×H100, FP8이 2×B200 또는 4×H100, W4A4가 1×B200 또는 2×H100입니다. 대부분의 팀에게 "두 장 H100"은 여전히 가벼운 로컬 실행이 아닙니다. 그러나 기업 AI 인프라 관점에서는 사내 GPU 서버나 전용 클라우드 인스턴스에서 검토 가능한 숫자로 내려온 것도 사실입니다.

이 지점이 이번 발표의 현실적인 긴장입니다. Command A+는 개인 노트북 오픈 모델이 아닙니다. 하지만 "대형 엔터프라이즈 에이전트 모델은 반드시 proprietary API로만 써야 한다"는 주장도 약하게 만듭니다. 오픈 모델 시장은 점점 "내 맥북에서 돌아간다"와 "프론티어 API를 호출한다" 사이의 넓은 회색 지대로 이동하고 있습니다.

Cohere가 강조한 벤치마크는 에이전트 쪽입니다

Cohere 발표에서 가장 공격적인 수치는 일반 채팅 리더보드보다 에이전트와 업무형 평가에 몰려 있습니다. Command A Reasoning과 비교해 ²-Bench Telecom은 37%에서 85%로, Terminal-Bench Hard는 3%에서 25%로 올랐다고 설명합니다. IFBench는 36%에서 74%, AIME 25는 57%에서 90%, SciCode는 30%에서 38%로 제시됩니다.

Terminal-Bench Hard가 특히 눈에 띕니다. 터미널 환경에서 문제를 해결하는 능력은 코딩 에이전트, 데이터 작업 에이전트, 운영 자동화 에이전트에 가까운 신호입니다. 물론 25%라는 숫자만 보면 "이제 완성됐다"라고 말하기 어렵습니다. 오히려 반대입니다. 어려운 터미널 과제에서는 여전히 실패가 많습니다. 하지만 3%에서 25%라는 변화는 Cohere가 Command A+를 일반 대화 모델보다 에이전트 실행 모델로 설계했다는 방향성을 보여줍니다.

North 내부 평가도 같은 방향입니다. Cohere는 자사 엔터프라이즈 워크스페이스인 North에서 Agentic Question Answering, Data Analysis, Memory Usage Quality를 평가했고, 각각 45%에서 65%, 13%에서 45%, 39%에서 54%로 개선됐다고 설명합니다. 이 수치는 흥미롭지만 읽는 방식은 조심해야 합니다. Cohere는 이 평가가 LLM-as-a-judge 방식이라고 밝힙니다. 내부 제품 평가이기 때문에 실제 고객 환경에서의 재현성, 데이터 구성, judge 편향, 실패 비용을 별도로 검증해야 합니다.

그래도 방향은 분명합니다. Cohere가 말하는 Command A+의 고객은 "가장 재미있는 챗봇"을 찾는 사용자가 아닙니다. 문서를 읽고, MCP로 연결된 파일 시스템이나 업무 시스템에서 근거를 찾아오고, 스프레드시트를 분석하고, 이전 대화의 메모리를 활용하는 기업 에이전트입니다. 그래서 모델 스펙도 일반 텍스트 생성보다 긴 문맥, tool use, citation, 다국어, 멀티모달 문서 처리 쪽으로 맞춰져 있습니다.

Apache 2.0이 중요한 이유

오픈 모델이라는 말은 너무 넓습니다. 어떤 모델은 연구 목적에는 열려 있지만 상업적 사용이 까다롭고, 어떤 모델은 weights는 공개하지만 라이선스 조건이 제품화에 부담을 줍니다. Command A+의 Apache 2.0 공개는 그래서 기사 제목에 들어갈 만한 사실입니다. 기업 개발자는 성능표만 보고 모델을 고르지 않습니다. 제품에 넣을 수 있는지, 고객 데이터와 함께 fine-tuning하거나 serving할 수 있는지, 법무 검토를 통과할 수 있는지가 중요합니다.

Apache 2.0은 이 논의를 단순하게 만듭니다. 물론 라이선스가 모든 위험을 제거하지는 않습니다. 모델 학습 데이터, 출력물 책임, 안전 정책, 산업별 규제, 고객 계약은 여전히 남습니다. 하지만 "이 모델을 상업 제품이나 사내 플랫폼에 쓸 수 있는가"라는 첫 관문에서 Apache 2.0은 강한 신호입니다.

이 점은 Cohere의 전략과도 맞물립니다. Cohere는 OpenAI나 Anthropic처럼 소비자 앱으로 대중의 시간을 장악하는 회사라기보다, 기업이 통제 가능한 환경에서 AI를 배포하도록 돕는 쪽에 가깝습니다. Command A+는 그 전략의 모델 레이어입니다. North, Model Vault, private deployment 같은 제품과 결합하면 "Cohere API를 쓰세요"보다 "당신의 환경에서 기업형 에이전트를 운영하세요"에 가까운 메시지가 됩니다.

두 장 H100은 싸지 않지만, 비교 기준을 바꿉니다

Command A+ 발표에서 가장 흥미로운 표현은 "as little as two H100 GPUs"입니다. 이 문장은 독자에 따라 정반대로 읽힙니다. 개인 개발자에게는 "두 장이나 필요하다고?"에 가깝습니다. 스타트업에게도 쉽지 않습니다. H100 서버는 여전히 비싸고, 안정적인 serving을 위해서는 모델 weight뿐 아니라 네트워크, 스토리지, 모니터링, autoscaling, 장애 대응, 보안 운영이 필요합니다.

하지만 엔터프라이즈 관점에서는 계산이 달라집니다. 이미 GPU 클러스터를 보유했거나, 민감 데이터 때문에 외부 API 사용이 제한되거나, 에이전트가 대량 토큰을 반복적으로 쓰는 조직이라면 두 장 H100은 "불가능한 연구 장비"가 아니라 "전용 워크로드 단위"로 보일 수 있습니다. 특히 에이전트는 비용 예측이 어렵습니다. 한 사용자의 작업이 몇 번의 tool call로 끝날지, 실패 후 얼마나 많은 재시도를 할지, 긴 컨텍스트를 얼마나 자주 유지할지에 따라 API 청구액이 크게 흔들립니다.

자체 호스팅은 이 문제를 완전히 해결하지 않습니다. GPU를 사거나 빌려도 비용은 사라지지 않고 다른 형태로 바뀝니다. 하지만 비용의 성격은 달라집니다. 토큰 단위 변동비를 GPU 점유율과 운영비로 바꾸는 선택입니다. 보안팀과 재무팀이 보는 표도 달라집니다. 어떤 팀에게는 API가 더 싸고 빠릅니다. 어떤 팀에게는 사내 추론이 더 통제 가능하고 예측 가능합니다. Command A+가 던진 질문은 "오픈 모델이 프론티어 모델을 이겼는가"보다 "어떤 워크로드부터 자체 추론으로 옮길 수 있는가"에 가깝습니다.

tool use와 citation은 모델 능력보다 운영 계약입니다

Hugging Face 모델 카드는 Command A+가 conversational tool use에 맞춰 훈련됐고, Transformers chat template에서 JSON schema 기반 tool description을 제공하는 방식을 설명합니다. citation을 켜면 모델이 tool result의 특정 span에 응답 일부를 연결하는 태그 형식을 쓴다고도 설명합니다.

이 기능들은 데모에서는 작게 보이지만, 기업 에이전트에서는 핵심입니다. 에이전트가 CRM, 데이터베이스, 문서 저장소, 티켓 시스템, 배포 파이프라인을 호출할 때 중요한 것은 "도구를 부를 수 있다"가 아닙니다. 어떤 도구를 언제 부르는지, 결과를 어떻게 근거로 삼는지, 잘못된 도구 호출을 어떻게 막는지, 사용자가 나중에 왜 이런 결론이 나왔는지 추적할 수 있는지가 중요합니다.

따라서 Command A+의 tool use는 모델 기능이면서 동시에 운영 계약입니다. 모델은 도구 호출 형식을 따라야 하고, 호스트 애플리케이션은 권한과 schema를 잘 설계해야 합니다. 모델이 citation span을 낼 수 있어도, 실제 tool result가 부정확하거나 권한이 과도하면 근거 있는 잘못된 답이 나옵니다. 에이전트의 신뢰성은 모델 alone의 문제가 아니라 모델, 도구, 데이터, 권한, 로그, human review의 합성 결과입니다.

이 점에서 Command A+는 오픈 모델 운영팀에게 더 많은 자유와 더 많은 책임을 동시에 줍니다. proprietary API를 쓰면 모델 내부는 덜 보이지만 운영 부담 일부를 공급자에게 넘길 수 있습니다. 자체 호스팅 오픈 모델을 쓰면 데이터와 배포 위치를 통제할 수 있지만, serving 품질, 안전 정책, 업데이트, 평가, 장애 대응을 직접 책임져야 합니다.

128K 문맥은 충분한가

커뮤니티 반응에서 반복되는 지적 중 하나는 128K 입력 문맥입니다. 몇 년 전이라면 128K는 매우 긴 문맥이었습니다. 지금은 Gemini 계열의 초장문 컨텍스트, Claude의 긴 문맥, 여러 오픈 모델의 256K 이상 문맥 발표가 이어지면서 128K가 아주 큰 숫자로만 보이지는 않습니다.

하지만 문맥 길이는 길수록 무조건 좋은 숫자가 아닙니다. 긴 문맥은 비용, 지연, attention/KV cache, retrieval 품질, 실제 사용 패턴과 연결됩니다. 많은 기업 업무에서는 1M 문맥보다 더 중요한 것이 있습니다. 필요한 문서를 잘 찾는 retrieval, 문서 출처를 보존하는 citation, tool result를 구조화하는 schema, 긴 세션에서 상태를 잃지 않는 memory, 그리고 실패했을 때 작업을 되감는 workflow입니다.

Command A+의 128K는 "모든 문서를 한 번에 넣는다"는 전략보다, RAG와 tool use를 전제로 한 긴 작업 공간에 가깝게 읽는 편이 맞습니다. Cohere도 North와 agentic QA, spreadsheet analysis, memory 평가를 함께 제시합니다. 즉 긴 문맥 단독 경쟁이 아니라 문맥, retrieval, tool use, memory를 묶은 엔터프라이즈 작업 모델을 말하고 있습니다.

한국어 팀에게도 숫자가 있습니다

Command A+ 발표에서 작지만 흥미로운 수치는 토크나이저입니다. Cohere는 새 토크나이저가 Arabic 20%, Korean 16%, Japanese 18%의 tokenization efficiency 개선을 보였다고 설명합니다. 한국어 개발자와 기업에게 이 수치는 무시하기 어렵습니다.

LLM 비용은 보통 토큰으로 계산됩니다. 한국어 문서가 영어보다 비효율적으로 잘리면 같은 업무에서도 비용과 지연이 커집니다. 자체 호스팅에서도 토큰 수는 latency와 throughput에 영향을 줍니다. 한국어 고객지원 기록, 사내 문서, 계약서, 회의록, 정책 문서를 많이 다루는 팀이라면 토크나이저 효율은 모델 품질만큼이나 운영비에 영향을 줄 수 있습니다.

다만 토큰 효율 개선이 곧 한국어 reasoning 품질을 보장하지는 않습니다. 토큰이 적게 나뉘어도 전문 용어를 이해하지 못하거나, 한국어 문서의 암묵적 구조를 놓치거나, 날짜와 숫자를 잘못 읽으면 실무 가치는 떨어집니다. 한국어 팀이 Command A+를 검토한다면 단순 번역 벤치마크보다 실제 문서 기반 QA, 표 추출, 규정 검토, 고객 응대 로그 요약, 코드 주석/이슈 분석 같은 내부 평가를 먼저 만들어야 합니다.

커뮤니티는 기대와 회의 사이에 있습니다

LocalLLaMA 쪽 반응은 대체로 복합적입니다. Hugging Face 모델 카드 공유 글에는 적지 않은 관심이 붙었고, Cohere의 과거 Command R/R+를 기억하는 사용자는 Apache 2.0 공개를 반겼습니다. 반면 회의도 분명합니다. 어떤 사용자는 128K 컨텍스트가 아쉽다고 봤고, 어떤 사용자는 두 장 H100이 여전히 너무 무겁다고 봤습니다. Command A Reasoning까지 공개했으면 더 큰 반응을 얻었을 것이라는 의견도 있었습니다.

이 반응은 자연스럽습니다. 오픈 모델 커뮤니티는 "내가 직접 돌릴 수 있는가"를 중요하게 봅니다. 그 기준에서 Command A+는 경량 모델이 아닙니다. 반대로 기업 AI 팀은 "내가 통제할 수 있는 환경에서 돌릴 수 있는가"를 봅니다. 그 기준에서는 Apache 2.0, W4A4, vLLM, Transformers, 2×H100이라는 조합이 꽤 구체적입니다.

즉 Command A+는 모두를 만족시키는 모델이 아닙니다. 개인 로컬 LLM 사용자에게는 여전히 큰 모델이고, 프론티어 API만 쓰는 팀에게는 운영 부담이 커 보입니다. 하지만 사내 GPU, 민감 데이터, 다국어 문서, 에이전트 워크플로, 비용 예측성이라는 조건이 겹치는 조직에는 검토할 만한 새 기준선을 제시합니다.

오픈 모델의 승부처는 이제 제품 운영입니다

Command A+를 둘러싼 더 큰 질문은 오픈 모델의 경쟁 방식입니다. 한동안 오픈 모델 뉴스는 "폐쇄형 모델을 얼마나 따라잡았는가"에 집중했습니다. 하지만 기업 도입 단계에서는 조금 다른 질문들이 커집니다. serving stack은 안정적인가. vLLM에서 tool call parsing이 잘 되는가. 모델 업데이트는 어떻게 적용하는가. eval을 어떻게 자동화하는가. latency와 throughput이 실제 사용량에서 버티는가. 데이터 권한과 audit log는 어떻게 남기는가.

Command A+는 이 질문들을 모두 해결해 주지는 않습니다. 대신 질문을 더 구체적으로 만듭니다. 예를 들어 W4A4는 하드웨어 요구사항을 낮추지만, quantization이 long reasoning과 hard benchmark에서 어떤 실패 패턴을 만드는지는 별도로 봐야 합니다. Cohere 모델 카드는 reasoning 모델이 낮은 비트 양자화에서 더 큰 손실을 겪을 수 있어 selective quantization과 distillation을 적용했다고 설명합니다. 좋은 접근입니다. 하지만 최종 판단은 각 팀의 workload에서 해야 합니다.

또한 2×H100 실행이 가능하다는 말과 production serving이 충분하다는 말은 다릅니다. 한 사용자가 느리게 테스트하는 것과 수십 명의 분석가가 동시에 긴 문서를 처리하는 것은 다릅니다. 64K 출력을 실제로 자주 생성한다면 비용과 지연은 다시 커집니다. 에이전트가 tool call을 여러 번 반복하면 GPU보다 외부 시스템 지연이 병목이 될 수도 있습니다.

그래서 누구에게 의미가 큰가

첫째, 규제 산업의 AI 플랫폼 팀입니다. 금융, 공공, 의료, 제조, 방산처럼 데이터 위치와 접근 권한이 중요한 조직은 proprietary API만으로 모든 에이전트 업무를 처리하기 어렵습니다. Command A+ 같은 오픈 모델은 최소한 파일럿의 폭을 넓힙니다.

둘째, 다국어 문서를 많이 다루는 기업입니다. 48개 언어 지원과 한국어 토큰 효율 개선 주장은 검증할 가치가 있습니다. 특히 영어 외 문서가 비용을 밀어 올리는 팀이라면 토크나이저와 retrieval 품질을 함께 봐야 합니다.

셋째, 에이전트 제품을 만드는 개발자입니다. tool use, citation, 긴 문맥, image input이 하나의 모델에 들어 있다는 점은 제품 설계 선택지를 늘립니다. 다만 에이전트 제품의 차별화는 모델을 붙이는 순간 끝나지 않습니다. 권한, UI, 관측성, 재시도, human-in-the-loop, rollback이 실제 제품 품질을 가릅니다.

넷째, GPU 비용을 이미 지불하고 있는 조직입니다. 사내 GPU가 놀고 있거나, inference workload를 장기적으로 예측할 수 있거나, API 비용이 빠르게 커지고 있다면 Command A+는 비교표에 올릴 만합니다. 반대로 GPU 운영 경험이 없는 작은 팀이라면 managed API가 여전히 더 싸고 빠를 수 있습니다.

결론

Command A+는 "Cohere가 새 모델을 냈다"로 끝낼 뉴스가 아닙니다. 더 정확히는 에이전트 시대의 오픈 모델이 어떤 조건을 갖춰야 하는지 보여주는 사례입니다. Apache 2.0이어야 하고, sparse MoE로 추론비를 줄여야 하며, tool use와 citation을 지원해야 하고, 긴 문맥과 다국어 문서를 처리해야 하며, 적어도 기업 GPU 단위에서는 자체 실행이 가능해야 합니다.

물론 아직 답보다 질문이 많습니다. 두 장 H100은 충분히 낮은 장벽인가. 내부 North 평가가 실제 고객 업무에서도 재현되는가. 128K 문맥은 에이전트 업무에 충분한가. W4A4 양자화는 긴 reasoning과 tool call에서 어떤 실패를 만드는가. 한국어 문서 처리 품질은 토큰 효율만큼 좋아졌는가.

그래도 이번 릴리스가 던진 메시지는 선명합니다. 오픈 모델 경쟁은 더 이상 "작고 무료인 모델"만의 이야기가 아닙니다. 기업 에이전트가 실제로 움직이려면 모델 weight, 라이선스, GPU, serving stack, 권한, 근거 추적이 한 묶음으로 계산되어야 합니다. Command A+의 가장 중요한 숫자는 218B일 수도, 25B일 수도, 2×H100일 수도 있습니다. 하지만 그 숫자들이 함께 말하는 것은 하나입니다. 에이전트 모델의 다음 경쟁은 성능표 위가 아니라 운영비 청구서와 보안 검토표 위에서 벌어집니다.