- Phí phiên âm audio của OpenAI được tính theo độ dài của audio đầu vào
- Nếu chuyển audio sang tốc độ 2–3x bằng các công cụ như ffmpeg rồi tải lên, có thể giảm thời gian xử lý và chi phí mà không làm giảm chất lượng phiên âm
- Khi thử với audio 40 phút và tăng tốc 2x, 3x, chi phí thực tế giảm 23–33%
- Mô hình gpt-4o-transcribe chỉ hỗ trợ audio dưới 25 phút, nên tăng tốc là một cách lách giới hạn hữu ích
- Chất lượng kết quả vẫn được giữ ở mức 2–3x, nhưng ở tốc độ 4x thì độ chính xác phiên âm giảm mạnh
Giới thiệu tóm tắt
- Một cách đơn giản để tận dụng hiệu quả hơn chính sách giá cho phiên âm và audio của OpenAI
- Chiến lược tăng tốc chuyển đổi audio để xử lý cùng một nội dung trong thời gian ngắn hơn, từ đó tiết kiệm cả chi phí lẫn thời gian
- Nếu dùng các công cụ mã nguồn mở như ffmpeg để chuyển file audio sang nhanh hơn 2–3 lần rồi tải lên OpenAI API, có thể giảm giá và thời gian xử lý mà không mất chất lượng
- Cách này đặc biệt hiệu quả với các audio dài, nhất là khi bị giới hạn độ dài đầu vào (ví dụ giới hạn 25 phút của mô hình gpt-4o-transcribe)
Cách cốt lõi để tiết kiệm thời gian/chi phí phiên âm
- Dịch vụ phiên âm audio của OpenAI tính phí dựa trên độ dài audio mà nó nhận vào
- Vì vậy, nếu tăng tốc file giọng nói trước lên 2–3x bằng ffmpeg hoặc công cụ tương tự rồi mới tải lên, số token đầu vào sẽ giảm đáng kể, đồng thời thời gian xử lý phiên âm cũng ngắn hơn
- Áp dụng cách này trong thực tế, với audio dài 40 phút, chi phí token đầu vào giảm hơn 33% (3x là $0.07, 2x là $0.09)
- Chi phí token đầu ra gần như không đổi bất kể tốc độ audio, vì nó được phân bổ tự động dựa trên độ dài phần tóm tắt đầu ra
- Tốc độ 2x và 3x cho độ chính xác phiên âm ổn định, nhưng ở 4x thì mô hình bắt đầu không nhận diện đúng nội dung
Ví dụ script sử dụng
Cần dùng các công cụ mã nguồn mở sau:
- yt-dlp: trích xuất audio từ YouTube và các nguồn tương tự
- ffmpeg: chuyển đổi audio và điều chỉnh tốc độ
- llm: tự động hóa việc tóm tắt văn bản
Quy trình tổng thể để tham khảo:
- Trích xuất audio bằng yt-dlp, sau đó
- Dùng ffmpeg chuyển audio sang tốc độ 2–3x và lưu dưới dạng mp3
- Tải mp3 lên OpenAI API (
gpt-4o-transcribe) để lấy văn bản phiên âm - Đưa văn bản kết quả vào
llmđể tự động tạo bản tóm tắt mong muốn
Trải nghiệm thực tế và những lần thử sai
- Ban đầu tác giả định dùng bản phiên âm tự động của YouTube, nhưng do dùng bản yt-dlp cũ (2025.04.03) nên xảy ra lỗi tải xuống
- Sau khi cập nhật chương trình thì đã hoạt động bình thường, nhưng trong lúc đó tác giả đã thử cách trích xuất thủ công + tăng tốc bằng ffmpeg → xử lý qua OpenAI API
- Khi chạy Whisper cục bộ trên M3 MacBook Air, xuất hiện vấn đề về pin và tốc độ chạy, nên offload lên cloud (OpenAI API) nhanh và hiệu quả hơn
Chất lượng phiên âm và đặc tính thuật toán
- Ngay cả khi tăng tốc audio lên 2x–3x, cũng giống như con người nghe bản gốc ở tốc độ cao, mô hình AI vẫn gần như nhận diện được đầy đủ thông tin cốt lõi
- Tương tự việc tối ưu dung lượng file ảnh (định dạng lossless/lossy), dù có mất một phần thông tin nghe được ở tốc độ cao (ví dụ thỉnh thoảng mất từ), điều đó vẫn không ảnh hưởng nhiều đến việc tóm tắt và hiểu nội dung
- Cũng như não người có thể bù để hiểu các từ viết sai chính tả hoặc câu chữ bị lược bớt, thuật toán phiên âm cũng trích xuất được phần lớn thông tin quan trọng từ audio đã tăng tốc
So sánh chi phí thực tế và mức tiết kiệm
- Với
gpt-4o-transcribecủa OpenAI, chi phí theo từng tốc độ audio được tính như sau- 2x (1.186 giây): $0.09
- 3x (791 giây): $0.07
- Nếu audio đầu vào quá dài (ví dụ bản gốc 2.372 giây) thì không thể xử lý do giới hạn của mô hình
- Với mô hình Whisper-1 là $0.006/phút, nên dùng cách này có thể giúp tiết kiệm tối đa khoảng 67% chi phí
- Chi phí token đầu ra gần như giống nhau bất kể tốc độ đầu vào (do ảnh hưởng của context window của mô hình và cách tóm tắt)
- Khi áp dụng 4x, kết quả đầu ra suy giảm nghiêm trọng, chẳng hạn xuất hiện các câu lặp lại
Khuyến nghị và kết luận
- Nếu muốn dùng dịch vụ phiên âm giọng nói của OpenAI nhanh hơn và rẻ hơn, thì tăng tốc audio lên 2–3x là hiệu quả nhất
- Tốc độ quá cao (4x) sẽ làm giảm độ chính xác
- Đây là cách đơn giản, dễ triển khai, đồng thời có lợi cho cả việc giữ chất lượng lẫn giảm chi phí
- Có thể áp dụng trực tiếp như một cách cắt giảm thời gian/chi phí cho startup và người làm IT thường xuyên phải xử lý dữ liệu giọng nói dài như audio kinh doanh, biên bản họp, v.v.
Tóm tắt (TL;DR)
- OpenAI tính phí dựa trên độ dài audio hoặc token đầu vào/đầu ra
- Nếu dùng ffmpeg để tăng tốc giọng nói lên 2–3x trước khi gửi vào, có thể tiết kiệm cả thời gian lẫn chi phí
- Do token đầu vào (hoặc thời lượng) giảm nên phí cũng giảm theo
- 2x và 3x là mức tốc độ tối ưu; từ 4x trở lên sẽ bắt đầu làm giảm chất lượng phiên âm
2 bình luận
Bạn có thể dùng
gpt-4o-transcribekhông?Hôm qua tôi đã hỏi OpenAI, và họ nói với tôi rằng chỉ có mô hình Whisper mới có thể được gọi bằng API key.
Tôi đang nghĩ đến việc thử Whisper với thiết lập nhanh hơn để xem chất lượng vẫn có thể được duy trì hay không.
Ý kiến Hacker News
Có cảm giác tốc độ bài nói chuyện của Andrej vốn dĩ đã là tốc độ tự nhiên nhanh hơn người bình thường ít nhất 1.5 lần, nên muốn theo kịp thì phải hạ tốc độ phát YouTube về đúng 1x. Nếu muốn dùng phút OpenAI hiệu quả hơn, có người đề xuất cách cắt hẳn các khoảng im lặng trước khi xử lý.
Với ví dụ lệnh
ffmpeg, mọi khoảng lặng dưới -50dB kéo dài hơn 20ms được thay bằng 20ms tạm dừng, và đã thử rút video 39 phút 31 giây xuống còn 31 phút 34 giây. Theo đúng tinh thần bài gốc, chỉ đo hiệu quả bằng độ dài, chưa kiểm tra riêng chất lượng của bản rút gọnTôi luôn xem mọi video ở tốc độ 2x và cả bài nói của Andrej cũng thấy 2x là tự nhiên. Tuy vậy, người xung quanh lại thường bảo video tôi làm quá nhanh nên phải xem ở 0.75x. Với tôi thì nếu không phải 2x sẽ thấy quá chậm. Tham khảo thêm, tôi còn thấy tốc độ nói của John Carmack ở 2x vẫn hoàn toàn tự nhiên. Nếu tò mò về video gần đây của tôi có thể xem tại đây; tôi đã làm hơn 250~300 video, đa số là chọn chủ đề rồi ghi ngay tại chỗ. Cũng muốn biết liệu mọi người thấy video của tôi quá nhanh, hay thật ra tốc độ đó vẫn đủ bình thường
Nếu đã không kiểm tra chất lượng, có lẽ chỉ cần so kết quả của hai phiên bản bằng thứ như diffchecker là đơn giản nhất
Ước gì YouTube có tốc độ 2.25x cho người bình thường. Tôi luôn dùng phím tắt và nghe ở 2x khoảng 90% thời gian, nhưng riêng bài nói của Andrej thì khó mà phát nhanh hơn 1.25x
Vì Andrej nói nhanh hơn người bình thường hơn 1.5 lần nên tôi đồng ý với ý rằng phải trả tốc độ YouTube về mức gốc. Không biết có cách nào tự động phát hiện tốc độ nói của con người không. Tốc độ là thứ chủ quan và khác nhau giữa mỗi người, nhưng nếu có thể phát hiện lúc cách làm của OP thất bại thì sẽ khá thú vị. (Ví dụ như khi chất lượng hỏng bét ở tốc độ x4)
Nghĩ đến việc còn có thể tận dụng thêm phép thuật
ffmpeglại thấy hào hứng. Cảm ơn vì ý tưởng này, sau tôi nhất định sẽ thửMột suy nghĩ về việc lướt qua sơ bộ so với dành thời gian đọc hoặc xem cho tử tế.
Khi chỉ đọc transcript và bản tóm tắt bài nói của Andrej, tôi thấy khá bình thường nên bỏ qua, nhưng khi xem toàn bộ video trên YouTube thì lại có trải nghiệm dẫn tới rất nhiều ý tưởng, suy nghĩ và quyết định khác nhau. Chuyện này tôi cũng hay gặp ở các chủ đề khác. Nếu trực tiếp tham dự hội nghị và nghe tại chỗ thì còn hữu ích hơn nhiều so với xem bài nói online. Ngay cả xem online cũng bổ ích hơn rất nhiều so với chỉ đọc tóm tắt. Thậm chí so với việc nghĩ qua loa 10 phút rồi thôi, đi dạo và suy nghĩ sâu lại tốt hơn hẳn. Tôi có cảm giác để suy nghĩ, làm chậm lại thường là cách tốt hơn
Điều này thật sự thấy rất lạ. Là một lập trình viên từng ghét kiểu trường học ném kiến thức đồng loạt vào đầu mọi người, giờ tôi lại sẵn sàng trả tiền cho chính dạng trải nghiệm đó. Bản thân việc đọc đã là niềm vui, và cảm giác các ý tưởng khớp vào nhau khi xem bài nói cũng rất tuyệt. Tôi cho rằng việc tự mình suy nghĩ về ý nghĩa của thế giới là điều làm con người trở nên con người. Nhưng tôi lại hoàn toàn không đồng cảm với quan điểm rằng xu hướng này đang biến tất cả trở nên ngu ngốc hơn
Rất đồng ý với ý trên. Tôi nghĩ giá trị của một bài nói không nằm ở bản thân các sự thật hay ý tưởng đã được công khai, mà ở lượng cảm hứng phụ trợ rất đa dạng nảy sinh từ đó. Trên đời có vô số thông tin, và ngữ cảnh là tất cả. Nếu có thêm một chút ngữ cảnh cụ thể hơn thì có lẽ tôi đã dành thời gian xem rồi, nhưng vì chỉ nhận được một liên kết không có ngữ cảnh nên tôi chỉ cố nắm nhanh “ý chính” để phản ứng. Rốt cuộc nhờ chủ đề này mà có khi tôi lại xem lại thật. Một lần nữa đồng ý rằng “suy nghĩ chậm thường tốt hơn”
Dù suy nghĩ chậm là quan trọng, tôi cũng thấy cách nghe qua một phần bài nói rồi xem lại sau để nghiền ngẫm sâu hơn có thể cũng khá hữu ích
Cũng đặt câu hỏi liệu tốc độ của video có thật sự quan trọng không, hay điều quan trọng là thông tin bổ sung mà video và audio mang lại. Những diễn giả nói tốt thường truyền tải cùng một thông điệp hiệu quả hơn rất nhiều qua audio/video. Audio có thể nhấn mạnh các đoạn nhất định, còn video có thể bổ sung thông điệp bằng cử chỉ và nét mặt
Ngược lại, khi thấy người khác nghe podcast hay audiobook ở 2~3x, tôi lại cảm thấy nếu là mình thì bật chậm xuống 0.8x sẽ tập trung tốt hơn và có nhiều thời gian suy nghĩ hơn. Không biết tôi có phải trường hợp ngoại lệ không
Có người thử dùng transcription API của OpenAI để tóm tắt một bài nói dài 40 phút, nhưng vì quá dài nên đã nén bằng
ffmpeglên 3x để lọt giới hạn 25 phút. Việc này thực sự có hiệu quả, tiết kiệm cả thời gian lẫn chi phí nên họ chia sẻ lại bằng bài viết, kèm toàn bộ script và cấu trúc chi phí“Độ chính xác thì sao?” — “Không biết, mà vốn dĩ đó cũng là ý chính.” Có cảm giác đây là một công việc rất ngầu đúng theo tinh thần của tác giả gốc, đồng thời cũng thấy tương lai này hơi bất an
Trước Gemini 2.0 đã từng có kiểu tính phí cố định 258 token cho một ảnh, nên cũng có mẹo nhét thật nhiều chữ vào một ảnh để xử lý rẻ hơn tương ứng
Có người làm một tiện ích mở rộng Chrome dùng mô hình OpenAI Whisper trong
huggingface/transformers.jschạy bằng WebGPU để chuyển audio thành văn bản ngay trong trình duyệt. Xem danh sách ví dụ. Ví dụ, họ không muốn nghe hay xem video từ mạng xã hội của tổng thống, nhưng khi xuất hiện một phát ngôn hớ hênh có ảnh hưởng lớn tới kinh tế thì cần phát hiện thật nhanh, nên cứ mỗi phút lại crawl bài đăng mới, tự động chạy OCR và audio transcription cục bộ, rồi phân tích văn bản; chỉ khi nào thật sự quan trọng về mặt kinh tế mới gửi thông báo. Liên kết dự ánCó người khuyên dùng Groq thay cho OpenAI Whisper API (rẻ hơn:
distil-large-v3là $0.02/giờ,whisper-large-v3-turbolà $0.04, còn OpenAI là $0.36/giờ). Nội bộ họ đang tự động xử lý transcription cho các cuộc họp hội đồng thành phố khi được đăng lên YouTube bằng Groq, Replicate, Deepgram v.v.Mẹo là dùng Inference API của Hugging Face thì có thể đổi qua lại giữa nhiều nhà cung cấp API rất dễ. Có thể xem ví dụ trực tiếp tại đây
Với mức giá $0.02~$0.04 mỗi giờ thì có vẻ chẳng cần tối ưu gì thêm, nhưng cũng tò mò liệu có thể phát audio nhanh hơn nữa để giảm chi phí tiếp không. Đồng thời cũng thắc mắc vì YouTube vốn đã tự động tạo phụ đề cho đa số video trong vòng một ngày
Nhấn mạnh rằng nếu dùng MacBook đời mới thì có thể chạy mô hình Whisper hoàn toàn miễn phí ở local. Có cảm giác nhiều người chưa nhận ra tài nguyên tính toán trên phần cứng họ đang sở hữu thực ra đã rất rẻ
Cũng có gợi ý dùng
whisper-large-v3-turbotrên cloudflare workers ai với chi phí khoảng $0.03/giờ (liên kết)Nhấn mạnh rằng trong Google AI studio, chỉ cần ném vào liên kết YouTube là có thể tự động lấy transcript kèm speaker label, thậm chí trích xuất cả tín hiệu thị giác. Cũng nhắc tới hỗ trợ đa phương thức cho video
Có người nói họ làm việc liên quan API tại OpenAI, và khá bất ngờ khi kết quả vẫn ổn ở tốc độ nhanh 2~3x. Trong thực tế, với kênh điện thoại họ còn dùng audio 8khz rồi upsample lên 24khz mà vẫn hoạt động tốt. Tuy nhiên, càng xa 1x thì độ chính xác giảm là điều có thật, và về dài hạn cần hỗ trợ upload file dài hơn
Có ý kiến thích phong cách viết đi thẳng vào vấn đề. Nhiều bài cứ dài dòng không cần thiết, còn cách tiếp cận này thì mới mẻ. Có lẽ nó cũng sẽ khiến một nửa số tác giả nhận ra rằng thật ra họ chẳng có thông điệp cốt lõi nào cả