13. DeepSeek·Kimi 공개 배포 사례 읽기 — explicit·inferred·unknown 분리

이 장의 핵심 질문

• 공개 배포 보고서를 읽을 때, 밝혀진 것(explicit) 과 추론한 것(inferred) 과 불명(unknown) 을 어떻게 갈라내는가?
• owner-reported(사업자 자기 보고) 경계를 보존한다는 것은 무슨 뜻인가?
• 자료가 풍부한 사례(DeepSeek)와 빈약한 사례(Kimi 서빙 인프라)를 같은 규율로 읽으면 무엇이 보이는가?

앞 장과의 연결 — 앞 장들(01–12)에서 배운 개념 어휘(PD 분리·EP·all-to-all·DP·TP·인터커넥트·오버랩)가 이제 실제 보고서를 해부하는 도구가 된다. 이 장은 그 어휘로 공개 사례를 읽되, 자료가 말한 것만 옮기고 나머지는 unknown으로 남기는 규율(원칙 6)을 훈련한다.

먼저: 왜 "배포 사례 읽기"가 별도의 기술인가

논문·블로그·기술 보고서는 배포의 일부만 공개한다. 흔한 실수는 공개된 조각을 보고 빈칸을 상상으로 메우는 것이다("이렇게 했으니 저것도 이랬겠지"). 이것이 잘못된 기술 브리프의 최대 원천이다.

증거 읽기의 규율은 세 상태로 나누는 것이다.

• explicit(명시) — 자료가 직접 말한 것. 예: "16-way PP, 64-way EP를 썼다."
• inferred(추론) — 자료가 말하지 않았지만 명시된 것에서 제한적으로 유도한 것. 반드시 "추론"이라 표시하고 근거를 남긴다. 예: "EP32라 했으니 all-to-all이 노드를 넘나들 것이다(추론)."
• unknown(불명) — 자료가 말하지 않았고 유도도 불가능한 것. 지어내지 않고 unknown으로 남긴다. 예: 정확한 실패 복구 절차, 실시간 라우팅 임계값.

여기에 하나 더: owner-reported 경계. 사업자 스스로 보고한 수치·구성은 owner-reported이지 독립 재현이 아니다(출처 등급의 PRIMARY지만 REPRODUCTION은 아님). 자기 보고를 검증된 사실처럼 옮기면 안 된다.

📌 핵심 — 배포 사례 읽기는 "무엇을 알게 됐나"만큼 "무엇을 여전히 모르나"를 명시하는 기술이다. explicit·inferred·unknown·owner-reported 네 라벨을 각 진술에 붙이는 습관이 핵심이다.

사례 A — DeepSeek-V3/R1: 자료가 풍부한 배포

DeepSeek은 모델뿐 아니라 추론 배포 전략을 비교적 상세히 공개한 드문 사례다. 앞 장들의 어휘로 그 공개 내용을 해부하되, 각 진술에 라벨을 붙인다.

explicit — 자료가 직접 말한 것 (확인일 2026-07-20)

• PD 분리 채택 — prefill과 decode를 분리하고, 두 phase에 서로 다른 병렬화 도를 적용한다고 명시. [explicit]
• 대규모 cross-node EP — MoE의 높은 희소성(예: 레이어당 다수 전문가 중 소수만 활성) 때문에, 전문가당 충분한 배치를 확보하려 매우 큰 전체 배치 + 대규모 EP가 필요하다고 명시. [explicit]
• prefill·decode의 병렬화 구성 — 한 학술·공식 자료 계열은 prefill 단계와 decode 단계에서 서로 다른 EP/DP 그룹 크기(배포 단위의 노드 수·GPU 수 포함)를 제시. 구체 숫자는 자료·버전마다 다르게 인용되므로 아래 근거표에서 출처를 붙여 다룬다. [explicit, 단 자료별 차이 있음]
• 인터커넥트 — 노드 안 NVLink·NVSwitch, 노드 간 InfiniBand. [explicit] (02장 개념과 일치)
• 통신-연산 오버랩 — cross-node EP의 무거운 all-to-all을 완화하려 계산과 통신을 겹치는 파이프라인식 접근을 썼다고 명시. [explicit] (06장 개념과 일치)

🔬 증거 읽기 — DeepSeek 배포 근거표 (확인일 2026-07-20)

conditions — per-node 처리량 수치는 특정 입력 길이·하드웨어·구현의 산물이다. 예를 들어 한 독립 재현(SGLang 팀)은 특정 노드 구성·2000-토큰 입력에서 per-node 입력/출력 토큰/초를 보고했는데, 이는 그 재현의 조건이지 DeepSeek 프로덕션 자체가 아니다. does-not-support — 이 표의 어떤 수치도 "다른 모델·하드웨어·워크로드에서도 같은 처리량이 난다"를 지지하지 않는다. 숫자를 옮길 때는 반드시 원 조건을 함께 옮긴다.

🔬 증거 읽기 — 독립 재현의 가치와 한계 — DeepSeek 사례에는 드물게 독립 재현(REPRODUCTION) 이 존재한다: 제3자(SGLang 팀)가 유사 구성을 공개 구현해 처리량을 보고했다. 이는 owner-reported 단독보다 강한 증거다(원칙 4의 REPRODUCTION 등급). 하지만 재현조차 원 조건과 완전히 일치하지 않을 수 있고(자료 스스로 "실시간 서빙 통계가 없어 입출력 분포로 대체" 같은 단서를 단다), 특정 하드웨어·입력 길이의 산물이다. 재현이 있어도 "그 조건에서"를 떼면 안 된다.

inferred — 명시에서 제한적으로 유도한 것

• 대규모 cross-node EP를 쓴다면, all-to-all이 노드 경계를 넘나들어 인터커넥트 topology와 강하게 얽혔을 것이다(05장). [inferred — 자료가 all-to-all 오버랩을 언급한 것과 02·05장 원리로부터]
• prefill/decode에 다른 병렬화 도를 준 것은 07장의 독립 스케일링 동기와 일치한다. [inferred — 개념적 정합성]

이 inferred 진술들은 "자료가 직접 말한 것이 아님" 을 반드시 표시한다.

unknown — 자료가 말하지 않은 것 (지어내지 않음)

• 정확한 실시간 라우팅·로드밸런싱 임계값과 EPLB(전문가 로드밸런서)의 운영 세부 파라미터. [unknown]
• 실패/복구 경로·보안 경계의 구체적 절차. [unknown]
• 단가·전력·총소유비용(TCO) 의 구체 수치. [unknown]
• 공개 문서 시점 이후의 현재 프로덕션 구성(구성은 시간이 지나며 바뀐다). [unknown]

⚠️ 경계 혼동 주의 — "공개했다"의 범위 — DeepSeek이 배포 전략을 공개했다고 해서 모든 것을 공개한 것은 아니다. 아키텍처·병렬화 구성은 explicit이지만, 운영 파라미터·실패 경로·단가·현재 상태는 대부분 unknown이다. "상세히 공개한 사례"조차 unknown이 많다는 것이 이 절의 교훈이다.

사례 B — Kimi(Moonshot): 모델은 공개, 자체 서빙 인프라는 대부분 unknown

Kimi K2 계열은 대조적 사례다. 모델 아키텍처·가중치는 오픈 웨이트로 공개되고 배포 방법(권장 엔진 등)은 안내되지만, Moonshot 자체 프로덕션 서빙 인프라의 세부는 대부분 공개되지 않는다.

explicit — 자료가 직접 말한 것 (확인일 2026-07-20)

• MoE 아키텍처 — 대형 total 파라미터에 토큰당 소수 전문가 활성(sparse MoE, 다수 전문가 중 소수 라우팅 + 공유 전문가)이라는 모델 구조. [explicit — 모델 카드]
• 권장 추론 엔진 — 자체 배포 시 vLLM·SGLang 등으로 돌리도록 안내(오픈 웨이트 배포 가이드). [explicit]
• 오픈 웨이트·라이선스·API 제공 — 가중치 공개, OpenAI/Anthropic 호환 API 제공. [explicit]

unknown — 자료가 말하지 않은 것

• Moonshot 자체 프로덕션의 병렬화 구성(PD 분리 여부·EP/DP/TP 도·노드 구성). [unknown]
• 자체 라우팅·오토스케일링·KV 계층 정책. [unknown]
• 자체 인프라의 처리량·SLO·단가·전력. [unknown]
• 제3자(예: 특정 기업)가 Kimi를 프로덕션에 쓴다는 언급이 있어도, 그들의 구체 서빙 구성은 대부분 unknown. [unknown]

📌 핵심 — 오픈 웨이트 ≠ 오픈 인프라 — "모델을 공개했다"와 "서빙 인프라를 공개했다"는 완전히 다르다. Kimi는 전자는 풍부하지만 후자는 대부분 unknown이다. 모델 스펙(전문가 수·컨텍스트 길이 등)을 안다고 해서 사업자가 어떻게 서빙하는지를 아는 것이 아니다. 이 둘을 섞으면 없는 정보를 있다고 착각한다.

⚠️ 경계 혼동 주의 — 2차 자료의 "권장 하드웨어" — "K2를 돌리려면 8×H100/H200가 필요하다" 같은 2차 자료 진술은 자가 호스팅 가이드/커뮤니티 추정이지, Moonshot 프로덕션 구성이 아니다. "돌리는 데 필요한 최소 하드웨어"(추정)와 "사업자가 실제로 서빙하는 구성"(unknown)은 다른 것이다. 전자를 후자로 읽으면 오해한다.

두 사례를 나란히 — 같은 규율, 다른 결과

flowchart TB
    subgraph DS["DeepSeek — 인프라 자료 풍부"]
        DE["explicit: PD 분리, 대규모 EP,<br/>prefill/decode 병렬화 도, 인터커넥트, 오버랩"]
        DI["inferred: all-to-all의 topology 의존 등"]
        DU["unknown: 운영 임계값, 실패/보안 경로,<br/>단가·전력, 현재 구성"]
        DR["REPRODUCTION 존재: 제3자 재현(조건 한정)"]
    end
    subgraph KM["Kimi — 모델 공개, 인프라 unknown"]
        KE["explicit: MoE 구조, 권장 엔진,<br/>오픈 웨이트·API"]
        KU["unknown: 자체 프로덕션 병렬화·라우팅·<br/>KV 정책·처리량·SLO·단가"]
    end

    classDef exp fill:#d1f0d1,stroke:#16a34a,color:#000
    classDef inf fill:#fff3c4,stroke:#d4a017,color:#000
    classDef unk fill:#ffd6d6,stroke:#dc2626,color:#000
    classDef rep fill:#c4f1f4,stroke:#0891b2,color:#000
    class DE,KE exp
    class DI inf
    class DU,KU unk
    class DR rep

두 사례를 같은 네 라벨(explicit·inferred·unknown·owner-reported)로 읽으면:

• DeepSeek은 explicit이 풍부하고 드물게 REPRODUCTION까지 있지만, 여전히 운영·비용·현재 상태는 unknown.
• Kimi는 모델은 explicit이나 자체 서빙 인프라는 대부분 unknown.
• 공통 교훈: 어느 사례든 unknown이 상당하며, 그 unknown을 상상으로 메우지 않는 것이 규율이다.

⚖️ 절충 — 자료가 풍부할수록 방심하기 쉽다 — 역설적으로, DeepSeek처럼 자료가 많은 사례일수록 "다 안다"고 착각해 unknown을 빈칸 메우듯 상상하기 쉽다. 자료가 많다는 것은 explicit이 많다는 뜻이지 unknown이 없다는 뜻이 아니다. 오히려 풍부한 explicit 사이의 unknown을 명시적으로 표시하는 규율이 더 중요해진다.

배포 사례를 기술 브리프로 (17장 예고)

이 장의 네 라벨은 17장 기술 브리프의 뼈대가 된다. 하나의 배포 주장(예: "PD 분리 + 대규모 EP로 높은 처리량")을 브리프로 쓸 때:

• 근거표 — 각 진술에 explicit/inferred/unknown·출처 등급·주장 유형·canonical URL·확인일.
• 조건표 — 처리량 수치의 입력 길이·하드웨어·구현.
• 적용 경계 — "이 구성은 이런 모델·워크로드에서, 이런 조건일 때"에 한정.
• 추가 검증 — unknown으로 남은 것 중 브리프 목적에 필요한 항목.

16장에서 이 사례들의 구성도를 재구성(data/control path·explicit/inferred/unknown 색 구분)하고, 17장에서 브리프로 종합한다.

이 장에서 배운 것

• 배포 사례는 explicit(명시)·inferred(추론)·unknown(불명) 세 상태와 owner-reported 경계로 읽는다. 각 진술에 라벨을 붙인다.
• DeepSeek은 PD 분리·대규모 EP·병렬화 도·인터커넥트·오버랩을 explicit으로 공개했고 드물게 독립 재현(REPRODUCTION) 까지 있으나, 운영 파라미터·실패/보안 경로·단가·현재 구성은 unknown이다.
• Kimi는 모델 아키텍처·권장 엔진·오픈 웨이트는 explicit이나, 자체 프로덕션 서빙 인프라는 대부분 unknown이다. 오픈 웨이트 ≠ 오픈 인프라.
• owner-reported 수치는 자기 보고이지 독립 재현이 아니다. 재현이 있어도 원 조건(입력 길이·하드웨어·구현)을 떼면 안 된다.
• 어느 사례든 unknown이 상당하며, 그것을 상상으로 메우지 않는 것이 규율이다. 자료가 풍부할수록 오히려 방심하기 쉽다.

🔎 이 장의 '지지하지 않는 결론' + 'unknown으로 남겨야 할 것'

• 지지하지 않는 결론 — "DeepSeek이 배포를 공개했으니 우리도 같은 처리량을 낼 수 있다"거나 "Kimi 모델 스펙을 아니 서빙 구성도 안다"는 지지되지 않는다. 처리량은 조건 의존이고, 모델 공개와 인프라 공개는 다르다.
• unknown으로 남길 것 — 두 사례 모두 운영 임계값·실패/보안 경로·단가·전력·현재 프로덕션 구성은 unknown. Kimi는 자체 서빙 인프라 전반이 unknown. 이들을 브리프에 옮길 때 반드시 unknown으로 표기한다.

✍️ 확인 문제

1. "DeepSeek은 16-way PP, 64-way EP를 썼고, 따라서 실패 시 자동 복구가 잘 되도록 설계됐을 것이다"라는 문장에서 explicit인 부분과 상상으로 메운 부분을 갈라라. 후자는 어떤 라벨로 표시해야 하는가?

1. (owner-reported 유형) 어떤 사업자가 "우리 시스템은 노드당 초당 N 토큰을 처리한다"고 자기 블로그에 밝혔다. 이 수치의 출처 등급과 주장 유형은 무엇인가? 이것을 "검증된 사실"로 브리프에 옮기면 무엇이 틀리는가? 독립 재현이 있다면 무엇이 달라지고 무엇은 여전히 조심해야 하는가?

1. (경계 혼동 유형) 동료가 "Kimi는 전문가 수·컨텍스트 길이가 공개돼 있으니, Moonshot이 어떻게 서빙하는지도 대충 안다"고 한다. '오픈 웨이트 ≠ 오픈 인프라'로 이 오해를 바로잡고, 실제로 unknown인 항목을 셋 이상 들어라.

다음 장에서는 이 사례들이 올라탄 하드웨어를 다룬다. 장치 이름(H100·특정 NPU 등)이 아니라 memory·kernel·software·topology·power라는 안정 축으로 비교하는 법이 초점이다.
다음 → 14. GPU·NPU·추론 하드웨어 비교 — 장치 이름이 아니라 안정 축으로