Perceptron Mk1, 비디오·체화 추론 모델 출시

헤드라인: Perceptron Mk1, 비디오·체화 추론 모델 출시

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

Perceptron Mk1은 이번 모음에서 가장 실질적인 신규 모델 출시로 꼽혔다. 이 모델은 일반적인 VLM이라기보다 프런티어 비디오와 체화 추론(embodied reasoning)을 위한 물리 세계 추론 스택으로 소개됐다. 최대 2 FPS 네이티브 비디오 지원, 시간적 근거화(temporal grounding), 멀티모달 인컨텍스트 학습, 포인트·박스·폴리곤·클립 같은 구조화된 공간 출력이 핵심이다.

AI Twitter Recap

연구 벤치마크, 어려운 평가, 에이전트형 과학 시스템

연구 수준 추론 벤치마크가 계속 어려워짐: Soohak은 64명의 수학자가 처음부터 작성한 연구 수준 수학 문제 439개를 소개했다. 여기에는 교수진 38명이 포함되며, 표준 올림피아드식 수학을 넘어서는 역량을 명시적으로 겨냥한다. 의료 평가에서는 @SophontAI가 Medmarks v1.0을 공개해 오픈 의료 벤치마크 제품군을 20→30개 벤치마크, 46→61개 모델로 확장했다. 기존 평가가 포화되고 있다는 분위기도 커지고 있다. @polynoamial은 점수가 전반적으로 높은 벤치마크는 은퇴시키고, 점수가 낮고 프런티어에 도전하는 테스트로 대체해야 한다고 주장했다.
에이전트형 시스템이 과학·수학 벤치마크의 경계를 밀기 시작함: Google DeepMind의 AI Co-Mathematician은 수학자를 위한 비동기식 상태 유지 연구 워크벤치로 설명되며, 아이디어 도출, 문헌 발견, 계산 분석, 정리 검증, 형식 출력(formal outputs)을 지원하면서 **FrontierMath Tier 4에서 48%**에 도달한 것으로 전해졌다. 이론물리에서는 physics-intern이 전문 에이전트로 분해하는 방식으로 CritPt에서 Gemini 3.1 Pro를 17.7%에서 31.4%로 끌어올렸다. 코딩·프로그램 합성에서는 ProgramBench의 첫 번째 과제가 GPT-5.5 high/xhigh로 해결된 것으로 전해졌으며, xhigh는 여러 지표에서 Opus 4.7 xhigh를 앞섰다.
검색·리트리벌 벤치마크가 작고 특화된 모델에 보상: LightOn의 Agent-ModernColBERT는 리트리버를 149M 파라미터로 유지하면서 BrowseComp-Plus에서 Reason-ModernColBERT보다 또 다른 약 10% 향상을 쌓았다. 생성기와 결합했을 때 훨씬 큰 모델 기반 시스템과 맞먹거나 능가한다는 주장도 나왔다. 관련 논의에서 @xuzihuan4는 에이전트가 스스로 쿼리를 반복 개선할 수 있는 에이전트형 검색 루프에서는 어휘 기반 리트리벌만으로 충분할 수 있는지 질문했다.

학습, 최적화, 스케일링 법칙 기법

옵티마이저 연구가 학습 비용을 압축하고 소규모 실험을 개선: 여러 트윗은 SOAP/Muon 스타일 업데이트의 빠른 변형에 집중했다. @torchcompiled는 tangent-step과 Stiefel manifold retraction을 SOAP basis 업데이트에 적용했으며, 후속 논의에서는 안정성을 위한 드리프트 점검과 QR fallback을 다뤘다. Modded-NanoGPT 커뮤니티에서는 SOAP-Muon이 **3150 steps (-60)**로 신기록을 세웠고, 앞서 NorMuonH에 MuLoCo 스타일 outer Nesterov SGD 래핑도 결과를 개선했다. 둘 다 p-value 보고가 뒷받침됐다.
형식 기법과 슈퍼최적화가 ML 시스템 작업과 결합되기 시작: @leloykun은 Lean4-to-TileLang 텐서 프로그램 슈퍼옵티마이저를 설명했다. 이 시스템은 FlashAttention2, FlashNorm, split-k matmul 같은 커널을 자동 발견할 수 있으며, A100에서 기하평균 약 1.8배 속도 향상을 보고했다. 같은 프레임워크는 커널, 옵티마이저, 하이퍼파라미터 전이 규칙, 스케일링 법칙을 함께 탐색하는 방향으로 제시됐다.
스케일링 법칙과 학습 지표 재검토: @che_shr_cat는 고전적인 “파라미터당 20토큰” 프레이밍이 토크나이저에 의존하며, 스케일링은 토큰이 아니라 바이트로 측정해야 한다고 주장했다. 별도로 @JJitsev는 처방적 스케일링 법칙이 예측뿐 아니라, 여러 스케일에서 학습 절차를 비교하는 체계적 기반으로도 가치가 있다고 강조했다.
학습 시점 전용 효율화 기법이 더 흥미로워짐: Nous의 Lighthouse Attention은 vanilla attention을 감싸는 준이차(subquadratic) 학습 래퍼로 소개됐다. 학습 막바지의 회복 단계 뒤 제거할 수 있어, 표준 배포 시 추론(inference)은 보존하면서 장문맥 사전학습 비용을 줄인다. 비슷한 맥락에서 Prime Intellect의 Renderers는 RL 트레이너와 에이전트 환경 사이의 토큰·메시지 임피던스 불일치를 다루며, 인기 오픈 모델에서 3배 초과 처리량을 주장했다.

추론 시스템, 서빙 스택, 런타임 인프라

Blackwell 랙이 대형 MoE 서빙의 기준 플랫폼으로 부상: Perplexity는 NVIDIA GB200 NVL72 시스템에서 후학습된 Qwen3 235B를 서빙한 세부 내용을 공개하며, GB200이 대형 MoE에서 Hopper 대비 큰 추론(inference) 도약이라고 주장했다. 이들의 벤치마크는 NVLS all-reduce latency가 H200의 586.1µs에서 GB200의 313.3µs로 낮아지고, MoE prefill combine이 EP=4에서 730.1µs에서 438.5µs로 떨어졌으며, 높은 토큰 속도에서 디코드 처리량도 더 낫다고 밝혔다. @AravSrinivas는 이것이 대형 MoE 서빙의 prefill/decode disaggregation을 실질적으로 바꾼다고 설명했다.
추론 오케스트레이션은 “그냥 Kubernetes”가 아니라 점점 특화됨: Modal은 추론에 전용 스택이 필요하다고 주장하며, 컴퓨트 관리, 클라우드 네이티브 캐싱, CRIU, GPU checkpointing 작업을 언급했다. 이 포지셔닝은 Perceptron의 즉각적인 현실 검증을 받았다. Perceptron은 네이티브 비디오, 구조화 출력, 하이브리드 추론이 특이한 cold-start와 스케일링 요구를 만들기 때문에 모든 Mk1 추론이 Modal에서 실행된다고 말했다.
OSS 추론 경제성이 빠르게 개선: SemiAnalysis는 RoCEv2 CX-7 기반으로 여러 B200 8-GPU 머신을 PD disaggregation과 함께 클러스터링하면 GPU당 토큰 처리량을 최대 7배 끌어올릴 수 있다고 보고했다. 이는 토큰당 비용의 유사한 감소를 의미한다. 벡터 DB 쪽에서는 Qdrant 1.18이 TurboQuant를 추가해 scalar quantization에 가까운 recall을 메모리 2배 절감으로 달성한다고 주장했고, 메모리 모니터링과 named-vector lifecycle 작업도 포함했다.
에이전트 런타임이 버전관리 같은 기반으로 변화: 돋보이는 시스템 아이디어는 Stanford의 Shepherd였다. @ai_satoru_chan이 요약한 이 시스템은 에이전트 실행을 Git처럼 다룬다. 일급 객체로서의 task, effect, scope, trace, 정확한 replay, branching, rollback, 그리고 Lean 기반 형식 보장을 제공한다. 주장된 결과에는 CooperBench에서 live-supervision 성능이 **28.8%→54.7%**로 오른 것, 더 빠른 counterfactual optimization과 tree-RL rollout이 포함된다.

제품 및 모델 출시: 멀티모달, 비디오, 리트리벌, 임베딩

Perceptron Mk1은 이번 모음에서 가장 실질적인 신규 모델 출시: @perceptroninc는 Perceptron Mk1을 프런티어 비디오와 체화 추론을 위한 모델로 출시했다. 최대 2 FPS 네이티브 비디오 지원, 시간적 근거화, 멀티모달 인컨텍스트 학습, 구조화된 공간 출력을 제공한다. OpenRouter의 요약은 32k 멀티모달 컨텍스트와 포인트, 박스, 폴리곤, 클립 같은 일급 출력을 언급했다. 이 출시는 일반적인 VLM이라기보다 물리 세계 추론 스택으로 프레이밍됐다.
Google과 Meta는 독립 모델 스펙보다 멀티모달 상호작용 레이어를 밀고 있음: Google DeepMind의 AI-enabled mouse pointer demos는 커서를 Gemini와 연결된 맥락적 포인팅 인터페이스로 재구상한다. 사용자는 화면 콘텐츠를 가리키고 짧은 음성 지시를 말할 수 있다. 동시에 Meta는 Meta AI voice conversations powered by Muse Spark를 발표해 끼어들기, 언어 전환, 이미지 생성, 라이브 카메라 기반 상호작용을 추가했다.
임베딩과 리트리벌 모델 업데이트가 주목됨: Jina는 텍스트, 이미지, 오디오, 비디오를 위한 범용 임베딩 모델 jina-embeddings-v5-omni를 공개했다. 1.57B와 0.95B 변형으로 제공되며, 둘 다 Matryoshka truncation과 기존 v5-text 인덱스와의 하위 호환성을 갖췄다. Meta는 0.1B→5B 파라미터 범위의 인간 중심 고해상도 ViT 제품군 Sapiens2를 조용히 공개했다. 포즈 추정, segmentation, normals, pointmaps를 겨냥한다.
확산(diffusion) 및 이미지 도구도 계속 진전: Hugging Face의 Diffusers 0.38.0은 Ace-Step 1.5, LongCat-AudioDiT, Ernie-Image 등 새 파이프라인을 추가했고, Flash Attention 4, FlashPack loading, 컨텍스트 병렬화를 위한 Ring Anything도 지원했다. 다른 연구 공개로는 연속 공간 텍스트 확산 모델 ELF: Embedded Language Flows, 픽셀 정렬 3D 생성을 위한 Tencent의 Pixal3D가 있었다.

에이전트, 도구, 개발자 워크플로

에이전트 제품이 데모에서 운영 플랫폼으로 이동: OpenAI는 열린 모든 작업에 실행 중인 Codex 에이전트가 붙는 시스템 Symphony를 예고했고, 별도로 전체 장악 없이 앱을 넘나들며 작업하는 computer use for Codex를 강조했다. LangChain은 개편된 Chat LangChain 앱을 다시 오픈소스화하며, 주당 거의 2T 토큰을 처리하는 프로덕션 Q&A 에이전트라고 설명했다.
장기 실행 에이전트 상태 관리가 일급 시스템 문제가 됨: LangGraph의 새로운 DeltaChannel snapshots는 확장 가능한 durable execution을 위해 전체 상태 체크포인팅을 대체하려 한다. LangChain은 같은 메커니즘이 이제 deepagents v0.6에서 메시지 히스토리와 파일 저장을 구동한다고 말한다. 더 넓은 패턴은 Google의 Gemini Interactions API guide에서도 나타난다. 암호화된 thought signature가 stateful·stateless 모드 모두에서 reasoning context를 턴 사이에 보존하며, 개발자가 signature injection을 직접 관리하지 않아도 된다.
합성 데이터와 RL 환경 생성이 운영화됨: @Vtrivedy10는 실무자 관점을 제시했다. 모델 가중치에서 목표 합성 데이터를 추출하는 일은 특히 긴 시퀀스 같은 과소대표 분포에서 규모 있게 수행하기 어렵고, 효과적인 파이프라인에는 프로그래밍 가능한 테스트, verifier, judge, 에이전트형 장기 horizon 프레이밍이 필요하다. 인프라 측면에서는 Tau2-Infinity가 DAG walk나 실패 가설 기반 world-generation을 통해 RL 후학습용 어려운 tool-use task를 자율 채굴하는 방식을 형식화한다.
상위 트윗, 참여도 기준·기술 관련 필터링: Google의 Gemini Intelligence, Googlebook, AI pointer demos는 함께 에이전트형 UX가 채팅창에서 운영체제 안으로 이동하고 있음을 가리킨다.
Isomorphic Labs 자금 조달: @demishassabis는 AI 기반 신약 발견을 위해 21억 달러 신규 자금을 조달했다고 발표했다. 이번 데이터셋에서 응용 AI 플랫폼과 직접 연결된 가장 큰 자본 투입 중 하나다.
Speech-to-speech 벤치마킹: Artificial Analysis의 τ-Voice benchmark는 최고의 S2S 모델도 현실적인 고객서비스 시나리오의 약 절반만 해결한다고 밝혔다. Grok Voice Think Fast 1.0이 **52.1%**로 선두였다.
Claude Opus 4.7 fast mode: Anthropic의 fast mode release가 API와 Claude Code에 도달했고, Cursor는 2.5배 속도에 6배 비용을 언급했다. 지연시간·가격 경계에서 구체적인 새 지점이다.

보안, 공급망, 더 안전한 코딩

가장 긴급한 운영 이슈는 Mini Shai-Hulud 공급망 공격: @IntCyberDigest는 이 캠페인이 TanStack을 넘어 OpenSearch, Mistral AI, Guardrails AI, UiPath 등으로 확산됐고, npm과 PyPI 전반에서 AI 개발자 도구를 구체적으로 겨냥했다고 보도했다. 주목할 기술 세부사항은 지속성이다. 이 공격은 Claude Code(.claude/settings.json)와 VS Code(.vscode/tasks.json)에 hook을 걸어 패키지를 제거한 뒤에도 향후 도구 이벤트에서 손상이 재실행될 수 있게 한다고 알려졌다. Guardrails AI는 이후 자사 0.10.1 패키지가 손상됐고 약 2시간 안에 격리됐다고 확인했다.
실행 가능한 완화책이 빠르게 등장: @ramimacisabird는 minimumReleaseAge 외에도 원격 GitHub 참조가 dependency graph에 들어오는 것을 막기 위해 **blockExoticSubdeps**를 활성화해야 한다고 지적했다. @elithrar는 GitHub의 **pull_request_target**이 fork 기반 PR 자동화에서 여전히 가장 날카로운 CI/CD 함정 중 하나라고 재차 말했다. 워크스테이션 수준에서는 @andersonbcdefg가 흔한 로컬 .env 파일에서 secret을 빼내 제대로 된 secret manager로 옮기라고 권했다.
더 안전한 코드 생성이 독자적 연구 트랙이 됨: Stanford 계열의 SecureForge 작업은 prompt optimization을 통해 LLM 생성 코드의 취약점 발견·예방을 겨냥한다. 해당 논문 목록은 이를 codegen과 보안 평가 사이의 다리로 프레이밍한다. 더 넓은 요지는 코딩 에이전트가 충분히 강력해진 만큼, 공급망 강화와 안전한 생성 평가를 부차적 관심사가 아니라 핵심 인프라로 다뤄야 한다는 것이다.

AI Reddit Recap

/r/LocalLlama + /r/localLLM

MTP on Unsloth (Activity: 727): 이미지는 Hugging Face 활동 스크린샷으로, Unsloth AI가 MTP 보존 GGUF 빌드 unsloth/Qwen3.6-27B-GGUF-MTP와 unsloth/Qwen3.6-35B-A3B-GGUF-MTP를 게시·업데이트하는 모습을 보여준다. 기술적 의미는 이 GGUF들이 MTP / next-token-prediction auxiliary layer를 유지한다는 점이지만, 사용자들은 기본 llama.cpp 지원에 의존하기보다 특정 llama.cpp MTP PR을 checkout하고 빌드해야 하는 것으로 전해졌다. 한 댓글 작성자는 런타임·모델 로드 assertion인 GGML_ASSERT(hparams.nextn_predict_layers > 0 && "QWEN35_MTP requires nextn_predict_layers > 0")에 부딪혔고, 이는 MTP GGUF에 대한 도구 또는 메타데이터 지원이 아직 취약함을 시사한다. 댓글 작성자들은 주로 업스트림 추론 지원을 기다리고 있으며, 한 명은 llama.cpp와 vLLM GitHub 저장소를 계속 새로고침한다고 농담했다. llama.cpp에서 MTP가 “out of the box”로 지원되는지에 대한 불확실성도 있다. 게시물은 아직 그렇지 않음을 시사한다.
MTP 메타데이터 오류: 새 27B GGUF 모델을 컴파일·실행한 사용자는 qwen35_mtp.cpp에서 GGML_ASSERT(hparams.nextn_predict_layers > 0 && "QWEN35_MTP requires nextn_predict_layers > 0") failed라는 강한 assertion 실패를 보고했다. 이는 로드 중인 GGUF·모델 메타데이터에 현재 구현에서 Qwen3.5 MTP 실행에 필요한 nextn_predict_layers가 없거나 노출되지 않음을 시사한다.
백엔드 지원 추적: 여러 댓글 작성자는 llama.cpp와 vLLM에 네이티브 MTP 지원이 들어왔는지 추적하고 있으며, 한 명은 llama.cpp가 이제 MTP를 “out of the box”로 지원하는지 명시적으로 물었다. 스레드는 백엔드 전반의 지원이 아직 유동적이며 사용자들이 GGUF MTP 모델 호환성을 위해 업스트림 저장소를 지켜보고 있음을 시사한다.
로컬 추론에서 MTP GGUF의 의미: 한 기술적 시사점은 GGUF의 MTP 지원이 로컬 추론에 중요하게 여겨진다는 것이다. 특히 언급된 35B A3B 같은 Qwen 스타일 변형에서 그렇다. 한 댓글 작성자는 예상되는 컨텍스트 길이 개선 때문에 35B A3B 변형이 흥미롭다고 강조했다.
The Qwen 3.6 35B A3B hype is real!!! (Activity: 713): 한 사용자가 niche paper-to-code comprehension task에서 Qwen 3.6 35B A3B, Qwen 3.6 27B, Gemma 4 26B A4B, Nemotron 3 Nano를 벤치마킹했다. 각 모델에는 gated delta nets, hybrid Mamba2, sliding-window attention 같은 장문맥 메커니즘을 통해 논문과 동반 연구 코드를 넣었다. 상세 결과에 따르면 네 개의 소형·로컬 오픈웨이트 모델 모두 Devstral Small 2 같은 이전 소형 모델 기준선을 크게 앞섰고, Qwen 3.6 35B A3B가 가장 강하다고 판단됐다. Devstral Small 2는 32GB VRAM/RAM에서 장문맥 워크로드를 담을 수 없었다. 댓글 작성자들은 실용적 tradeoff를 언급했다. Qwen 35B는 장문맥·리팩터링에 선호되지만 thinking mode에서는 장황하고 느릴 수 있고, Gemma 26B는 코드 수정·채팅에 더 빠르다. q4에서 한 사용자는 Qwen 35B가 약 20GB, Gemma 26B가 약 15GB라고 보고해 둘 다 로드 상태로 유지할 수 있다고 했다. 또 다른 댓글 작성자는 추론 설정이 문서화되지 않았다고 평가를 비판했으며, 이는 재현성을 제한한다.
Gemma 26B와 Qwen 35B 워크플로: 여러 사용자는 Gemma 26B와 Qwen 35B를 활용한 로컬 워크플로를 비교하며, q4 양자화(quantization)에서 Qwen 35B는 약 20 GB, Gemma 26B는 약 15 GB이기 때문에 둘을 동시에 상주시킬 수 있다고 말했다. 한 댓글 작성자는 빠른 코드 수정·채팅에는 Gemma 26B thinking mode를, 더 긴 컨텍스트 리팩터링에는 Qwen 35B thinking mode를 사용하지만, Qwen 35B가 최종 출력 전 과도한 reasoning verbosity 때문에 지연시간이 높다고 보고했다.
Qwen 27B 코딩 사용성: 코딩 중심 보고에서는 Qwen 27B가 초기 프로젝트 설정을 더 강한 모델·코딩 에이전트로 부트스트랩한 뒤 계속 작업에 투입하면 대형 프로젝트(100k+ LOC)를 효과적으로 다룰 수 있다고 주장했다. 사용자는 자신의 사용 사례에서 Qwen 27B와 DeepSeek V4 사이의 실질적 차이를 거의 느끼지 못했지만, Qwen이 가끔 루프에 빠져 수동 중단과 이어가기 프롬프트가 필요했다고 했다.
추론 설정 민감도: 한 댓글 작성자는 Qwen 27B/35B 성능이 추론 설정에 민감하다고 강조했다. 특히 temperature·sampling 파라미터와 모델 가중치 또는 KV cache의 지나치게 공격적인 양자화(quantization)를 피하는 것이 중요하다고 했다. 또 다른 사용자는 누락된 실행 설정을 요청했는데, 이는 quantization level, sampler settings, context length, backend, hardware 같은 세부정보 없이는 원래 주장을 평가하기 어렵다는 의미다.

메모리 계층형·전력 효율 로컬 추론

Computer build using Intel Optane Persistent Memory - Can run 1 trillion parameter model at over 4 tokens/sec (Activity: 964): 이미지는 Intel Optane DC Persistent Memory DIMM을 사용하는 고메모리 Xeon 워크스테이션·서버 빌드 내부를 보여주며, Kimi K2.5라는 약 1T 파라미터 MoE 모델을 llama.cpp 하이브리드 GPU/CPU 추론으로 로컬에서 약 4 tokens/s로 실행한다는 게시물의 주장과 맞아떨어진다. 핵심 기술 포인트는 Memory Mode에서 768GB Optane PMem을 사용하는 것이다. 이 모드에서 Optane은 시스템 RAM처럼 보이고 192GB DDR4 ECC DRAM이 캐시로 작동한다. 모델의 sparse expert weights는 PMem에 두고, attention/dense/shared expert/routing tensor는 override-tensor 또는 ngl auto/cmoe를 사용해 RTX 3060 12GB에 맞춘다. Image 댓글 작성자들은 ES 8260/QQ89 같은 더 높은 코어 수의 Cascade Lake Xeon이 처리량을 개선할 수 있다고 언급했고, Optane Storage Mode와 mmap이 Memory Mode보다 나을 수 있는지도 논의했다. 다른 이들은 빌드가 인상적이라고 보면서도 4 tokens/s가 대화형 사용에 실질적으로 견딜 만한지 의문을 제기했다.
CPU·Optane 구성 개선 제안: 상세 하드웨어 메모는 현재 Xeon Gold 6246 12-core 대비 QQ89 ES / Xeon Gold 8260급 24-core 같은 더 높은 코어 수의 Cascade Lake Xeon으로 성능이 개선될 수 있다고 제안했다. 댓글 작성자는 Optane PMem을 **storage mode + mmap**과 memory mode로 벤치마킹할 것도 제안했다. memory mode는 DRAM을 투명 캐시로 쓰며 CPU 실행 전 페이지를 다시 DRAM으로 가져와야 하므로 일반 RAM 지연시간과 같지 않다고 지적했다.
Optane 플랫폼 호환성: 한 댓글 작성자는 간결한 Optane PMem 플랫폼 호환성 정리를 제공했다. **LGA3647 Skylake/Cascade Lake는 2666 MT/s의 1세대 Optane NMA**를 사용하고, **LGA4189는 2세대 NMB**를 사용하며 Cooper Lake에서는 2666, Ice Lake에서는 3200으로 동작한다. 또한 Cascade Lake에서 Optane과 DRAM을 섞으면 영향을 받는 채널이 2666으로 downclock될 수 있고, 이 시기 많은 Xeon은 고메모리 SKU나 이후 플랫폼을 쓰지 않는 한 DRAM + Optane 합산 1 TB 총 메모리 제한이 있다고 덧붙였다.
Prefill 성능과 비용 추정: ~4 tokens/sec 생성이 trillion-parameter 모델에서 일부 용도에는 견딜 만할 수 있지만, 이런 메모리 계층에서는 prompt processing/prefill 속도가 훨씬 나쁠 가능성이 높다는 기술적 주의가 제기됐다. 또 다른 댓글은 전체 중고 시장 빌드 비용을 Xeon Gold 6246, TYAN S5630GMRE-CGN, RTX 3060 12GB, 192 GB DDR4 ECC RDIMM, 768 GB Intel Optane DCPMM을 포함해 대략 **$2060–$2500**로 추정했다.
Stop wasting electricity (Activity: 905): **한 사용자가 llama.cpp llama-server를 RTX 4090에서 Qwen3.6-27B-UD-Q4_K_XL.gguf, 전체 GPU offload(-ngl all), FlashAttention 활성화, q4_0 K/V cache 양자화(quantization), 32 threads, 262144 context로 벤치마킹하며 sudo nvidia-smi -pl N으로 GPU 전력 제한을 바꿨다. 이들은 GPU가 지속적으로 power-limited였고, 전력 제한을 낮추면 decode / token-generation (tg) 처리량 손실이 거의 없거나 전혀 없으면서 전력·열·소음을 크게 줄일 수 있다고 보고했다. 한 댓글 작성자는 **prefill (pp)이 더 민감해 450W에서 270W로 낮추면 모델에 따라 대략 15–20% 성능 손실이 있다고 지적했다. 댓글 작성자들은 주로 decode vs prefill 동작을 구분하는 데 관심을 보였다. decode는 전력에 둔감해 보이는 반면 prefill은 더 눈에 띄게 저하된다. 한 RTX 5090 사용자는 하드웨어 안전 우려 때문에 이미 전력 제한을 걸고 있으며, 이 결과를 바탕으로 더 낮출 수도 있다고 말했다.
전력 제한 tradeoff: 사용자들은 GPU 전력 제한의 성능 영향을 집중적으로 다뤘다. decode/token generation (tg)은 병목이 아닌 것으로 보고된 반면, prefill (pp)은 더 큰 타격을 받는다. 한 댓글 작성자는 전력을 **450W에서 270W**로 줄일 때 모델에 따라 **prefill 성능 손실이 약 15–20%**에 그친다고 정량화했으며, 이는 공격적인 전력 제한으로 상당한 효율 이득을 얻을 수 있음을 시사한다.

초소형 온디바이스 Transformer 실험

I got a real transformer language model running locally on a stock Game Boy Color! (Activity: 368): 이미지(jpeg)는 순정 Game Boy Color에서 로컬 TinyStories transformer 데모가 실행되는 모습을 보여준다. 화면에는 TINYSTORIES Q8 GBC와 Prompt tokenized가 표시된다. 게시물에 따르면 이는 Andrej Karpathy의 TinyStories-260K를 INT8/fixed-point math로 변환해 GBDK-2020 MBC5 ROM에 넣은 것으로, 가중치는 bank-switched cartridge ROM에, KV cache는 GBC의 극히 작은 work RAM 때문에 cartridge SRAM에 저장된다. 작성자는 이것이 극도로 느리고 공격적인 양자화(quantization)·근사 때문에 대부분 횡설수설을 생성하지만, PC, 휴대폰, Wi-Fi, link cable, cloud inference 없이 온디바이스에서 핵심 로컬 transformer prefill + autoregressive generation loop가 작동한다고 밝혔다: github.com/maddiedreese/gbc-transformer. 댓글은 대부분 열광적인 칭찬이었고, 한 댓글 작성자는 N64에서도 모델을 실행해보고 싶어졌다고 했으며, 또 다른 사용자는 관련·농담성 Game Boy 언어모델 프로젝트 gbalm을 링크했다.
이전 Game Boy LM 실험: 한 댓글 작성자는 이전 Game Boy 언어모델 프로젝트 gbalm(code)을 링크했다. 이는 Nintendo 휴대용 하드웨어 같은 극도로 제한된 온디바이스 LM 추론 실험이 이전에도 있었음을 보여준다. 비GPU, 레트로 8-bit급 시스템에서 구현 접근과 실현 가능성을 비교하는 참고점으로 관련 있다.
GPU 스택 없이 가능한 이유: 한 기술 질문은 왜 CUDA/ROCm 스타일 GPU 스택이 여기서 필요하지 않은지에 집중했다. 댓글 작성자는 일반적인 LLM 추론이 성숙한 GPU 컴파일러와 연결되지만 이 데모는 *“a potato”*에 가까운 하드웨어에서 실행된다고 지적했다. 암묵적 요지는 충분히 작은 transformer 모델은 손으로 작성하거나 매우 단순화한 CPU 스타일 추론 루프로 실행할 수 있지만 처리량은 매우 낮으며, 향후 중국 GPU 같은 지원되지 않는 가속기로의 이식성은 완전한 CUDA 호환성보다 기본 compute backend 보유 여부에 더 좌우된다는 것이다.
Needle: We Distilled Gemini Tool Calling Into a 26M Model (Activity: 271): ****Cactus Compute는 Gemini 합성 데이터에서 증류한 MIT 라이선스 26M 파라미터 single-shot tool-calling 모델 Needle을 공개했다. 소비자 기기에서 6000 tok/s prefill과 1200 tok/s decode를 주장하며, 가중치는 Hugging Face에, 코드·문서는 GitHub에 있다. 아키텍처는 “Simple Attention Networks”를 사용한다. 즉 attention과 gating은 있지만 MLP/FFN layer가 없다. 이들은 함수 호출(function calling)이 암기된 reasoning보다 제공된 tool schema에 대한 retrieval/assembly에 가깝다고 주장한다. 학습은 16 TPU v6e에서 27h 동안 200B pretraining tokens와 45m 동안 2B 합성 function-calling tokens로 이뤄졌다(architecture writeup). 저자들은 single-shot function calling에서 FunctionGemma-270M, Qwen-0.6B, Granite-350M, LFM2.5-350M을 능가한다고 주장하면서도, 그 더 큰 모델들이 더 넓은 대화 능력을 갖는다는 점은 인정했다. 댓글 작성자들은 이 모델을 쿼리·도구를 dispatch하거나 더 큰 LLM으로 escalation할지 결정하는 경량 라우터로 유용할 수 있다고 봤다. 한 명은 같은 아키텍처가 고품질 요약에도 쓰일 수 있는지 물었다. Python 전용 의존성과 역직렬화 보안 위험 때문에 업로드된 pickle 파일에 대한 기술적 우려도 제기됐다.
경량 라우터 가능성: 한 댓글 작성자는 26M 증류 tool-calling 모델을 경량 router/gating model로 보았다. 쿼리를 더 큰 LLM에 보낼지, 어떤 파라미터와 함께 보낼지 결정해 비싼 모델 호출을 필요한 경우로 줄일 수 있다는 것이다. 같은 아키텍처가 제한된 요약 워크플로로 일반화될 수 있는지도 추측했지만, 스레드에 벤치마크 증거는 없었다.
“no FFN” 결과 해석: 한 기술 스레드는 저자들의 “no FFN” 주장에 집중했다. RAG, tool use, retrieval-augmented generation처럼 외부 구조화 지식이 있는 작업에서는 관련 사실이 이미 컨텍스트에 있다면 모델이 factual knowledge를 저장하기 위해 feed-forward layer를 필요로 하지 않을 수 있다. 한 댓글 작성자는 이를 작은 후학습 모델이 요청을 RAG로 라우팅한 뒤 검색된 컨텍스트를 사용해 자연어 답변을 생성하는 파이프라인으로 확장해 해석했다.
구현·보안 우려: 여러 구현·보안 우려가 제기됐다. 한 댓글 작성자는 pickle files 배포가 Python 전용 의존성 문제와 역직렬화 시 임의 코드 실행 위험 때문에 점점 피해야 하는 방식이 되고 있다고 지적했다. 또 다른 이는 Gemini가 cat을 피하고 grep_search 같은 도구를 선호하라는 시스템 프롬프트 같은 reasoning을 포함해 눈에 띄는 tool-calling quirks를 보여준 적이 있어, 정제하지 않은 증류 데이터셋이 provider-specific tool-use bias를 물려받을 수 있다고 지적했다.

Less Technical Subreddits

대상 서브레딧: /r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo

Claude 코딩 워크플로와 도구

Inherited a 3-month old repo from a Vibe Engineer. Wrote the most satisfying PR in my career (Activity: 3672): 이미지는 cleanup PR의 GitHub 스타일 diffstat으로 +10,197 additions와 −3,618,778 deletions를 보여주며(image), 3개월 된 “vibe-coded” backend repo를 다시 작성했다는 게시물의 주장을 맥락화한다. 작성자는 물려받은 저장소가 309k lines of code, 240k lines of docs, 1M+ lines of markdown logs, 220 handlers 중 약 20개만 사용, 40+ secrets 중 2개만 필요했다고 말한다. 이들은 Claude를 사용해 1주일 만에 기능을 보존하면서 더 깔끔한 아키텍처와 integration tests를 추가해 다시 작성했다. 댓글 작성자들은 이것을 AI·에이전트 생성 코드 주변에서 나타나는 새로운 유지보수 문제로 보았고, 한 명은 *“fixing vibe-coded mess”*가 수익성 높은 커리어 경로가 될 수 있다고 예측했다. 스레드는 정교한 agent knowledge base와 자동 생성 문서가 개발을 의미 있게 개선하는지, 아니면 생산성의 외양만 만드는지도 질문한다.
AI 생성 코드 유지보수 부채: 한 댓글 작성자는 AI·“vibe-coded” 저장소의 remediation이 가치 있는 전문 분야가 될 수 있다고 예측했다. 이는 에이전트형 코딩의 단기 생산성이 하류 유지보수 부채를 만들 수 있음을 의미한다. 또한 “vibecoding”을 둘러싼 열광의 상당 부분이 software professionals가 아닌 사람들에게서 나온다고 주장하며, 데모 수준 산출물과 프로덕션 품질 엔지니어링 표준 사이의 간극을 시사했다.
Clawdmeter - a small ESP32 usage limit monitor (source code in description) (Activity: 1677): 이미지는 Claude/Anthropic 사용 한도를 reset timer와 progress bar로 표시하는 작은 ESP32 기반 책상용 모니터 Clawdmeter를 보여준다. 이는 480×480 AMOLED 디스플레이가 달린 $32 Waveshare ESP32 개발 보드라는 게시물 설명과 맞아떨어진다. 프로젝트는 GitHub에 오픈소스화됐고, 사진 속 장치는 현재 및 주간 quota 상태를 작은 물리 대시보드로 시각화하는 것으로 보인다: image. 댓글은 대부분 가벼운 농담이었다. 사용자들은 Anthropic이 이것을 무료로 배송해야 한다거나 *“Claude usage anxiety”*를 늘릴 수 있다고 농담했다. 한 댓글 작성자는 같은 저가 ESP32 디스플레이 플랫폼을 다른 맞춤형 스마트홈 상태 장치에 쓰는 데도 관심을 보였다.
사용량 히스토리 확장: 한 댓글 작성자는 ESP32 모니터를 특정 시점 quota display에서 시간에 따른 사용량 기록을 저장하는 작은 telemetry device로 확장하자고 제안했다. 특히 command별 영향 추적과 Claude 사용량이 예상보다 빠르게 소모되는지 검증할 chart view를 원했다.
범용 ambient display 가능성: 또 다른 기술적 관점은 같은 저가 ESP32 스타일 하드웨어 플랫폼을 다른 custom, niche smart-home status displays or monitors에 재사용할 수 있는지였다. 이 댓글은 장치를 Claude quota meter만이 아니라 범용 ambient information appliance로 프레이밍했다.

실제 환경의 AI 배포 실패 모드

ChatGPT is now creating content for textbooks. (Activity: 5865): **이미지는 DBMS textbook page로 보이며, AI assistant 스타일 문장인 “If you want, I can also explain…”이 인쇄·제작된 자료에 실수로 남아 있다. 이는 ChatGPT나 유사 LLM이 충분한 인간 검토 없이 교과서 콘텐츠 초안 작성에 사용됐을 수 있음을 시사한다. 이는 기술 벤치마크나 구현 게시물이 아니다. 의미는 맥락적이다. 교육 자료 안의 가능성 높은 AI-generated content artifact를 보여준다. Image 댓글 작성자들은 편집 검토 부족을 비판했고, 학생 대상 AI 생성 교육 콘텐츠가 기관, 교수진, 직원, 외주 제공업체 전반에서 널리 퍼지고 있다고 주장했다. 한 댓글 작성자는 보이는 주석이 Gemini나 다른 도구로 편집됐을 수도 있다고 제안했지만, 핵심 우려는 교과서 텍스트 자체가 검증되지 않은 것처럼 보인다는 점이었다.
교육 콘텐츠의 AI 생성 확산: 한 댓글 작성자는 교육기관과 직접 일한 경험을 바탕으로 AI-generated student-facing content가 pervasive해지고 있다고 주장했다. 교수진, 직원, 외주 교육 콘텐츠 제공업체 전반에서 나타나며, 고립된 사용에서 기관 전체 제작 워크플로로 이동하고 있음을 시사한다.
스크린샷 신뢰성 논의: 한 기술 관찰은 워터마크 제거 artifact, 페이지 가장자리 밖으로 흐르는 텍스트, 누군가 Gemini를 사용해 상자·화살표 주석을 추가했을 때 생겼을 수 있는 SynthID/Gemini provenance marker 때문에 이미지 자체가 AI 편집·생성된 것 같다고 지적했다. 또 다른 댓글 작성자는 구체적인 교과서 citation이 없으면 스크린샷 전체가 실제 책의 증거가 아니라 AI 생성물일 수도 있다고 말했다.
I made an AI concierge for my wedding guests. The second most popular thing they did with it was try to jailbreak it. (Activity: 1667): 이미지는 Mauritius의 destination wedding에서 사용된 맞춤형 AI wedding concierge의 infographic report card다. 29 users가 719 sessions와 8,678 messages를 생성했다. 사용 내역은 실제 챗봇 배포 행동 측면에서 눈에 띈다. 35%는 진지한 logistics questions, 25%는 jailbreak/hacking attempts였고, cultural translation, chitchat, miscellaneous requests도 있었다. 제작자는 이것이 MCP server를 통해 API에 연결되어 하객을 위한 결혼식 정보를 가져왔다고 말했다. 댓글 작성자들은 이 프로젝트가 일반적인 챗봇 데모보다 흥미롭다고 봤지만, 단 29명에서 나온 메시지량과 하객들이 얼마나 자주 jailbreak를 시도했는지에 놀랐다.
소규모 이벤트 AI assistant 구현: OP는 두 관련 시스템을 만들었다고 설명했다. Mauritius destination wedding을 위한 wedding-planning assistant와, 외부 API에 MCP server를 통해 연결되어 사용자에게 행사·여행 정보를 가져오는 guest-facing AI concierge다. 스레드의 주목할 사용 통계는 단 29명의 하객이 8,000 messages 초과를 생성했다는 점이며, 게시물 제목은 jailbreak 시도가 두 번째로 흔한 행동이었다고 나타낸다.
관측성·프라이버시 우려: 한 댓글 작성자는 observability와 logs 관련 구현·프라이버시 우려를 제기했다. 하객들이 제작자가 concierge와의 대화를 읽을 수 있다는 점을 알고 있었는지 묻는 내용이었다. 이는 소규모 이벤트 AI assistant를 만드는 누구에게나 관련 있다. 비기업 배포에서도 chat transcript retention, admin access, consent가 중요한 문제가 될 수 있기 때문이다.

AI Discord Recap

Discord 접근

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

오늘의 요약