AI ToolsDoc trong 12 phut

Runway truyền nhân vật số ở 24 khung hình mỗi giây. Phải đợi bao lâu mới có câu trả lời?

Bài nghiên cứu của Runway tách thời gian tạo video trực tiếp khỏi khoảng chờ mà người dùng thực sự trải qua trong cuộc trò chuyện.

K
Ken Jo

Khi khách hàng hỏi xong, nhân vật hoạt hình có một khoảng rất ngắn để cho thấy đã nghe. Video có thể rất mượt sau khi phát, nhưng khoảng trống trước câu trả lời đầu tiên vẫn có thể giống như cuộc gọi bị ngắt. Bài báo mới của Runway cung cấp đủ chi tiết thời gian để thấy khoảng trống đó đến từ đâu.

Runway ra mắt Characters ngày 9 tháng 3 năm 2026. Bản tiền ấn phẩm ngày 3 tháng 11 mô tả hệ thống đứng sau nhân vật hội thoại tạo video trong lúc nói. Đây là mô tả kỹ thuật của một sản phẩm đã có. Các tác giả ở Runway báo cáo số liệu trên hệ thống của họ, gồm cách video chạy trên bốn GPU NVIDIA H100. Số liệu giúp các nhóm đặt câu hỏi cụ thể trong đợt thử. Kết quả trên thiết bị, kết nối hoặc ứng dụng khác cần đo tại nơi sử dụng.

Máy chủ trong một phép thử NVIDIA H100 được quay độc lập

Máy chủ dùng thử phần cứng H100, loại GPU dùng trong bài báo Runway. Ảnh bối cảnh của 极客湾Geekerwan, đã đổi kích thước, CC BY 3.0. Nguồn ảnh · Giấy phép.

Mỗi lô khung hình có khoảng 167 mili giây

Tạo video trực tiếp: 4 khung hình, 147,4 ms sau khi hợp nhất, giới hạn 166,7 ms, mục tiêu 24 fps

Tạo video trực tiếp. Minh họa do Telli.sh thực hiện.

Ở 24 khung hình mỗi giây, một lô bốn khung hình cần sẵn sàng sau khoảng 167 mili giây. Nếu các lô tới chậm hơn tốc độ phát, hệ thống cần đệm thêm, đổi mức chất lượng hoặc điều chỉnh theo cách khác để giữ chuyển động liên tục. Một lô có thể mất gần hết 167 mili giây ngay cả khi video phát mượt.

Các tác giả mô tả hệ thống khoảng 57 tỷ tham số tạo khung hình 704 × 1.088 pixel. Họ báo cáo trung vị cho một bước khuếch tán là 240,9 ms ở cấu hình tham chiếu, 159,3 ms ở cấu hình đã tối ưu và 147,4 ms sau khi hợp nhất thêm thao tác. Mỗi biểu diễn ẩn đã khử nhiễu tương ứng bốn khung hình, còn bộ giải mã có phần xử lý chồng lấp riêng. Thời gian bước đo khác với thời gian phản hồi người dùng cảm nhận.

Một điểm khác là quá trình tạo video có thể đạt tốc độ cần thiết sau khi lô đầu bắt đầu. Bài báo nêu 0,49 giây cho luồng xử lý video và trung vị khoảng 2,1 giây cho lượt hội thoại đầy đủ trong điều kiện đo. Xử lý lời nói, sinh hội thoại, tổng hợp tiếng nói, truyền dữ liệu và lần phát hữu ích đầu tiên đều ảnh hưởng đến cuộc trò chuyện. Các bước có thể chồng lấp, nên trừ thời gian video khỏi tổng không cho biết riêng mỗi bước tốn bao lâu.

Chỉ sốTrả lời câu hỏi nàoCần đo gì trong đợt thử
Khung hình mỗi giâyVideo có giữ chuyển động liên tục được không?Khung hình nhận được và khoảng ngắt trong câu trả lời dài
Thời gian tới câu trả lời phát được đầu tiênSau câu hỏi im lặng bao lâu?Trung vị và các trường hợp chậm trên thiết bị người dùng
Phản ứng khi bị ngắtNgười dùng có thể nói lại ngay không?Thời gian từ lúc ngắt lời đến khi âm thanh dừng
Đồng bộ âm thanh và hình ảnhLời nói và chuyển động có khớp không?Độ lệch sau khi ngắt lời, đứng hình và khôi phục

Khi nào nhân vật chuyển động phát huy tác dụng?

Một phép thử khả thi là trạm giới thiệu sản phẩm trong bảo tàng hoặc phòng trưng bày. Khách hỏi một nút điều khiển dùng để làm gì, ứng dụng chọn câu trả lời ngắn từ tài liệu đã duyệt và nhân vật phản hồi trong khi sơ đồ vẫn hiện trên màn hình. Khuôn mặt rõ, hướng nhìn hoặc dấu hiệu tới lượt nói có thể giúp người vừa ghé qua. Hệ thống có thể chuyển sang giải thích bằng chữ nếu kết nối không ổn định.

Tình huống thứ hai là đóng vai khi đào tạo nhân viên. Người học tập xử lý một khách hàng bức xúc rồi nhận phản hồi từ ứng dụng. Đây là bài toán thời gian khó hơn lời chào có sẵn. Nhân vật cần dừng giữa câu, xử lý khi bị ngắt và phục hồi khi nghe nhầm. Đợt thử có ích sẽ ghi việc người học nói lặp hay nói chồng lên nhân vật, cùng các số liệu độ trễ thông thường.

Khi nhân vật dùng hình ảnh hoặc giọng người thật, cần có sự đồng ý và quy định cách thể hiện. Tổ chức có thể xác định ai được tạo nhân vật, hình ảnh có thể xuất hiện ở đâu và cách gỡ. Dùng nhân vật hư cấu rõ ràng hoặc người biểu diễn có giấy đồng ý giúp tách kết quả về giao diện khỏi các vấn đề cấp phép sau này.

Số liệu vận hành còn để ngỏ điều gì?

Đo cả lượt hội thoại: dứt lời, phản hồi đầu tiên, phát nội dung, ngắt lời

Đo cả lượt hội thoại. Minh họa do Telli.sh thực hiện.

Theo các tác giả, 99,5% phiên dài ít nhất một giây đạt trung bình trên 23,5 khung hình mỗi giây. Mẫu số và cửa sổ tính trung bình đều quan trọng. Phiên có thể vượt ngưỡng khung hình trung bình mà vẫn đứng hình thấy rõ. Phản hồi cũng có thể đến nhanh nhưng sau đó mất mượt. Bài báo không cho từng khách hàng biết phân bố thời gian phản hồi đầu tiên ở tải đồng thời họ dự kiến.

Đợt thử nhỏ nên có kết nối văn phòng thông thường, kết nối di động giới hạn và loại thiết bị mà khách thật dùng. Bắt đầu bằng mốc giọng nói và bản chép lời, rồi thử cùng câu hỏi với nhân vật. So tỷ lệ hoàn thành, bỏ dở và ngắt lời. Giữ câu trả lời theo kịch bản và chính sách hội thoại ổn định để gắn khác biệt với giao diện. Ghi phản hồi chậm cùng các ví dụ thành công.

Cấu hình phần cứng trong bài báo không nói được người mua phải trả bao nhiêu cho một cuộc trò chuyện. Đơn vị hữu ích có thể là một lượt huấn luyện hoàn tất hoặc một câu hỏi khách được trả lời đúng. Số phút đã tạo chỉ có nghĩa khi nhóm biết bao nhiêu phút thực sự hữu ích. Video minh họa được hình thức và chuyển động. Hội thoại có đo đạc cho thấy ứng dụng đã sẵn sàng cho người xem chưa.

Xem một cuộc trò chuyện theo từng khung hình

Bài báo nêu hai phân bố độ trễ cụ thể hơn. Trong 43 lượt có đánh dấu, trung vị từ lúc người dùng dứt lời đến khi thiết bị khách phát tiếng nhân vật là 2,13 giây. Bách phân vị thứ 10 và 90 lần lượt là 1,45 và 3,00 giây. Từ âm thanh đầu tiên của tác nhân đến khung hình đang nói đầu tiên do LiveKit ghi, trung vị là 493 ms, với hai bách phân vị tương ứng là 421 và 562 ms. Số đầu mô tả khoảng im trước câu trả lời nghe được trong điều kiện thử. Số sau mô tả lúc hình ảnh nói bắt đầu. Khách có thể cảm nhận cả hai.

Số liệu tốc độ khung hình lấy từ đợt thu thập khác. Các tác giả nói đã ghi dữ liệu vận hành của tiến trình xử lý trong bảy tuần. Họ cũng xác định các phiên được đưa vào phép đo. Một thử nghiệm ở địa điểm đông người có thể bổ sung bằng cách quan sát khoảng ngắt ngay sau khi người dùng chen lời hoặc khi nhiều khách đến cùng lúc. Ghi âm và hình trên máy khách thật để phép đo bao gồm mạng và phát lại.

Để đo công bằng, đánh dấu lúc người dùng dứt lời, lúc tác nhân bắt đầu trả lời và khung hình đang nói đầu tiên nhìn thấy được. Dùng các câu hỏi lặp lại đã biết đáp án. Người thử có thể phân biệt câu trả lời đúng nhưng chậm với phản hồi nhanh mà sai ý. Thêm một vài lần ngắt lời ở thời điểm tương đương trên hai giao diện.

So sánh chi phí theo phiên hoàn tất

Trung tâm trợ giúp Runway mô tả mức phí 2 credit ban đầu và thêm 2 credit cho mỗi 6 giây phiên hoạt động. Với mức công bố 0,01 USD mỗi credit trước thuế, một phiên hoạt động 60 giây tốn 22 credit, tức 0,22 USD, theo phép tính minh họa. Đây là ví dụ với cách tính đã công bố. Tổng thực tế phụ thuộc tài khoản, thời gian hoạt động, giá hiện tại và thành phần ứng dụng bị tính riêng.

Nhóm so giao diện với mốc chỉ có giọng nói có thể theo dõi chi phí trên mỗi lượt trao đổi hoàn tất. Có người thoát trước khi nhân vật nói xong. Người khác phải mở cuộc trò chuyện thứ hai khi gặp lỗi mạng hoặc câu trả lời chưa rõ. Những phiên này vẫn tốn tài nguyên dù khách chưa xong việc ban đầu. Giữ phiên bỏ dở trong mẫu số khi đo tỷ lệ hoàn tất và đưa phí của chúng vào tổng chi.

Chi phí kiểm duyệt và rà soát nội dung cũng có thể thay đổi. Công ty có thể cần kiểm tra lời nói sinh ra có theo chính sách, nhân vật tổng hợp có được xuất hiện ở khu vực dự kiến và khách liên hệ nhân viên thế nào nếu hệ thống không biết câu trả lời. Hãy thử những đường đi đó kỹ như phần kết xuất. Phương án dự phòng tốt có thể giảm gián đoạn do mạng chậm.

Chạy phép so sánh có ghi đo

  1. Chọn một tương tác đã được duyệt có câu trả lời đúng và kết quả thành công rõ ràng.
  2. Thử mốc văn bản hoặc giọng nói và phiên bản có nhân vật, dùng cùng nguồn trả lời và chính sách hội thoại.
  3. Lặp câu hỏi trên thiết bị và kết nối khách sử dụng. Có một câu trả lời dài, một lần cố ý ngắt lời và một lần mất kết nối ngắn.
  4. Ghi lúc bắt đầu phản hồi, lúc video nói bắt đầu, khoảng ngắt phát, số lần ngắt lời thành công và việc khách có xong tác vụ không.
  5. Xem lỗi cùng bằng chứng phát lại. Xác định lỗi đến từ nhận dạng lời nói, tạo câu trả lời, đồng bộ thời gian, mạng hay giao diện.
  6. So sánh số phiên hoàn tất và tổng chi phí giữa hai phiên bản trước khi mở rộng sang phiên dài hơn hoặc đông người hơn.

Bài thử cho thấy khi nào hình ảnh bổ sung thực sự hữu ích. Nhân vật có thể giúp một nhóm biết tới lượt nói nhưng làm nhóm khác đợi lâu không cần thiết. Kết quả phải gắn với tương tác, mạng và thiết bị đã tạo ra nó.

Xem phần tài nguyên phía sau các mốc thời gian

Các tác giả mô tả việc giảm từ tám GPU H100 xuống bốn cho một phiên thời gian thực. Theo báo cáo, cấu hình bốn GPU chưa dùng bước hợp nhất sau này đạt 24,5 khung hình mỗi giây. Đây là cấu hình phần cứng và phần mềm cụ thể đạt mục tiêu với tải đã thử. Nó không bảo đảm số phiên đồng thời cho tải khác hoặc cho biết tài nguyên được cấp cho một tài khoản khách hàng.

Bên mua có thể hỏi nhà cung cấp phần nào của dịch vụ khởi động trước, điều gì xảy ra khi thiếu công suất và phiên phục hồi thế nào. Phòng trưng bày có thể chịu được gián đoạn hình ảnh ngắn nếu vẫn nghe tiếng và câu hỏi được trả lời. Ứng dụng huấn luyện đồng bộ có thể cần tạm dừng, báo trạng thái rõ và tiếp tục từ một điểm đã biết. Lặp cùng thao tác sau gián đoạn để xem ứng dụng biết phần nào người dùng đã nghe.

Điểm đánh đổi hiện rõ khi có người chen vào giữa câu. Hệ thống có thể đệm tiếng hoặc hình đã tạo để phát mượt. Bộ đệm quá lớn có thể khiến nhân vật nói tiếp khi người dùng muốn giành lượt. Đệm nhỏ hơn có thể nhạy hơn với mạng thay đổi. Đo riêng thời điểm dừng thực tế và lúc nghe được câu trả lời tiếp theo.

Thử cách phục hồi mà người dùng có thể hiểu

Đợt thử nhỏ với khách có thể chuyển từ kết nối bình thường sang cấu hình chậm trong khi đang phát câu trả lời. Ghi tiếng có dừng, hình có đứng và giao diện báo gì. Sau đó khôi phục kết nối rồi xem nhân vật nói tiếp cùng câu, yêu cầu hỏi lại hay chuyển sang kênh khác. Mỗi kết quả ảnh hưởng khác nhau tới người đứng trước trạm.

Khi hệ thống không khôi phục được, hãy đưa bản chép lời, văn bản dễ tiếp cận hoặc chuyển cho nhân viên nếu ứng dụng hỗ trợ. Công việc ngắn có thể vẫn hoàn thành dù video lỗi. Bài tập dài có thể cần quay về điểm đã lưu. Hành vi phù hợp phụ thuộc vào phần trao đổi đã thực hiện được.

Kiểm thử tải định kỳ có thể bắt đầu với ba kiểu người dùng đến. So sánh một phiên dài, vài phiên ngắn độc lập và một nhóm đến cùng lúc. Theo dõi phản hồi đầu tiên và những trường hợp chậm nhất trong từng kiểu. Luồng đạt tốc độ yêu cầu sau khi bắt đầu phát vẫn có thể gây trải nghiệm kém nếu khách phải đợi lâu hơn nhiều khi lượng người tăng đột ngột.

Nguồn


Để lưu các cuộc trao đổi và quyết định trong công việc theo cách có thể tìm lại, hãy tạo tài khoản Telli.sh.


← Quay lai blog