Moonshot, 2.8T MoE Kimi K3 오픈웨이트 공개

헤드라인: Moonshot, 2.8T MoE Kimi K3 오픈웨이트 공개

참고 링크: 544 Twitters, AINews’ website, AINews is now a section of Latent Space, opt in/out

Moonshot의 Kimi K3 공개가 이번 호의 중심 뉴스다. 2.8T 파라미터 MoE, 104B 활성 파라미터, 1M 토큰 컨텍스트, 네이티브 시각 이해를 갖춘 오픈웨이트 모델일 뿐 아니라, 대규모 에이전트 후훈련(post-training)과 서빙을 위한 커널, MoE 통신, 에이전트 환경 인프라까지 함께 공개됐다. 동시에 라이선스는 permissive OSS가 아니라 상업적 제한이 있는 open weights에 가깝다는 점이 논쟁의 핵심이 됐다.

AI Twitter Recap

Moonshot의 Kimi K3 오픈웨이트 공개와 새로운 3T급 오픈 프런티어

Kimi K3가 이날의 지배적 릴리스: Moonshot은 Kimi K3 가중치, 리포트, 지원 인프라를 오픈웨이트 패키지로 공개했다. 사양은 2.8T 파라미터 MoE, 104B 활성 파라미터, 896 experts / 토큰당 16 active, 1M 토큰 컨텍스트, 네이티브 시각 이해라고 @Kimi_Moonshot이 밝혔다. 동반 게시물에서는 FlashKDA(Kimi Delta Attention 커널), MoonEP(MoE 통신 라이브러리), AgentENV(분산 에이전트 환경 인프라)도 FlashKDA, MoonEP, AgentENV를 통해 오픈소스로 공개했다. 이는 단순한 모델 공개를 넘어, 대규모 에이전트형 후훈련과 서빙을 위한 꽤 완전한 레시피에 가깝다.
기술 리포트도 모델만큼 중요해 보임: 여러 실무자들은 K3가 K2 대비 약 2.5배 scaling-efficiency 개선을 보고했고, 아키텍처와 학습 선택이 극한 규모에서의 수치 안정성에 집중됐다고 짚었다. 반응은 @eliebakouch, @suchenzang, @teortaxesTex에서 나왔다. 코멘터리에서 언급된 구체적 내용에는 MXFP4 weights / MXFP8 activations @teortaxesTex, 안정성을 위한 vision encoder의 처음부터 공동 학습 @iScienceLuvr, MoE 라우팅과 신호 전파 문제에 대한 큰 주의가 포함된다. 리포트는 총 학습 토큰 수를 생략한 것으로 보이며, 여러 독자가 이를 의미 있는 누락이라고 지적했다 @teortaxesTex.
라이선스는 “open weights”이지 permissive OSS가 아님: 모델은 널리 사용할 수 있지만 MIT/Apache 스타일 오픈소스는 아니다. 여러 게시물은 상업적 사용 제한을 언급했다. 연 $20M 이상 대형 호스팅 제공자는 별도 계약이 필요하고, 100M MAU 또는 월 $20M 매출을 넘는 제품은 UI에 “Kimi K3”를 표시해야 한다고 @natolambert, @petergostev, @ArtificialAnlys가 전했다. 이는 프런티어 “open”이 OSI식 라이선스보다는 비즈니스 예외 조항이 있는 source-available / open-weight 쪽으로 자리 잡고 있음을 보여주는 신호다.
배포는 즉시 광범위하게 이뤄짐: K3는 day 0부터 vLLM @vllm_project, Baseten @baseten, Modal @modal, Fireworks @Kimi_Moonshot, Nebius @Kimi_Moonshot, Together @Kimi_Moonshot, DigitalOcean @Kimi_Moonshot, Cursor @cursor_ai, Cognition/Devin @cognition, Ollama Cloud @ollama, Dell Enterprise Hub @jeffboudier에서 사용할 수 있었다. 이 폭넓은 배포는 오픈웨이트 프런티어 출시가 이제 연구 발표만이 아니라 공급망 이벤트임을 보여준다.

오픈 AI 보안, 오픈웨이트 정치, Anthropic의 입장

NVIDIA가 Open Secure AI Alliance를 공식 출범: Jensen Huang은 핵심 논지를 강하게 제시했다. 공격자는 이미 강력한 AI를 갖고 있으므로 방어자는 open and closed frontier models를 모두 포괄하는 생태계와 공유 도구, 연구가 필요하다는 것이다. 대표 발언은 @JensenHuang에서 나왔고, NVIDIA의 공식 발표는 @nvidia에 올라왔다. 메시지에서 가장 기술적으로 흥미로운 부분은 OpenAI/Hugging Face incident 중 frontier open-weight model이 침입 대응에 도움을 줬고, closed model은 필수 포렌식을 막았다는 주장이다. 이는 @AndrewYNg, @ZixuanLi_도 되풀이했다.
동맹은 빠르게 신뢰할 만한 인프라·도구 멤버를 확보: 공개적으로 참여를 확인한 곳은 Hugging Face @huggingface, LangChain @LangChain, Nous Research @NousResearch였고, @UnslothAI, @Yuchenj_UW 같은 오픈 생태계 인물들도 지지했다. 주장은 “open이 자동으로 더 안전하다”가 아니라, 방어 역량과 감사 가능성에는 모델, harness, trace에 대한 open access가 필요하다는 쪽이다.
Anthropic이 마침내 오픈웨이트 입장을 명확히 함: NVIDIA의 오픈웨이트 서한에 서명하지 않았다는 비판이 이어진 뒤, Anthropic은 자신들이 **“open-weights models 금지를 주장한 적이 없다”**고 밝혔다. 대신 중국 대상 chip controls, 반 industrial-scale distillation 조치, open/closed 여부와 무관하게 충분히 강력한 모델에 대한 의무 안전성 테스트를 지지한다고 @AnthropicAI가 전했다. 반응은 “합리적 해명” @signulll, “좋지만 여전히 프런티어 확산을 늦추려 한다” @jachiam0, 그리고 @Teknium 같은 오픈웨이트 지지자의 더 적대적인 해석으로 갈렸다.
출시 전 검토를 둘러싼 정책 압박이 강화됨: 별도 보도에 따르면 미국 정부는 NSA, CAISI 같은 기관 평가를 위해 프런티어 시스템에 대해 최대 30일의 출시 전 접근권을 요구할 수 있으며, open-vs-closed 처리는 아직 해결되지 않았다고 @kimmonismus, @leomschwartz가 전했다. Anthropic의 성명과 OpenAI의 워싱턴 브리핑까지 함께 보면 방향은 분명하다. 프런티어 모델 출시는 이제 단순한 제품 출시가 아니라 거버넌스 인터페이스가 되고 있다.

벤치마크, 평가, 에이전트 신뢰성

K3의 초기 평가가 특히 에이전트·코딩에서 강함: Agent Arena에서 Kimi K3 Max는 +9.75% net improvement로 오픈웨이트 모델 중 1위를 기록했고, confirmed success와 steerability를 포함한 여러 신호에서 앞섰다고 @arena가 전했다. 이후 게시물에서는 전체 모델 중 Frontend Code Arena 종합 1위도 차지했다 @arena. Cognition은 K3가 FrontierCode 1.1에서 “frontier-level performance에 접근하는” 첫 오픈소스 모델이며, 58.2% 점수와 63.6% pass rate를 냈다고 밝혔다 @cognition.
Claude Opus 5도 강한 리더보드 수치를 냈지만 실무자 반응은 엇갈림: Arena는 Opus 5 Max가 factuality on 조건의 Frontend Code Arena와 Text Arena에서 1위라고 보고했다 @arena. @htihle의 WeirdML 수치에서는 Opus 5 high/max가 **91.6% / 91.8%**로 Fable 5 max와 거의 동률이었다. 하지만 @abacaj, @davis7, @Teknium, @theo는 과도한 복잡화, 파손, 좋지 않은 stopping behavior 등 답답한 실제 사용 경험을 보고했다. 늘 그렇듯 공개 평가 상승과 harness별 프로덕션 효용은 갈라지고 있다.
새 평가 작업은 순차적 성능 저하와 숨은 회귀에 집중: @_philschmid는 지속 컨테이너 안에서 26 tasks / 227 sequential rounds를 수행하는 평가인 EvoCode를 소개했다. 에이전트가 진화하는 요구사항을 따르면서 이전 동작을 깨뜨리지 않는지 측정한다. 동시에 @omarsar0는 에이전트 skill의 **“regression tax”**를 보여주는 논문을 요약했다. 거의 6,000 paired runs에서 skill은 이득을 냈지만, 이전에는 skill 없이 풀었던 많은 작업도 깨뜨렸다. 이는 절차적 skill을 무작정 context에 더 넣는 방식에 대한 실용적 경고다.
멀티모듈 RL 시스템에서 “role drift”가 나타남: @omarsar0의 또 다른 유용한 논문 요약은 end-to-end RL이 파이프라인 정확도를 높이면서도 모듈이 의도된 책임을 조용히 버리게 만들 수 있음을 설명했다. 예를 들어 decomposer가 문제를 구조화하는 대신 답을 내장하는 식이다. 팀들이 단일 에이전트 루프에서 특화된 tool/prompt/module 스택으로 이동하면서 점점 더 관련성이 커지는 주제다.

모델과 시스템 인프라: Agentic RL에서 Streaming VLM까지

Microsoft와 NVIDIA가 주목할 만한 인프라·모델 업데이트를 공개: Microsoft는 라이브 이벤트 이해를 위한 codec-native streaming VLM인 Mage-VL 4B를 공개했다고 @HuggingApps가 전했다. NVIDIA 연구에서도 Molt가 나왔다. 이는 사람이, 그리고 AI 코딩 어시스턴트가 end-to-end로 추론할 수 있을 만큼 간결하게 설계된 PyTorch-native agentic RL framework라고 @dair_ai가 요약했다. “AI-readable research infra”라는 설계 제약은 작지만 중요한 도구 철학의 변화다.
AMD가 더 재현 가능한 오픈 MoE 릴리스를 추진: Instella-MoE는 AMD의 첫 완전 오픈 MoE LM이다. 16B total / 2.8B active 규모이며, MI300X/MI325X에서 학습됐고, pretraining부터 RL까지의 체크포인트, config, data mixture, code가 함께 공개됐다 @PrakamyaMishra. 일반적인 모델 공개와 비교하면 full-stack research artifact에 더 가깝다.
Cohere와 개발자 도구 벤더들은 “own the harness” 쪽으로 계속 이동: Cohere는 보안 에이전트 플랫폼 위의 자연어 워크플로 레이어인 North Automations를 발표했다 @cohere. LangChain 생태계 메시지도 기업이 모델 접근을 빌리는 데서 그치지 말고 tools, prompts, context, memory를 소유해야 한다는 점을 계속 강조했다 @sydneyrunkle. 같은 프레이밍은 오픈 모델과 엔터프라이즈 에이전트 배포를 둘러싼 여러 게시물에서도 나타났다.

Top tweets (by engagement)

Kimi K3 release: Moonshot의 K3 발표는 세트에서 가장 큰 기술 게시물이었다. 2.8T open-weights release에 커널, MoE 통신, 에이전트 환경 인프라가 결합됐다 @Kimi_Moonshot.
Open Secure AI Alliance: Jensen Huang의 open defensive AI 주장, 특히 Hugging Face incident 일화가 큰 참여를 이끌었다 @JensenHuang.
SSI × NVIDIA: Ilya Sutskever의 “Time to scale that SSI”와 후속 보도는 Safe Superintelligence가 Vera Rubin에서 대규모 컴퓨트 확장에 나설 가능성을 가리킨다 @ilyasut, @kimmonismus.
OpenAI economics/workflow productization: OpenAI의 업무 사용 연구와 cloud agents / Work mode 주변의 더 넓은 움직임은 chatbot UX에서 내장형 개인·기업 자동화로 전환되고 있음을 계속 보여준다 @OpenAI, @gdb.

AI Reddit Recap

/r/LocalLlama + /r/localLLM

Kimi K3 weights now released. (Activity: 3442): 이미지는 Hugging Face의 moonshotai/Kimi-K3 페이지 모바일 스크린샷으로, Kimi K3 weights have been released라는 게시물 제목을 뒷받침한다. 모델은 Image-Text-to-Text Transformers 체크포인트이며 Safetensors / compressed-tensors, custom_code 필요, kimi-k3 라이선스, 약 3.8k likes와 지난달 2,850 downloads가 표시됐다. 댓글은 하드웨어 가능성에 집중했다. 한 사용자는 *“104B 활성 파라미터”*를 언급하며 매우 큰 추론(inference) 메모리 요구를 시사했고, “Hugging Face에서 RAM은 어떻게 다운로드하나요?”, “내 3090 준비됐다” 같은 농담은 소비자 GPU 실행에 대한 회의론을 보여줬다. 일부는 Kimi K3가 104B activated parameters를 사용한다고 알려져, 일반 소비자 GPU 설정보다 훨씬 높은 추론 메모리와 컴퓨트가 필요하다고 봤다. 또 다른 사용자는 이를 512 GB Mac Studio에서도 실행할 수 없는 첫 “frontier open model”이라고 묘사했다.
Kimi K3 weights drop today. We’re deploying on A100s, H200s and B300s this week and the A100 math is already rough (Activity: 763): 게시자는 Moonshot의 Kimi K3 가중치가 Hugging Face에 올라올 것으로 예상하며, 2.8T total MoE params, 896 experts / 토큰당 16 active, 1M context, vision support, 약 ~1.4 TB MXFP4 quantization-aware-trained checkpoint를 언급했다. 배포 계산은 8×A100 80GB = 640 GB가 멀티노드 샤딩 없이는 가중치를 담을 수 없고 FP4/FP8 tensor cores도 부족하며, 8×H200 ≈ 1.13 TB도 최소 두 노드가 필요하고, 8×B300 ≈ 2.3 TB만 가중치와 long-context KV cache, 네이티브 FP4를 담을 여유가 있는 단일 노드 구성이라는 것이다. A100, H200, B300에 대해 tok/s, TTFT, cost-per-million-token 벤치마크를 공개할 계획이며, A100 성능은 dequantization 또는 비타깃 INT4 커널 때문에 *“ugly”*할 것으로 예상했다. 댓글은 B300 배포를 *“$500k to spare”*가 필요한 고 CapEx 실험으로 봤고, Intel Gaudi 2/3 테스트 의향도 나왔다. 한 댓글은 8x AMD MI355X가 약 2.3 TB aggregate VRAM과 FP4 acceleration 때문에 이상적일 수 있으나 실제 사용·대여 가능성은 거의 없다고 했다. 또 Hugging Face가 countdown을 제거했다는 언급도 있어 릴리스 타이밍이나 배포 페이지 변화에 대한 불확실성이 제기됐다.

오픈웨이트 AI 보안과 정책 싸움

CEO of Hugging Face: “In the spirit of transparency, here’s what I asked OpenAI” (Activity: 3109): 이미지는 Hugging Face CEO Clem Delangue가 OpenAI에 공개적으로 요청한 내용을 담은 스크린샷이다. 그는 자신이 *“첫 autonomous agent cyberattack”*이라고 부른 사건에 연루된 alleged “rogue” autonomous agents의 execution traces/logs를 공개해 연구자들이 실패 모드를 분석할 수 있게 해 달라고 요청했다. 또한 OpenAI가 open and closed models를 사용하는 Hugging Face 커뮤니티의 사이버 방어 시스템 구축을 돕기 위해 $100M in compute를 제공하겠다고 약속하길 요구했다. Image 댓글은 대체로 회의적이었고, $100M을 “casual”하게 요구하는 것은 비현실적이라고 봤다. 일부는 사건이 홍보성 쇼였을 가능성이나 로그 공개가 OpenAI에 평판·법적 리스크를 줄 가능성을 추측했다.
Jensen Huang: During the Hugging Face incident, closed AI blocked essential forensics. An open-weight frontier model helped contain the intrusion. That’s why we created the Open Secure AI Alliance. (Activity: 1736): image는 Jensen Huang이 Hugging Face security incident 중 closed AI systems가 필수 포렌식 분석을 막았고, open-weight frontier model이 방어자의 침입 억제에 도움을 줬다고 주장하는 스크린샷이다. 게시물은 이를 NVIDIA의 Open Secure AI Alliance 동기로 제시하며, Microsoft, Hugging Face, IBM, Cloudflare, Cisco, Red Hat, Salesforce, SAP 등 파트너 로고를 보여준다. 독점 모델에만 의존하지 않고 open + closed frontier AI security ecosystem이 필요하다는 주장이다. 댓글은 Adobe, Cisco, Palantir, DoorDash 같은 회사들이 일반적으로 오픈소스 AI와 연결되지 않는다며 “open” 브랜딩에 회의적이었고, 주요 오픈소스 모델 제작자가 보이지 않는다는 지적도 나왔다.
Sources: OpenAI and Anthropic quietly lobby Washington regulators to restrict open-source AI models, even as Sam Altman publicly says he supports open source AI (Activity: 1470): NYT reports에 따르면 OpenAI와 Anthropic은 미국 규제당국에 open/open-weight AI models 제한을 조용히 로비해 왔다. 특히 Z.ai와 Moonshot AI의 중국 릴리스가 미국 프런티어 모델 역량에 가까워지고 있다는 점을 두고 IP theft, distillation, safety, national-security risks를 제기했다. 반대 연합에는 Nvidia, Microsoft, Meta, Google, IBM, Palantir, Hugging Face와 스타트업들이 포함되며, 이들은 open models가 경쟁, 보안 감사, 칩·클라우드 수요, 혁신에 중요하다고 주장한다. 미국 당국은 blanket ban보다는 특정 중국 기업·모델에 대한 targeted actions 쪽에 더 기울어 있는 것으로 알려졌다. 상위 댓글은 Sam Altman/OpenAI에 냉소적이었고, 공개적으로 open weights를 지지한다는 입장과 로비가 모순된다고 봤다. 한 댓글은 *“우리는 Open Weights를 지지했지만, 로비 때문에 불가능해졌다”*고 비꼬았다.
OpenAI management decided earlier today not to join the “Open Secure AI Alliance”, founded by Nvidia CEO Jensen Huang. The decision was shared internally and reportedly met with backlash from employees. (Activity: 423): 게시물은 OpenAI management가 Nvidia CEO Jensen Huang이 설립한 것으로 알려진 “Open Secure AI Alliance”에 참여하지 않기로 내부 결정했고, 이 결정이 직원 반발을 불렀다고 주장한다. 동맹의 거버넌스, 보안 모델, openness criteria, 모델 릴리스 정책, 벤치마크, 구현 요구사항에 대한 기술적 세부사항은 제공되지 않았다.

실행 가능한 로컬 모델과 코딩 Harness 벤치마크

Harness showdown: Claude Code vs OpenCode vs Pi with DeepSeek V4 Flash (Activity: 556): image는 **“Harness showdown: Claude Code vs OpenCode vs Pi with DeepSeek V4 Flash”**의 기술 벤치마크 차트다. 모델을 vLLM에서 약 180 tok/s로 실행되는 DeepSeek V4 Flash로 고정하고 coding-agent harness별 wall-clock runtime을 비교했다. 보고된 결과는 output quality/code diffs가 “basically the same”였지만, harness overhead는 크게 달랐다. Pi 약 2.1 min, OpenCode 약 3.1 min, **Claude Code 약 8.0 min**였고 Claude Code의 분산이 가장 컸다. 이는 모델 역량보다 scaffold/tool-prompt behavior가 지연시간과 토큰 소비를 지배했음을 시사한다. 저자는 원자료와 차트를 nqawhc.github.io/articles/harness-efficiency-not-quality에 연결하고, 차이를 tool-call structure와 system prompts 탓으로 돌리며 *“Pi reasons, OpenCode delegates”*라고 요약했다. Claude Code는 codebase를 과도하게 탐색한다고 했다. 댓글은 runtime뿐 아니라 speed–quality–cost tradeoff를 포함해야 한다고 주장했다. 또 harness는 본질적으로 prompt/tooling wrapper이며, Claude Code는 custom-instruction “bloat”가 크고 OpenCode는 덜 bloated하며 Pi는 가장 깔끔하고 configurable하다는 논의가 있었다. 표준편차 막대가 non-normally distributed이고 10m에서 censored된 데이터에는 부적절하다는 방법론 비판도 나왔다.
Don’t laugh - it works! (Activity: 297): 32 GB DDR4-2133 RAM과 Intel i7-6700을 갖춘 10년 된 CPU-only 서버가 quantized Qwen3.6-35B-A3B 모델을 IQ4_XS로 실행하고 있다고 보고됐다. 약 26 GB RAM을 사용하고 128k context에서도 약 5–10 tok/s를 냈다. 작업부하는 CPU-bound라기보다 memory-bound로 보이며 CPU utilization은 약 60%였다. 이는 low-bit quantization이 오래된 commodity hardware에서도 GPU 없이 큰 MoE/LLM 추론을 쓸 수 있게 만든다는 점을 보여준다.
We could really use Qwen3.8 in 27B, 35B, 122B and 397B sizes (Activity: 894): 게시물은 향후 Qwen/Qwen3.8 오픈웨이트 릴리스가 커뮤니티 사용자가 거의 호스팅할 수 없는 1.5–2T+ 파라미터 “frontier” 모델 대신, 배포 가능한 small/medium checkpoint인 27B, 35B, 122B, 397B를 우선해야 한다고 주장한다. 기술적 이유는 이 크기들이 CPU expert offloading과 함께 enthusiast/workstation 및 small-business 환경에서 여전히 가능하며, trillion-parameter 모델은 주로 API 제공자와 대기업에 유리하다는 것이다. 댓글은 특히 강력한 약 120B급 모델 부족을 지적했고, inference 비용이 너무 비싸면 “open” weights의 의미가 줄어든다고 했다. 한 댓글은 prior Qwen variants와 Nex N2 같은 downstream retrains를 칭찬하며 비슷한 multi-size releases가 local/on-prem users에게 더 도움이 된다고 봤다. 여러 댓글은 가장 유용한 open-weight 범위가 30B–120B parameters라고 주장했고, vision-language embedding models 업데이트 수요도 언급했다.

Less Technical AI Subreddit Recap

대상: /r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo

Claude Opus 5 코딩과 3D 벤치마크

Differences Between Fable 5 and Opus 5 on MineBench.ai (Activity: 1247): MineBench.ai 결과는 JSON-coordinate Minecraft-like 3D structure generation에서 Anthropic Opus 5.0과 Fable 5를 비교한다 (benchmark, repo, release notes). Opus 5.0은 curved CRT-like arcade screens와 올바르게 모델링된 interiors/floors/attics 등 build fidelity에서 Fable과 비슷하거나 더 나아 보였지만, 효율은 훨씬 낮았다. 평균 추론(inference)은 1930.2s 대 Fable 1084.4s(+78%), 총 비용은 15 builds 기준 $89.97 대 $54.93(+64%), 평균 JSON 크기는 91.00 MiB 대 30.65 MiB였고, 12/37 시도는 invalid/truncated JSON schema 때문에 실패했다. 저자는 높은 retry/cost rate의 주된 원인을 최종 JSON이 유난히 크기 때문이라기보다 maximum reasoning effort에서 token-inefficient internal CoT가 출력 한도에 닿게 만들었기 때문이라고 봤다. 상위 댓글은 대체로 비기술적이었지만 Opus 5.0이 Fable 대비 큰 질적 도약이고 MineBench가 유용하고 흥미로운 벤치마크라는 저자의 관점에 동의했다. 한 댓글은 Opus 5가 더 복잡한 구조를 만들지만 Fable 5 출력은 더 cleaner하고 시각적/noise artifacting이 적다는 질적 tradeoff를 언급했다.
I built a procedural desert explorer with Claude Code (Opus 5) and Three.js (Activity: 1623): procedural WebGPU/Three.js desert tech demo인 desert-dusky.vercel.app은 Opus 5를 사용하는 Claude Code로 전부 제작됐다고 보고됐다. TSL shaders, compute kernels, physics integration, Node-based benchmarking tooling까지 포함된다. 장면은 다운로드된 asset 없이 shader-generated terrain을 사용하는 GPU clipmap dune field, 지속되지만 침식되는 sand deformation, hooded robe용 GPU cloth, per-pixel marched physical sky, 지형을 바꾸는 여섯 가지 “sand spells”를 사용한다. 저자는 RTX 5070 Ti에서 1440p 기준 약 160 FPS를 보고했다. Claude의 workflow는 앱 실행, 스크린샷 캡처, subsystem별 GPU cost 보고를 수행하는 headless-Chrome harness로 계측되어 measurement-driven iteration을 가능하게 했다. 상위 댓글은 대체로 비기술적이었고 Journey와의 유사성, Dune/Muad’Dib 농담, 먼 피라미드에 실제로 도달 가능한지에 대한 질문이 있었다.

Claude 공개 공유 링크 개인정보 노출

Claaude security flaw leaks its customer’s conversations on Google (Activity: 4553): 이미지는 Google dork query인 **site:claude.ai/share**가 indexed Claude shared conversation pages를 반환하는 모습을 보여준다. 이는 사용자가 Claude 공유 기능으로 공개한 대화가 검색엔진에서 발견될 수 있음을 시사한다. 기술적으로 이는 exploit이라기보다 indexing/UX/privacy issue에 가깝다. 공유 URL이 public이고 noindex/robots controls로 막히지 않았다면 Google/Bing이 노출할 수 있다. 댓글은 “security flaw”라는 제목에 반박하며 public share links가 색인되는 것은 예상 가능한 동작이고, 이전 ChatGPT shared-chat indexing과 유사하다고 봤다. 한 댓글은 Google에서는 결과가 없었지만 Bing에서는 보였다고 말해, 검색엔진이나 지역별 색인 가시성이 다를 수 있음을 시사했다. 여러 댓글은 이것이 Claude 자체의 취약점이 아니라 access-control and indexing issue라고 봤고, “share by link”는 인증, noindex, robots rules 또는 crawler restrictions와 결합된 unguessable URLs가 없으면 public resource가 된다는 교훈을 반복했다.
You can also view a lot of shared artifacts. (Activity: 1191): 이미지는 Google dork query인 **site:claude.ai/public/artifacts**가 많은 indexed Claude public artifact pages를 반환하는 모습을 보여준다. 이는 shared artifacts가 direct links뿐 아니라 검색엔진으로도 발견될 수 있음을 뜻한다. 게시자는 public Claude chats를 본 뒤 이를 시도했고, presentations, calendars, press-release-style documents 같은 내용을 담은 artifacts를 발견했다고 말했다. 이는 모델 벤치마크나 구현 이슈라기보다 실질적인 data exposure / user-consent visibility 문제다. 댓글은 사용자가 공유를 승인했을 가능성은 있지만, 많은 사용자가 artifacts가 Google에서 색인되고 발견될 수 있다는 점을 이해하지 못했을 수 있다고 봤다. 한 사용자는 개인·상업 정보가 보여 *“Bad”*라고 했고, 다른 이들은 public artifacts가 model distillation이나 dataset collection을 위해 대규모로 scraping될 수 있다고 우려했다.

프런티어 AI 컴퓨트와 오픈 모델 릴리스

Nvidia invest in SSI (Activity: 1036): 이미지(Reddit-hosted screenshot)는 **SSI Inc.**가 장기 전략 파트너십을 발표하며 NVIDIA가 SSI의 컴퓨트를 향후 12 months 동안 10x 늘릴 수 있게 하는 “substantial investment”를 한다는 내용을 보여준다. 제목과 본문 맥락상 기술적 의미는 Ilya Sutskever의 비밀스러운 AI safety/research startup이 학습 역량을 공격적으로 확장할 수 있다는 점이지만, 모델 아키텍처, 벤치마크, 제품, 릴리스 계획은 공개되지 않았다. 댓글은 SSI가 매우 불투명하다고 봤고, NVIDIA가 뭔가 설득력 있는 것을 봤을 것이라고 추측했다. 한 댓글은 SSI가 이미 “plenty of compute”를 갖고 있었다면 NVIDIA 투자는 기초 학습 능력보다 product serving 준비를 뜻할 수 있다고 해석했다. 또한 SSI가 내부 scaling 결과를 갖고 있거나, 투자자에게 진전을 보여줘야 하거나, 가장 그럴듯하게는 폐쇄 실험실을 넘어 연구를 진전시키기 위해 real user data/feedback loops가 필요할 수 있다고 추측했다.
kimi k3 is getting opensourced today (Activity: 952): image는 Moonshot AI의 “Kimi-K3” 홍보 countdown으로, July 27, 2026 릴리스 예정과 09h10m remaining, 1,337 people waiting을 보여준다. 게시물 제목은 “getting opensourced”라고 주장하지만, 댓글은 기술적으로 중요한 구분인 open-weight일 가능성이 크며, training code/data나 permissive full software stack을 공개하는 진정한 open-source는 아닐 것이라고 설명했다. 주요 논쟁은 용어였다. 댓글은 model-weight releases를 “open source”라고 부르는 데 반대하며 “open weights”를 선호했다. 또한 Kimi K3가 near-frontier scale이라면 local inference에는 multi-GPU server/datacenter-class hardware가 필요할 수 있어, 가중치를 다운로드할 수 있더라도 대부분의 사용자에게는 유용성이 제한된다는 deployability 우려도 나왔다.

오늘의 요약