원문 타래: https://x.com/Multi_Serio_Ai/status/2058756938498998289

2026-05-25

밤새 자율적으로 27M의 텍스트를 처리.

글을 써 보신 적이 있다면, 일단 처리 속도에서는 공포를 조금 느끼셔도 좋습니다. 제가 보기에 품질도 이 정도면 합격점이고.

아마 앞으로 고품질 번역 외의 상당수가 기계 번역으로 대체 될 거 같고 이미 대체되는 중일 거라고 판단함. https://t.co/NOQ9CXJNPI

원문 보기

오후에는 요즘 번역쪽에 핫뜨거핫인

https://t.co/7LMoEDFTCr

탄센트의 훈위안 MT2를 물려놓고 돌려볼 생각.

원문 보기

약 6시간 후의 결과.

3090 머신 2대의 Gemma4 26b 에서 약 2.4~2.7mb/h의 속도로 텍스트를 번역 중.

글자수로 치면 시간당 약 120~150만 자 정도고 하루로 치면 2500만 ~ 3600만 자 정도 되네요. https://t.co/hl6a7yPkZ0

원문 보기

8시간 후 결과. 잘 진행되는 중. https://t.co/yK8sqQj6ev

원문 보기

8시간 후

중간에 모종의 이유로 2번 api 번역 프로세스가 죽고 단독으로 작업이 진행됨. 그래서 일부 속도 저하 발생.

아침이면 3박4일의 행군이 종료될 듯.

사무실이 너무 더워져서 잘때는 안시켜야지. https://t.co/eJ3XlSuwjv

원문 보기

원문 타래: https://x.com/Multi_Serio_Ai/status/2058411818247450737

2026-05-24

현재 Qwen 3.6 27b + Gemma4 26b 듀얼로

14시간 자율 작업 중.

대충 1% 수준의 리퀘스트 오류가 나오는 중.

오류 발생시 회귀 재작업 기능은 넣어 놨으니 일단 지켜보는 중.

예상 작업 시간은 총 18~20시간. https://t.co/MRo5mXZQVy

원문 보기

작업 에러는 너무 빠른 시간에 다시 재 작업 요청이 들어가서인듯. 기계적 청킹 중 10글자 이하의 청킹 작업이 있어서 그게 요청이 빠르게 들어가는 과정에서 문제가 종종 발생함.

근데 청킹을 왜 저따구로 하는거지?

다 끝나면 프로세스 한번 살펴봐야할듯 https://t.co/xcGyBZ7sE0

원문 보기

저야 하꼬라

• 계획 + 스크립트를 미리 Ai와 작성

• 오케스트레이터와 실행 에이전트 사이에 동일 작업을 계속 핑퐁 + Ai agent 기반 작업 검수를 장시간 하게 해 둠

• 사실 이걸 사람이 했다면 인력 투입이 아찔할 일이라, 이런 작업을 하는 분들의 미래를 생각하면 좀 아찔한 부분이 있긴 함.

원문 보기

작업은 15시간으로 종료되었는데, 그건 제가

• Qwen 3.6 을 물고 있는 머신에도 Gemma4 를 로드

• Gpt 5.5 medium을 오케스트레이터로 설정

• 두 머신을 동시에 돌리면 시간을 단축

할 수 있다는 사실을 이제서야 깨달은 깡통이었기 때문입니다.

원문 보기

원문 타래: https://x.com/Multi_Serio_Ai/status/2058453537353568401

2026-05-24

Qwen도, 딥시크에서도 보고되는 부분이지만, 서구권 모델에 비해 사고 풍선이 매우 거대함. Qwen 3.6 27b 의 경우 사고 풍선이 결과물의 3~4배로 진짜 풍선처럼 부풀어 오르는경우를 자주 볼 수 있음. 낮은 파라메터를 보완하기 위해 결과물 전체를 사고한 뒤 작업하게 설계해 두었기 때문으로 보임.

원문 보기

이는 서구권 SOTA에 비해 모델 파라메터가 낮기 때문. 현재 Opus 는 약 3~5T, Gpt 는 10T 파라메터로 추정되는데 중국 모델들은 아직 2T를 넘는 모델이 잘 없음. 결국 이러한 사고 버블의 확장으로 실제 소비되는 토큰의 양이 꽤 많이 늘어남. 그래서 토큰당 낮은 가격이 실제 낮은 가격은 아님.

원문 보기

물론, 그럼에도 불구하고 여전히 낮은 가격임을 부정할 수는 없지만 동일 토큰에 동일 결과물이 나오는 게 아니라는 것임. 사고 버블로 인한 토큰 낭비와 성능 부족으로 인한 재작업까지 고려하면 단순히 토큰당 가격으로 비교하는 것은 맞지 않다는 말을 하고 싶었음.

원문 보기

원문 타래: https://x.com/Multi_Serio_Ai/status/2058502242983141867

2026-05-24

https://t.co/1OIHV9AxSh

점심쯤에 말한 ‘Local AI 웹번역’을 공개해 봅니다.

크롬 확장 스토어는 조금 기다려 주세요.

(돈도 내야하고, 이래저래 절차가 복잡하네요.)

• 시작은 크롬 내부 AI Gemini-nano 이용

• 외부 Api 이용 가능

• 다양한 모델 대응 (Gemma4 사용 권장) https://t.co/65WWr6wlTs

원문 보기

1. 장점

• 크롬 기계 번역의 페이지 번역 과정을 이용. 대부분의 웹 페이지 대응

• 페이지 번역 과정에서 외부 데이터 유출이 없음.

• 모델 성능에 따라 더 고품질의 번역 웹 페이지 이용이 가능함( Gemma E4b, 26b 모델 사용 권장) https://t.co/mg6abKKpAl

원문 보기

2. 단점

• 느림. Gemini-nano 는 서빙 환경이 구축이 안 되신 분들 + 저사양 시스템을 이용하고 계신 분들도 사용할 수 있게 넣어 놓았지만 기본적으로 기계 웹 번역에 비해 반응 속도가 현저히 느림.

• Gemma4 26b + 3090 : 디코딩100t/s 로도 Fhd 100% 화면 기준으로 약 3~5초 소요됨.

원문 보기

원문 타래: https://x.com/Multi_Serio_Ai/status/2058181769086771454

2026-05-23

1. Gemma4 E4B 랑 26B-a4b는 토큰 생산속도가 차이가 없음. 그러므로 26B-a4B를 쓸 수 있는 상황에선 쓰는 게 좋음. 31B dense가 품질 정확도 면에선 더 좋을 수 있겠지만, mtp 나 Dflash 없는 이상 속도가 끔찍함.그래서 로컬에서 Gemma4는 생산보단 대화/자연어 처리 등의 작업에 투입하는 게 좋음.

원문 보기

2. Qwen 3.6 27b 는 로우 파라메터의 문제인 루프에 빠지지 않고 EOD를 가져오는 거의 유일한 모델. MTP까지 적용했을 때 3090 기준 35~40T/s 정도. 결과물의 퀄리티는 Gemmini 3 pro 보다 좀 더 좋다. 본인들은 Opus 4.5 랑 같은 급으로 놓던데 그건 에바임. 그냥 이거 쓰세요. 다른 거 보지 마시구.

원문 보기

3. 양자화가 좋으면 더 좋은 결과를 가져오지만, Q4를 넘어가면 효율이 급격히 저하됨. 결국 스윗 스팟은 Q4.

4. 그래서 현재로선 로컬LLM엔 Qwen 3.6 27b + Gemma4 26b 의 이중화구성이 가장 효율적. 둘을 잘 스위칭해도 좋고, 듀얼 시스템에서 하나는 Qwen, 한쪽은 Gemma 올려놓고 써도 좋다.

원문 보기