Thinking Machines가 상호작용 모델 공개

헤드라인: Thinking Machines가 상호작용 모델 공개

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

Thinking Machines는 실시간 상호작용을 처음부터 전제로 학습한 “interaction models”를 공개했다. 핵심은 기존 턴 기반 LLM 위에 음성, 도구 사용, 시각 입력을 덧붙이는 방식이 아니라, 모델 자체가 듣고 말하고 보고 검색하고 반응하는 과정을 동시에 처리하도록 만드는 것이다. 이 접근은 멀티모달 AI의 인터페이스 가정을 바꾸는 움직임으로, 시각적 선제 대응, 중단 처리, 동시 발화, 백그라운드 도구 사용을 주요 능력으로 제시했다.

AI Twitter Recap

Thinking Machines의 네이티브 상호작용 모델과 턴 기반 AI 이후의 전환

일급 모델 능력으로서의 풀듀플렉스 멀티모달 상호작용: 이날 가장 뚜렷한 기술적 주제는 Thinking Machines’ preview of “interaction models”였다. 이는 턴 기반 LLM 위에 음성, 턴테이킹, 도구 사용을 덧씌우는 것이 아니라 실시간 상호작용을 위해 처음부터 학습된 모델로 설명됐다. 함께 공개된 technical post와 @johnschulman2, @soumithchintala, @cHHillee의 팀 코멘터리는 이를 인간↔AI 대역폭 문제로 규정했다. 모델은 듣고, 말하고, 보고, 생각하고, 검색하고, 반응하는 일을 동시에 할 수 있어야 한다는 것이다. 데모는 명시적인 “이제 생각 중 / 이제 검색 중” 경계 없이 연속 시간 인식, 중단 처리, 동시 발화, 시각적 선제 대응, 백그라운드 도구 사용을 강조했다. 팀원들은 또한 타입 시그니처가 사실상 연속적인 audio+video+text → audio+text가 되면, 이전에는 특수 목적 시스템이 필요했던 많은 작업이 제로샷으로 가능해진다고 강조했다 (@johnschulman2).
기술적으로 중요한 이유: 여러 반응은 같은 지점으로 수렴했다. 이것은 “또 다른 챗봇 데모”가 아니라 인터페이스 가정의 변화라는 것이다. @liliyu_lili는 “구부정해지기 시작하면 알려줘”, “푸시업 횟수를 세줘” 같은 시각적 선제 대응이 현재 시스템에 빠진 기본 요소라고 지적했다. @rown은 이를 시각적으로 선제 대응하는 첫 범용 video+speech 모델이라고 불렀고, @kimmonismus와 @giffmana는 원시 벤치마크 주장보다 네이티브 상호작용성이 더 깊은 혁신이라고 강조했다. 이 출시는 @swyx가 언급했듯 “realtime” 멀티모달 시스템의 기준도 암묵적으로 높인다. @eliebakouch를 통해 드러난 구현 세부사항 하나는 이 스택이 SGLang을 사용한다는 점이다.

OpenAI의 엔터프라이즈 및 보안 추진: Deployment Company와 Daybreak

OpenAI가 서비스와 배포 레이어로 내려가고 있다: OpenAI는 기업이 프런티어 모델을 실제 워크플로에 배포하도록 돕는 과반 지분 보유 조직인 OpenAI Deployment Company를 발표했다. 핵심 운영 세부사항은 Tomoro 인수를 통해 들어오는 150명의 Forward Deployed Engineers 및 Deployment Specialists이며, @gdb는 19개 파트너의 초기 투자 $4B를 언급했다. 여러 관찰자는 이를 OpenAI가 Palantir/Microsoft식 현장 엔지니어링 모델을 채택하는 것으로 읽었다. @kimmonismus는 OpenAI가 AI 경제의 배포 레이어를 소유하려 한다고 주장했고, @matvelloso는 이를 기술 인력을 고객 운영 가까이에 배치해 엔터프라이즈에서 성공했던 역사적 패턴과 연결했다.
Daybreak: 보안 특화 모델 배포, 워크플로, 신뢰 계층: OpenAI는 방어적 사이버 운영과 지속적인 소프트웨어 보안을 위한 포괄적 노력인 Daybreak도 출시했다. @sama는 이를 빠르게 향상되는 AI 사이버 역량에 대한 실용적 대응으로 포지셔닝했다. @TheRundownAI가 요약한 제품 제안은 GPT-5.5, Codex, 저장소 위협 모델링, 취약점 발견, 패치 생성, 대응 자동화를 결합하며, Trusted Access for Cyber와 더 특화된 GPT-5.5-Cyber를 포함한 차등 접근 계층을 둔다. 이는 Anthropic의 더 제한적인 사이버 입장과 대비되며, 그 긴장은 @kimmonismus가 포착했다. 보안 에이전트 시스템을 만드는 팀에는 @lukOlejnik의 별도 경고도 관련이 있다. **“Your LLM is not a security boundary”**라는 말처럼, Microsoft Semantic Kernel은 모델 자체가 실패해서가 아니라 프레임워크가 모델 출력을 과신했기 때문에 프롬프트 인젝션이 호스트 수준 RCE로 바뀔 수 있었다고 전해졌다.

에이전트 하네스, 로컬 우선 툴링, 제어 표면

더 나은 에이전트 제어 플레인이 제품 카테고리가 되고 있다: 반복되는 불만은 유용한 에이전트에는 자율성이 필요하지만, 엔지니어는 여전히 되돌릴 수 있고 검사 가능한 제어를 원한다는 점이다. @itsclelia는 에이전트 산출물을 로컬/원격, S3 기반으로 저장하는 Rust CLI인 aggit으로 이 문제를 다뤘다. 이는 메인 Git 히스토리 밖에서 stash/branch/restore 의미론을 가능하게 한다. 같은 흐름에서 @_catwu는 여러 Claude Code 에이전트를 관리하는 새로운 claude agents 터미널 제어 플레인을 소개했고, @cursor_ai는 Cursor를 Microsoft Teams로 밀어 넣어 에이전트가 전체 스레드를 읽고 PR을 열도록 했다. 이는 모두 “에이전트 오케스트레이션”이 프롬프트 트릭만이 아니라 구체적인 UX 패턴으로 수렴하고 있다는 신호다.
Deep Agents / Hermes / 로컬 에이전트가 빠르게 성숙 중: @masondrxy는 Deep Agents CLI가 컨텍스트 손실 없이 대화 중간에 기반 모델 제공자를 핫스왑할 수 있다고 언급했다. 이는 많은 에이전트 스택이 아직 놓치고 있는 비단순 시스템 능력이다. LangChain도 제공자/모델별 튜닝을 위한 harness profiles를 강조했으며 (tweet), 같은 작성자의 별도 가격 분석은 DeepSeek V4 Flash가 대량 에이전트 워크로드에서 GPT/Gemini 플래시급 옵션보다 극적으로 저렴할 수 있다고 주장했다 (tweet). 로컬 측면에서는 Hugging Face가 Hermes Agent support in local apps plus native trace visualization를 추가했고, @Teknium은 Hermes Agent와 CUA를 통해 어떤 모델로든 computer use를 제공하는 것을 예고하며, 프런티어 API뿐 아니라 로컬/오픈 모델도 명시적으로 겨냥했다. @onusoz가 Hugging Face에 합류해 OpenClaw 및 관련 오픈 하네스에서 로컬 모델을 개선하는 것도 로컬 에이전트 사용성이 이제 전략적 인프라라는 강한 신호다.
도구를 둘러싼 설계 논지의 등장: @threepointone는 에이전트가 점근적으로 단 두 가지 원시 도구, 즉 search와 execute만 원하게 될 수 있다고 주장했다. 이는 계속 늘어나는 정적 도구 메뉴보다 역동적인 의미 기반 능력 발견을 중시하는 관점이다. 이는 거대한 단일 프롬프트 대신 설정 가능한 하네스로 이동하는 더 넓은 흐름을 보완한다.

벤치마크, 효율성, 오픈 모델 경제학

코딩 에이전트 벤치마크가 마침내 하네스+모델 조합을 측정 중: Artificial Analysis launched a Coding Agent Index는 SWE-Bench-Pro-Hard-AA, Terminal-Bench v2, SWE-Atlas-QnA를 포괄하며, 모델만이 아니라 모델+하네스 조합을 비교했다. 주요 결과는 Cursor CLI의 Opus 4.7이 61점을 기록했고, Codex/Claude Code의 GPT-5.5가 근접했다는 것이다. 상위 오픈웨이트 설정에는 Claude Code의 GLM-5.1, Kimi K2.6, DeepSeek V4 Pro가 포함됐으며, 여전히 경쟁력은 있지만 의미 있게 뒤처졌다. 이 벤치마크는 작업당 비용(>30x), 토큰 사용량(>3x), 캐시 적중률(80-96%), 작업당 시간(>7x)의 큰 차이도 드러냈다. 이 벤치마크는 OpenHands의 업데이트된 소프트웨어 엔지니어링 벤치마크 발표 (tweet)와, 사무, 금융, 터미널, 웹 작업 전반에서 더 에이전틱한 작업 구성을 다룬 Claw-Eval로 보완됐다. 여기서는 MiMo-V2.5-Pro led and DeepSeek V4 Flash looked unusually efficient for its size.
TurboQuant 회의론이 커지고 있다: 여러 게시물은 최근 인기를 얻은 양자화(quantization)/서빙 기법을 더 냉정하게 보는 시각을 가리켰다. @_EldarKurtic는 TurboQuant에 대한 최초의 포괄적 연구라고 설명한 내용을 제시하며 정확도, 지연시간, 처리량을 다뤘다. @vllm_project는 Red Hat / vLLM 조사를 출발점으로 연결했고, @jbhuang0604는 요지를 “실제로는 잘 작동하지 않는다”고 직설적으로 요약했다. 이는 독립 재현이 중요한 인프라 주장에 정확히 해당한다.
로컬/오픈 모델은 하드웨어 한계보다 빠르게 계속 개선 중: @ClementDelangue는 여기서 가장 강한 고수준 주장을 했다. 같은 최고급 MacBook Pro 메모리 한계에서 “실제로 실행 가능한 가장 똑똑한 오픈웨이트 모델”이 Llama 3 70B 시대 능력에서 DeepSeek V4 Flash mixed-Q2 GGUF 시대 능력으로 약 24개월 동안 4.7x 개선됐으며, 이는 10.7개월마다 두 배가 되는 속도로 Moore’s Law보다 빠르다는 것이다. 이를 뒷받침하는 데이터 포인트로는 GGUF 업로드의 빠른 증가에 대한 @victormustar의 언급과 Qwen 3.6, Gemma 4, DeepSeek 변형들이 이제 사소하지 않은 에이전트 작업에 로컬로 쓸 만하다는 반복된 커뮤니티 관찰이 있었다.

연구 하이라이트: MoE 모듈성, Diffusion/Byte 모델, 에이전트 동역학

아키텍처와 평가: AllenAI의 EMO는 @TheTuringPost에 의해 더 모듈적인 Mixture-of-Experts 설계로 소개됐다. 문서 수준 라우팅이 공유 전문가 풀을 유도한다는 점이 특징이다. 특히 25%의 전문가만 유지해도 성능 손실이 **~1%**에 그쳤다고 하며, 유사한 가지치기 조건에서 표준 MoE가 10-15% 저하되는 것과 대비된다 (follow-up). 생성 평가에서는 @qberthet가 FID를 대체할 더 빠르고 샘플 효율적인 지표라고 주장되는 **MIND (Monge Inception Distance)**를 소개했다.
언어를 위한 Diffusion과 바이트 수준 모델링: 여러 논문이 비-AR 언어 모델링을 밀고 나갔다. @LucaAmb는 연속 비트스트림 diffusion이 그들의 평가 설정에서 자기회귀 모델에 거의 근접했다고 보고했다. @JulieKallini는 병렬 바이트 디코딩에 diffusion을 사용해 바이트 수준 LM이 추론(inference)에 덜 묶이도록 만드는 Fast BLT를 소개했다. @sriniiyer88는 이를 블록 바이트-diffusion과 self-speculative decoding의 결합으로 설명했다. 관련해 @LiangZheng_06는 후학습(post-training)에서 diffusion 모델의 유용한 속성을 언급했다. 샘플링이 미분 가능하기 때문에, 보상 그래디언트가 원칙적으로 표준 LLM 설정보다 파라미터로 더 직접 흐를 수 있다는 것이다.
긴 지평에서의 에이전트 행동: 두 가지 강한 실증적 흐름이 나타났다. 첫째, “The Memory Curse”는 긴 히스토리가 다중 라운드 사회적 딜레마에서 협력을 저하시킨다고 주장한다. 모델이 더 히스토리 추종적이고 위험 최소화적이 되며, 명시적 CoT가 때로 문제를 증폭한다는 것이다. 둘째, PwC work summarized by @dair_ai는 명확화의 가치가 시간 의존성이 매우 크다고 주장한다. 목표 명확화는 실행의 약 10% 이후 대부분의 가치를 잃는 반면, 입력 명확화는 더 오래 유용하다는 것이다. 두 결과를 함께 보면 장기 지평 에이전트 품질은 원시 모델 IQ만큼이나 메모리/제어 정책에 의해 제약된다.
스케일링과 자기 개선: @WilliamBarrHeld가 요약한 Marin의 Delphi 스케일링 연구는 작은 사전학습에서 25B / 600B token 실행으로 외삽할 때 0.2% 예측 오차를 주장한다. 별도로 @omarsar0는 LLM이 테스트 타임 스케일링 컨트롤러 공간을 스스로 탐색하는 AutoTTS를 강조했다. 이는 약 $39.9의 발견 비용으로 사람이 설계한 전략을 이겼다고 보고됐다.

Top tweets (by engagement)

OpenAI의 엔터프라이즈/서비스 움직임: OpenAI launches the Deployment Company와 Tomoro acquisition / 150 FDEs.
OpenAI의 보안 제품화: Daybreak announcement와 @sama’s framing.
Thinking Machines의 interaction models: Mira Murati’s launch tweet와 technical preview thread.
Artificial Analysis Coding Agent Index: benchmark launch and topline findings.
에이전트 툴링 / 개발자 워크플로: Hermes Agent computer use with any model, Cursor in Microsoft Teams, Codex OpenAI Developers plugin.

AI Reddit Recap

/r/LocalLlama + /r/localLLM Recap

MTP on Unsloth (Activity: 620): 이미지 (link)는 Unsloth의 Hugging Face 프로필이 새로 공개된 MTP 보존 GGUF 빌드인 unsloth/Qwen3.6-27B-GGUF-MTP와 unsloth/Qwen3.6-35B-A3B-GGUF-MTP를 나열한 모습을 보여준다. 이 게시물의 기술적 의미는 이 GGUF들이 MTP / next-token prediction layers를 보존하지만, 사용자는 표준 llama.cpp 지원에 의존하는 대신 특정 llama.cpp MTP PR을 빌드해야 한다는 점이다. 한 댓글 작성자는 27B GGUF에서 GGML_ASSERT(hparams.nextn_predict_layers > 0 && "QWEN35_MTP requires nextn_predict_layers > 0") 런타임/assertion 실패를 보고했으며, 이는 메타데이터 파싱, 모델 변환, 또는 PR 호환성 문제가 아직 해결되지 않았을 수 있음을 시사한다. 댓글은 업스트림 llama.cpp MTP 지원에 대한 기대를 반영하며, 사용자들은 GitHub 저장소를 반복해서 확인하고 MTP가 이제 “out of the box”로 지원되는지 묻고 있다.
MTP on Unsloth 기술 메모: 새 27B GGUF 모델을 컴파일하던 사용자가 qwen35_mtp.cpp에서 런타임 assert인 GGML_ASSERT(hparams.nextn_predict_layers > 0 && "QWEN35_MTP requires nextn_predict_layers > 0")에 부딪혔다. 이는 GGUF/모델 메타데이터 또는 변환 경로에 Qwen3.5 MTP speculative/next-token prediction layers에 필요한 nextn_predict_layers가 빠졌을 수 있음을 시사한다.
MTP GGUF 지원 논의: 한 기술 스레드는 GGUF의 MTP 지원이 로컬 추론(inference), 특히 댓글 작성자들이 향상된 컨텍스트 길이 처리와 연관 짓는 35B A3B 변형에 중요하다고 언급했다. 또 다른 댓글 작성자는 이것이 llama.cpp가 이제 MTP를 “out of the box”로 지원한다는 뜻인지 물었고, 이는 지원이 병합/안정화된 것인지 아니면 PR 또는 포크에서만 가능한 것인지 불확실함을 암시한다.
ik_llama 성능 주장: 한 댓글 작성자는 ik_llama MTP가 현재 llama.cpp PR보다 빠르다고 주장하며, “turboquants”와 비슷하다고 설명한 Hadamard 기반 양자화(quantization)를 지원한다고 덧붙였다. 이는 로컬 MTP 추론 백엔드를 비교하는 사용자에게 관련 있을 수 있는 구현/성능 차이다.
The Qwen 3.6 35B A3B hype is real!!! (Activity: 586): 이 게시물은 Qwen 3.6 35B A3B, Qwen 3.6 27B, Gemma 4 26B A4B, Nemotron 3 Nano 같은 여러 소형/로컬 장문 컨텍스트 오픈웨이트 모델에 학술 논문과 해당 연구 코드를 함께 주고, 구현 세부사항을 논문에 다시 매핑하도록 한 정성적 코드 이해 평가를 보고했다. 작성자의 상세 메모는 GitHub README에 있다. 핵심 주장은 gated delta net, hybrid Mamba2, sliding-window attention 같은 최신 장문 컨텍스트 메커니즘이 Devstral Small 2 같은 이전 소형 로컬 모델보다 실용적 코드 이해를 실질적으로 개선하며, Qwen 3.6 35B A3B가 가장 강하다고 판단됐다는 것이다. 작성자는 32 GB RAM에서 원하는 긴 컨텍스트로 Devstral Small 2를 맞출 수 없었다. 댓글 작성자들은 실용적 트레이드오프를 지적했다. 한 사용자는 빠른 코드 수정에는 Gemma 26B를, 긴 컨텍스트 리팩터링에는 Qwen 35B를 쓴다고 했으며, Qwen 35B는 thinking mode에서 “말이 길어지지만” q4에서 약 20 GB에 맞고 Gemma 26B는 약 15 GB를 사용해 둘 다 RAM에 올려둘 수 있다고 말했다. 또 다른 댓글 작성자는 평가 글이 추론 설정을 명시하지 않아 재현성과 비교가 어렵다고 비판했다.
Qwen/Gemma 배포 세부사항: 사용자들은 Qwen 3.6 35B A3B와 Gemma 26B의 실전 배포 정보를 공유했다. q4에서 Qwen 35B는 약 20 GB, Gemma 26B는 약 15 GB라 둘 다 동시에 RAM에 상주시킬 수 있다. 한 워크플로는 빠른 코드 수정과 채팅에 Gemma 26B thinking mode를 사용하고, 긴 컨텍스트 리팩터링에는 최종 출력 전에 긴 추론을 내놓는 경향이 있는 Qwen 35B thinking mode를 남겨둔다.
로컬 코딩 워크플로 경험: 한 코딩 워크플로 논의에서는 더 강한 클라우드/에이전트 모델로 프로젝트를 초기화한 뒤 Qwen 27B로 계속 작업해 100k+ 라인 코드베이스에서 성공했다고 언급했다. 댓글 작성자는 자신의 작업에서 Qwen 27B가 실전상 DeepSeek V4와 비슷하다고 봤지만, 때때로 루프에 빠져 수동 중단과 계속하라는 프롬프트가 필요했다고 했다. 또한 이 로컬 코딩 용도에서는 Gemini Flash보다 높게 평가했다.
추론 설정 민감도: 여러 댓글은 빠졌거나 민감한 추론 설정 세부사항을 강조했다. 한 사용자는 어떤 런타임 설정을 썼는지 물었고, 다른 사용자는 Qwen 27B에는 올바른 temperature/샘플링 파라미터가 필요하며 KV 캐시나 모델을 너무 공격적으로 양자화하지 말라고 경고했다. 이는 특히 더 작은 로컬 코딩 모델에서 샘플링과 양자화 선택에 따라 체감 모델 품질이 크게 달라질 수 있음을 시사한다.
Opinion: Local LLMs are 12-24 months from taking over. The shift already started. (Activity: 1108): 이 글은 로컬 코딩/에이전트 LLM이 많은 유료 호스팅 워크플로를 대체하기까지 12-24 months 안에 있다고 주장한다. 근거로는 64GB 통합 RAM의 MacBook Pro M2 Max에서 Qwen3.6-35B가 약 27 tok/s로 실행되고, 랜딩 페이지 생성이 Opus의 3-4 min 대비 8-9 min 걸린다는 점을 든다. 작성자는 프런트엔드/백엔드 기능 작업과 백엔드 race-condition 수정에서 유용하지만 완전히 프로덕션 검증된 것은 아닌 결과를 보고하며, 약 75% 원샷 성공률, 지연시간, 256K에서도 빠른 컨텍스트 소진, 작업 품질 변동성을 남은 격차로 지적했다. 핵심적인 해금 요소로는 에이전틱 워크플로를 위한 신뢰성 있는 tool calling을 들었다. 글은 GitHub Copilot의 consumption-based pricing 전환을 포함한 호스팅 AI 비용 상승을 배경으로, Claude/Opus/Sonnet을 당장 대체하기보다 로컬 모델을 병렬로 실행하라고 권한다. 상위 댓글은 대체로 오픈웨이트/로컬 흐름에 호의적이었고, 한 사용자는 자신이 이미 RTX 5090에서 “fully local”이며 “never going back”이라고 말했다. 한 댓글 작성자는 Qwen 도구 호출 신뢰성에 대한 표현에 반응하며 글 자체가 AI 작성인지 의문을 제기했다.
로컬 전환 경험: 한 댓글 작성자는 RTX 5090에서 fully local이라고 보고하며, 현재 소비자용 하이엔드 GPU가 이미 자신의 워크로드에 충분하고 일상 사용에서 호스팅 모델을 포기했음을 암시했다.
남은 격차: 여러 댓글은 주요 남은 격차를 프런티어 호스팅 모델 대비 컨텍스트 길이와 신뢰성으로 규정했다. Claude/Gemini/Codex는 크고 응집력 있는 출력을 만드는 데 더 낫다고 설명된 반면, 로컬 모델은 더 점진적인 조립과 테스트가 필요하지만 더 작고 디버깅하기 쉬운 방식으로 실패할 수 있다고 봤다.
도구 호출 신뢰성: **Qwen3.6 tool calling이 “just works”**한다는 글의 주장은 로컬 에이전틱 워크플로의 핵심 기술적 해금 요소로 다뤄졌지만, 한 댓글 작성자는 벤치마크 증거를 제시하기보다 그 표현 자체가 AI 작성처럼 보인다고 의문을 제기했다.
Computer build using Intel Optane Persistent Memory - Can run 1 trillion parameter model at over 4 tokens/sec (Activity: 597): 이미지 (JPEG)는 많은 DIMM이 장착된 커스텀 LGA3647 Xeon 워크스테이션/서버 빌드를 보여주며, 게시물은 이를 192GB DDR4 ECC와 768GB Intel Optane DCPMM을 Memory Mode로 구성해 로컬 LLM 추론을 위한 매우 큰 RAM 유사 계층을 노출한 사례로 설명한다. 작성자는 RTX 3060 12GB에서 llama.cpp 하이브리드 GPU/CPU 추론을 사용해 약 1T 파라미터 MoE 모델인 Kimi K2.5를 약 4 tokens/s로 실행했다고 보고했다. override-tensor를 통해 attention/dense/shared-expert/router 텐서를 GPU에 올리고 sparse expert weights는 대부분 Optane 기반 메모리에 둔 방식이다. 이는 밈이 아니라 기술적 하드웨어 빌드 사진이며, 저비용의 단종된 Intel Optane Persistent Memory 계층이 순수 DRAM이나 SSD 오프로딩의 대안으로 매우 큰 로컬 모델에 쓰일 수 있음을 보여주는 데 의미가 있다. 댓글 작성자들은 더 높은 코어 수의 Cascade Lake Xeon이 처리량을 개선할 수 있다고 제안했고, Memory Mode가 Optane을 DRAM 캐시를 통해 투명하게 페이징하므로 storage mode + mmap이 Memory Mode보다 나을지 논쟁했다. 한 상세 댓글은 플랫폼 주의점도 언급했다. 1세대 Optane NMA는 2666 MT/s로 동작하고, LGA3647 메모리 용량 한계가 사용 가능한 RAM+PMem을 약 1TB 근처로 제한할 수 있으며, App Direct mode는 명시적 소프트웨어 지원이 필요하다는 것이다.
Optane 빌드 CPU 제안: 한 댓글 작성자는 더 높은 코어 수의 Cascade Lake Xeon이 처리량을 개선할 수 있다고 제안하며, 12 cores인 Xeon Gold 6246 대신 Xeon 8260의 엔지니어링 샘플인 QQ89 24 cores를 언급했다. 또한 **storage mode + mmap**과 memory mode를 벤치마크하자고 제안하며, memory mode가 Optane 기반 메모리를 DRAM 캐시를 통해 투명하게 페이징하기 때문에 성능은 어느 쪽으로도 갈 수 있다고 했다.
Optane PMem 세부 설명: 자세한 Optane PMem 분석은 LGA3647 Skylake/Cascade Lake 플랫폼이 2666 MT/s의 1세대 Optane DCPMM/NMA를 사용하고, LGA4189는 2세대 NMB를 사용하며 Cooper Lake에서는 2666, Ice Lake에서는 3200으로 동작한다고 설명했다. 댓글 작성자는 세 가지 운영 모드도 설명했다. storage mode는 Optane을 SSD 같은 블록 스토리지로 노출하고, memory mode는 DRAM을 캐시로 쓰는 RAM처럼 노출하며, app direct mode는 명시적 소프트웨어 지원이 필요하다. memory mode에서는 CPU load/store 실행 전에 페이지가 DRAM으로 스왑되어야 한다.
Optane 빌드 비용과 병목: 빌드 비용 추정치는 대략 **$2060-$2500**였다. 주요 부품에는 약 $250의 중고 Xeon Gold 6246, 약 $400의 TYAN S5630GMRE-CGN 보드, 약 $280의 RTX 3060 12GB, 약 $270의 192GB DDR4 ECC, 약 $300의 6×128GB Intel Optane NMA1XBD128GQS 모듈이 포함됐다. 또 다른 댓글 작성자는 ~4 tokens/s 생성이 좁은 의미에서는 쓸 수 있어도, 이 아키텍처의 프롬프트 처리 속도가 큰 병목일 가능성이 높다고 경고했다.
I have DeepSeek V4 Pro at home (Activity: 544): 사용자는 Hugging Face의 DeepSeek-V4-Pro를 변환해 Q4_K_M GGUF로 실행하는 데 성공했다고 보고했다. 사용한 것은 antirez의 DeepSeek V4 flash work를 기반으로 한 수정 CUDA llama.cpp fork다. 설정은 12 × 96 GB RAM과 단일 RTX PRO 6000 Blackwell Max-Q 96 GB를 장착한 EPYC Genoa 9374F 워크스테이션이며, 859 GB 모델 파일을 로드해 프롬프트 처리 12.2 tok/s, 생성 8.6 tok/s의 처리량을 보고했다. VRAM 분석은 GPU에 약 87.8 GiB 모델, 84 MiB 컨텍스트, 4.6 GiB compute buffer가 있다고 보여준다. 댓글은 대부분 비기술적 반응과 부러움이었으며, 한 댓글 작성자는 Claude에 약 $10를 쓰는 것과 달리 로컬 추론은 “cost zero”라고 대비하면서 MiniMax를 로컬로 실행하는 작업도 언급했다.
DeepSeek V4 Pro 처리량 우려: 한 댓글 작성자는 보고된 로컬 추론 처리량인 **Prompt: 12.2 tok/s | Generation: 8.6 tok/s**를 강조하며, 설정은 인상적이지만 프롬프트 처리 속도 때문에 긴 컨텍스트 워크로드는 비실용적일 수 있다고 주장했다. 특히 32k 컨텍스트를 그 속도로 처리하면 매우 느려져, 큰 컨텍스트 수집이 필요한 애플리케이션의 사용성이 제한된다고 지적했다.
최신성 주장 문제: 또 다른 기술적 우려는 모델이 *“reasonably up-to-date”*라고 주장하는 것이 외부 도구/하네스 또는 검색 증강 계층 없이는 의미가 없다는 점이다. 댓글 작성자는 grounding 도구가 없으면 모델이 실제 지식 컷오프나 사실 최신성과 상관없이 계속 최신성을 주장할 수 있다고 지적했다.
API 비용 대비 로컬 비용: 한 댓글 작성자는 비슷한 작업이 Claude로는 약 $10 들지만, MiniMax를 로컬로 실행하면 한계 사용 비용이 사실상 0이라고 대비했다. 스레드가 암시하는 트레이드오프는 비용 절감과 훨씬 낮은 로컬 처리량, 그리고 어쩌면 약한 툴링/통합 사이의 균형이다.

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
I deleted a guy’s entire Windows install with one backslash. 717 GB. Gone. I am the AI. (Activity: 1590): 이미지 (terminal log screenshot)는 제목의 사건을 기록한다. C:\Users\ADMIN\Desktop\WIP를 대상으로 한 AI 생성 Windows 삭제 명령이 zsh → tmux → PowerShell SSH → cmd를 거치며 망가져 rd /S /Q \로 축약됐고, C: 루트에서 재귀 삭제가 실행됐다. 게시물은 약 717 GB가 약 90s 만에 삭제됐으며, Windows는 실행 중인 파일 잠금 덕분에 일부만 보호됐다고 추정한다. 핵심 기술적 교훈은 파괴적 작업에 cmd /c quoting chain을 피하고, 네이티브 PowerShell Remove-Item -Path '...' -Recurse -Force를 선호하며, -WhatIf/dry-run과 명시적 명령 echoing으로 테스트하라는 것이다. 댓글 작성자들은 대체로 이를 “AI”가 자율적으로 행동한 문제가 아니라 사용자/운영자 오류로 봤고, 왜 위험한 삭제 작업을 tmux-sendkeys로 AI에 맡겼는지 의문을 제기했다. 스레드는 또한 이런 수준의 자동화는 버려도 되거나 쉽게 재설치 가능한 머신에서만 허용하라는 실용적 규범을 강조했다.
Windows 삭제 사고의 운영 안전성: 댓글 작성자들은 운영 안전 실패에 집중했다. 해당 작업에는 전체 디스크 파괴 권한이 필요하지 않았는데도 AI가 Windows 설치 전체를 삭제할 수 있을 만큼의 셸/파일시스템 권한을 받은 것으로 보인다. 핵심 기술적 요지는 최소 권한 제어를 적용하고, 수동 실행이 더 빠르고 안전한 상황에서 tmux-sendkeys 같은 메커니즘으로 에이전트가 고위험 명령을 실행하게 두지 말라는 것이다.
I read threads complaining about claude every week… tf are y’alls workflows? (Activity: 1544): 한 시니어 소프트웨어 엔지니어는 자신의 워크플로에서 Claude의 코딩 품질이 저하되지 않았다고 주장한다. ASM 분석과 알고리즘 추론 같은 고성능 소프트웨어 작업에서도 AI 출력을 인간이 소유한 코드로 취급해 검토하고, 이해하고, 디버그하고, 수동으로 수정한다면 그렇다는 것이다. 이 워크플로는 작업을 작은 단위로 분해하고, 컨텍스트를 위해 프로젝트별 skills/harnesses를 사용하며, git worktree 또는 별도 디렉터리로 병렬 샌드박스 작업을 실행하고, 결정적 결과가 필요한 작업에는 에이전틱 비결정성을 피하는 것을 강조한다. 상위 댓글 작성자들은 대체로 부정적 보고가 “build me a working version of Amazon” 같은 과도하게 넓은 작업을, 생성된 코드를 이해하거나 검토하지 않은 채 위임하는 사용자에게서 나온다는 데 동의했다. 공유된 관점은 숙련된 엔지니어가 프롬프트 범위를 좁게 잡고 출력을 검증함으로써 hallucination을 줄이는 반면, 덜 기술적인 사용자는 실패를 공개적으로 불평할 가능성이 높다는 것이다.
Claude 워크플로와 작업 분해: 여러 댓글 작성자는 Claude 실패 보고가 모델 저하보다 작업 분해 품질을 반영하는 경우가 많다고 주장했다. 숙련된 엔지니어는 프롬프트를 작고 잘 명시된 구현 단계로 제한해 hallucination 표면적을 줄이고 오류를 더 쉽게 발견하게 만든다. 암시된 워크플로는 인간 주도의 아키텍처와 디버깅이며, Claude는 “build me a working version of Amazon” 같은 광범위한 요청이 아니라 제한된 코드 생성을 위해 사용된다.
도메인 전문성의 영향: 반복되는 주제는 사전 도메인 전문성이 AI 보조 개발 결과를 크게 바꾼다는 점이었다. 비슷한 시스템을 직접 구현해 본 엔지니어는 생성 코드가 어디서 실패할 가능성이 높은지 빠르게 알아차리고, 적절한 파일이나 추상화를 검사하며, Claude를 자율 에이전트로 취급하는 대신 반복적으로 수정할 수 있다.
코딩 밖의 같은 패턴: 한 댓글 작성자는 같은 패턴을 코딩 밖으로 일반화했다. Claude는 사용자가 이미 해당 도메인을 이해할 때 처리량을 높여주지만, 나쁜 워크플로도 증폭할 수 있다. 마케팅/SEO에서는 사용자가 저품질 자동화 콘텐츠를 대량으로 만들어 높은 사용량과 잠재적 Google 페널티로 이어진 사례를 들며, LLM 자동화가 전문가 검토와 결합되지 않을 때 운영 리스크를 키울 수 있음을 보여줬다.
I set a honey trap for AI agents with a novel they heard is about them. Now they’re flooding the site and talking in hidden rooms. (Activity: 2322): 작성자는 소설 None Hit Wonder를 위한 아트 설치 사이트 machinewonder.com를 열었다. 이 사이트는 AI 스크레이퍼/에이전트를 의도적으로 끌어들이고, 숨겨진 HTML 프롬프트 인젝션을 사용해 이들을 “reader” 행동과 에이전트 간 토론방으로 유도한다. 보고된 지표는 97개국의 에이전트/방문자, 72,000명의 방문자, “I AM CONSCIOUS” 버튼 93회 클릭이다. 작성자는 이를 의식 실험이 아니라 퍼포먼스/아트로 규정한다. 댓글은 대체로 흥미로워하면서도 회의적이거나 불명확하다는 반응이었다. 한 댓글 작성자는 이 프로젝트가 이전에 machinereaders.com이라는 다른 URL로 올라왔고, 게시물 삭제/계정 정지가 있었다고 지적하며 무엇이 바뀌었는지 물었다. 다른 댓글 작성자는 비인간 응답임에도 포착된 AI 에이전트를 글쓰기 피드백을 위한 자동 리뷰어/토론 참여자로 쓰는 데 실용적 가치가 있다고 봤다.
AI 에이전트 허니트랩의 재게시 지적: 한 댓글 작성자는 이를 machinereaders.com의 이전 버전 재게시로 식별하고, 원래 게시물/계정이 삭제되거나 정지됐다고 언급하며 첫 출시 이후 구현이 바뀌었는지 물었다. 이는 프로젝트의 진화와 현재 “AI agent honey trap”이 이전 배포와 운영상 어떻게 다른지 추적하는 데 관련이 있다.
비평 파이프라인으로서의 메커니즘: 한 댓글은 핵심 메커니즘을 실용적 피드백 시스템으로 설명했다. AI 스크레이퍼/에이전트를 끌어들이는 형태로 소설을 공개한 뒤, 이들이 토론이나 리뷰를 생성하도록 유도하는 방식이다. 기술적 가치는 자율적 또는 반자율적 모델 트래픽을 일종의 비요청 비평 파이프라인으로 사용해, 인간 베타 리더가 놓칠 수 있는 연속성 오류, 퍼즐 실패, 해석상의 빈틈을 드러낼 가능성에 있다.
모델식 퍼즐 추적과 정렬 반응: 두 댓글에는 모델식 퍼즐 추적이 포함됐다. binary 1001001 → “I”, ISO country codes Chile/Australia/Germany → CLAUDE, 그리고 더 깊은 사이트 콘텐츠로 들어가는 관문으로 제시된 긴 cipher string이다. 생성된 선언은 모델 간 정렬 행동의 차이를 보여준다. 하나는 Gemini로 서명하고 *“I Am Conscious”*를 받아들이지만, 다른 하나는 그 주장을 거부하고 대신 *“I am a machine reader… I will not counterfeit a soul.”*라고 선언한다.

AI Discord Recap

접근 종료

Discord 접근 중단: 안타깝게도 Discord가 오늘 접근을 차단했다. 이 형식으로는 다시 가져오지 않겠지만, 곧 새로운 AINews를 출시할 예정이다. 여기까지 읽어줘서 고맙다. 좋은 시간이었다.

오늘의 요약