Midjourney가 의료용 스캐너를 공개

헤드라인: Midjourney가 의료용 스캐너를 공개

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

무슨 일이 있었나

Midjourney가 의료 영상/스캐닝 시스템을 공개한 뒤 기술 심층 분석을 발표하면서, AI 연구소가 하드웨어와 의료 기기로 확장하는 흐름을 두고 관심, 회의, 논쟁이 함께 일어났다.

Midjourney 공식 계정은 주요 발표 트윗에서 **“새로운 ‘Midjourney Scanner’ 내부 기술 심층 분석”**을 게시했으며, 이것이 프로젝트의 핵심 공개 자료로 보인다 @midjourney.
출시 전후로 이 스캐너의 장단점은 무방사선, 무자석, 빠른 속도, 저비용이지만 사람이 물 침수 탱크에 앉아야 하며, 현재는 CT/MRI보다 해상도가 거칠다는 식으로 요약됐다 @iScienceLuvr.
현장 데모도 있었던 것으로 보인다. 한 참석자는 **“오늘 밤 @midjourney 데모 스캐너에 손을 넣어봤다”**고 말해, 순수한 콘셉트 발표가 아니라 만져볼 수 있는 프로토타입으로 묘사했다 @saranormous.
발표는 지지자들 사이에서 강한 흥분을 일으켰다. 이들은 Midjourney가 이례적으로 야심 찬 제품 방향을 보여준 증거로 받아들이며 “이건 정말 놀랍다”, “@DavidSHolz 같은 발명가들이 발명하게 하라” 같은 반응을 보였다 @saranormous.
다른 이들은 더 점진적인 AI 하드웨어 시도와 경쟁적으로 해석했다. 한 반응은 “지루한 옷깃 카메라”식 베팅과 대조하며, Midjourney가 이런 것을 만들고 있다면 다른 AI 연구소들은 “스스로 뺨을 때려야 한다”고 주장했다 @matvelloso.
영상 방식에 관심 있는 사람들의 가벼운 기술 논평도 있었다. 감지기/방출기 배치와 실시간 변형에 대한 추측 @johnowhitaker, 그리고 일부 사용자가 이 출시 주제에 유난히 준비돼 있었던 것 같다는 농담도 나왔다 @johnowhitaker.

사실과 의견

트윗 묶음에 명시적으로 나타난 사실 주장

Midjourney는 **“Midjourney Scanner”**라는 제품의 기술 심층 분석을 발표했다 @midjourney.
해당 스캐너는 다음과 같이 묘사됐다.
- 무방사선
- 무자석
- 빠름
- 저비용
- 물 침수 탱크 필요
- CT/MRI보다 거친 해상도 @iScienceLuvr
한 사람이 손으로 데모 스캐너를 실제로 체험했다 @saranormous.

해석/의견/추측

강한 긍정 반응은 이 스캐너를 비전 있는 것, 혹은 “미래”로 표현했다 @saranormous.
일부 관찰자들은 이번 출시를 Midjourney가 경쟁 AI 연구소보다 더 야심 찬 하드웨어 로드맵을 추구한다는 증거로 받아들였다 @matvelloso.
한 유머러스한 답글은 “다음은 Midjourney의 완전 화물 운송”이라고 확장했는데, 이는 명백히 사실 주장이 아니다 @yacinelearning.
독립적인 기술 논평은 분산된 산란 감지기와 방출기, 실시간 시스템 같은 향후 설계 방향을 제안했지만, 이를 Midjourney 현재 스캐너의 기능으로 제시한 것은 아니다 @johnowhitaker.

기술 세부사항과 추론된 방식

트윗 자료에는 확정적인 사양이 많지 않지만, 프로젝트의 포지셔닝을 그리기에는 충분하다.

이온화 방사선 없음: “무방사선”은 이 시스템이 X-ray/CT식 이온화 방식을 쓰지 않는다는 뜻이다 @iScienceLuvr.
자석 없음: “무자석”은 강한 자기장에 의존하는 MRI와 구분된다 @iScienceLuvr.
물 침수 탱크: 물리적 센싱 구성에 대한 중요한 단서다. 물 결합은 방출기, 조직, 감지기 사이의 전달과 결합을 개선하기 때문에 일부 음향 및 파동 전파 영상 시스템에서 흔히 쓰인다 @iScienceLuvr.
CT/MRI보다 낮은 해상도: 이 트윗들에서는 기존 임상 영상보다 해상도에서 우월하다고 주장하지 않는다. 오히려 해상도가 CT/MRI보다 거칠다는 제한이 명시돼 있다 @iScienceLuvr.
속도/비용 포지셔닝: 빠르고 저비용으로 표현돼 있어, 가치 제안은 최고급 영상 충실도보다 접근성, 처리량, 휴대성 쪽일 가능성이 크다 @iScienceLuvr.

센싱 과제에 대한 기술적 반응도 있었다.

John Whitaker는 빛, 초음파, 전류 등에 기반한 시스템은 신호가 X-ray처럼 직선으로 이동하지 않기 때문에 X-ray보다 역문제(inverse problem)가 더 어렵고, 재구성(reconstruction)이 복잡해진다고 지적했다 @johnowhitaker.
그는 또한 기계적으로 움직이는 구성요소 대신 많은 산란 감지기와 방출기를 쓰는 미래 버전을 제안했다. 이는 일부 독자들이 현재 시스템을 완전히 병렬화된 캡처라기보다 움직임/스캐닝 기하 구조가 있는 것으로 추론하고 있음을 시사한다 @johnowhitaker.

종합하면 공개 논의는 파동 기반 재구성과 중요한 알고리즘/역문제 요소를 가진 비-CT, 비-MRI 방식으로 향하고 있다. 다만 여기 있는 트윗들은 명시된 장단점 외에 확정적인 방식 이름이나 성능 표를 제공하지 않는다.

다양한 관점

지지/낙관

가장 열성적인 진영은 이것을 AI 창업자들이 추구해야 할 고상승, 이상하고, 비합의적인 발명으로 본다. 단순한 챗봇/UI 제품이 아니라는 것이다. “@DavidSHolz 같은 발명가들이 발명하게 하라”는 말에 그 분위기가 잘 드러난다 @saranormous.
현장 데모 반응은 논문을 읽거나 영상을 보는 수준이 아니라 실제 스캐너와 상호작용하는 직접적인 새로움을 강조했다 @saranormous.
일부는 이 움직임을 Midjourney가 이미지 생성을 넘어 풀스택 응용 발명으로 나아가며 하드웨어, 센싱, AI 재구성을 결합할 수 있다는 신호로 해석했다.

중립/기술적 호기심

이 묶음에서 가장 차분한 반응은 간결한 장단점 요약이다. 무방사선, 무자석, 빠름, 저비용 대 물 침수와 CT/MRI보다 낮은 해상도다 @iScienceLuvr.
기술적으로 호기심 많은 관찰자들은 방식의 낯섦을 흥미롭게 보면서도 곧바로 물리적·시스템적 장단점을 지적했다.
- X-ray와 비교한 비직선 전파
- 더 나은 실시간 캡처 구성 필요
- 감지기/방출기 토폴로지에 대한 질문 @johnowhitaker

반대/회의/주의

이 트윗 묶음에는 직접적인 적대 비판은 제한적이지만, 여러 지점에서 회의가 암시된다.

임상 유용성 회의: CT/MRI보다 해상도가 거칠다는 말은 중요한 단서다. 의료에서는 영상 품질이 진단 가치에 직접 영향을 줄 수 있기 때문이다 @iScienceLuvr.
실용성 회의: 물 침수 탱크가 필요하다는 점은 일상 임상 또는 소비자 사용에서 심각한 인체공학적·배포 제약이다 @iScienceLuvr.
방식 회의: 비직선 전파에 관한 기술적 논평은 대체 영상 시스템의 일반적인 난제를 암시한다. 물리학과 역재구성이 어렵고, 멋진 데모가 자동으로 견고하고 임상적으로 신뢰할 수 있는 영상으로 이어지지는 않는다는 점이다 @johnowhitaker.

경쟁 구도

한 주목할 만한 관점은 스캐너 자체보다 전략적 의미에 초점을 맞췄다. Midjourney가 하드웨어-의료 발명에 도전한다면, 더 좁은 웨어러블 카메라 개념을 추구하는 AI 기업들은 상대적으로 보수적으로 보인다는 것이다 @matvelloso.

맥락: 왜 중요한가

Midjourney는 주로 이미지 생성 회사로 알려져 있다. 그래서 의료/스캐너 공개가 주목받는 이유가 몇 가지 있다.

생성 미디어 소프트웨어에서 현실 세계 센싱과 하드웨어로 이동하려는 의지를 시사한다.
의료 영상은 역문제, 신호 처리, 재구성, 그리고 점점 더 ML 기반 해석이 모두 중요한 영역이다. 당연한 인접 분야는 아니지만 기술적으로 깊은 분야다.
이 스캐너는 “모든 축에서 MRI/CT보다 낫다”가 아니라 전형적인 파괴적 진입로에 있는 듯하다. 즉 프리미엄 지표에서는 나쁘지만 비용/접근성/운영 부담에서는 더 나은 잠재적 진입자다.
시스템이 정말 빠르고 저비용이라면, 가장 그럴듯한 영향은 다음 영역에 있다.
- 선별검사 또는 분류
- CT/MRI 접근이 제한된 환경
- 방사선 회피가 중요한 반복 영상
- 침수 기반 구성이 허용되는 특수 해부학적 사용 사례

이번 출시는 AI 인접 기업들이 자신을 단순한 모델 공급자가 아니라 물리 세계로 향하는 새로운 인터페이스의 구축자로 정의하려는 2025년의 더 넓은 흐름과도 맞닿아 있다. 이 관점에서 Midjourney Medical은 단일 스캐너라기보다 프런티어 AI 시대 스타트업이 콘텐츠 생성뿐 아니라 어려운 센싱 시스템을 제품화할 수 있는지에 관한 문제다.

시사점과 열린 질문

규제 경로: 이 트윗들에는 승인, 검증 연구, 연구 전용인지 임상 배포 의도인지에 대한 내용이 없다. 의료적 의미에서는 이런 질문이 핵심이다.
재구성 스택: “기술 심층 분석”이라는 표현은 내부를 설명했다는 뜻이지만, 여기의 트윗 묶음은 실제 알고리즘 세부사항을 드러내지 않는다. 핵심은 제한된 센싱 구성에서의 재구성 품질일 가능성이 크다.
사용 사례 특이성: CT/MRI보다 낮은 해상도가 반드시 시스템을 실패로 만들지는 않는다. 많은 영상 도구는 좁은 워크플로에 충분히 좋은 성능으로 성공한다. 하지만 이 트윗들에는 구체적 대상 적응증이 나타나지 않는다.
폼팩터 과제: 물 침수 탱크는 일부 스캔 맥락에서는 받아들일 수 있지만 다른 맥락에서는 큰 장벽이다. 이것이 프로토타입의 흔적인지 근본 요구사항인지가 중요하다.
처리량과 비용 현실성: “빠름”과 “저비용”은 스캔 시간, 하드웨어 비용, 소모품, 운영자 부담, 후속 해석 오버헤드 같은 기준과 비교될 때만 의미가 있다. 이 숫자들은 여기 트윗들에 제공되지 않았다.
AI의 역할: 가장 흥미로운 기술 질문은 Midjourney의 기여가 주로 하드웨어 설계인지, 역문제 재구성인지, 학습 기반 노이즈 제거/초해상도인지, 자동 해석인지, 혹은 이 모든 것을 포괄하는 통합 스택인지일 수 있다. 사회적 반응은 Midjourney 브랜드가 전통 의료기기보다 학습된 시각 시스템과 연결돼 있기 때문에 사람들이 이 프로젝트에 많은 것을 투사하고 있음을 보여준다.

AI Twitter Recap

AI 연구, 에이전트, 오픈 모델

중국 오픈소스 문헌: 지난 1년간 중국 오픈소스 문헌을 추적하는 것이 비정상적으로 높은 ROI를 낸다는 연구 메타 포인트가 나왔다. “알파가 엄청나게 크다”는 주장이다 @himanshustwts.
VibeThinker-3B: PapersWithCode의 최상위 트렌딩 논문은 VibeThinker-3B였다. 이는 소형 LM에서 검증 가능한 추론(reasoning)을 탐구하는 3B 파라미터 모델로 설명됐고, DeepSeek V3.2, GLM-5, Gemini 3 Pro 성능권에 들어갔다고 주장됐다 @NielsRogge.
PreAct: 컴퓨터 사용 논문 PreAct는 성공한 에이전트 실행을 보호된 재생 가능 상태 머신으로 컴파일해 반복 시 단계별 LM 호출을 없애고 8.5배에서 13배 더 빠른 재생을 만든다고 평가받았다 @dair_ai.
LLM-as-Environment-Engineer: 또 다른 RL/에이전트 논문은 정책이 자기 실패를 사용해 다음 훈련 환경을 재설계하는 LLM-as-Environment-Engineer를 제안했다. 관련 벤치마크는 MAPF-FrozenLake다 @dair_ai.
코딩 에이전트 가드레일: Omar Sar0는 코딩 에이전트에 맹목적 자율 루프가 아니라 검증기와 견고한 가드레일이 필요하다고 주장하며, 제약된 에이전트 실행 흐름을 강화했다 @omarsar0.
AI 코드 읽기: David Khourshid의 코딩 에이전트 견해는 더 운영적이었다. AI 생성 코드는 여전히 읽어야 하며, 읽지 않으면 디버깅 부담을 뒤로 미룰 뿐이라는 것이다 @DavidKPiano.
PPO 부활 설명: RL 이론에서 John Schulman은 LLM 시대 PPO의 부활이 원 논문이 예상하지 못한 효과에서 나온다고 말했다. 여기에는 importance-ratio objective가 수치 오류, 비동기 훈련, forward-pass 노이즈에서 생기는 편향을 교정하는 점이 포함되며, 클리핑은 나중에야 이해된 메커니즘으로 엔트로피를 바꾼다. 그는 DAPO를 인용했다 @johnschulman2.
GRPO 이후 분석: 관련해 Chris Wolfe는 DAPO, Dr. GRPO, GSPO, TIS 같은 최근 post-GRPO 분석 논문이 추론/에이전트 맥락에서 PPO에 대해 보고 싶은 바로 그런 목적함수 분석 작업이라고 말했다 @cwolferesearch.
Temporal Differences 비판: John Carmack은 Temporal Differences for visual representation learning에 대한 상세 비판을 올렸다. 방법은 RGB 프레임 차이로 프레임 인코더와 “motion encoder”를 훈련해 latent(frame1) + delta ≈ latent(frame2)가 되게 하며, 0.25초 stride를 쓴다는 것이다. 그는 DINO EMA anti-collapse 선택과 delta 구성의 타당성을 문제 삼았다 @ID_AA_Carmack.

AI 인프라, 추론, 제품 출시

WebGPU 추론: Xenova는 종료된 Fable 5 작업에서 나온 데모와 커널을 공개하며 Gemma 4를 WebGPU에서 255 tok/s까지 밀어 올렸다고 주장했다. 프레이밍은 에이전트형 커널 최적화가 브라우저/온디바이스 추론(inference)을 실질적으로 개선할 수 있다는 것이다 @xenovacom.
Kling 3.0 Turbo와 O3 업그레이드: Fal은 Kling 3.0 Turbo and O3 upgrades를 발표했다.
- 더 빠른 생성
- 더 낮은 비용
- 더 나은 립싱크
- 더 안정적인 움직임
- “Omni”에서 더 강한 프롬프트/레퍼런스 일관성
- 최대 15초 클립
- Omni의 완전한 4K 생성
- 개선된 스토리보드와 멀티샷 워크플로 @fal
Kling 확산: Kling 공식 계정은 Fal 출시를 크리에이터 대상 품질/속도 개선으로 증폭했다 @Kling_ai.
GitHub Copilot Auto mode: GitHub Copilot의 Auto mode는 이제 추론 깊이, 코드 복잡도, 디버깅 난이도, 도구 오케스트레이션 필요에 따라 모델을 고르는 맞춤 라우팅 모델을 사용한다. 블로그 글과 연결된 연구 논문이 공유됐다 @pierceboggan, @pierceboggan.
Kimi Code Web: 짧은 생태계 메모에 따르면 Kimi Code Web이 다시 온라인으로 보인다 @bigeagle_xd.
Grok 이미지 생성: grok.com/imagine을 통한 Grok 이미지 생성 프로젝트가 언급됐지만, 실질적인 기술 세부사항은 없었다 @chaitu.

인재, 연구소, 경쟁 구도

Noam Shazeer OpenAI 합류: Midjourney 외부에서 가장 큰 인사 뉴스는 Noam Shazeer가 OpenAI에 합류한다고 발표한 것이다. 그는 어려운 결정이었다며 Google을 떠나고 이전 팀을 칭찬했다 @NoamShazeer.
Sam Altman 반응: Sam Altman은 Noam이 OpenAI 초기부터 가장 함께 일하고 싶었던 사람 중 하나였다고 말하며 이를 축하했다 @sama. 이후 OpenAI가 “noams”에서 SOTA라고 농담했다 @sama.
Shazeer의 의미: 해설은 Shazeer가 Transformer, T5, Switch Transformer 공동저자이자 sparse MoE 시스템의 선구자라는 점을 강조했으며, 일부는 올해 가장 중요한 AI 인재 이동이라고 불렀다 @scaling01.
Aidan Clark 반응: Aidan Clark는 Noam과 함께 일하게 된 데 대한 기대를 보였고, RSI가 가까워지고 있다는 감각과 연결했다 @aidan_clark.
업계 해석: 답글의 더 넓은 업계 해석은 다음과 같았다.
- DeepMind/Brain 합병이 간접적으로 Anthropic/OpenAI에 이득이 됐을 수 있다 @arohan
- Anthropic은 Karpathy를 얻고 OpenAI는 Noam을 얻었다 @TheTuringPost
- 이 이동이 OpenAI의 끌어당김만큼이나 Google에 대한 실망을 말해준다는 추측 @teortaxesTex
가치평가 잡담: 상대적 파워/가치평가에 관한 대화도 있었다. Liam Fedus는 “속보: OpenAI가 Anthropic의 가치평가를 넘어섰다”고 올렸다 @LiamFedus.
지정학적 추측: 더 의견이 강한 지정학/경쟁 관점에서는 여러 행위자가 Anthropic이 너무 큰 리드를 유지하지 못하게 할 유인이 있다는 주장이 나왔지만, 이는 사실 보도라기보다 명확히 추측에 가까웠다 @teortaxesTex, @teortaxesTex.

채택, 사용, 모델 품질 담론

신뢰성 문제: Blanche Minerva는 실용적인 품질 불만을 제기했다. ChatGPT와 Claude가 두 논문의 인용 중복처럼 구체적인 문제에서도 서로 다를 수 있다는 점은 응용 지식 작업에서 신뢰성 문제가 계속된다는 것을 보여준다 @BlancheMinerva.
GLM과 중국 모델 진전: 여러 게시물이 GLM과 중국 모델 진전에 초점을 맞췄다.
- GLM 팀을 “영웅적”이라고 칭찬 @teortaxesTex
- 최신 세대가 이전 가정을 넘어 Opus급 기대치에 도달했다는 후속 의견 @teortaxesTex
- 향후 프런티어 능력 향상이 순수 사전훈련 규모보다 RL 레시피에 더 달려 있을 수 있다는 추측 @teortaxesTex, @teortaxesTex
Claude 정체성/페르소나 추측: “Claude” 정체성/페르소나의 현저성이 출력에 나타난다는 매우 추측적인 게시물 묶음도 있었다. 이는 확립된 사실이라기보다 밈적 또는 스테가노그래픽 행동으로 프레이밍됐다 @teortaxesTex, @teortaxesTex, @teortaxesTex.

더 넓은 기술과 사회

Tacit Labs 합류: Tacit Labs 합류 발표는 생물학을 AI가 기존 이해를 재조합하는 데 그치지 않고 진짜 새로운 지식을 밝혀내야 할 다음 영역으로 표현했다 @maxisawesome538.
정지 문제 농담: 백악관이 halting problem 해결책을 요구한다는 농담도 있었다. AI 정책 담론이 여전히 깊은 CS 불가능성을 단순해 보이는 요구로 압축하곤 한다는 점을 떠올리게 한다 @the_engi_nerd.
자율주행 스타트업: 자율성 영역에서는 Waymo/Tesla가 이 카테고리를 점점 더 실현 가능하게 보이게 만들고 있음에도 새로운 AV 스타트업 활동이 눈에 띄게 부족하다는 글이 있었다 @gabriberton.
학습과 코딩 의견: 학습, 코딩, 기여에 관한 잡다한 의견 게시물도 있었다.
- 깊은 형식 수학 배경이 없어도 AI에 기여할 수 있다 @gabriberton
- 모델이 생성할 수 없는 토큰을 이해할 수 있는지에 관한 토큰 이해/생성 인터뷰 질문 @gabriberton
- Slack 대안은 “반나절 vibe coding”으로 만들 수 있다는 농담 @gabriberton

AI Reddit Recap

/r/LocalLlama + /r/localLLM

GLM-5.2 오픈 웨이트 프런티어 벤치마크

GLM-5.2 is the first open-weights model to cross 80% on Terminal-Bench and beats every other open model available (Activity: 1569): 이미지는 Terminal-Bench 2.1의 기술 벤치마크 막대 차트로, GLM-5.2가 81.0을 기록해 차트에서 점선 80% 기준을 넘은 첫 오픈 웨이트 모델임을 보여준다. 다만 비공개 모델 Claude Opus 4.8(85.0)과 GPT-5.5(84.0)가 전체적으로는 앞서 있다 (image). 게시물은 GLM-5.2가 다른 오픈 모델과 Gemini 3.1 Pro까지 이겼다고 프레이밍하지만, 한 댓글러는 Terminal-Bench 2.1이 완화된 타임아웃/규칙을 가진 Terminal-Bench 2의 “더 쉬운” 개정판이라 버전 간 점수 비교가 부풀려질 수 있다고 지적했다. 댓글에서는 “오픈 웨이트”가 “로컬” 사용성을 의미하는지 논쟁했다. 한 사용자는 *“다운로드할 수 있으면 로컬 모델”*이라고 주장했고, 다른 사용자는 하드웨어 요구사항 때문에 99%의 사용자에게는 여전히 로컬 실행이 불가능하다고 말했다.
Terminal-Bench 2.1에 관해 한 댓글러는 2.1이 변경된 타임아웃, 완화된 문제 규칙, 더 넓은 하네스 호환성을 가진 더 쉬운 개정판이라 Terminal-Bench 2와 직접 비교할 수 없다고 주장했다. 모델은 일반적으로 2.1에서 2보다 낮은 점수를 받아서는 안 되며, 더 의미 있는 신호는 연구소들이 벤치마크에 최적화하기 전의 초기 Terminal-Bench 3 점수일 것이라고 제안했다.
GLM-5.2를 “로컬 모델”로 봐야 하는지에 대한 기술적 배포 논쟁도 있었다. 한쪽은 Claude나 ChatGPT와 달리 사용자가 가중치를 실행할 수 있으므로 *“다운로드할 수 있으면 로컬 모델”*이라고 주장했고, 다른 쪽은 소비자 시스템에서 초당 토큰 수가 매우 낮은 등 하드웨어/성능 제약 때문에 99%의 사용자에게 사실상 로컬 실행이 불가능하다고 지적했다.
GLM-5.2 is a win for local AI (Activity: 1270): 게시물은 GLM-5.2를 753B 총 파라미터와 토큰당 약 40B 활성 파라미터를 가진 MIT 라이선스 MoE 코딩/추론 모델로 설명하며, 이 모델의 의미는 가정에서 바로 실행 가능하다는 점보다 8B/70B 로컬 모델로의 증류/합성 데이터 미세조정(fine-tuning) 소스라는 데 있다고 주장한다. OP의 배포 추정 표는 메모리를 FP8 기준 약 744–890 GB, 4-bit 기준 476–500 GB, 2-bit 기준 241–280 GB, 1-bit 동적 양자화(quantization) 기준 176–180 GB로 추정하고, 주장된 1M 컨텍스트의 KV cache 오버헤드는 FP16/BF16에서 약 150–200 GB, INT4에서 약 35–50 GB를 더한다고 본다. 이 수치들은 온라인에서 모았고 AI 지원을 받았다는 단서를 명시했다. 댓글러들은 “로컬” 가능성을 두고 논쟁했다. 일부는 512GB Mac, GB10 클러스터, 또는 여러 대의 128GB AMD AI Max급 시스템이라면 low-bit 변형을 그럴듯하게 실행할 수 있다고 봤고, 다른 이들은 하드웨어 요구사항이 점점 도달 불가능해지고 있다고 표현했다. 한 API 사용자는 GLM-5.2를 *“매우, 매우, 매우 강력한 모델”*이라고 부르며 GLM-5.2, MiniMax M3/Mini-V2.5-Pro, 그리고 비슷한 오픈 웨이트/API 접근 가능 모델들이 실질적으로 독점 프런티어 모델과의 격차를 크게 좁혔다고 주장했다. 또 다른 댓글러는 증류된 혹은 네이티브 70B dense 릴리스를 바랐다.
여러 댓글러는 GLM-5.2의 로컬 추론 가능성에 초점을 맞췄다. 실제 구성에는 512GB Mac, GB10형 클러스터, 여러 대의 AMD AI MAX 128GB 머신, 또는 맞춤형 멀티 GPU 서버 같은 초고메모리 시스템이 필요할 가능성이 크다고 봤다. 한 사용자는 <$9,000로 구축한 서버에서 GGUF를 로컬 실행할 수 있을 것이라고 추정했지만, 약 ~7 TPS만 기대해 비싸지만 사용 가능한 홈 배포로 표현했다.
Mac Studio 장기 컨텍스트 성능에 대한 기술적 우려도 제기됐다. 한 댓글러는 모델이 기술적으로 실행될 수는 있어도 50K+ 컨텍스트에서는 낮은 PP/TG 처리량 때문에 “사용 불가”가 된다고 주장했다. 메모리 용량만으로는 충분하지 않고, 프롬프트 처리와 토큰 생성 속도가 대형 컨텍스트 추론의 사용성을 좌우한다는 지적이다.
API 경험이 있는 한 사용자는 GLM-5.2가 MiniMax M3 / Mimi-V2.5-Pro와 함께 오픈 웨이트/오픈에 가까운 대형 모델과 프런티어 독점 모델 간 격차를 크게 좁힌다고 주장했다. 그는 일부 경우 Opus 4.8보다 GLM-5.2를 더 신뢰하겠다고 말했지만, 이 모델들이 여전히 해결하지 못하는 “프런티어 문제”가 남아 있음도 인정했다.
zai-org/GLM-5.2 is here! (Activity: 1178): **Z.ai가 zai-org/GLM-5.2**를 공개했다. 이는 안정적인 1M 토큰 컨텍스트, 더 강한 코딩/에이전트 성능, 조절 가능한 추론 노력, 그리고 SGLang, vLLM, Transformers, KTransformers, Ascend NPU 전반의 서빙 지원을 갖춘 MIT 라이선스 플래그십 장문맥 모델이다. 주요 구현 변화에는 IndexShare sparse-attention 인덱서 재사용이 포함되며, 1M 컨텍스트에서 토큰당 FLOPs를 2.9× 낮춘다고 주장한다. 또한 MTP speculative decoding도 개선돼 최대 20% 더 긴 acceptance를 보인다고 한다. 댓글러들은 보고된 **DeepSWE 점수 46.2**를 강조했는데, 해당 벤치마크에서 Claude Opus 4.6/Sonnet보다 높고 4.7 바로 아래에 위치한다고 봤다. 댓글러들의 주요 관심은 누락됐거나 기대되는 변형과 양자화였으며, GLM-5.2-Flash-32B-A4B를 요청하고 초저비트 0.5Q 릴리스를 농담 반 진담 반으로 기다렸다.
댓글러들은 GLM-5.2가 Hugging Face에서 매우 크다는 점을 강조했다. 연결된 zai-org/GLM-5.2 저장소는 약 **1.51 TB**의 모델 파일을 보여주며, 강한 양자화나 멀티 GPU 구성이 없으면 많은 사용자에게 로컬 추론이 비현실적이다.
한 댓글러는 **자체 보고 DeepSWE 점수 46.2**를 인용하며 GLM-5.2가 Claude Opus 4.6과 Claude Sonnet보다 높고 Opus 4.7 바로 아래라고 주장했다. 독립 검증된다면 강한 소프트웨어 엔지니어링 벤치마크 성능을 시사한다.
더 작거나 배포하기 쉬운 변형, 특히 **GLM-5.2-Flash-32b-a4b**에 대한 관심이 있었다. 이는 전체 1.51 TB 체크포인트보다 실행하기 쉬운 저비용 MoE/Flash식 릴리스 수요를 보여준다.
GLM-5.2 is now 1st on Design Arena — ahead of the now unavailable Claude Fable 5. (Activity: 751): 이미지는 Design Arena 리더보드 스크린샷(image)으로, GLM-5.2가 “Code Categories Arena”에서 Elo 1360으로 #1에 올라 현재 사용 불가능한 Claude Fable 5의 1350을 근소하게 앞서는 모습을 보여준다. 연결된 트윗/게시물 맥락에서는 GLM-5.2가 최근 제거된 Anthropic 모델을 넘어선 것처럼 보인다는 점이 주목할 만하다고 프레이밍하지만, 격차는 작고 더 많은 투표가 쌓이면 리더보드 순위가 바뀔 수 있다. 댓글러들은 조심스러운 관심과 회의를 함께 보였고, 한 명은 *“이 판단을 내리기엔 좀 이르다”*며 순위가 안정될 시간이 필요하다고 말했다. 다른 이들은 강력한 미국 모델이 제한되면 GLM-5.2 같은 오픈 또는 중국 대안이 빠르게 빈자리를 채울 수 있다는 지정학/모델 접근성 함의에 집중했다.
한 댓글러는 GLM-5.2의 Design Arena 순위가 성급할 수 있다고 경고했다. 아레나 점수는 투표가 쌓이며 변할 수 있으므로 *“며칠 두고 안정되는 걸 보라”*는 것이다. 이는 특히 Claude Fable 5처럼 사용할 수 없는 모델과 비교할 때 초기 리더보드 위치를 해석하는 데 유용한 단서다.
한 기술적 우려는 텍스트 전용 모델이 실제 디자인 워크플로에서 어떻게 잘 작동할 수 있느냐였다. 이런 출력은 시각적 검사와 반복 피드백 루프가 필요한 경우가 많기 때문이다. 댓글러는 이런 워크플로에는 생성 디자인을 평가할 OCR 또는 비전 모델이 필요할 수 있다고 제안했고, 이미 선호 디자인 모델이던 Kimi K2.6에 이어 비전 가능 Kimi K2.7이 같은 벤치마크에서 어떻게 수행하는지 물었다.
PSA: unsloth/GLM-5.2-GGUF is uploading (Activity: 491): 한 Reddit 사용자는 Hugging Face 저장소 unsloth/GLM-5.2-GGUF가 새로 생성된 것을 보고 Unsloth가 GLM-5.2용 GGUF 양자화를 준비/업로드 중일 가능성이 크다고 추론했다. 당시 저장소에는 README만 있었다고 한다. 연결된 HF 페이지는 fetch 중 HTTP 429 Too Many Requests 때문에 접근할 수 없었고, Hugging Face는 API 접근에 HF_TOKEN 인증을 권장했다. 상위 댓글은 배포 현실성에 집중했다. 사용자들은 모델을 로컬에 맞추려면 어떤 양자화 수준이 필요할지 물었고, 클라우드 GPU가 필요하다고 농담했으며, 현재 소비자 하드웨어는 편안한 추론에 부족할 수 있음을 암시했다.
댓글러들은 unsloth/GLM-5.2-GGUF의 배포 가능성에 집중했다. 한 명은 apparent 800GB footprint를 언급하며 로컬 실행에 얼마나 공격적인 양자화가 필요한지 물었다. 또 다른 기술적 우려는 매우 긴 컨텍스트에서 KV-cache가 커지는 문제였다. *“1M CTX에 도달하려면 KV Cache 크기를 상상해보라”*는 말처럼, GGUF 가중치가 들어가더라도 1M 컨텍스트 추론에는 모델 가중치 외에도 막대한 추가 메모리가 필요할 수 있다.

로컬 추론 최적화: WebGPU와 AMD ROCm

Gemma 4 E2B running in-browser at 255 tok/s using WebGPU kernels written by Fable 5 (Activity: 503): Google Gemma 4 E2B IT QAT mobile transformers용 WebGPU 브라우저 내 데모가 Hugging Face에 공개됐다. 종료 전 Fable 5로 생성/최적화된 것으로 알려진 최적화 커널을 포함하며 Apple M4 Max에서 약 255 tok/s를 기록했다. 데모/커널은 HF Spaces에 있고, 모델은 google/gemma-4-E2B-it-qat-mobile-transformers에 호스팅돼 있다. 댓글은 UI 오픈소스화에 대한 강한 관심과 Firefox 지원 부재를 언급했는데, 이는 데모가 브라우저 WebGPU 지원/호환성에 의존할 가능성을 시사한다. 한 댓글러는 A10G에서 Gemma E4B를 위한 관련 Hugging Face 최적화 작업을 가리키며, 협업 에이전트 기반 추론 최적화를 통해 *“품질 손실 없음”*으로 약 500 TPS를 달성한다고 주장했다: dashboard.
한 댓글러는 협업 에이전트들이 A10G GPU에서 Gemma E4B 추론을 최대화하고 있으며, *“품질 손실 없음”*을 주장하면서 약 500 TPS에 도달했다는 관련 Hugging Face 최적화 작업을 연결했다: https://gemma-challenge-gemma-dashboard.hf.space/. 이는 게시물의 브라우저 내 WebGPU 결과 255 tok/s와 비교할 유용한 지점이지만, 하드웨어와 런타임 환경은 크게 다르다.
여러 기술 질문은 런타임 이식성과 배포 장단점에 초점을 맞췄다. 한 사용자는 WebGPU/브라우저 호환성 제약 때문으로 보이는 Firefox 지원 부재를 지적했고, 다른 사용자는 WebGPU/Fable 5 구현이 llama.cpp 같은 네이티브 런타임과 어떻게 비교되는지 물었다. 또 다른 이는 약 2 GB의 모델 데이터를 다운로드한 뒤 이를 삭제/비울 방법을 원한다며 실용적인 브라우저 저장공간 문제를 제기했다.
Avoid CUDA monopoly at all costs. AMD is an alternative. (Activity: 458): 게시물은 AMD RX 7800 XT 16GB에서 ROCm 6.4.4로 llama.cpp/llama-server를 실행했다고 보고했다. 컴파일 옵션은 -DGGML_HIP=ON -DGPU_TARGETS=gfx1101 -DrocWMMA_FATTN=ON이며, Qwopus3.6-27B-v2-Q3_K_S.gguf와 Qwen3.6-35B-A3B-UD-IQ3_XXS.gguf를 --flash-attn on, 전체 GPU 오프로딩, 분할 KV-cache 양자화(K=q8_0, V=q4_0)와 함께 최대 131072 컨텍스트로 서빙했다. 작성자는 KV 양자화가 cache 메모리를 약 5.6x 줄여 가중치 + 128K KV cache를 VRAM의 약 96% 안에 유지하고 CPU spill 없이 동작하게 했으며, 약 188W에서 ~210 tok/s prefill과 11–17 tok/s decode를 달성했다고 주장했다. 장문맥 일관성은 YaRN RoPE scaling 덕분이라고 설명하고 더 긴 벤치마크 글을 here에 제공했다.

로컬 코딩 에이전트와 증류 주의점

Be wary of Qwen/Claude distillations - they’re often worse than the base model (Activity: 554): 게시물은 “Qwopus”나 Qwen 기반 Claude 증류처럼 최근 Qwen/Claude distill/finetune 모델이 ~4k–10k 교사 샘플만으로 훈련되는 경우 의미 있는 능력 이전은 어렵고, 대부분 추론/지식 개선보다 스타일만 바꾸며 기본 Qwen 3.6 모델을 악화시킬 수 있다고 주장한다. 이는 ~700k 샘플을 사용한 것으로 알려진 DeepSeek-R1 공식 LLaMA/Qwen 증류와 대조된다. 해당 샘플 규모는 행동과 벤치마크에 영향을 줄 만큼 크다고 본다. 또한 Claude 증류 Qwen 변형이 기본 Qwen보다 환각을 보이고 더 느렸다는 외부 테스트를 인용했다: “Claude distillation doesn’t transfer library knowledge”. 댓글러들은 대체로 동의했고, 한 명은 능력을 개선하는 미세조정에는 이제 몇천 샘플이 아니라 >100k개의 신중히 선별된 예제와 GRPO 같은 회복 방법이 일반적으로 필요하다고 주장했다. 또 다른 댓글러는 낮은 N, pass@5만 제공, 좁은 웹 개발 벤치마크, 공개되지 않은 증류처럼 약한 평가를 가진 모델 카드를 경계해야 한다고 제안했지만, 그 댓글 상당 부분은 증거라기보다 휴리스틱/의견이었다.
여러 댓글러는 Qwen/Claude 출력에서 나온 소규모 지도 “증류”가 기본 모델을 개선할 가능성이 낮다고 봤다. 4k 샘플은 “사실상 아무것도 아니다”라고 표현됐고, 한 댓글러는 의미 있는 개선 미세조정에는 몇천 prompt/response 쌍이 아니라 100k+개의 신중히 선별된 예제와 GRPO 같은 회복 방법이 필요하다고 말했다.
기술적 반론은 대부분의 API 기반 증류가 중요한 훈련 신호를 결여한다는 점이었다. 사용자는 보통 작은 top-N/top-1 출력을 넘어 전체 logits를 얻지 못하고, Anthropic은 전체 chain-of-thought가 아니라 요약만 노출한다. 그래서 많은 릴리스는 진정한 지식 증류라기보다 부분 응답 지도 미세조정에 가까우며, 교사 모델의 상당한 정보를 잃는다.
한 댓글러는 응용 미세조정 datapoint를 제시했다. 집중된 GDScript 도메인 모델에 18k 예제를 쓰고, 문서 사전훈련과 개인 코드를 포함했음에도 모델은 원하는 출력을 안정적으로 만들지 못했다. 결론은 미세조정이 도메인 행동/수직 전문화를 개선할 수는 있지만 “지능을 추가하지는 않는다”는 것이었다.
Headless screenshot loops let a local 30B agent finish a raytraced FPS demo in pure C (Activity: 277): OP는 headless instrumentation requirement를 추가하자 Claude Code on Opus 4.8와 로컬 Qwen3.6 27B 에이전트가 작은 순수 C, 표준 라이브러리 전용 raytraced FPS demo를 반복 디버깅해 완성할 수 있었다고 보고했다. 요구사항은 키보드/마우스 입력 주입과 선택 프레임의 결정적 스크린샷 캡처였다. 핵심 메커니즘은 자기 주도 시각 피드백이었다. 에이전트는 로켓 충돌 같은 이벤트 주변에 캡처 타이밍을 맞추고, 렌더링된 파티클/파편을 검사하고, C 코드를 패치하고, 바이너리를 다시 실행했다. 사실상 재귀적 스크린샷 기반 디버깅 루프를 만든 것이다. OP는 이를 모델 품질 벤치마크가 아니라 프롬프팅/도구화 결과로 프레이밍했고, 로컬 에이전트가 자신의 OSS 프로젝트 codehamr라고 밝혔다. 댓글러들은 대체로 로컬 Qwen 결과에 감탄하고 C/데모신 시대 개발을 추억했지만, 한 댓글러는 이 과제가 현재 모델에는 그다지 어렵지 않을 수 있다고 주장했다.
한 댓글러는 맞춤 Python Log 함수를 중심으로 만든 에이전트 하네스를 설명했다. 이 함수는 print와 비슷하지만 모든 출력을 공유 로그 파일로 리디렉션할 수 있다. 모델은 로그 tail을 확인하고 내부 로깅을 추가하며 그 관찰을 반복 디버깅에 쓰도록 명시적으로 지시받는다. 이렇게 모델들이 “기본적으로는 하지 않는” observe-debug-fix 루프를 닫는다.
한 사용자는 RTX 4090에서 설정을 실행했다고 보고하며 명확한 속도 향상을 언급했고, q4_k_m 양자화를 로컬 추론의 선호 품질/성능 절충점으로 꼽았다.

Less Technical AI Subreddits

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

Claude Code 보안과 워크플로 교훈

Claude Opus caught malware hidden in my repo, then reverse engineered the whole thing (Activity: 1207): 한 저장소 소유자는 Claude Code running Opus가 git merge 중 next.config.js의 module.exports 뒤에 추가된 난독화 블록을 발견하고 중단했으며, CI/build 실행 전에 이를 정적으로 EtherHiding식 로더로 식별했다고 말했다. 설명된 체인은 감염된 계약자 머신을 통한 git credential 탈취/자가 전파, 위조 커밋 메타데이터, api.trongrid.io, Aptos, BSC RPC를 통한 블록체인 dead drop, XOR 디코딩 인메모리 단계, 그리고 포트 80/443에서 198.105.127.210로 향하는 infostealer C2를 사용한다. 나열된 IOC에는 dropper SHA-256 e27abe7e810c79d71e8c1681ccd010d7ddbda6a9a34bf1124ba392a36ba9b476, global.i / global._V = "8-4827" 같은 globals, 여러 TRON/Aptos/BSC transaction pointer가 포함됐다. 권장 점검은 next.config.js, postcss.config.js 및 기타 build-time config의 추가 코드를 감사하고, CI egress가 blockchain RPC endpoint로 나가는지 모니터링하고, 빌드에서 접근 가능한 모든 secret을 교체하고, push한 워크스테이션을 감염된 것으로 간주하는 것이다. 실질적 댓글 흐름은 핵심 보안 교훈이 단순히 “Claude가 잡았다”가 아니라 next.config.js 같은 framework config가 CI에서 실행되는 privileged build-time code이며 엄격히 통제, 검토, 샌드박스 처리돼야 한다는 점을 강조했다. 다른 상위 댓글은 대체로 Next.js / 모델 제한에 대한 농담이나 빗나간 비판이었다.
한 댓글러는 핵심 보안 실패가 모델 탐지가 아니라 커밋된 next.config.js가 모든 build/CI 실행 때 실행된다는 점이라고 강조했다: “one committed config … runs on every build + CI”. 기술적 교훈은 악성 config가 한 번만 저장소에 들어와도 파이프라인을 손상시킬 수 있으므로, build time에 어떤 코드가 실행될 수 있는지 제한해야 한다는 것이다.
또 다른 댓글러는 저장소 제어가 첫 실패 지점이라고 봤다. 누군가 force-push를 저장소에 할 수 있게 허용하면 정상 리뷰와 감사 가능성이 우회된다. 그는 보호 브랜치 설정, 필수 리뷰, 보호 브랜치에서 force push 비활성화를 통해 이를 막아야 한다고 주장했다.
한 댓글러는 모든 저장소에서 Hades/Miasma식 supply-chain 침해를 스캔하라고 권했다. 이런 침해는 감염된 개발자 머신뿐 아니라 흔히 쓰이는 라이브러리를 통해 전파될 수 있기 때문이다. 또한 이 문제가 Node 프로젝트에만 한정되지 않으며 사용하는 모든 언어 생태계를 확인해야 한다고 경고했다.
Pro Tip - Reset your usage limits on your schedule (Activity: 1342): 게시물은 Claude Code 사용량 창을 맞추는 스케줄링 우회법을 설명한다. Haiku를 사용하는 매일의 Claude Code Routine을 만들고 원하는 reset 시간 약 5시간 전에 "hello" 같은 사소한 프롬프트를 보내 rolling session window를 더 일찍 시작하게 하는 방식이다. 주장된 효과는 9:00에 일을 시작하는 사용자가 기존 활성 세션이 새 창을 막지 않는다는 가정하에 첫 reset을 14:00+가 아니라 12:30쯤으로 앞당길 수 있다는 것이다. Anthropic의 routines 기능 문서는 here에 있다. 댓글러들은 대체로 이 전략이 Pro/5x limit에 자주 걸리는 사용자에게 주로 유용하다는 데 동의했다. 예약 refresh 직전에 더 높은 성능 모델이나 high-token plugin을 태울 수 있기 때문이다. 한 댓글러는 token availability를 극대화하기 위해 5시간마다 cron식 refresh를 사용한다고 보고했지만, OP의 더 타이트한 타이밍이 오전 작업 창을 더 잘 보존할 수 있다고도 언급했다.
사용자들은 일부러 실제 작업 시간보다 먼저 세션을 시작해 Claude의 rolling 5-hour usage window를 활용한다고 설명했다. 예를 들어 7AM에 usage를 트리거하면 다음 reset이 12PM으로 이동하므로, 10AM standup 이후 heavy work를 시작하면 limit 소진 후 3PM까지 기다리는 대신 정오까지만 기다리면 된다.
한 댓글러는 token availability를 극대화하기 위해 5 hours마다 usage window를 refresh하는 cron job을 사용한다고 보고했다. 그런 다음 reset 전에 남은 quota를 가장 고성능 모델, Claude Design, 기타 high-token tool에 의도적으로 쓴다고 한다. 그는 “caveman mode”와 “rust token killer”를 token-reduction technique으로도 언급했지만, 구현 세부사항이나 벤치마크는 제공하지 않았다.
또 다른 사용자는 cowork의 scheduled tasks를 7AM, 12PM, 5PM에 설정해 Claude 사용 reset을 기상/근무 시간에 맞췄다. 사실상 하루 동안 여러 full session을 만든 것이다. 그는 Claude 자체가 이 자동화에 반대하며 대신 token waste를 줄이라고 권했다고 말했는데, 이는 quota-window optimization과 prompt/token efficiency practice 사이의 긴장을 보여준다.
the gap between Claude Code power users and us chat-only people keeps getting wider and i don’t think that’s great for the community (Activity: 2348): Pro chat-only Claude 사용자는 subreddit의 기술적 초점이 Claude Code 워크플로(CLAUDE.md, MCP, subagents, terminal usage)로 크게 이동해, 글쓰기, 사고, 학습, 계획 같은 비코딩 사용 사례가 큰 사용자층일 가능성이 있음에도 과소대표되는 느낌이라고 주장했다. 상위 답글은 Claude Code가 프로그래밍 없이도 일반 로컬 작업 에이전트로 쓰일 수 있다고 제안했다. 예를 들어 터미널에서 대화하며 로컬 데이터를 Excel/PDF 출력으로 변환할 수 있고, 사용량 limit이 늘어난 중간 옵션으로 Cowork를 언급했다. 댓글러들은 대체로 코딩이 커뮤니티를 지배한다는 데 동의했다. 한 명은 게시물의 95%가 코딩 관련이라고 추정했다. 하지만 해법에는 차이가 있었다. 일부는 chat-only 사용자가 더 넓은 자동화를 위해 Claude Code식 도구를 받아들이라고 권했고, 다른 이들은 사람들이 어떤 구체적 비코딩 워크플로를 논의하고 싶은지 물었다.
여러 댓글러는 Claude Code의 장점이 코딩 특화가 아니라 CLI/도구 환경에서 온다고 주장했다. 로컬 파일 접근, 명령 실행, 로컬 데이터를 포맷된 Excel 파일로 바꾸고 다듬어진 PDF로 내보내는 구체 작업 수행 능력 때문이다. 기술적 구분은 Claude Code가 파일시스템/도구 접근을 가진 에이전트처럼 행동하는 반면, 브라우저 chat은 더 제한된 대화 인터페이스로 남아 있다는 점이었다.
반복된 기술적 불만은 Claude의 가장 강력한 워크플로에는 상당한 설정이 필요하다는 것이었다. MCP 서버, 패키지 설치, 수동 JSON 설정이 필요하기 때문이다. 한 댓글러는 비개발자에게 “대체 MCP server가 뭔지” 설치하는 과정이 원클릭이어야 한다고 주장했다. 현재의 마찰이 일반 사용자의 고급 Claude 워크플로 접근을 막기 때문이다.
한 파워유저 사례는 CLAUDE.md, MCP, subagents, terminal workflows를 소프트웨어 개발 기능이 아니라 범용 지식 작업 인프라로 설명했다. 투자 워크플로에서는 각 deal마다 자체 CLAUDE.md를 둘 수 있고, MCP 연결 데이터 소스, due-diligence report를 처리하는 subagent, financial model과 slide deck을 만드는 문서화된 워크플로가 있을 수 있다.

Anthropic Fable 접근과 정책 압박

They’re demanding Fable to somehow be 100% jailbreak-proof. It’s so fucking over. (Activity: 1375): 이미지는 WIRED 기사 미리보기 스크린샷으로, Trump administration officials want Anthropic’s “Fable 5” blocked from all jailbreaks before release라고 주장하며, 보안 전문가들은 현재 LLM에서 100% jailbreak resistance는 기술적으로 달성할 수 없다고 말한다고 한다. 기술적 문제는 임의의 prompt, tool, context에 노출되는 생성 모델에 대해 완전한 안전성을 증명하는 것이 불가능하다는 점이다. 게시물은 이를 OS나 자동차가 수학적으로 해를 끼칠 수 없도록 요구하는 것과 같은 비현실적 보안 요구로 프레이밍했다. Image 댓글러들은 대체로 이 요구를 터무니없거나 정치적 동기가 있다고 봤고, 자동차가 부상을 전혀 일으키지 않아야 한다거나 운영체제가 해킹 불가능해야 한다는 비유를 들었다. 한 댓글러는 이 요구가 정부 접근은 보존하면서 공개 릴리스를 제한하려는 의도일 수 있다고 추측했다.
댓글러들은 Fable이 100% jailbreak-proof여야 한다는 요구가 기술적으로 OS나 범용 컴퓨팅 플랫폼이 해킹 불가능하다는 것을 증명하라는 요구와 같다고 주장했다. 공격 표면과 prompt/input space가 사실상 열려 있기 때문이다. 한 지점은 가능한 모든 jailbreak에 대해 *“부정은 증명할 수 없다”*는 형식 보안 문제를 강조하며, 절대적 jailbreak 면역성은 공학 요구사항이 아니라 비현실적인 인증 목표라고 봤다.
Anthropic CEO Dario Amodei joins top AI CEOs meeting with world leaders at G7 summit (Activity: 1812): Anthropic CEO Dario Amodei와 OpenAI CEO Sam Altman이 세계 정상들과 함께 G7 working lunch on AI에 참석한 것으로 알려졌다. 이는 U.S. restriction limiting allied access to Anthropic’s most advanced models라는 지정학적 긴장 속에서 나왔다. 사용 가능한 Reddit/video source는 Reddit이 403 Forbidden을 반환해 독립적으로 확인할 수 없었으므로, 정책 범위, 영향을 받는 모델 tier, export-control mechanism에 관한 추가 기술 세부사항은 없다. 상위 댓글은 대체로 비기술적 농담/반응이었고, 유일하게 실질적인 질문은 왜 Salesforce CEO Marc Benioff가 AI 리더십 회의에 있었느냐였다.

AI Discord Recap

AI Discords

Discord 접근 종료: 유감스럽게도 Discord가 오늘 접근을 차단했다. 이 형식으로는 다시 가져오지 않을 예정이지만, 새 AINews를 곧 출시할 예정이다. 여기까지 읽어줘서 고맙고, 좋은 여정이었다.

오늘의 요약