Tìm kiếm
25 kết quả cho “khoá theo version model”. Tìm không phân biệt dấu.
- Torch compile caching for inference speed Bài tóm tắt · Replicate · 2025
…- Theo Replicate, cold boot giảm 2–3 lần (flux-kontext-dev khoảng 120 giây còn 60). Bài học cho SWE - Chi phí khởi động lặp lại ở mọi container thì cache theo version đầu vào. Liê…
- Nền tảng ML (feature, training, serving, giám sát model) Chủ đề Thành viên
Model ML đầu tiên của một công ty thường được nhúng thẳng vào một service có sẵn, với feature tính trong vài script và train bằng một job riêng. Khi số model và số người làm model tăng, bốn chỗ cùng hỏng:
- How Instacart Modernized the Prediction of Real Time Availability for Hundreds of Millions of Items While Saving Costs Bài tóm tắt · Instacart · 2023
…n tầng theo tần suất: item "đầu" (có tín hiệu trong 10 giờ, khoảng 1% item) được chấm trending hằng giờ và real-time; item "thân" (trong một tháng, khoảng 85%) và "đuôi" chỉ chấm g…
- Deploy và release an toàn Chủ đề Thành viên
Phần lớn incident bắt đầu bằng một thay đổi: code mới, cấu hình mới, hạ tầng mới. Khi hệ thống và tổ chức lớn lên, câu hỏi là làm sao đưa thay đổi lên production thường xuyên mà vẫn giới hạn được thiệt hại khi có lỗi.
- Halving the Time: How Uber Eats Rebuilt Its Search Pipeline Bài tóm tắt · Uber · 2026
…hiệm offline và online cho thấy vài chiến lược retrieval từ khoá phạm vi rộng tốn nhiều latency mà ít đóng góp (kết quả đã có từ nguồn khác, gồm semantic); bỏ chúng giảm khoảng 120…
- Observability và monitoring Chủ đề Thành viên
Lúc đầu, monitoring là vài dashboard và một công cụ cài sẵn; log đọc thẳng từ máy. Khi hệ lớn lên, chính hệ quan sát thành một hệ phân tán có bài toán riêng:
- Migration không downtime Chủ đề Thành viên
Hệ thống đang chạy thật (gọi xe, chat, thiết kế) không được dừng, nhưng phải đổi ngôn ngữ, database hoặc hạ tầng bên dưới.
- Hạ tầng phục vụ LLM inference Chủ đề Thành viên
Phục vụ LLM giống một dịch vụ web ở chỗ cần scale theo tải, deploy phiên bản mới an toàn và phục hồi khi một process chết; nhưng ba đặc điểm làm các công cụ quen thuộc hỏng:
- Cache và invalidation Chủ đề Thành viên
Cache là cách rẻ nhất để một DB chịu được lượng đọc tăng nhiều lần. Vì vậy nó xuất hiện ngay từ giai đoạn đầu (Instagram 2011, Facebook 2004–2010). Cái giá đến sau, và lặp lại ở hầu hết các nguồn:
- Event-driven, message queue và Kafka Chủ đề Thành viên
Khi một hệ có nhiều bên cần biết "có gì vừa xảy ra" (đơn hàng đổi trạng thái, tin đăng được sửa, ticket được cập nhật), synchronous call từng bên một làm producer phải biết mọi consumer, và một consumer chậm kéo chậm cả…
- Kiến trúc frontend Chủ đề Thành viên
Frontend bắt đầu là vài trang render ở server; lớn lên thành ứng dụng có trạng thái, nhiều team cùng sửa, và mỗi tính năng thêm vào là thêm byte phải tải. Ba trục lặp lại trong các nguồn: render ở đâu (server, client,…
- Pipeline dữ liệu và analytics Chủ đề Thành viên
Lúc đầu, báo cáo chạy thẳng trên DB production. Đến một lúc truy vấn phân tích làm chậm giao dịch, dữ liệu cần gộp từ nhiều nguồn, và có thêm người dùng mới (analyst, ML, khách hàng xem dashboard). Khi đó cần một data…
- Multi-tenancy và cô lập tenant Chủ đề Thành viên
Một hệ phục vụ nhiều khách (tenant: workspace, shop, organization, account, service nội bộ) trên cùng hạ tầng thì rẻ và dễ vận hành, vì tài nguyên được dùng chung. Cái giá là bốn câu hỏi đi theo hệ suốt đời:
- Realtime và fan-out Chủ đề Thành viên
Một sự kiện (tin nhắn, ảnh, tweet, vote) phải tới rất nhiều người, rất nhanh, qua rất nhiều kết nối mở cùng lúc.
- Failover, replica và dự phòng dữ liệu Chủ đề Thành viên
Mọi hệ có trạng thái đều giữ nhiều bản (replica) để một máy chết không làm mất dịch vụ. Khó không nằm ở việc có bản sao mà ở lúc chuyển sang bản sao:
- Tự động hoá vận hành và auto-remediation Chủ đề Thành viên
Khi số máy, shard, pod tăng lên hàng nghìn, lỗi "hiếm" (một node chết, một đĩa hỏng, một replica trễ) thành chuyện hằng ngày, và thao tác tay không còn theo kịp: Stripe có hàng trăm lần shard suy giảm mỗi năm, mỗi lần…
- Hạ tầng nghiên cứu định lượng (dữ liệu thị trường, feature, backtest) Chủ đề Thành viên
Một quỹ định lượng hay công ty market making sống bằng vòng nghiên cứu: đặt giả thuyết → lấy dữ liệu → tạo feature → train model hay dựng tín hiệu → backtest/mô phỏng → đưa vào giao dịch thật → lặp lại. Theo Optiver, độ…
- Monolith và microservices — đi và quay lại Chủ đề Thành viên
Lúc nào nên tách hệ thống thành nhiều service, và cái giá của việc đó là gì? Các nguồn hiện có cho thấy đây không phải đường một chiều.
- Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định) Chủ đề Thành viên
Lỗi trong hệ phân tán là chắc chắn (máy chết, zone mất, dependency chậm, cấu hình sai), nhưng phần lớn lỗi nằm ở những tổ hợp hiếm mà test chức năng không chạm tới. Bài toán là chủ động gây lỗi để biết hệ thống phản ứng…
- LinkedIn Công ty Thành viên
Bài khung là bài nhìn lại năm 2015 . LinkedIn bắt đầu năm 2003 là một monolith tên Leo. Service đầu tiên tách ra là member graph, vì đồ thị kết nối có profile tải khác hẳn; DB profile được đỡ bằng scale dọc rồi read…
- Zillow Công ty Thành viên
Zillow cho thấy một công ty dữ liệu đi từ ứng dụng web có cache tự làm sang nền tảng dữ liệu, ML và thí nghiệm dùng chung. Năm 2012 các sản phẩm mới đã chạy trên AWS: nền tảng website cho môi giới trên WordPress dùng…
- Replicate Công ty Thành viên
Nền tảng chạy model ML bằng API, và là tác giả của Cog (công cụ đóng gói model vào container); mọi số đo và nhận định về sản phẩm trong các nguồn là "theo Replicate", họ tự đo. Blog của họ phần lớn là hướng dẫn, nên…
- ML Feature Serving Infrastructure at Lyft Bài tóm tắt · Lyft · 2021
…Đọc bằng batch-get : Redis trước, miss thì DynamoDB, không khoá. - Online–offline parity: feature định nghĩa một lần, training và serving dùng chung định nghĩa, kiểm tra và biến đ…
- Did you mean "Galene"? Bài tóm tắt · LinkedIn · 2014
…iờ tìm được mọi member; theo LinkedIn nhanh hơn gấp đôi với khoảng một phần ba phần cứng . - Tác động tổ chức: index dựng lại hằng tuần buộc quy trình test và release linh hoạt hơn…
- Lyft Công ty Thành viên
Năm 2019, Amundsen, công cụ tìm dữ liệu dựa trên metadata, xếp hạng bảng theo số lần được query và lấy "ai hay dùng" từ audit log; metadata cơ bản công khai cho mọi người, metadata giàu chỉ cho người có quyền . Nền tảng…