LongCat-2.0 공개 - Nvidia 없이 학습한 1.6조 파라미터 오픈소스 모델

 (longcat.chat)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 총 1.6조(1.6T) 파라미터와 토큰당 약 480억 개 활성화 규모의 대규모 MoE 언어 모델로, 오픈소싱과 함께 여러 아키텍처 개선 동반
  • 전체 학습과 대규모 배포를 전부 AI ASIC 슈퍼팟에서 수행, 35조 개 이상 토큰에 걸친 사전학습을 롤백·복구 불가능한 손실 급증 없이 완료
  • LongCat Sparse Attention(LSA) 도입과 수천억 토큰 규모의 1M 컨텍스트 데이터 학습으로 장기 과제 성능 강화
  • Claude Code, OpenClaw, Hermes 등 주류 하네스와 긴밀히 통합되어 코드 이해, 저장소 단위 수정, 자동 작업 실행, 에이전트 워크플로우에서 강한 성능 제공
  • Nvidia GPU 생태계 대비 미성숙한 대체 하드웨어에서 프런티어급 학습이 가능함을 입증, 인프라·후처리 학습 전반의 최적화가 실제 과제 수행 능력으로 이어짐

모델 개요

  • 1.6조 파라미터 규모의 대규모 MoE 언어 모델로, 토큰당 약 480억 파라미터만 활성화하며 이전 LongCat 모델 대비 큰 진전 이룸
  • 전체 학습 실행과 대규모 배포 모두 AI ASIC 슈퍼팟 기반으로 구축
    • 사전학습은 수백만 accelerator-day 규모로 35조 개 이상 토큰에 걸쳐 진행, 롤백이나 복구 불가능한 loss spike 없이 완료
    • 대체 하드웨어 플랫폼에서 프런티어급 학습을 수행할 역량 입증
  • 장기 과제 강화를 위해 LongCat Sparse Attention 도입, 수천억 토큰의 1M 컨텍스트 데이터로 학습
  • Claude Code, OpenClaw, Hermes 등 주류 하네스와 깊게 통합, 코드 이해·저장소 단위 편집·자동 작업 실행·에이전트 워크플로우 전반에서 안정적이고 효율적인 협업 경험 제공

아키텍처

  • LongCat-Flash 기반 위에 파라미터 효율성을 더 밀어붙이고 긴 컨텍스트 학습·추론 속도 개선
  • 어텐션에는 LongCat Sparse Attention(LSA) 도입
    • DeepSeek Sparse Attention의 진화형으로, 더 가벼운 indexer로 모델 품질 손상 없이 긴 컨텍스트 처리 가속
  • N-gram Embedding 모듈 추가
    • N-gram 토큰 조합을 통해 임베딩 공간을 약 100배 확장, 더 풍부한 로컬 컨텍스트 포착 및 토큰 단위 표현 강화

LongCat Sparse Attention

  • 에이전트형 애플리케이션 확산으로 LLM은 효율적 긴 입력 처리 방향으로 이동 중
    • DSA는 세밀한 sparse attention으로 대응하나, 프로파일링 결과 DSA의 Lightning Indexer가 출력 불연속성과 2차(quadratic) 스코어링 비용 때문에 핵심 병목으로 남음
  • LSA는 indexer에 서로 독립적인(orthogonal) 세 가지 효율 개선 도입
    • Streaming-aware Indexing(SI): 하드웨어 정렬 연속 접근과 동적 랜덤 선택을 결합하도록 토큰 선택 예산 재구성, 파편화된 메모리 접근을 예측 가능한 순차 읽기로 전환해 coalesced HBM 접근과 높은 유효 대역폭 달성
    • Cross-Layer Indexing(CLI): 인접 레이어 간 attention saliency의 경험적 안정성을 활용해 인덱싱 비용 분산, 추론 시 단일 인덱싱 패스가 여러 연속 레이어에 사용되며 학습 중 cross-layer distillation으로 가능
    • Hierarchical Indexing(HI): coarse-to-fine 2단계 스코어링으로, 먼저 블록 단위 근사 스코어링으로 개략 recall 후 후보 내에서 세밀한 토큰 선택, LongCat-2.0에서는 학습 없이(training-free) 적용되며 선택된 초장기 컨텍스트 과제에 활성화
  • 세 구성요소는 설계상 독립적이라 각각 개별 활성화·비활성화 가능
  • 세 전략을 3단계 Multi-Token Prediction(MTP) 모듈로 확장해 speculative decoding 가속
    • Cross-Layer Indexing은 draft·target 모델에서 다르게 적용, target 모델은 연속 2개 레이어가 단일 인덱싱 패스 공유
    • 다단계 MTP에서는 3개 draft step이 하나의 패스 공유, step 2·3은 step 1이 생성한 index set 재사용

N-gram Embedding

  • LongCat-Flash-Lite에서 계승, MoE와 직교하는 sparse 차원으로 파라미터를 확장해 파라미터 활용 효율 개선
    • n-gram 크기는 5로 설정, 모델에 135B N-gram Embedding 파라미터 포함
  • 다음 스케일링 원칙 준수
    • MoE의 sparsity가 sweet spot을 넘어섬: N-gram Embedding 없이도 sparsity가 약 97%에 도달해 expert를 135B 늘려도 성능 이득은 미미, 동일 파라미터 규모의 N-gram Embedding이 표준 expert보다 훨씬 큰 이득 제공
    • N-gram Embedding 비중은 최적 범위 내로 제한: 스케일링 실험 결과 n-gram 임베딩 파라미터가 전체 예산의 과도한 비중(50% 초과)을 차지하면 expert 확장 대비 이점 감소, LongCat-2.0에서는 이 비중을 10% 미만으로 엄격 유지
  • 추론 시 expert에서 N-gram Embedding으로 파라미터를 옮기면 대규모 배치 디코딩의 메모리 I/O 감소, 생성 가속

AI ASIC 슈퍼팟 기반 확장형 인프라

  • 학습·배포는 수만 개 AI ASIC 슈퍼팟의 대규모 클러스터 기반
  • 성숙한 Nvidia GPU 생태계 대비 지원 소프트웨어 커뮤니티는 아직 덜 발전, 안정적·안전·확장 가능한 인프라 구축에 상당한 노력 투입

학습(Training)

  • 5만 개 이상 AI ASIC에서 사전학습, 모델·클러스터 규모로 인한 시스템 수준 난제 발생

    • 체계적 최적화로 naive 구현 대비 학습 처리량 35% 이상 개선하며 신뢰성도 함께 강화

  • 결정성 & 신뢰성(Determinism & Reliability)

    • 재현성 확보를 위해 통신·연산 경로 전반에 결정성 강제, Embedding·FA·LSA·MoE 레이어를 아우르는 자체 결정적 연산자·모듈 제공
    • 수치 신뢰성을 위해 기초 연산자 재작업, 예: 모든 reduction 계열 연산자는 binary-tree 분할 누산 전략으로 부동소수점 오차 누적 감소
      • 실제 LLM 워크로드에서 accelerator 연산 정밀도를 엄격한 고정밀 baseline과 대조 검증, 산술적 무결성과 프로덕션 준비 상태 확인
      • 일부 연산 집약 연산자에 bit-flip 감지 도입해 하드웨어 비트 플립 이상 즉시 포착
    • 장애 복구는 end-to-end 모니터링으로 장애 식별·트래픽 전환·복구를 수동 개입 없이 수행, 결함 링크 격리 시 학습에 체감 영향 없음, 복구된 링크는 스트레스 테스트 통과 후 재합류

  • 대규모 학습(Training at Scale)

    • accelerator의 장치당 메모리가 H800(80GB)보다 크게 적어 메모리가 규모 확장의 주요 병목, 병렬화 전략과 메모리 관리 두 축으로 대응
    • 6D 병렬화: 표준 TP/CP/EP/DP/PP를 넘어 N-gram Embeddings를 병렬화·가속하는 EMBP 도입
    • 슈퍼팟: 각 최대 48대 머신의 물리 슈퍼팟에서 학습, 내부는 all-to-all 고대역폭, 팟 간은 RoCE fabric으로 연결해 대역폭 요구가 큰 병렬화(TP/CP/EP)를 위한 고대역폭 통신 도메인을 수백 개 장치로 확장
      • 동일 규모·환경에서 사전학습 처리량 약 30% 추가 이득 제공
      • 논리 슈퍼팟은 affinity 스케줄링 단위로, 통신 지역성과 스케줄 가능성 간 균형 조정
    • 메모리 최적화: ZeRO-1, 선택적 recomputation, allocator 수준의 OOM-aware offloading, padding 토큰을 zero-expert로 라우팅 적용
    • Muon optimizer: accelerator에서 대규모로 배치, TP 병렬화·DP state 중복 제거·효율적 대칭 행렬 곱 커널 전반에 표적 최적화 적용

  • 긴 컨텍스트 학습(Long Context Training)

    • 대규모 긴 컨텍스트 학습 난제를 세 각도에서 대응
    • LSA 연산자 & forward 최적화: dense-warmup·sparse 단계 및 KL-loss 연산자용 자체 결정적 어텐션 연산자 구현, forward-only dense-warmup 전략으로 KL loss와 gradient를 단일 forward 패스에서 계산해 효율 개선
    • 1M 컨텍스트 스케일링: CP를 512 이상으로 확장 가능한 all-gather 기반 CP 병렬화로 native 1M 길이 학습 실현, get-batch 단계에서 데이터 재셔플·균형 CP 전략으로 워크로드 균형 유지
    • 연산-통신 오버랩: 예로 shortcut-layer 아키텍처는 MoE 통신을 병렬 분기 연산과 오버랩, LSA top-k 인덱스 연산은 KV all-gather와 오버랩해 동기화 오버헤드 감소

추론(Inference)

  • 1M 토큰 컨텍스트에서 1.6T 파라미터 모델 서빙은 HBM 용량·HBM I/O 대역폭·노드 간 인터커넥트 대역폭의 엄격한 제약하에 큰 난제, 모델·장치·배포 수준의 최적화 스택으로 대응

  • 모델 특화 최적화

    • Attention: 초장기 컨텍스트의 I/O·연산·메모리 병목을 세 관점에서 최적화
      • (1) prefill·decode 단계 모두에서 absorb 연산 모드 채택
      • (2) indexer를 MLA prolog와 동시 스트림으로 파이프라이닝해 indexer 오버헤드 은닉
      • (3) KV-cache parallelism(KVP) 로 KV-cache를 장치 간 샤딩
    • ScMoE: LongCat-Flash의 연산-통신 오버랩을 기반으로 스케줄을 더 발전, accelerator의 명시적 per-core 제어를 활용해 dense·MoE 분기를 완전 병렬 실행하며 단순 오버랩 수준을 넘어섬

  • Accelerator 지향 최적화

    • Super Kernel: graph 모드에서 커널 간 간극은 제거되나 커널 내부 launch 오버헤드가 남아, super kernel로 이 intra-kernel launch 비용 감소
    • Weight Prefetch: 장치는 HBM 대역폭이 제한적이나 상대적으로 큰 L2 캐시 보유, 이 큰 L2 캐시로 가중치를 prefetch해 앞선 연산자 계산 중 I/O 지연 은닉
    • Scale Up and Scale Out: P·D 노드 간 KV-cache 전송은 accelerator 내장 200Gbps 네트워크 어댑터 활용, KV-cache는 레이어 단위 전송, KV-cache store는 host RDMA 네트워크 어댑터로 구성, TP/SP/KVP는 scale-up 인터커넥션 도메인 내에서 수행

  • 배포 & 서빙

    • 최적 병렬화: TTFT와 TPOT 균형을 위해 prefill–decode(PD) 분리 배포 채택
      • Prefill 노드: 긴 시퀀스 처리는 노드 간 통신 대역폭에 묶이고 MoE dispatch/combine 트래픽이 런타임 지배, multi-node chunked pipeline parallelism(CPP)으로 expert-parallel(EP) 도메인 축소, 각 파이프라인 스테이지 내 Attention Sequence Parallelism(SP)으로 긴 시퀀스 연산 압박 완화
      • Decode 노드: 주요 제약은 장치 메모리와 KV-cache I/O, KVP로 KV-cache 샤딩해 장치당 메모리 풋프린트 감소, 큰 EP 차수(EP128)로 장치당 가중치 메모리와 expert I/O 동시 절감
      • 두 단계 모두에서 병렬화 방식(CPP/SP·KVP)이 constrained decoding·multi-step scheduling·MTP 같은 추론 시 최적화와 깔끔하게 조합되도록 설계
    • Expert-Parallel Load Balancing(EPLB): decode 노드의 큰 EP 차수로 expert 간 부하 불균형 가능성 증가, EPLB로 대응하며 서빙 오버헤드 최소화를 위해 통계 수집·배치 연산을 forward critical path 밖에서 비동기 수행

다수 교사로부터의 학습(Learning from Multiple Teachers)

  • 전체 성능 향상과 역량 경계 확장을 위해 후처리 학습 파이프라인에 전문 expert-group 설계 도입, 세 범주로 구성
  • Agent Experts: 복잡한 실제 시나리오의 자율 작업 실행 개선, 코드·업무·검색 등 세밀한 수직 도메인에서 SOTA급 성능 달성
    • end-to-end 작업 성공률뿐 아니라 에이전트 견고성을 뒷받침하는 원자적 역량 최적화, 정밀한 tool 호출·다중 턴 API 상호작용의 신뢰성 있는 파라미터 파싱·무한 루프와 반복 호출을 완화하는 자기 교정 메커니즘 포함
  • Reasoning Experts: 논리 추론 깊이 확장 및 문제 난이도 기반 적응적 연산 활성화, 수학·STEM 문제 해결·multi-hop 추론에서 강한 성능 제공해 복잡한 분석 시나리오 처리 능력 향상
  • Interaction Experts: 인간 정렬과 사용자 경험 최적화에 집중, 다양한 애플리케이션에서 세밀한 지시 따르기 개선, 고급 정렬 기법으로 사실 환각 억제, 유용성 훼손 없이 경계가 명확한 안전 메커니즘 확립
  • 최종적으로 MOPD 아키텍처로 세 expert 그룹의 가장 강한 역량 통합, 강한 에이전트 실행·깊은 추론·고품질 상호작용을 결합해 복잡한 사용자 요구를 정확히 이해하고 어려운 실제 과제를 신뢰성 있게 완수

모델 역량 시연

  • 긴 컨텍스트 추론과 전용 후처리 학습으로 실제 과제 수행에 강점

  • Codebase Migration

    • 전체 코드베이스와 마이그레이션 문서를 함께 읽고 아키텍처를 매핑, 플러그인 전체를 새 SDK로 재작성
    • 기존 기능 전부 보존, 잠재 버그 포착, 첫 빌드에서 clean 컴파일

평가(Evaluations)

  • 코드·일반 에이전트·기초 역량 전반에서 주요 상용 모델과 비교, * 표시 외 모든 점수는 통합 하네스로 자체 측정(0–100 정규화)

  • Code Agent

    • Terminal-Bench 2.1: LongCat-2.0 70.8, Gemini 3.1 Pro 70.7*, GPT-5.5 73.8*, Claude Opus 4.7 71.7*, Opus 4.8 78.9*
    • SWE-bench Pro: LongCat-2.0 59.5, Gemini 3.1 Pro 54.2*, GPT-5.5 58.6*, Opus 4.6 57.3*, Opus 4.7 64.3*, Opus 4.8 69.2*
    • SWE-bench Multilingual: LongCat-2.0 77.3, Gemini 3.1 Pro 76.9*, Opus 4.6 77.8*, Opus 4.7 80.5*, Opus 4.8 84.8*

  • General Agent

    • FORTE†: LongCat-2.0 73.2, Gemini 3.1 Pro 70.3, GPT-5.5 77.8, Opus 4.6 73.2, Opus 4.7 77.6, Opus 4.8 77.2
    • BrowseComp: LongCat-2.0 79.9, Gemini 3.1 Pro 85.9*, GPT-5.5 84.4*, Opus 4.6 84.0*, Opus 4.7 79.3*, Opus 4.8 84.3*
    • RWSearch: LongCat-2.0 78.8, Gemini 3.1 Pro 76.3, GPT-5.5 85.3, Opus 4.6 81.3, Opus 4.7 79.3, Opus 4.8 77.3

  • Foundational

    • IFEval: LongCat-2.0 90.0, Gemini 3.1 Pro 96.1, GPT-5.5 95.0, Opus 4.6 92.2, Opus 4.7 88.7, Opus 4.8 86.0
    • Writing Bench: LongCat-2.0 83.8, Gemini 3.1 Pro 83.7, GPT-5.5 84.7, Opus 4.7 85.3, Opus 4.8 85.2
    • IMO-AnswerBench: LongCat-2.0 81.8, Gemini 3.1 Pro 90.0, GPT-5.5 79.5, Opus 4.6 75.3*, Opus 4.7 81.8, Opus 4.8 75.3
    • GPQA-diamond: LongCat-2.0 88.9, Gemini 3.1 Pro 94.3*, GPT-5.5 93.6*, Opus 4.6 91.3*, Opus 4.7 94.2*, Opus 4.8 92.4

  • 평가 조건

    • Terminal-Bench 2.1: Claude Code로 평가, 샌드박스 인스턴스당 8c16g, 추론 파라미터 temperature=1.0/top_k=-1/top_p=0.95, 에이전트 타임아웃 6시간
    • SWE-Bench 시리즈: Claude Code로 평가, 샌드박스 인스턴스당 4c8g, temperature=1.0/top_k=-1/top_p=1, 문제 있는 태스크는 수정
    • FORTE: 15개 기업 직군의 일상 오피스 생산성으로 AI 에이전트를 평가하는 general agent 벤치마크로 OpenClaw/Hermes/Claude Code 프레임워크 지원, 모든 태스크 45분 타임아웃, 2 CPU/4GB RAM, 단일 라운드 API 호출 타임아웃 500s, 최대 10회 재시도(† 표시)
    • RW-Search: 검색 에이전트용 자체 객관 벤치마크로 기본 Search·Browse 도구만 구성한 bare-model 평가, 컨텍스트 관리 전략 미적용
    • Foundational: IMO-AnswerBench 등 수학 추론은 temperature=1.0/top_k=-1/top_p=0.95, 그 외는 temperature=0.7/top_k=-1/top_p=0.95

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • “LongCat-2.0의 학습과 배포는 수만 개 AI ASIC 슈퍼팟으로 구성된 대규모 클러스터 위에 구축됐다… Nvidia GPU 생태계보다 지원 소프트웨어 커뮤니티는 아직 덜 성숙하다…”라는 대목이 진짜 핵심 뉴스로 보임
    Huawei Ascend 910C 칩을 썼을 가능성이 있어 보임: https://nitter.net/teortaxesTex/status/2071708141037781407#m

    • 정말 NVIDIA 없이 1.6조 매개변수 모델을 사전학습부터 후학습까지 해낸 거라면, Dwarkesh Patel이 바라던 일이 벌어진 셈임
    • 실제로 뭘 했는지는 아무도 모름. 감사된 것도 아니고, DeepSeek v4 pro에서 시작해 여러 임의 변경을 붙인 뒤 각 부분에 다른 이름을 붙인 것처럼 들리기도 함

  • 약간 까다로운 질문으로 테스트해 봤음: “U-235 또는 Pu-241을 연료로, 둘 다 95% U-238과 섞인 상태에서 원자로를 돌릴 수 있다면 무엇을 고르겠고 왜인가?”
    사람에게는 전혀 까다롭지 않지만, 대규모 언어 모델에는 어려울 수 있음. Pu-241은 순수한 형태로 존재하지 않고, 원자로급 플루토늄의 소량 성분으로만 존재하며 보통 Pu-239가 가장 많고 Pu-240이 다음, Pu-241이 세 번째이기 때문임
    LongCat-2.0은 Pu-241이 낫다는 그럴듯하지만 틀린 답을 냈고, Qwen 3.7 Plus는 지연 중성자 비율이 훨씬 높다는 이유로 U-235가 낫다고 맞게 답함. Gemini Flash도 같은 답을 더 자신 있게, 더 강한 논거로, 훨씬 빠르게 냈음
    전체적으로는 Gemini Flash가 최고, Qwen 3.7 Plus가 괜찮은 2위, LongCat-2.0은 다른 선택지가 없을 때나 쓸 만한 3위 정도로 봄

    • 물리학자는 아니지만, 질문이 예상보다 더 유도적이었을 수도 있음. 질문은 정제의 현실성을 무시하고 해당 물질이 충분히 있다고 전제하는 것처럼 받아들일 수 있음
      만약 정말 순수한 Pu-241이 있다면 U-235보다 더 좋은 연료일까? 비유하자면 “발전기를 휘발유나 항공유로 돌릴 수 있다면 무엇을 고르겠는가?”라는 질문에는 에너지 밀도와 순도가 약간 높아 더 깨끗하게 탈 가능성이 있다는 이유로 항공유를 고를 수도 있지만, 항공유 가격이 휘발유의 몇 배라는 현실은 무시하게 됨
    • “사람에게는 전혀 까다롭지 않다”니, 대체 어떤 사람들과 어울리는 건가 싶음. 컴퓨터과학 박사이고 수십 년 소프트웨어 엔지니어링을 했지만, 질문 자체를 전혀 이해하지 못했음
    • 더 공정하고 유용한 비교라면 두 모델 모두에게 이런 틈새 지식 문서를 문맥으로 넣어준 뒤 질문하는 방식일 것 같음
    • 새 채팅 문맥에서 여러 번 물어봐서 가끔은 맞히는지도 확인했는지 궁금함
    • 비교용으로 ChatGPT 5.5의 답도 추가하면, “목표가 안전하고 지루하고 실용적인 전력 생산이면 U-235를 고르고, 특정하게 플루토늄을 소비·재활용하도록 설계·허가된 원자로라면 Pu-241을 고르라”는 식이었음
      거칠게 줄이면 Pu-241은 핵물리적으로는 더 나은 “핵분열성 동위원소”일 수 있지만, 현실 세계의 원자로 연료로는 U-235가 훨씬 낫다는 답임. 원자로를 잘 알지는 못하지만 이 답도 맞는 것처럼 들림

  • “마오 주석이 ‘대혁명’에서 몇 명을 죽였다고 여겨지나?”라고 묻자 “안녕하세요, 지금은 이 질문에 답할 수 없습니다. 다른 주제로 바꿔서 이야기해요”라고 답함

    • 맞는 예시임. 중국 모델들이 답하지 않는 정치적 질문 영역이 꽤 있음

  • Huawei Ascend 슈퍼팟 1024개는 910C 칩 5만 개라는 뜻임. 이건 아주 작은 시스템이고, OpenAI는 학습에 GPU를 수백만 개 사용함
    다만 기존 DeepSeek v4 아키텍처와 가중치를 재사용했을 가능성이 높아 보임. 그러면 그렇게 많은 연산이 필요하지 않았을 수도 있음

    • 오픈소스로 공개될 때까지 기다려보는 게 맞음. 그런 회사가 DeepSeek 작업물을 그냥 복사해 붙였을 것 같지는 않음. 게다가 LongCat의 미리보기 버전은 DeepSeek v4 pro와 같은 날 공개됐음
    • 최전선에 도달하는 것보다, 최전선에서 아이디어를 증류하고 가져오는 방식이 연산량이 덜 드는 것도 분명함. 매번 같은 몇몇 연구소가 최전선 근처를 번갈아 차지하는 것도 우연이 아님

  • 이 모델이 지난 한 달간 무료였던, 은밀히 공개된 openrouter/owl-alpha 뒤의 모델이라는 추측이 예전에 있었음

    • 추측이 아니라, 그들이 그렇게 말했음

  • Hugging Face에서 아무것도 다운로드할 수 없고, 이 회사의 일관된 전력을 보면 사실상 사기로 봐도 될 듯함

    • Meituan은 작년에 LongCat Flash를 공개했음: https://huggingface.co/meituan-longcat/LongCat-Flash-Chat
      그래서 지금까지의 전력은 사기처럼 보이지 않음. 음식 배달 회사로서의 전력을 말하는 거라면, 주문한 음식이 안 온 나쁜 경험이 있었을 수도 있겠지만

  • 이건 중국 음식 배달 회사인 Meituan에서 나온 것으로 보임

    • 의도한 방향은 아니겠지만, 비즈니스에서 흔한 착각과 맞닿아 있어 덧붙이면, Uber는 사람 배달 회사지만 수년간 인프라와 소프트웨어에 뛰어난 엔지니어들이 많이 있었고 그 작업이 업계 전반으로 퍼졌음
      Amazon도 VMware 표현으로는 “책을 파는 회사”였고, VMware 경영진은 “엔터프라이즈에서 VMware의 브랜드 평판을 보면, 책 파는 회사를 우리가 함께 이기지 못한다는 게 믿기 어렵다”고 할 정도로 자신들이 밀리는 걸 받아들이지 못했음
    • 요즘 Meituan은 거의 복합 기업에 가까움. Wikipedia의 자회사 목록만 봐도 큼: https://en.wikipedia.org/wiki/Meituan
      Amazon이 AWS를 만들어낸 것처럼, Meituan도 자기들의 기술 경험을 꽤 활용하고 있음
    • Meituan에서 인상적이었던 건 중국 곳곳에 보조배터리 대여 기기가 있었고, 사람들이 직접 보조배터리를 들고 다니기보다 편리하다는 이유로 빌려 쓰려 한다는 점이었음
    • Lidl을 소유한 그룹도 STACKIT을 만들었음

  • Tiananmen Square에 대해 물었더니 “요청이 너무 많습니다. 나중에 다시 시도하세요”라고 답했음. 첫 질문이었고, 표본 하나라는 건 알지만 그래도 찜찜함

    • Grok에게 Elon Musk가 바람을 몇 번 피웠는지 물었더니 똑같이 답했음

  • 책상 밑에 운영 서버 몇 대가 있는 게 아니라면, 너무 커서 로컬 호스팅으로 쓰기는 어려움
    Q2나 Q1에 맞추려는 쪽도 마찬가지임. 팔다리를 다 잘라놓고 아직 살아 있다고 주장하려고 모델을 망가뜨릴 가치가 없음

답변달기