Muse Spark 1.1 được công bố

 (ai.meta.com)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Muse Spark 1.1 do Meta Superintelligence Labs công bố là một mô hình suy luận đa phương thức hướng tới các tác vụ agent, tăng cường khả năng dùng công cụ và máy tính, lập trình, cũng như hiểu đa phương thức so với phiên bản trước
  • Điểm cốt lõi là đảm nhiệm việc lập kế hoạch và orchestration trên nhiều ứng dụng, dịch vụ bên ngoài, đồng thời khái quát hóa zero-shot sang native tools, MCP servers và custom skills
  • Chủ động quản lý cửa sổ ngữ cảnh 1 triệu token để truy xuất thông tin từ các tác vụ trước đó, đồng thời nén và duy trì ngữ cảnh cốt lõi cần cho các bước tiếp theo
  • Nhà phát triển có thể truy cập mô hình qua Meta Model API đang ở bản public preview, và có thể dùng trong chế độ “Thinking” trên ứng dụng Meta AI và meta.ai
  • Meta cho biết đã tiến hành đánh giá an toàn trước khi triển khai theo Advanced AI Scaling Framework, và đánh giá mô hình nằm trong biên độ an toàn ở các hạng mục Chemical & Biological, Cybersecurity và Loss of Control

Vị trí và cách cung cấp Muse Spark 1.1

  • Muse Spark 1.1 là mô hình mới nhất của Meta Superintelligence Labs, được giới thiệu là bản nâng cấp lớn so với Muse Spark hiện có
  • Đây là mô hình suy luận đa phương thức dành cho tác vụ agent, nhấn mạnh các cải tiến trong những lĩnh vực sau
    • Sử dụng công cụ
    • Sử dụng máy tính
    • Lập trình
    • Hiểu đa phương thức
  • Lần ra mắt này, cùng với việc công bố Muse Image, được gắn với một bước tiến gần hơn tới tầm nhìn “personal superintelligence” mà Meta nói đến
  • Nhà phát triển có thể truy cập Muse Spark 1.1 thông qua Meta Model API đang ở bản public preview
  • Trên ứng dụng Meta AI và meta.ai, mô hình được cung cấp dưới chế độ “Thinking”

Tác vụ agent và xử lý ngữ cảnh dài

  • Lập kế hoạch và điều phối luồng thực thi trong các tác vụ agent cá nhân trải rộng trên nhiều ứng dụng và dịch vụ bên ngoài
  • Khái quát hóa zero-shot sang native tools, MCP servers và custom skills
  • Được huấn luyện để xử lý các dự án phức tạp nhanh hơn nhiều so với Muse Spark
    • Agent chính thu thập ngữ cảnh, lập kế hoạch rồi ủy quyền thực thi cho các subagent chạy song song
    • Subagent tuân theo tác vụ được giao, hiểu các công cụ có sẵn và escalates lên agent chính khi cần
  • Chủ động quản lý cửa sổ ngữ cảnh 1 triệu token
    • Ghi nhớ các hành động đã thực hiện
    • Truy xuất thông tin từ các tác vụ xa hơn trong quá khứ
    • Nén để giữ lại các bước cốt lõi cần thiết cho những tác vụ tiếp theo

Tự động hóa việc sử dụng máy tính

  • Muse Spark 1.1 thể hiện thế mạnh trong workflow sử dụng máy tính khi phải chuyển qua lại giữa nhiều ứng dụng và thông tin thay đổi theo thời gian thực
  • Duy trì ngữ cảnh ngay cả trong các phiên dài, thích ứng với yêu cầu thay đổi và điều hướng các giao diện chưa quen thuộc với mức can thiệp tối thiểu từ con người
  • Không phải lúc nào cũng xử lý tác vụ desktop theo từng cú nhấp chuột, mà tùy tình huống chọn giữa tự động hóa và thao tác trực tiếp
    • Khi tự động hóa nhanh hơn, mô hình viết script
    • Khi tương tác trực tiếp đơn giản hơn, mô hình dùng cú nhấp chuột
    • Ở mỗi bước, mô hình tạo ra nhiều hành động theo nhóm
  • Trong ví dụ chuẩn bị tiệc tối, khi xuất hiện ngữ cảnh mới trong quá trình đặt hàng, mô hình nhận biết điều đó và thực hiện các cập nhật cần thiết mà không cần người dùng can thiệp

Hiệu năng lập trình và workflow phát triển

  • Hiệu năng của Muse Spark 1.1 được cải thiện đáng kể trong các tác vụ lập trình thực tế liên quan đến những codebase lớn và phức tạp
  • Có thể chẩn đoán và sửa các lỗi phức tạp, triển khai tính năng mới cho hệ thống cấp doanh nghiệp, và thực hiện các đợt migration mã nguồn quy mô lớn
  • Cho thấy cải thiện lớn so với mô hình đầu tiên trong các trường hợp sử dụng như tạo ứng dụng web và hỏi đáp end-to-end
  • Được huấn luyện để thích ứng mượt mà với nhiều harness khác nhau và xử lý ổn định các hành động nhiều lượt phức tạp
    • planning mode
    • goal conditioning
    • subagent delegation
    • Hỗ trợ các chức năng lập trình agent phổ biến như context compaction
  • Trong demo gỡ lỗi OpenCode, mô hình tạo một ứng dụng web chat, dùng ảnh chụp màn hình tự động để tìm lỗi mà người dùng nhìn thấy, truy vết tới mã liên quan để sửa, rồi xác minh các thay đổi
  • Các nhà phát triển và nhà nghiên cứu nội bộ của Meta đang dùng Muse Spark 1.1 hằng ngày; trên Meta Internal Coding Bench, mô hình cải thiện rõ rệt so với Muse Spark và cho kết quả cạnh tranh với các lựa chọn thay thế chính
  • Các nhà nghiên cứu cũng đang dùng Muse Spark 1.1 trong workflow để tự động hóa các tác vụ phát triển và đánh giá mô hình
  • Trong ví dụ đánh giá DeepSWE, mô hình tự đánh giá một phần tác vụ DeepSWE ở nhiều mức cường độ suy luận khác nhau trong OpenCode, rồi tạo dashboard phân tích dựa trên kết quả

Hiểu và thực thi đa phương thức

  • Muse Spark 1.1 cũng thể hiện thế mạnh trong các tác vụ kết hợp tri giác, suy luận đa phương thức và sử dụng công cụ
  • Có thể tạo đầu ra có căn cứ khi tương tác với môi trường thực tế
    • Tạo sản phẩm mã nguồn từ tài liệu trực quan
    • Tạo caption rất chi tiết cho hình ảnh và video
    • Thực thi workflow agent cho các trường hợp sử dụng đa phương thức
  • Năng lực đa phương thức đặc biệt hữu ích trong những tình huống cần cả tri giác lẫn hành động
    • Kiểm tra hình ảnh và âm thanh
    • Bảo toàn chi tiết trong các workflow dài
    • Tận dụng các chi tiết đó khi thay mặt người dùng điều khiển máy tính
  • Trong ví dụ agent Facebook Marketplace, mô hình trích xuất các ảnh hữu ích từ video quay bằng smartphone, suy luận về sản phẩm, rồi điều khiển trình duyệt của người dùng để tạo bài đăng trên Marketplace

Đánh giá an toàn

  • Trước khi triển khai, Meta đã thực hiện đánh giá an toàn trên diện rộng theo Advanced AI Scaling Framework
  • Framework này định nghĩa các tiêu chí đánh giá, mô hình mối đe dọa và tiêu chuẩn triển khai cho những mô hình tiên tiến nhất của Meta
  • Các hạng mục đánh giá bao gồm các frontier risk sau
    • Chemical & Biological
    • Cybersecurity
    • Loss of Control
  • Trong đánh giá của Meta, Muse Spark 1.1 hoạt động trong biên độ an toàn ở tất cả các hạng mục frontier risk
  • Thể hiện khả năng kháng mạnh trước jailbreak trực tiếp, các cuộc tấn công gián tiếp đến từ dữ liệu không đáng tin cậy, prompt injection và tấn công developer-prompt
  • Nhờ đó, adversarial robustness được cải thiện, đồng thời tỷ lệ hallucination và sycophancy giảm
  • Toàn bộ nội dung liên quan đến an toàn được ghi lại trong Muse Spark 1.1 Evaluation Report

Phản hồi từ đối tác ban đầu và kế hoạch tương lai

  • Thông qua bản public preview của Meta Model API, lần đầu tiên nhà phát triển có thể bắt đầu xây dựng dựa trên Muse Spark 1.1
  • Các đối tác ban đầu đánh giá đây là một mô hình nền tảng có thể xử lý workload agent quy mô lớn nhờ kết hợp khả năng xử lý ngữ cảnh dài, lập trình và suy luận
  • CEO Replit Amjad Masad nhấn mạnh việc một mô hình duy nhất tích hợp ngữ cảnh 1 triệu token, hỗ trợ đa phương thức hình ảnh/video/PDF, tìm kiếm tích hợp kèm trích dẫn, structured output, gọi công cụ song song và package tương thích OpenAI
  • CEO Cline Saoud Rizwan cho biết ông muốn cung cấp quyền truy cập sớm cho các nhà phát triển Cline vì mô hình vừa có khả năng dùng công cụ mạnh, vừa có mức giá cho phép chạy workload lập trình thực tế ở quy mô lớn
  • Yashodha Bhavnani của Box đánh giá rằng trên bộ đánh giá tác vụ doanh nghiệp của Box, Muse Spark đã thể hiện năng lực doanh nghiệp cạnh tranh với các frontier model hàng đầu hiện nay
  • Dave Morin của OpenClaw Foundation đánh giá Muse Spark 1.1 là một mô hình nhanh và mạnh cho thực thi agent
  • Meta đang huấn luyện các mô hình có hiệu năng cao hơn và dự định chia sẻ trong tương lai

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • Báo cáo được liên kết có nhiều chi tiết hơn hẳn: https://ai.meta.com/static-resource/muse-spark-1-1-evaluatio...
    Nhìn vào chi tiết Terminal-Bench-2.1 thì có ghi “đã đánh giá 89 tác vụ Terminal-Bench 2.1 từ kho chính thức bằng một harness tác nhân chỉ dùng công cụ bash, với tài nguyên bị giới hạn ở CPU 6 lõi và RAM 8GB”, nhưng như vậy thì kết quả là không hợp lệ
    Mỗi tác vụ benchmark terminal có giới hạn CPU và RAM riêng, và vượt quá một trong hai là bị loại. Theo tbench-2.1, trong 89 tác vụ không có tác vụ nào cho phép CPU 6 lõi, và chỉ có 8 tác vụ cho phép RAM 8GB
    Kiểu benchmark đáng ngờ như thế này làm mất hết niềm vui khi xây harness để tăng hiệu năng benchmark của mô hình, vì dù làm gì cũng không thể thắng được những con số không chính xác trên tiêu đề. Có lẽ vì vậy mà mô hình này không có trên bảng xếp hạng chính thức https://www.tbench.ai/leaderboard/terminal-bench/2.1
    Là cựu nhân viên Meta, tôi thấy hơi đắng lòng nhưng cũng không quá ngạc nhiên. Cho đến khi PSC kết thúc và chuyển sang việc tiếp theo, đẩy số liệu lên là chỉ số đánh giá hiệu quả cốt lõi

    • Ngoài trường hợp mô hình vô tình gây ra fork bomb, tôi không hiểu vì sao phải xét đến giới hạn tài nguyên. Tôi tưởng benchmark này đo khả năng dùng terminal, đặc biệt là khả năng nối nhiều lệnh gọi công cụ bash lại với nhau; điều này trở nên quan trọng trong test case nào?
    • Đây chính là vấn đề của mô hình đóng. Chúng ta không biết chính xác thứ mình trả tiền là một mô hình nền tảng tốt hơn, hay một harness được thiết kế tốt để tối đa hóa điểm benchmark
    • Hỏi hoàn toàn vì tò mò: giới hạn tài nguyên thường xuyên trở thành nút thắt đến mức nào? Harness giúp gì ở đây? Kiểu như hạn chế song song hóa hoặc dùng công cụ hiệu quả hơn?
    • Tôi hiểu ý chính, nhưng không chắc nó quan trọng đến mức đó
      harbor / tb2.1 có giới hạn swap mà Docker có thể dùng khi chạy không? Trước đây từng có lỗi khiến instance Docker có thể dùng nhiều bộ nhớ hơn đặc tả. Một số tác vụ ban đầu gần như không thể hoàn tất nếu không tận dụng swap, và nếu chặn Docker truy cập swap thì ngay cả lời giải oracle cũng không qua được
      Theo trí nhớ của tôi thì crack-7z-hash và filter-js-from-html gặp vấn đề đó, nhưng tôi đã không xem trong vài tháng nên không chắc
    • Tôi không thấy đó là vấn đề lớn đến vậy. Khi đánh giá bất kỳ sản phẩm nào, tôi cũng không tin nguyên xi lời của bên tạo ra sản phẩm. Tất nhiên sẽ có thiên lệch. Vì thế mới có kiểm thử độc lập như https://artificialanalysis.ai

  • Tôi đã có thể dùng thử trước trong vài ngày, và trong thời gian đó đã làm được một plugin cho LLM. Có thể thử mô hình trong terminal như sau
    uv tool install llm
    llm install llm-meta-ai
    llm keys set meta-ai
    # paste API key here
    llm -m meta-ai/muse-spark-1.1 "Generate an SVG of a pelican riding a bicycle"
    Kết quả ở đây: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...
    Để so sánh, con bồ nông do Muse Spark 1 tạo ra ở đây: https://simonwillison.net/2026/Apr/8/muse-spark/

    • Tôi tò mò không biết bạn lấy đâu ra thời gian để xem trước nhiều mô hình như vậy. Gần đây việc ra mắt mô hình thật sự quá dồn dập, đôi khi nó không giống công việc sao?

  • Có lẽ Zuck nên tập trung hơn vào vai trò kẻ phá bĩnh trong thị trường mô hình thay vì cạnh tranh trực diện
    Không cần bắt kịp doanh thu mô hình của Anthropic hay OpenAI, chỉ cần có thể cắt giảm 99% doanh thu đó là đủ. Cứ tiếp tục chi vài chục tỷ USD để phát triển mô hình frontier, rồi phát hành dưới dạng trọng số mở để biến mô hình coding thành hàng hóa phổ thông. Cũng cần một harness benchmark mã nguồn mở được làm tốt nữa
    Rất ít người ở vị thế có thể làm điều này và nó cũng hợp lý về mặt kinh doanh. Dù sao dòng chảy nhiều khả năng cũng sẽ đi theo hướng đó, và ông ấy có thể tăng tốc nó đáng kể. Ta nên hy vọng các mô hình cũng chuyển từ sản phẩm độc quyền sang hàng hóa phổ thông như trình biên dịch đã từng
    Đây có thể là một trong những điều tốt nhất Zuck có thể làm cho thế giới

    • Nếu họ mất doanh thu, ai sẽ thuê dùng tài nguyên tính toán của Meta?
    • Muốn thật sự trở thành vua phá bĩnh thì hãy phát hành bộ dữ liệu huấn luyện dưới dạng mã nguồn mở. Tôi nghi ngờ họ sẽ đi xa đến mức đó
    • Mô hình coding không phải đích đến. Mô hình coding chỉ là một phần của quá trình bootstrap để tiến tới trí tuệ tổng quát
    • Chẳng phải họ đã thử làm điều đó với llama rồi sao?
    • Điều ông ấy cần làm chỉ là chứng minh rằng việc tạo ra những mô hình như thế này không còn khó đến vậy nữa. Vì hào lũy của các công ty này chính là nhận thức rằng xây dựng mô hình frontier thật sự rất khó

  • Giá tốt đến mức khó tin. Input $1.25 cho mỗi 1 triệu token, output $4.5, còn input đã được cache là $0.15
    https://dev.meta.ai/docs/getting-started/pricing-rate-limits

    • Cái này có thể so sánh trực tiếp nhất với xAI Grok 4.5. Cả hai đều có định hướng gần như “trí tuệ cấp Opus với giá Haiku”, và đây là chuyện rất lớn với các nhà phát triển ứng dụng muốn đưa kiểu model này vào app
      Tôi đang thử thay Haiku và Sonnet bằng Grok 4.5, và cũng định thử cả cái này. Đặc biệt giá cache rẻ hơn nhiều
    • Tỷ lệ giá input đã cache rất tốt
      Grok 4.5 ra mắt với giá $2/$6, nhưng âm thầm thu $0.50 cho mỗi 1 triệu token input đã cache. Mức này đắt ngang Opus 4.8
    • Meta hiện không nằm trong radar của phần lớn những người đang chọn model. Nếu họ thật sự có một model tốt, việc trợ giá để thu hút người dùng trước khi cân bằng theo giá đối thủ là hợp lý
    • Rẻ hơn Qwen 3.7 Max. Sau mức $2 input / $6 output của Grok 4.5, đây là tín hiệu thứ hai cho thấy các phòng lab lớn đang cảm nhận áp lực từ GLM 5.2
    • Dù vậy vẫn đắt một cách vô lý. Hãy nghĩ đến việc phải trả $10 cho 100 kết quả tìm kiếm Google; thực chất chuyện này cũng tương tự vậy
      Tôi thật sự không hiểu vì sao lại có người muốn chi hơn $1.50 cho mỗi 1 triệu token output. Chưa nói đến $15~50. Có trường hợp nào người tiêu dùng thực sự trả tiền theo mức sử dụng không?

  • Mới đến hôm qua thôi, có vẻ không khí chung vẫn là OpenAI và Anthropic đã dẫn trước đến mức không thể đảo ngược, nhưng giờ xAI và Meta ít nhất cũng đã tung ra những thứ có thể cạnh tranh với các model thực dụng, mà giá còn rẻ
    Tất nhiên nếu nhìn vào Fable, và có lẽ cả GPT-6 sắp ra, câu chuyện rằng hai phòng lab dẫn đầu vẫn đang đi trước vẫn còn đúng, nhưng đây không phải là ván cờ đã hoàn toàn kết thúc như giới dẫn dắt dư luận nói

    • Giờ model nhìn chung đã đủ tốt. Nếu không có đột phá lớn, từ giờ điều quan trọng chỉ còn là chi phí
    • Mọi người đã hiểu nhầm việc Google tụt lại thành Anthropic và OpenAI vượt xa khủng khiếp. Thực tế gần hơn với việc Google tụt lại như hồi Tensorflow, Angular, GCP
    • Sắc thái đó hơi khác
      Kỳ vọng đối với GLM 5.2 vốn đã rất lớn từ trước. xAI hay Meta không tạo ra khác biệt lớn theo một cách khác, mà gần hơn là đạt kết quả tương tự GLM 5.2 với mức giá tương tự

  • Cá nhân tôi không thích Meta, nhưng chuyện này thì phải công nhận. Càng nhiều cạnh tranh càng tốt cho người tiêu dùng phổ thông, và cũng tốt cho doanh nghiệp
    Các model Trung Quốc, Grok, Meta, Google, OpenAI, Anthropic đều cạnh tranh với nhau là một chiến thắng. Tôi đang xây dựng như điên để tận dụng tối đa những token được trợ giá này khi còn có thể dùng được

    • Model llama chạy local của Meta từng là gương mặt đại diện của AI mã nguồn mở. Cuộc chơi đã thay đổi rất nhiều
    • Tôi chắc chắn xem đây là một điều tốt. Tuy vậy trong lòng tôi vẫn đang tranh luận liệu những tiến bộ này sẽ làm số lượng kỹ sư phần mềm cần thiết trong kỷ nguyên AI tăng lên hay giảm đi
      Một mặt, việc tạo sản phẩm sẽ dễ hơn nên sẽ có nhiều người tạo hơn, nhiều sản phẩm và tính năng hơn. Nhiều người không chuyên kỹ thuật cũng sẽ muốn làm, nhưng rồi sẽ mắc kẹt, và cuối cùng vẫn cần kỹ sư. Tổng lượng sản phẩm do các công ty công nghệ lành nghề, các nhà sáng lập không chuyên kỹ thuật và những người chuẩn bị khởi nghiệp tạo ra sẽ rất lớn. Kịch bản tăng trưởng cho việc cần nhiều kỹ sư phần mềm hơn trong tương lai gần nằm ở đây
      Mặt khác, sau khoảng một năm, mọi người sẽ tạo ra rất nhiều sản phẩm như vậy, nhưng phần lớn sẽ không marketing được, không bán được hoặc không kiếm ra tiền. Cuối cùng có thể sẽ không cần nhiều kỹ sư phần mềm đến thế. Dù vậy, xét tổng thể tôi cho rằng khả năng kịch bản tăng trưởng thắng về hiệu ứng ròng là lớn
    • Nếu liệt kê cụ thể hơn các model Trung Quốc thì có DeepSeek, GLM(Z.ai), Minimax, Kimi(Moonshot), Hy3(Tencent), Qwen(Alibaba)
      Từng model đều có thể tải trọng số về và chạy local
    • Ông ấy đăng tin này lên X chứ không phải Meta Threads của mình. Điều đó cho thấy mức độ quan tâm muốn thổi bùng chuyện này lớn đến đâu. Tất nhiên, trong khi các công ty này tiếp tục đốt tiền mặt, về phía chúng ta chi phí có thể vẫn ở mức chịu được
    • Đây là cuộc cạnh tranh công nghệ lớn nhất tôi từng thấy. Những công ty giàu nhất, những con người thông minh nhất, những quốc gia giàu nhất đều đã nhảy vào
      Tôi không biết cạnh tranh có tốt hay không, vài năm nữa sẽ thấy. Tôi đang mong đến ngày lâu lắm rồi mới lại có một công việc lao động chân tay

  • Làm sao mà công ty nào cũng có thể khiến mình trông như hạng nhất trên mọi benchmark vậy?

    • Trước hết xem trong bộ benchmark do chính mình chọn thì những model nào kém hơn
      Tiếp theo so với phiên bản trước của model đối thủ. Nếu vẫn chưa có vẻ tốt thì so với model trước của chính mình
    • Vì hào lũy không lớn, cải tiến mang tính tiệm tiến, và họ chọn lọc các model để đưa vào so sánh
      Nói công bằng thì nếu điểm mạnh chính là giá, có lẽ so với các model có hiệu năng tương tự sẽ hợp lý hơn
    • Giờ so với Gemini giống như ô bingo miễn phí vậy
    • Với người hiểu sâu về mảng AI, trong coding thì nên xem benchmark tiêu chuẩn là gì?
    • Chỉ cần chờ đúng khoảnh khắc model của mình dẫn trước trên ít nhất N benchmark rồi công bố là được

  • Tôi đã bỏ lỡ chuyện Meta đang phát triển và phát hành model trọng số đóng. Tiếc thật. Hy vọng sẽ có nhiều tiến triển hơn với các model trọng số mở của Mỹ

  • Tôi đã làm cho nó chạy cùng codex trong container. Nhân tiện, có vẻ có một bug mà bạn sẽ thường gặp ở giao diện Codex:Muse
    Theo tôi thấy thì codex không dự liệu các lời gọi công cụ phía server, và cách Meta xử lý các ID đó gây ra một kiểu lỗi parsing hoặc tích hợp. Khi tôi chạy codex với muse vài lần đầu, nó thất bại ở lời gọi không phải tìm kiếm web đầu tiên
    Tôi đã sửa được, và cá nhân tôi vẫn chưa hoàn toàn bị thuyết phục bởi lời gọi công cụ phía server tùy chỉnh và lưu trữ file vô thời hạn, nhưng đến giờ đây là một model khá tuyệt và tôi đang dùng rất vui
    https://github.com/accretional/awesome-muse-spark/blob/main/...

  • Nhìn vào benchmark được công bố thì coding và multimodal cũng khá tốt, nhưng tỷ lệ gọi công cụ thành công có vẻ rất cao.
    Trường hợp sử dụng nào sẽ phù hợp nhất với kiểu hiệu năng này?

    • Debug và chẩn đoán đòi hỏi gọi công cụ rất nhiều. Bao gồm cả việc grep hoặc biến đổi log, gọi profiler hoặc tracer, rồi viết báo cáo sự cố.
      Chẩn đoán lỗi là lĩnh vực vừa phải biết coding ở mức nhất định, vừa cần tận dụng công cụ tốt hơn. Nếu có báo cáo chẩn đoán tốt thì phần sửa lỗi có thể giao cho Opus.
      Opus cũng viết báo cáo ở mức nào đó, nhưng trong tài liệu typst vẫn thường xuyên sai độ rộng bảng, khiến cột cuối cùng đầy chữ nhưng bề rộng chỉ đủ vài ký tự.
    • Gemini 3.5 Flash tốt hơn Fable ở phần gọi công cụ. Gọi công cụ có lẽ là một trong những lĩnh vực có thể cải thiện tương đối dễ bằng hậu huấn luyện.
    • Tôi tò mò liệu trong mỗi bản phát hành mới về sau ta có thấy mẫu hình như vậy không. Việc sử dụng công cụ có khả năng thay đổi nhanh, nên mô hình mới nhất có thể luôn có lợi thế hơn mô hình thông minh nhất.
    • Điều này nghe có vẻ hơi vô dụng. Việc có hiệu năng tốt với decoder bị ràng buộc như JSON thì thú vị, nhưng với decoder thông thường, vòng lặp đi qua trình kiểm chứng công cụ, nhận thông báo lỗi tốt rồi thử lại hầu như luôn có thể làm công cụ chạy ở lần thử thứ hai. Input được cache nên chi phí cũng không đắt.