MiniMax H3 GPU 최적화, Jev와 Adaptive VSA 분석
TypeSafe AI가 9월 15일 공개한 결정 모델 Jev와는 이름만 같고 아무 관계가 없는 또 다른 Jev를 오픈소스 GPU 최적화 프로젝트에서 발견했습니다. RTX 4070 12GB 한 장에 실제로 설치하고 keep_percent를 바꿔가며 측정한 결과까지 정리합니다.
:스트리밍 실험 기록TypeSafe AI가 9월 15일 공개한 결정 모델 Jev와는 이름만 같고 아무 관계가 없는 또 다른 Jev를 오픈소스 GPU 최적화 프로젝트에서 발견했습니다. RTX 4070 12GB 한 장에 실제로 설치하고 keep_percent를 바꿔가며 측정한 결과까지 정리합니다.
텐센트 훈위안의 이미지 생성 모델 Hy Image3.5 Preview가 9월 22일 정식 공개됐습니다. 참고 이미지 20장까지 한 번에 다루는 편집 능력과 4K 출력, 공개된 벤치마크와 실제로 만들어본 결과물까지 정리합니다.
SSAI에서 광고 스티칭이 실패하는 흔한 원인 중 하나는 크리에이티브가 제때 트랜스코딩되지 않는 경우입니다. AWS MediaTailor의 실제 FILLED_AVAIL 로그 스키마와 의사코드로 광고 단위 처리를, 그 대척점에 있던 Tencent Cloud StreamPackage의 구간 단위 처리를 비교하고 개선까지 이어진 과정을, 그리고 StreamPackage 콘솔의 Ad Insertion Statistics로 그 개선을 확인하는 방법까지 정리합니다.
광고가 화면에 나갔다는 것만으로는 광고비를 정산할 수 없습니다. SSAI에서 재생 진행 상황을 서버가 직접 보고하는 비콘 구조를 AWS MediaTailor의 예시로 살펴보고, Tencent Cloud StreamPackage가 같은 체계를 어떻게 지원하는지 정리합니다.
SSAI로 스티칭된 광고는 플레이어 입장에서 그냥 영상일 뿐이라 VAST의 ClickThrough를 그대로 쓸 수 없습니다. StreamPackage가 세션 초기화와 트래킹 폴링만으로 이 문제를 어떻게 푸는지, 실제 세션을 직접 만들어보며 정리합니다.
영상 생성 모델은 품질을 올릴수록 비용이 함께 뛰는 경우가 많습니다. 텐센트가 자체 개발한 WAND-Vega가 등급을 나눠 이 문제를 어떻게 풀었는지, 그리고 스토리보드부터 사운드까지 이어지는 제작 파이프라인을 정리합니다.
CVD를 TKE 등록 노드와 TI-ONE 외부 자원 그룹으로 각각 편입하는 절차를 정리하고, 추론과 학습이 요구하는 자원이 어떻게 다른지, 서비스 공개 전에 확인해야 할 장애 대응 체크리스트를 실측 기준으로 정리합니다.
라이브 광고 구간마다 광고 결정 서버를 실시간으로 호출하면 수만 세션이 한 번에 몰려 타임아웃과 Fill-rate 하락으로 이어집니다. StreamPackage의 SSAI Ad Prefetching이 이 요청을 어떻게 앞당겨 분산시키는지, 그리고 CLS 로그로 어떻게 확인하는지 정리합니다.
SSAI 광고에 CTA 버튼을 직접 붙여보면서 겪은 세 가지 문제를 정리합니다. clickThrough URL이 내려와도 CTA가 안 뜨는 경우, 클릭은 되는데 지표가 안 잡히는 경우, 트래킹 응답이 첫 번째 이후로 계속 비어 있는 경우입니다.
GPU 배치, 샘플링 단계 수, 해상도를 바꿔가며 영상 생성 파이프라인의 단건 지연시간과 시간당 처리량을 실측하고, 실제 GPU 인스턴스 단가로 완성 영상 한 편의 비용을 계산합니다.
GPT, Claude, Gemini 같은 상위 모델을 매번 호출하면 답변 품질은 좋지만 트래픽이 늘수록 비용이 그대로 늘어납니다. 시중에 있는 Service LLM API 하나로 여러 모델의 답변을 모아 내 목적에 맞는 소형 모델을 학습시키는 방법과, 이게 왜 비용 면에서 유리한지를 실제로 5억 파라미터 모델을 직접 학습시켜본 결과로 정리합니다.
MiniMax-H3를 SGLang 포트에 직접 붙이는 대신, 초해상도 후처리와 모델 전환까지 포함한 별도 Agent API(7002)로 감싸고, 재시도/다운로드/검증까지 갖춘 Python 클라이언트로 실제 요청을 끝까지 흘려봤습니다.
MiniMax H3 영상생성 모델을 SGLang으로 서빙하면서 BF16/FP8, Turbo LoRA/LightX2V 가속, 4GPU 단일 인스턴스부터 1GPU 복제까지 GPU 배치를 바꿔가며 실제로 돌려보고 지연/처리량 차이를 확인합니다.
AI로 영상을 뽑으려면 카메라 위치와 동선, 공간 구조까지 프롬프트 한 줄에 눌러 담아야 했습니다. Higgsfield는 OpenAI의 최신 모델 GPT-6 Astra를 픽셀 대신 장면 설계를 맡는 기획 레이어로 쓰고, 실제 렌더링은 자사 영상 모델 Seedance 2.5에 맡기는 방식으로 이 문제를 풀었습니다.
AI 영상 생성 툴 Higgsfield는 영상을 그리지 않는 AI를 장면 설계 담당으로 세워두고, 실제 렌더링은 자사 모델에 맡깁니다. 같은 아이디어를 Text LLM과 HY 3D, WAND-Vega로 직접 재현해, 카지노 원테이크 장면 하나를 프롬프트에서 완성 영상까지 뽑아본 핸즈온 기록입니다.
MiniMax H3 영상생성 모델을 CVD GPU 인스턴스에 올리고, ComfyUI 워크플로와 SGLang API 두 실행 경로를 각각 구성해 실측했습니다. 4 GPU 병합 경로와 단일 GPU 4분할 경로에서 Turbo LoRA가 서로 다르게 동작한다는 점도 실제로 확인했습니다.
같은 CVD GPU 워크스페이스에 GLM-5.3-Flash를 배포하고, DeepSeek 배포와 관리 방식/인증/추론 옵션이 실제로 어떻게 다른지 실측으로 비교합니다.
DeepSeek-V4-Flash 전용 CVD 이미지에서 vLLM 기반 API를 직접 띄우고, CLI/REST/Python 세 경로로 호출하며 스트리밍, 추론 모드, 도구 호출, 컨텍스트 길이 변경까지 실제로 확인합니다.
Tencent Cloud Desktop(CVD) 위에 GPU 기반 AI 에이전트 워크스페이스를 구축하는 과정을 실제로 밟아봤습니다. GPU가 언제 필요하고 언제 필요 없는지부터, GPU 메모리 산정, 인스턴스/이미지 구성, 콘솔/사설망/공인망 접속 경로까지 실측으로 정리합니다.
Tencent Hy3의 후속 모델 Hy4-preview가 오픈웨이트로 공개됐습니다. 770B 파라미터 중 49B만 활성화하는 MoE 구조와 벤치마크 상승폭, 실제로 써본 인상을 정리합니다.
AOMedia가 VP9 이후 내놓은 오픈소스 코덱 AV1이 어떤 기술로 압축 효율을 끌어올렸는지 정리합니다. 코딩 블록 분할, 인트라/인터 예측, 변환, 엔트로피 코딩, 루프 필터링까지 VP9와 항목별로 비교하고, H.264, H.265와 함께 실제 적용 분야까지 짚습니다.
모바일 웹에서 저지연(WebRTC) 라이브를 일시정지했다가 다시 재생하면 화면이 HLS로 폴백되어 있는 현상을 추적합니다. 원인은 fps와 bitrate만으로 스트림 생사를 판정하는 로직이 사용자의 pause와 실제 네트워크 단절을 구분하지 못한다는 데 있습니다.
타임시프트 재생 URL의 delay 파라미터가 캐시 키에 그대로 들어가면서 조합 수가 3만 개 규모로 불어났고, 오리진 요청이 처리 한도의 약 3배까지 몰리며 404가 다운스트림 CDN까지 퍼진 장애를 복기합니다. request collapse가 무력화되는 조건과, 캐시 키 설계를 오리진 용량 설계 문제로 바라봐야 하는 이유를 정리합니다.
광고 종료를 알리는 SCTE35-IN 마커가 선언된 END-DATE보다 평균 2.2초, 최대 4.7초 일찍 매니페스트에 나타났습니다. 49개 샘플을 모아보니 원인은 IN 발행 로직이 아니라 OUT 태그가 세그먼트 경계에 맞춰 밀리는 현상에 있었습니다.
SRT로 들어온 SCTE-35 OUT 신호의 splice 시점과 HLS 매니페스트에 찍힌 START-DATE 사이에 최대 8초의 차이가 관측됐습니다. 원인을 뜯어보니 관측 경로가 달라서 생기는 고정 3초와, CTS가 큰 스트림에서 splice 지점 판단이 흐려져 segment 경계까지 밀리는 가변 0초에서 5초가 겹쳐 있었습니다. 두 성분을 분리하면 측정에서 그냥 차감할 부분과 실제로 고쳐야 할 부분이 갈립니다.
RTMP로는 멀쩡하던 스트림이 HLS로 패키징하면 첫 프레임에서 디코더가 죽는 사고를 따라갑니다. 원인은 NAL 유닛 자체가 아니라 그걸 감싸는 포장 방식(AVCC와 Annex B)이 컨테이너마다 다르다는 데 있습니다. RTMP, SRT, MPEG-TS, fMP4가 각각 어떤 포장을 쓰는지, 그리고 왜 그렇게 정해졌는지를 정리합니다.
508초짜리 SCTE-35 마커에 15초 단위 광고 소재를 채우면 495초에서 멈춥니다. 남은 13초가 EXT-X-PROGRAM-DATE-TIME과 EXTINF 누적값을 갈라놓습니다. 이건 로직 버그가 아니라 나눗셈이 안 떨어지는 산술적 한계이고, 고칠 수 있는 부분과 고칠 수 없는 부분을 구분해서 정리합니다.
같은 StreamPackage 채널이라도 SSAI를 붙이면 세그먼트 URI 표기법이 갈라집니다. 라이브 세그먼트는 Content Source 기준의 절대경로, 광고 세그먼트는 /v1/로 시작하는 루트 상대경로입니다. SSAI를 빼면 라이브 세그먼트는 다시 상대경로로 돌아갑니다.
동일한 1080p 원본을 libx264와 libx265로 인코딩해 비트레이트와 VMAF를 실측 비교합니다. CRF, VBV, preset, keyint, rc-lookahead 같은 핵심 파라미터가 두 인코더에서 서로 다른 값과 범위를 갖는 이유를 원리부터 짚습니다. 절반 이하의 비트레이트로도 더 높은 VMAF 점수를 낸 실측 결과와 그 배경을 다룹니다.
같은 EXT-X-MEDIA-SEQUENCE 번호에 처음엔 라이브 세그먼트가, 4초 뒤엔 광고 세그먼트가 들어 있었습니다. HLS 사양이 금지하는 in-place 수정입니다. 원인은 광고 마커 계산과 실제 광고 소재 트랜스코딩이 서로 다른 속도로 준비되는 경합이었습니다.
라이브 스트리밍 운영 중 실제로 마주쳤던 코덱 관련 증상 6가지를 정리했습니다. 검은 화면, 오디오 싱크 어긋남, ABR 전환 깜빡임, HEVC 미지원 기기, RTMP-HLS 변환 크래시, 광고 전환 음소거까지 증상에서 원인으로 거꾸로 따라가 봅니다.
VBR 인코딩의 비트레이트 붕괴 구간이 플레이어의 ABR 판단을 속이면, 정작 버퍼링은 화면이 다시 밝아진 뒤에 발생합니다. 원본 영상 8초 암전 구간과 버퍼링 스파이크 사이의 시차를 실측 데이터로 추적합니다.
라이브 스트림에 룩백 윈도우가 길거나 시청자가 광고 도중에 합류하면, 광고 개인화를 무조건 켜두는 게 오히려 문제가 됩니다. AWS MediaTailor가 이 상황을 위해 만든 기능이 Avail Suppression입니다. 라이브 엣지를 기준으로 언제 개인화를 건너뛸지 정하는 규칙을 모드와 값, 채우기 정책 세 가지로 뜯어봅니다.
ByteDance Seed와 칭화대가 강화학습으로 CUDA 커널을 자동 생성하는 CUDA Agent를 공개했습니다. torch.compile 대비 평균 2.11배 빠른 결과를 학습 데이터 합성, Agent 루프, 보상 설계라는 세 축으로 뜯어봅니다.
트랜스포머와 어텐션부터 CUDA, PyTorch, PTX, 양자화, MoE, 서빙 인프라까지 프롬프트 하나가 답변이 되기까지 거치는 계층을 흐름 중심으로 정리합니다.
AI 엔지니어링은 좋은 프롬프트를 쓰는 단계를 지나, 어떤 컨텍스트를 넣고 어떤 실행 하네스로 제어할지의 문제로 넘어가고 있습니다. 실제 서비스에서 중요한 건 모델의 똑똑함보다 통제 가능한 시스템입니다.
코덱, 비트레이트 컨트롤, GOP와 B-frame, Profile과 Level, preset, 색공간 메타데이터까지, 이 시리즈에서 FFmpeg와 Tencent Cloud MPS로 각각 실측했던 파라미터 처리 방식을 한 표로 종합합니다. 같은 소스에 가능한 한 동일한 값을 넣어 두 경로를 직접 돌려본 결과도 함께 정리합니다.
CVD는 클라우드에서 가상 데스크톱을 만들고 사용자 접속, 보안 정책, 파일 제어를 중앙에서 관리하는 DaaS 서비스다.
텐센트 수석 AI 과학자 야오순위와 CSIG 총책임자 탕다오셩이 나눈 공개 대담을 번역했습니다. 좋은 문제를 찾는 게 더 중요해진 AI 하반전, 컨텍스트가 곧 경쟁력이 되는 이유, 기반과 제품과 프론티어라는 세 기둥까지 두 사람이 각자의 언어로 짚습니다.
요청한 시간, 서버가 받은 시간, 실제 세그먼트에 박힌 시간은 같은 시간이 아닙니다.
Timed metadata를 넣는다고 해서 JSON 문자열을 base64로 던지면 되는 건 아니었습니다.
ID3가 세그먼트 시작보다 앞에 있다는 이상한 계산은 스트림 문제가 아니라 분석 코드 문제였습니다.
Tencent Cloud VOD의 AIGC는 텍스트, 이미지, 영상 생성 모델을 한 게이트웨이에서 호출하게 해주는 미디어 AI 기능입니다. 이 글에서는 구조를 정리하고, 프롬프트로 이미지를 만든 뒤 그 이미지를 기반으로 짧은 영상을 뽑는 실습 흐름까지 잡아보겠습니다.
AAC 오디오 트랜스코딩에서 sampling rate, bitrate, channel 설정이 실제로 어떻게 반영되는지 FFmpeg와 Tencent Cloud MPS 양쪽에서 직접 인코딩해 ffprobe로 검증했습니다. 특히 저비트레이트 구간에서 두 경로가 값을 다루는 방식이 다르다는 점을 실측으로 확인했습니다.
SSAI는 광고를 서버 측에서 본편 스트림에 합성해 하나의 연속된 스트림처럼 내려보내는 방식입니다. VAST, SCTE-35, Beacon, Manifest Manipulation을 같이 이해해야 운영에서 덜 터집니다.
BT.2020, PQ(smpte2084), matrix coefficients 같은 HDR 색공간 메타데이터가 트랜스코딩 과정에서 유지되는지 실측합니다. 진짜 HDR 그레이딩 소스가 없어서 SDR 소스의 컨테이너 태그만 인위적으로 재태깅하는 방식으로 검증했고, FFmpeg 로컬 파이프라인과 Tencent Cloud MPS 양쪽에서 태그가 다른 결과를 보였습니다.
AWS Bedrock은 질문 분류에만 쓰고, 실제 답변 생성은 Tencent Cloud VOD Text LLM API로 넘기는 챗봇을 Terraform으로 배포해봅니다. 실습 과정에서 만난 IAM, Bedrock inference profile, Lambda Function URL 차단, API Gateway 29초 제한까지 같이 정리합니다.
TSC의 핵심은 "같은 화질, 적은 비트레이트"다. 일반 x264 대비 동일 VQA 스코어에서 비트레이트를 30% 이상 줄이는 게 목표이고, CPU 사용량은 거의 동일하거나 오히려 줄어든다. 클라우드 MPS API로 쓸 수도 있지만, 자체 인프라에서 대량 트랜스코딩을 돌리거나, 기존 ffmpeg 파이프라인에 TSC를 끼워 넣고 싶은 경우에는 이 SDK가 필요하다. AWS로 치면 MediaConvert의 QVBR 모드와 비슷한 포지션이며, TSC는 별도 인코더 바이너리로 빠져 있어서 자체 인프라에서도 사용가능하다.
Top Speed Codec은 장면 인식과 동적 비트 배분으로 같은 화질에서 비트레이트를 줄이는 Tencent Cloud의 지능형 인코딩 기술입니다. CDN 비용, 코덱 선택, 실제 적용 방식 관점에서 봅니다.
라이브 스트리밍에서 Failover는 장애가 났을 때 시청자 화면을 어떻게 살릴지의 문제입니다. StreamLive와 AWS MediaLive의 이중화 모델을 비교하고, 실제 구성 시 고려할 지점을 정리합니다.
FFmpeg(libx264/libx265)의 ultrafast부터 veryslow까지 5단계 preset을 동일 CRF와 동일 목표 비트레이트 조건에서 각각 실제로 인코딩해 소요 시간, 출력 비트레이트, VMAF 변화를 실측합니다. Tencent Cloud MPS에는 x264 preset과 똑같은 손잡이는 없지만, 극속고화질(TEHD) 기능에 딸린 압축 전략 옵션이 비슷한 역할을 한다는 것도 함께 확인합니다.
H.264 Baseline/Main/High Profile과 Level 1.0~4.2 조합을 FFmpeg(libx264)로 실제 인코딩하고, 해상도와 비트레이트가 지정한 Level의 한계를 넘을 때 인코더가 경고만 내고 넘어가는지 아니면 값을 바꿔버리는지 ffprobe로 검증합니다. 같은 조합을 Tencent Cloud MPS에서도 실측해서 로컬 결과와 비교합니다.
Tencent Cloud Stream 시리즈에서 SSAI를 구성하려면 StreamLive가 SCTE-35 신호를 처리하고, StreamPackage가 매니페스트 조작과 광고 삽입을 맡습니다. 콘솔 옵션을 실제 파이프라인 관점에서 정리합니다.
라이브 스트림 초반 몇 개 GOP만 짧게 잡고 이후엔 일반 GOP로 돌아가는 Startup GOP 구조를 FFmpeg로 직접 만들어 ffprobe로 키프레임 위치와 구간별 비트레이트를 실측합니다. Tencent Cloud MPS의 VideoTemplate 스키마에 같은 개념이 노출돼 있는지도 API로 직접 확인합니다.
720p/360p 등급만 쓰기로 한 ABR 템플릿인데, 가로로 넓은 화면(예: iPad)에서만 유독 1080p 과금이 트리거된다는 문의가 들어왔습니다. 원인은 한쪽 변만 고정하는 단순한 스케일링 규칙이 화면비 구간에 따라 다른 쪽 변을 등급 상한 밖으로 밀어낸 것이었고, 화면비 구간별로 장변/단변 우선순위를 나눠서 해결했습니다.
며칠 전, Netflix가 자체 라이브 스트리밍을 위해 만든 커스텀 오리진 서버에 대한 기술 블로그 글을 공개했습니다. 2024년 타이슨-폴 복싱 경기에서 동시 6,500만 스트림을 처리한 인프라의 핵심 컴포넌트입니다. 일반적인 CDN 오리진과는 결이 다른, 라이브 전용 설계가 곳곳에 녹아 있어서 하나씩 뜯어봅니다.
StreamPackage는 라이브 스트림을 HLS/DASH로 패키징하고 DRM, SSAI, 타임시프트, 오리진 기능을 제공하는 미디어 패키징 서비스로, AWS의 Elemental mediapackage를 대체할 수 있는 텐센트의 클라우드 미디어 솔루션이다.
GOP 길이와 B-frame 개수를 바꿔가며 같은 소스를 실제로 인코딩하고, ffprobe로 I/P/B 프레임 시퀀스와 키프레임 위치를 직접 확인합니다. HLS 세그먼트 경계가 GOP와 어떻게 맞물리는지, Tencent Cloud MPS에서 같은 GOP 설정을 걸면 결과가 어떻게 나오는지도 실측으로 검증합니다.
StreamLink는 AWS의 Elemental MediaConnect 와 같이 라이브 스트림을 안정적으로 받아 다른 리전, 프로토콜, 목적지로 전달하는 관리형 전송 서비스다.
CBR, VBR, ABR, CRF 네 가지 레이트 컨트롤 방식으로 같은 소스를 실제로 인코딩해서 평균 비트레이트, 초당 변동폭, 파일 크기를 프레임 단위로 실측 비교합니다. Tencent Cloud MPS의 Bitrate 파라미터가 선언한 숫자를 그대로 지키는지, 아니면 소스와 해상도에 따라 넘나드는지도 실제 API 호출로 확인합니다.
Tencent Cloud StreamLive와 AWS MediaLive는 둘 다 해상도 등급으로 트랜스코딩 요금을 매기지만, 그 등급을 산출하는 공식 자체가 다릅니다. StreamLive는 장변과 단변을 함께 보는 2차원 판정이고, MediaLive는 세로 해상도 값 하나만 보는 1차원 판정입니다. 세로 숏폼 라이브 하나만 예로 들어도 두 서비스의 청구 등급이 완전히 갈립니다.
Tencent Cloud MPS는 출력 영상의 가로세로 픽셀 수를 그대로 보지 않고, 장변/단변과 화면비를 조합한 별도 공식으로 해상도 등급을 매깁니다. 이 등급이 그대로 분당 단가로 이어지기 때문에, 같은 '1080 높이' 영상이라도 화면비에 따라 실제 청구 금액이 최대 55% 차이 납니다.
크로마 서브샘플링(4:2:0/4:2:2/4:4:4)과 비트 뎁스(8bit/10bit)가 실제 인코딩 결과에 어떤 차이를 만드는지 FFmpeg로 직접 인코딩하고 ffprobe로 검증합니다. 클라우드 트랜스코딩 API에 같은 조합을 요청했을 때 실제로 받아들여지는 범위가 로컬 인코더와 어떻게 다른지도 실측으로 확인합니다.
H.264, H.265, VP9, AV1 네 코덱으로 같은 원본을 실제로 인코딩해 파일 크기, 비트레이트, 인코딩 시간, VMAF 점수를 비교합니다. 고움직임 소스와 저움직임/고복잡도 소스에서 압축 효율이 어떻게 달라지는지, 그리고 로컬 FFmpeg 결과와 Tencent Cloud MPS 트랜스코딩 결과가 어떻게 다른지도 실측으로 확인합니다.
Tencent Cloud VOD는 업로드, 저장, 관리, 처리, AI 분석, 배포와 재생까지 담당하는 파일 기반 미디어 플랫폼으로, 단순히 미디어 저장소의 역할만 하는 것이 아닌, 생성형 AI와 관련된 기능이 모두 통합되어있는 AI 미디어 스토리지 솔루션이다.
StreamLive는 Tencent Cloud 미디어 파이프라인에서 라이브 신호를 받아 방송용 출력으로 가공하는 채널 기반 처리 서비스로, AWS의 Elemetal MediaLive의 텐센트 버전 제품이다.
CAR는 무거운 3D 애플리케이션을 클라우드 GPU에서 실행하고, 사용자는 얇은 단말에서 영상 스트림으로 조작하게 해주는 텐센트의 클라우드 렌더링 서비스다.
라이브 스트리밍 운영하다 보면 "소리가 안 들려요"라는 리포트가 들어올 때가 있다. 원인은 수십 가지다. 플레이어 문제, 트랜스코딩 오디오 트랙 누락, 코덱 미스매치, 오디오 레벨 자체가 바닥.. 어디서부터 봐야 하는지 감이 안 올 수 있다. 결론부터 말하면, 원본부터 확인하는 게 제일 빠르다. 파이프라인 끝단(플레이어)에서 올라가는 것보다, 입력단(소스)에서 내려가는 게 디버깅 효율이 훨씬 좋다.
MPS는 단순한 트랜스코딩 서비스라기보다 Tencent Cloud 미디어 제품군 뒤에서 영상을 처리하는 공용 엔진에 가깝다.
MPEG-DASH는 MPD라는 XML 매니페스트로 Period, AdaptationSet, Representation, Segment 구조를 표현하는 HTTP 기반 적응형 스트리밍 표준입니다. HLS와 비슷하지만 표현력과 생태계가 다릅니다.
CSS는 Tencent Cloud의 라이브 스트리밍 전용 클라우드 서비스다. 인코더로부터 스트림을 수신해 클라우드에서 처리하고, CDN으로 시청자에게 배포하는 원스탑 라이브 스트리밍 플랫폼이다. 트랜스코딩, 녹화, 타임시프트, 워터마크, 미디어 AI, 콘텐츠 모더레이션까지 별도 서비스 없이 CSS 안에서 모두 처리할 수 있다.
LL-HLS는 기존 HLS의 세그먼트 기반 지연을 Part, Blocking Reload, Preload Hint로 줄이는 저지연 확장입니다. 구조는 단순해 보이지만 실제 운영에서는 CDN, 오리진, 플레이어가 같이 맞아야 합니다.
Tencent RTC란 텐센트클라우드의 실시간 커뮤니케이션 클라우드 서비스로 음성 및 동영상 통화, 라이브 채팅, 라이브 스트리밍, 인터넷 강의, 화상회의, 뷰티필터 등 미디어적으로 구현할 수 있는 거의 모든 기능을 제공하는 상품이다. 이례적으로 독립적인 상품 홈페이지까지 있는 것으로 보아 텐센트클라우드의 베스트셀러로 보이는 이 TRTC의 카테고리와 장점을 공식 홈페이지에서는 아래와 같이 소개하고 있다.
어느 날 Tencent Cloud EdgeOne 콘솔에서 새로운 메뉴를 발견했다.
출근 길 버스에서 고객사의 전화 한 통을 받았다. 고객사는 서비스 확장을 위해 스테이징 환경에서 텐센트클라우드의 CVM과 TencentDB로 작은 웹 서비스 아키텍쳐를 구성했는데 DB접속이 안 되는 현상이 발생했다고 했다. 구체적인 이슈는 이러했다.
Tencent Cloud AI Code Assistant는 텐센트에서 5월에 공개한 AI 코딩 어시스턴트 툴로, 텐센트의 자체 거대 언어 모델인 훈위안(混元,hunyuan)을 기반으로 개발되었다. 개발자들에겐 이미 Copilot이나 CursorAI 등의 다른 AI 코딩 툴을 먼저 접해봐서 익숙할텐데 Tencent Cloud AI Code Assistant 역시 코드 자동완성, 변수명 제안, 리팩토링, 테스트코드 작성, 최적화 등 코딩 시 개발자에게 편리한 기능을 제공해준다. VScode나 인텔리제이 IDE 제품들 내부에서 플러그인 형태로 적용 가능하며 현재는 중국 콘솔에만 베타버전으로 오픈된 것으로 보인다.
Tencent Cloud의 스팟인스턴스는 Pay-as-you-go 대비 매우 저렴한 가격으로 인스턴스를 빌려 사용할 수 있는 과금모델이다. 그러나 인스턴스의 재고상황에 따라 자동으로 회수되는 특성 때문에 프로덕션 환경에 직접적으로 사용하기에는 적합하지
메이저 클라우드 벤더들이 그러하듯 텐센트클라우드 역시 자체개발한 OS를 오픈소스로 제공하고 있다. CentOS를 기반으로 한 리눅스 배포판인 TencentOS Server가 바로 그 것. 당연하게도 CentOS와 호환되며 텐센트클라우드 상품에 최적화된 성능을 제공한다고 한다. CentOS의 유지관리가 중단된 시점에서 갈 길을 헤매고 있는 이들에게 새로운 한 줄기 빛이 될 수 있을지 텐센트가 소개하는 TencentOS Server의 내용을 살펴보도록 한다.
Tencent Cloud의 Cloud Block Storage를 구매한 후 인스턴스에서 정상적으로 접근하려면, 해당 인스턴스에 CBS 리소스를 마운트하는 과정이 필요합니다. 또한, 필요한 경우 파일 시스템을 포맷하고 파티션을 설정하는 작업도 진행해야 합니다. 이 글에서는 리눅스 시스템에서 이러한 과정을 진행하는 방법을 소개합니다.
기업이 클라우드 도입으로 얻는 이점 중 비용절감에 대한 부분은 빼놓을 수 없는 요소이다. 클라우드 운영비용이 자체 데이터센터 운영이나 코로케이션 모델보다 비용적인 우위를 가지느냐는 여전히 뜨거운 논쟁거리이지만 클라우드에 적합한 서비스에 훌륭한 아키텍쳐의 설계가 합쳐지면 충분히 경제적인 인프라 운영이 가능한 것도 사실이다. 여기에 담당자의 적절한 비용 최적화 운영을 더한다면 기업 입장에서는 더 큰 이득을 얻을 수 있다.
Lighthouse는 경량 애플리케이션 개발, 웹 사이트, 테스트 환경 구축등의 시나리오를 위해 텐센트클라우드에서 제공하는 클라우드 호스팅 서비스로 워드프레스, Node.js , LAMP , 도커등의 오픈소스 소프트웨어를 쉽게 호스팅 할 수 있는 환경을 제공합니다. 사용자는 프로그램이나 런타임 환경의 설치를 고려할 필요 없이 몇 번의 클릭만으로 원하는 스택을 선택하여 웹 애플리케이션을 구축하고 관리하고 할 수 있습니다.
예약 인스턴스 구매 후, 고객사의 사정으로 인해 RI의 구조를 변경해야 하는 경우가 생기기도 합니다. 이럴때 이미 구매한 RI를 최대한 활용하여 효율적으로 구독 모델을 구성하는 방법을 소개합니다.
IaC를 도입한 프로젝트에서 가장 많이 작성하게 되는 건 아무래도 가상머신 프로비저닝에 관한 코드일 것입니다. 프로젝트의 규모가 클 수록 많은 tfstate 파일과 configuration tf 파일을 관리하는 일도 쉬운 일은 아니지만 이러한 반복작업을 클라우드 콘솔에서 진행하는 것에 비하면 훨씬 생산적입니다. 이 글에서는 기본적인 스펙의 Tencent Cloud CVM을 생성하는 간단한 IaC 예제를 소개합니다.
어떤 CSP를 쓰든 MSP로 바인딩 된 계정이라면 대부분 콘솔에서 MSP 담당자들이 직접 어카운트에 크레딧을 할당해 주고 유저는 그 크레딧으로 온디맨드 클라우드 리소스의 사용료를 차감해서 사용하는 방식을 채택하고 있다. MSP 담당자들이 놓치지 않는 이상 고객사 계정의 크레딧이 0이 될 일은 사실상 거의 없긴 한데, 아주 가끔 그런 일이 발생하지 말라는 보장은 또 없기 때문에 최근에 비슷한 일을 겪은 입장에서 크레딧이 0이 된 MSP 바인딩 계정의 CVM 리소스는 얼마 기간 동안 정상적으로 버틸 수 있을지 궁금하여 한 번 찾아보았다. Tencent Cloud 공식 홈페이지에 친절히 관련 내용이 설명되어있다.
이 글에서는 [Tencent Cloud EdgeOne의 애플리케이션 가속 기능](https://perfective.tistory.com/entry/EdgeOne-Tencent-Cloud-EdgeOne%EB%A5%BC-%EC%95%8C%EC%95%84%
이 섹션은 하시코프사의 IaC 도구인 테라폼(Terraform)으로 클라우드 인프라를 관리하는 방법을 간단하게 소개합니다. 테라폼은 Tencent Cloud를 Provider로 지원하고 있으므로 손쉽게 IaC로 리소스를 관리할 수 있습니다.
"ICP 비안을 발급 받지 않은 웹 사이트를 운영하는 해외기업이 EdgeOne의 가속솔루션을 사용을 위해 EdgeoNe에 도메인을 등록할 때 아래 단계에서부터 어려움을 겪게 됩니다. 중국 유저에게 서비스를 해야하기 때문에 Chinese mainland 혹은 Global을 선택해야 하지만 모두 해당 사이트에 ICP비안이 발급되어있는지 검증하는 절차를 통과해야 합니다.
Tencent Global Digital Ecosystem Summit 2023는 Tencent 에서 매년 개최하는 글로벌 Summit 행사로, 참석 후기를 정리해보았습니다.
고객사는 글로벌 전자상거래 플랫폼으로 전 세계 고객들에게 상품을 판매하는 플랫폼을 운영하는 기업입니다. 내년을 목표로 새로운 지역에 서비스를 확장 오픈 하려는 계획을 가지고 있습니다.
출처 : https://chat.openai.com ChatGPT Chatbot Slack에 ChatGPT를 연동하여 간단한 챗봇을 구현하는 작업은 이미 너무 유명하여 구글링만 해봐도 수 십개의 관련 블로그글이 검색된다. 가장 기본적인 방식은 AWS Lambda를 활용한 구현인데, 이번에 우리는 람다대신 Tencent c
ENI는 VPC 환경에서 가상 네트워크의 역할을 하는 논리적 네트워크 구성 요소로 온프레미스 환경에서 사용되는 NIC에 대응되는 개념이다. 이 글에서는 Tenc
이 글에서는 Tencent cloud의 VPC리소스가 외부 공용 인터넷에 접근하는 방식을 AWS와 비교분석합니다.
Auto Scaling은 클라우드 시스템 자원을 필요에 따라 자동으로 추가하고 제거하는 스케일링 시스템이다. 이 글에서는 간단한 실습으로 콘솔에서 Tencent cloud Auto Scaling을 체험하는 내용을 담았다.
CHAT은 소셜 커뮤니케이션, 고객 서비스 메시징, 챗봇, 온라인 학습, 라이브 스트리밍, 대화형 게임, 웹 3, 음성 및 화상 통화 앱 또는 웹사이트 구축을 위한 확장 가능하고 빠른 API, SDK 및 UIKit이다.
이전글에 이어 CVM 세팅하기 이제 본격적으로 CVM을 세팅한다. 총 5대의 CVM을 프로비저닝 하면 되는데, Bastion host용으로 사용할 CVM은 Public subnet에 두고, 나머지 4대의 가상머신은 Web server와 WAS로 쓸 것이기 때문에 모두 private subnet에 배치한다. 세팅이 끝나면
Analysis 고객사는 요즘 젊은 세대들의 필수품인 사진 편집 및 필터기능을 제공하는 기업으로, 플랫폼의 대대적인 기술적 개편을 진행하는 과정에서 해당 도메인에 대한 설계를 서버리스 아키텍처로 전환하고자 합니다.
고객사는 혁신적인 실시간 오디오 스트리밍 플랫폼을 개발하는 스타트업으로, 사용자들이 언제 어디서나 DJ가 되어 자신만의 이야기를 전 세계와 공유할 수 있는 공간을 제공합니다.
클라우드를 이용한 DR multi-region 설계를 제공해야 하는 아키텍쳐 입니다.
고객사는 IoT기반 전기차 관리 애플리케이션을 제작하는 업체입니다. 고객사에게 클라우드 기반 아키텍쳐를 제안합니다.
텐센트클라우드의 서버리스인 SCF와 OCR API로 간단한 예제를 제작합니다.
클라우드 기반 아키텍쳐 설계의 기본이 되는 3-tier 구조를 구현합니다.
모놀리직 아키텍쳐를 Tencent의 cloud 인프라로 마이크로서비스로 전환합니다.
온라인 교육 플랫폼을 운영하는 스타트업에 Tencent Cloud 를 통한 클라우드 아키텍쳐를 제안합니다.