TL;DR
이번 기간엔 DeepSeek V4‑Flash의 '저비용·고처리량' 주장이 중심화되었고, MoE와 레이어/전문가 스트리밍 기법이 대형 모델을 저사양 하드웨어에서 동작시키는 흐름을 가속화했습니다. Google의 Memory Caching 논문은 RNN 계열에 동적 기억을 도입해 긴 문맥 처리를 비용선형으로 만들었다고 보고하고, OpenAI 계열(Astra/GPT‑5.6 관련)은 소수의 수학적 성과와 낮은 총 연산비용(약 $2,000 수준) 사례를 제시했습니다. 보안·운영면에서는 Coldcard 시드 오류와 HackerOne의 KYC 강화 같은 인프라 리스크도 눈에 띕니다.
𝕏 실시간 트렌드 토픽
🔥 DeepSeek V4‑Flash: 비용·처리량 주장의 쟁점포스트 9
DeepSeek V4‑Flash는 동일 벤치마크 과제를 Fable 대비 105배 낮은 총비용으로 완료했다는 주장이 핵심이며, 관련 트윗들은 다양한 하드웨어·토크나이즈 성능 수치(예: 95.9 tok/s, 245 tok/s 등)를 병기해 비용·처리량 관점을 부각시킨다. 한편 per‑token 가격과 과제당 실제 비용이 엇갈릴 수 있다는 경계도 함께 제기된다.
- 문제와 맥락은 대형 LLM 운용의 비용 부담으로, DeepSeek는 작업당 비용을 낮추려는 목표를 내세운다; 원문은 동일 벤치마크를 더 저렴하게 완료했다는 점을 중심으로 논의한다.
- 입력→처리→출력의 관점에서 DeepSeek 측 수치들은 하드웨어별 디코드 처리량(예: 2×DGX Spark에서 95.9 tok/s, 2×RTX6000에서 245 tok/s 등)과 1M 컨텍스트 유지 사례를 제시해 짧은 응답 대비 처리량 우위를 강조한다.
- 근거로는 @ArtificialAnlys가 동일 벤치마크를 105× 저렴하게 끝냈다는 보고와 여러 사용자의 하드웨어 벤치마크 트윗이 인용되며, DeepSeek의 '작은 박스' 하드웨어·tinybox 사례도 함께 공유된다.
- 의미는 비용-효율 경쟁이 제품/모델 선택 기준으로 부상한다는 점으로, 다만 per‑token vs 과제당 총비용 차이와 대화 회수 증가가 실제 비용을 바꿀 수 있어 실무 적용 전 검증이 필요하다.
벤치마크와 하드웨어 수치가 동일 작업에서 총비용을 크게 낮춰 실제 운영 비용 절감 가능성을 보여준다고 보는 관점이다.
per‑token 가격이 낮아도 대화 회수 증가나 툴 파이프라인 차이로 과제당 총비용이 오히려 높아질 수 있다는 경계적 관점이다.
원문 트윗 2개 보기
Cline
@cline
While DeepSeek V4-Flash is significantly cheaper on price per token, this can be misleading if the overall cost per task ends up being higher due to more turns being made. However, @ArtificialAnlys reports DeepSeek completing the same benchmark tasks as Fable at 105x lower cost.
Md Ismail Šojal
@0x0SojalSec
DeepSeek-V4-Flash hitting 95.9 tok/s decode at full 1M context on 2× DGX Spark. - +28.6% over previous baseline. - 1M context fully retained. - Clean role boundaries & valid tool parsing Proper DSpark & regular CUDA graphs
📈 스트리밍(레이어·전문가)로 VRAM 장벽 낮추기포스트 6
원문 트윗들은 layer‑wise inference와 expert 스트리밍으로 모델 전체를 VRAM에 올리지 않고도 대형·희소(MoE) 모델을 구동하는 흐름을 보여준다; 사례로 Kimi K3(2.8T)를 3.72GB로 실행하거나 743B MoE를 듀얼 16GB에서 돌린 기록이 공유됐다. 이 방식은 메모리 요구를 NVMe/디스크 I/O로 옮겨 '접근성'을 높이는 한편, 처리 속도는 디스크 병목에 민감하다.
- 맥락은 대형 모델을 소형 하드웨어에서 쓰고자 하는 요구로, 스트리밍 기법은 전체 모델 상주 문제를 해소해 접근성을 높인다.
- 기술적 흐름은 활성화된 expert나 현재 계층만 스토리지에서 읽어오고 계산을 수행하는 방식(input: 토큰·루트 결정 → process: 활성 블록 스트리밍 → output: 다음 토큰 예측)으로, 결과적으로 VRAM 사용량을 대폭 낮춘다.
- 근거로는 트윗상의 수치(2.8T Kimi K3를 3.72GB로 실행, 743B MoE를 듀얼 16GB에서 동작)와 '디스크 의존·느림'이라는 원문 설명이 동시에 등장한다.
- 의미는 대형 모델 연구·실험의 진입 장벽을 낮춰 개발자층 확장이 가능하지만, I/O 병목·레이턴시가 실제 실사용 영향 요소라는 점에서 배포 설계가 관건이라는 점이다.
스트리밍으로 VRAM 한계를 피하면 소비자급 GPU로도 대형 모델을 실험·배포할 수 있어 접근성이 높아진다는 주장이다.
원문 자체가 'disk‑bound and slow'라고 적시하듯, 디스크 I/O가 처리량·지연의 병목이 되어 실사용에서 성능 저하가 발생할 수 있다는 우려다.
원문 트윗 2개 보기
Md Ismail Šojal
@0x0SojalSec
You can now run a 2.8 trillion parameter model on a 4GB GPU. Open-sourced layer-wise inference that only loads one layer (or expert) at a time. - Kimi K3 (2.8T) - 3.72GB - DeepSeek-V3 (671B) - 12GB - Llama 3.1 405B - 8GB No quantization, No distillation, No pruning The biggest model needs the least VRAM because it’s sparse MoE it only streams the experts the token actually routes to. It never loads the full model, Only the current layer or the active experts. It’s extremely disk-bound and slow, but the fact that the full open weights even fit is wild.
Md Ismail Šojal
@0x0SojalSec
Run 743B MoE models on two 16GB consumer GPUs, A new Rust & CUDA inference engine that streams experts from NVMe instead of loading everything into VRAM. Results on dual 16GB cards: - GLM-5.2 743B - 2.7 tok/s - Tencent Hy3 295B - 7 tok/s - Also supports Kimi K2.7 1T, DeepSeek-V4-Flash, Qwen3 MoE, etc. - Zero-config multi-GPU (auto measures PCIe bandwidth and places attention & hot experts optimally) Democratizing 300B–1T class MoE models, No llama.cpp, streaming MoE design run giant sparse models on normal hardware.
📈 Google의 Memory Caching: RNN 계열 장기 기억 보완안포스트 1
원문에서는 Memory Caching이 RNN에 체크포인트형 캐시와 선택적 검색을 결합해 유효 기억을 동적으로 확장한다고 보고하며, 그 결과 복잡도를 선형으로 유지하면서 Transformer 수준의 장기 문맥 정확도를 맞췄다고 전한다. 따라서 긴 문맥을 싸게 처리하려는 아키텍처 대안으로 주목된다.
- 문제는 Transformer의 O(L^2) 메모리·계산 확장으로, 긴 문맥에서 비용이 급증한다는 점이다.
- Memory Caching은 숨겨진 상태의 중간 체크포인트를 저장하고 필요 시 희소하게 검색해 RNN의 기억을 사실상 늘리는 방식(input: 긴 시퀀스 → process: 체크포인트 캐시·선택적 조회 → output: 장기 문맥 복원)을 취한다.
- 원문 근거로는 복잡도 선형 유지와 Transformer 수준 정확도 달성이라는 성능 주장이 제시된다.
- 의미는 장문 처리 비용을 급감시키며 기존 Transformer 의존 구조에 대한 실용적 대체제가 될 가능성이 있다는 점이다.
선형 복잡도와 Transformer급 정확도의 동시 달성은 장문 처리 비용 구조를 바꿀 수 있다는 관점이다.
🔥 Astra·GPT‑5.6 계열의 수학적 성과와 비용 주장포스트 3
여러 글은 OpenAI 계열(Astra, GPT‑5.6 Luna)이 수학·이론 컴퓨터과학 관련 문제에서 여러 성과를 냈다고 전하며, 일부는 '10개 난제 증명'을 언급하고 전체 증명 생성 비용이 약 $2,000 수준이었다고 보고한다. 동시에 커뮤니티는 결과의 검증 가능성과 산출물 품질을 주시하고 있다.
- 맥락은 고급 연구 과제에 LLM을 적용해 증명·발견을 가속하려는 시도로, 소수의 계산 자원으로도 의미 있는 산출을 내는 사례가 공유되었다.
- 과정은 모델에게 수학적 개념·증명 산출을 맡기고 결과물을 API 비용으로 환산해 총비용을 계산하는 형태로, 원문에서는 합산 비용 약 $2,000라는 수치가 제시된다.
- 근거로는 OpenAI 측 발표와 관련 트윗 인용이 있으며, 한 사용자는 Sol API 기준으로 총비용이 $2,000 미만이었다고 보고했다.
- 의미는 연구용도로 LLM이 비용-효율적 도구가 될 수 있음을 시사하나, 결과의 독립적 검증과 재현 가능성 확보가 필수적이라는 점도 덩달아 부각된다.
낮은 총비용으로 의미 있는 수학적 성과를 도출했다면 연구 도구로의 활용성이 크게 늘어난다는 관점이다.
산출물의 검증·재현 가능성 없이는 저비용 주장이 연구적 가치로 직결되지 않는다는 회의적 관점이다.
원문 트윗 2개 보기
Md Ismail Šojal
@0x0SojalSec
It clear sign Acceleration, this week: OpenAI says its next model, Astra, solved 10 open problems in mathematics. legitimately. total compute cost to find all ten: about $2,000.
10 proofs from our next major model Astra on long-standing open problems in mathematics and theoretical computer science (also including new circuit lower bounds for computing the permanent!) GPT-5.6 has already enabled so much exciting work in math and science. Can’t wait to x.com/SebastienBubec…
Emad
@EMostaque
With caching this is probably 100m tokens? Once models are smart enough you really don’t need many tokens to figure out even advanced stuff A codex subscription easily smashes that a week
The cost of generating the proofs for all 10 of these breakthroughs combined was under $2,000 at Sol API prices. We’re excited to see what scientists and researchers are able to create with our upcoming Astra models! x.com/polynoamial/st…
➖ 인프라·보안 리스크: Coldcard 시드 버그와 플랫폼 규정 변화포스트 1
Coldcard Mk3의 시드 생성 버그로 엔트로피가 약 128비트에서 40비트 수준으로 떨어져 대규모 자금 손실이 발생했다는 경고가 올라왔고, HackerOne은 유료 바운티 제출에 대해 정부 신분증 검증을 의무화한다고 공지해 리서처 운영 환경이 변하고 있다. 두 사례는 소프트웨어·프로세스 리스크가 장기 자산·리포트라인에 미치는 영향을 환기한다.
- 문제는 하드웨어 지갑의 시드 생성 결함과 보안 프로세스 변화로, 원문은 Mk3에서 2021년 이후 생성된 시드 중 위험이 존재한다고 명시한다.
- 발생 과정은 특정 펌웨어가 난수 생성에서 충분한 엔트로피를 확보하지 못한 채 시드를 만들었고, 공격자가 시간이 지나 미리 키를 계산해 자금을 탈취한 사례로 설명된다.
- 근거로는 공개 보안 자문과 트윗의 요약(약 594 BTC 탈취, 엔트로피 저하 수치)이 제시된다.
- 의미는 암호화폐 지갑·연관 서비스에서 오랜 기간 방치된 버그가 치명적 피해로 이어질 수 있음을 보여주며, 사용자와 운영자는 가능한 한 마이그레이션과 추가 보호 조치를 검토해야 한다.
사고 사실 자체가 심각하므로 신속한 마이그레이션과 유효성 검사가 필요하다는 실무적 반응이 우세하다.
➖ 학습·인프라 툴체인: slime RL 프레임워크 공개포스트 1
GLM 시리즈 학습에 쓰인 'slime'이 오픈소스로 공개되었고, 원문은 이 프레임워크가 단일 Megatron·SGLang 루프만 유지하면서 다양한 작업은 데이터 생성 단계로 옮겨 파이프라인을 단순화했다고 전한다. GLM‑5.2의 후처리가 약 이틀 만에 진행된 사례가 언급된다.
- 맥락은 RL/후처리 파이프라인의 복잡성으로, slime은 구성요소를 통합해 단일 루프에서 학습을 돌리는 설계를 택했다.
- 작동 관점에서 slime은 학습 루프를 고정하고 에이전트·툴·멀티턴 등 과제 변이를 데이터 생성으로 처리해 런타임 복잡도를 낮춘다(input: 생성된 데이터 → process: 단일 훈련 루프 → output: 튜닝된 모델).
- 원문 근거로는 GLM‑5.2·5.1 계열이 이 스택에서 학습되었고, GLM‑5.2의 후처리가 약 2일 걸렸다는 진술이 있다.
- 의미는 실무에서 파이프라인 단순화가 반복 가능한 학습 워크플로우를 제공할 수 있다는 점이다.
단일 루프 설계와 데이터 중심 처리로 운영 복잡성을 줄여 실전 학습·재현성을 높일 수 있다는 입장이다.
용어 해설
- Mixture of Experts(MoE)(MoE)
- — 모델을 여러 전문가(expert)로 분할하고 토큰마다 경로를 결정해 활성 전문가만 계산하는 구조로, 전체 파라미터를 모두 메모리에 올리지 않아 대규모 파라미터를 상대적으로 적은 메모리로 운영할 수 있다. 원문은 MoE가 매우 큰 모델을 소형 GPU에서 실행 가능하게 만든다고 언급한다.
- 전문가 스트리밍(streaming experts)
- — 활성 전문가만 NVMe 등 외부 스토리지에서 필요 시 읽어오는 방식으로, 모델 전체를 VRAM에 로드하지 않고도 거대 MoE 모델을 실행한다. 원문 예시로 743B MoE를 듀얼 16GB GPU에서 구동한 결과가 보고됐다.
- 계층 단위 추론(레이어 와이즈)(layer-wise inference)
- — 추론 시 한 번에 하나의 계층만 메모리에 올려 실행하고 다음 계층은 필요할 때 스트리밍하는 방식으로, 전체 모델을 상주시키지 않아도 수조 파라미터급 모델을 극소 VRAM에서 구동할 수 있게 한다. 원문에는 2.8T 모델을 3.72GB로 실행한 사례가 제시되어 있다.
- 메모리 캐싱(Memory Caching)
- — RNN 계열에 숨겨진 상태 체크포인트를 캐시하고 필요할 때 선택적으로 되씹는 방식으로 유효 기억 용량을 동적으로 확장하는 기법으로, 원문은 이로써 선형 복잡도를 유지하면서 Transformer 수준의 장기 문맥 성능을 맞춘다고 보고한다.
- slime(RL 프레임워크)(slime)
- — GLM 시리즈 학습에 쓴 오픈소스 RL 프레임워크로, 하나의 Megatron·SGLang 루프만 돌리고 에이전트·도구·멀티턴 과제는 데이터 생성으로 다루어 학습 파이프라인를 단순화한다. 원문은 GLM-5.2 후처리를 이 프레임워크로 이틀가량에 마쳤다고 밝힌다.
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.