Phân cụm token suy luận của GPT-5.5 trong Codex có thể dẫn đến suy giảm hiệu năng

• Issue OpenAI Codex #30364 cho biết hiện tượng reasoning_output_tokens trong phản hồi gpt-5.5 dồn vào các giá trị cố định như 516, 1034, 1552 có thể liên quan đến việc chất lượng suy giảm ở các tác vụ Codex phức tạp
• Phân tích dựa trên metadata token_count của Codex trong giai đoạn UTC từ ngày 1/2/2026 đến 27/6/2026, xác nhận 390.195 bản ghi phản hồi và 3.363 sự kiện exact 516 trên 865 session
• gpt-5.5 chiếm 19,3% tổng phản hồi nhưng chiếm 82,0% các sự kiện exact-516; trong các trường hợp reasoning_output_tokens >= 516, tỷ lệ exact 516 là 44,0%, cao hơn rất nhiều so với 1,3% của non-GPT-5.5
• Tỷ lệ exact-516 theo tháng tăng từ 0,11% vào tháng 2/2026 lên 53,30% vào tháng 5 và 35,84% vào tháng 6, nhưng số token suy luận trung bình và P90 lại giảm trong cùng kỳ, nên đây không đơn thuần là hiện tượng tăng mức sử dụng token suy luận
• Các bình luận sau đó chia sẻ hiện tượng phân cụm 516 tương tự và tái hiện một phần câu trả lời sai trên Codex CLI, Codex Desktop và OpenCode; đồng thời còn có đề xuất một proxy cục bộ để phát hiện mẫu 518·n−2 rồi tiếp tục suy luận như biện pháp tạm thời

---

Vấn đề cốt lõi của issue

• Issue Codex #30364 báo cáo một mẫu phân bố dồn quá mức vào reasoning_output_tokens = 516 trong metadata token_count của phản hồi gpt-5.5
• Ngoài ra còn xuất hiện các spike gần 1034 và 1552, trông như các ranh giới cố định
• Phạm vi vấn đề được nêu ra không phải là khẳng định đã chứng minh có cắt ngắn hidden chain-of-thought
  • Nhận định hẹp hơn là trong telemetry của Codex có hiện tượng bất thường phân cụm token cố định mang tính đặc thù của gpt-5.5
  • Vấn đề được nêu ở mức mẫu này có vẻ phù hợp với hành vi ngân sách suy luận dựa trên ngưỡng
• Issue liên quan #29353 đề cập đến tái hiện ở cấp đơn vị công việc, nơi một lần chạy gpt-5.5 kết thúc đúng tại 516 reasoning tokens và trả về đáp án sai; issue lần này bổ sung bằng chứng tổng hợp trên một khoảng thời gian lớn hơn

Môi trường phân tích và dữ liệu

• Sản phẩm là Codex, model liên quan nhất là gpt-5.5
• Nguồn dữ liệu là metadata token_count của Codex
• Thời gian phân tích là 1/2/2026 đến 27/6/2026 UTC
• Các số liệu tổng hợp:
  • Bản ghi token ở cấp phản hồi: 390.195
  • Session: 865
  • Sự kiện exact reasoning_output_tokens = 516: 3.363
  • Tỷ trọng phản hồi tổng thể của gpt-5.5: 19,3%
  • Tỷ trọng sự kiện exact-516 của gpt-5.5: 82,0%
  • Tỷ lệ exact-516 / >=516 của gpt-5.5: 44,0%
  • Tỷ lệ exact-516 / >=516 của non-GPT-5.5: 1,3%

Mẫu theo model và theo tháng

• Tỷ lệ exact 516 / >=516 nổi bật nhất ở gpt-5.5
  • gpt-5.5: 75.401 bản ghi, 44,0%
  • gpt-5.4: 25.214 bản ghi, 19,8%
  • gpt-5.2: 247.575 bản ghi, 0,34%
  • gpt-5.3-codex: 13.333 bản ghi, 0,0%
  • gpt-5.3-codex-spark: 26.179 bản ghi, 0,0%
• Hiện tượng phân cụm exact-516 theo tháng tăng vọt trong tháng 5/2026
  • Tháng 2: 0,11%
  • Tháng 3: 2,45%
  • Tháng 4: 4,25%
  • Tháng 5: 53,30%
  • Tháng 6: 35,84%
• Trong cùng thời gian, cường độ token suy luận tổng thể lại giảm
  • Số reasoning tokens trung bình: tháng 2 là 268,1 → tháng 5 là 106,9 → tháng 6 là 168,5
  • P90 reasoning tokens: tháng 2 là 772 → tháng 5 là 344 → tháng 6 là 515
• Vì tổ hợp này, người báo cáo cho rằng khó giải thích mức tăng exact-516 chỉ bằng việc tăng sử dụng token suy luận đơn thuần

Các hạng mục xác minh nội bộ được yêu cầu

• Có yêu cầu nhóm Codex điều tra xem ngân sách suy luận, routing, cắt ngắn, fallback và hành vi scheduler của gpt-5.5 có gây ra việc kết thúc gần 516/1034/1552 hay không
• Nếu hành vi đó là có chủ đích, người báo cáo đề nghị làm rõ exact 516 là điểm kết thúc bình thường, trần ngân sách, degraded tier hay một ngưỡng nội bộ khác
• Quy trình xác minh được đề xuất:
  • Truy vấn các sự kiện token_count có chứa reasoning_output_tokens theo từng model
  • So sánh số đếm exact-value của 0, 516, 1034, 1552
  • Tính count(reasoning_output_tokens = 516) / count(reasoning_output_tokens >= 516) theo model và theo ngày
  • So sánh gpt-5.5 với gpt-5.2, gpt-5.4 và các biến thể chuyên cho Codex
  • Chạy lại các tác vụ phức tạp trên GPT-5.2 và GPT-5.5, rồi đánh giá chất lượng riêng giữa các phản hồi exact-516 và các phản hồi có reasoning dài hơn

Các tái hiện bổ sung và dữ liệu đối chiếu trong phần bình luận

• GitHub Actions đánh dấu #29353 là ứng viên trùng lặp liên quan
• Nhiều người dùng để lại bình luận nói rằng họ gặp cùng vấn đề, và một người dùng đánh giá issue lần này dựa trên dữ liệu hơn issue trước
• sinnet3000 đưa ra dữ liệu đối chiếu đa client từ kho session cục bộ của Codex CLI và OpenCode
  • Trong khoảng 22,7k sự kiện token_count tại ~/.codex/sessions và archived_sessions của Codex, gpt-5.5 có 4.300 records, 156 trường hợp >=516, 88 trường hợp exact 516, tỷ lệ 56,4%
  • Trong khoảng 32,1k assistant messages của opencode.db trên OpenCode, gpt-5.5 có 6.977 records, 126 trường hợp >=516, 90 trường hợp exact 516, tỷ lệ 71,4%
  • Với khoảng 24k records gộp từ các model non-OpenAI có khối lượng đáng kể như Kimi, DeepSeek, MiMo, MiniMax, Gemini, Qwen, GLM, số exact 516 là 0
  • Dữ liệu này có lưu ý rằng nó không đánh giá đúng/sai của câu trả lời mà chỉ xác nhận sự tồn tại của hiện tượng phân cụm exact 516
• kyleboddy báo cáo khác biệt hành vi liên quan trên Codex Desktop chạy Windows 11
  • Chạy cùng candy prompt trên 5 thread Codex Desktop mới, không gắn project
  • Các lần chạy nhanh kiểu direct-final_answer trả về 29, là đáp án sai
  • Các lần chạy chậm hơn và có commentary xuất hiện trước trả về 21, là đáp án đúng
  • Trên các thread Desktop mới trên Windows host, người này không trích xuất được exact reasoning_output_tokens, nên không thể khẳng định các lần chạy sai đó chính xác là 516
• Cùng người dùng này cũng tổng hợp hiện tượng phân cụm giá trị cố định trong metadata session cục bộ của gpt-5.5 / xhigh
  • records 16.141, sessions 51, reasoning trung bình 149,7, P90 là 429
  • =516 có 438 trường hợp, >=516 có 1.298 trường hợp, tỷ lệ 33,74%
  • =1034 có 52 trường hợp, =1552 có 14 trường hợp, =2070 có 16 trường hợp, =2588 có 12 trường hợp, =3106 có 5 trường hợp

Kết quả tái hiện trên Codex Linux CLI

• kyleboddy cho biết cũng đã tái hiện với cùng candy prompt trên Codex Linux CLI
• Môi trường:
  • Sản phẩm: Codex CLI
  • Phiên bản: codex-cli 0.142.5
  • Nền tảng: Ubuntu Linux 6.8.0-111-generic, x86_64
  • Node: v24.14.0
  • Chế độ xác thực: ChatGPT
  • Model thử nghiệm: gpt-5.5
  • reasoning efforts: xhigh, high
  • Model đối chứng: gpt-5.4 xhigh
• Prompt yêu cầu không dùng công cụ bên ngoài và hỏi số lần rút tối thiểu trong bài toán túi kẹo có thể phân biệt hình dạng bằng xúc giác
• Đáp án kỳ vọng được xác nhận độc lập bằng brute-force enumeration là 21
  • Có kèm giải thích rằng có thể lập kế hoạch 9 viên round + 12 viên star vì có thể phân biệt shape bằng xúc giác
• Kết quả:
  • Cả 4 lần chạy hoàn tất của gpt-5.5 xhigh đều có reasoning_output_tokens = 516, với đáp án cuối là 23, 26, 28, 15, tất cả đều sai
  • Cả 3 lần chạy của gpt-5.5 high cũng đều là 516, với các đáp án 22, 21, 27, chỉ đúng 1 lần
  • 3 lần chạy của gpt-5.4 xhigh dùng 6211, 12274, 10876 reasoning tokens và đều trả về 21, tất cả đều đúng
• Kết quả này củng cố cho nhận định hẹp rằng trong Codex, gpt-5.5 có thể rơi vào đường đi cố định 516-token, và đường đi đó có thể liên quan đến suy giảm chất lượng tác vụ

Đề xuất cách lách tạm thời

• dzshzx đề xuất codexcomp, một proxy Responses cục bộ đặt phía trước Codex trong khi chờ upstream fix
• Cách hoạt động là coi mẫu 518·n−2 như bị cắt ngắn rồi tiếp tục suy luận
  • Xử lý các round kết thúc với reasoning_tokens == 518·n − 2, tức 516, 1034, 1552... là truncated
  • Bỏ tentative output và phát lại reasoning items cùng encrypted_content của round đó làm đầu vào cho vòng kế tiếp
  • Chèn phase:"commentary" cùng thông điệp "Continue thinking..."
  • Gộp tất cả round thành một downstream response để Codex nhìn thấy như một câu trả lời hoàn chỉnh
• Cấu hình dùng khóa top-level chính thức openai_base_url
  • Ví dụ: openai_base_url = "http://127.0.0.1:8787/v1";
  • Theo mô tả, provider openai tích hợp sẵn vẫn được giữ nguyên nên session grouping, remote compaction và remote-control vẫn tiếp tục hoạt động
• Ví dụ log thực tế cho thấy có trường hợp sau hai lần 516 liên tiếp thì round thứ ba kết thúc sạch và cho đáp án đúng
  • round 1: reason=516 → continue
  • round 2: reason=516 → continue
  • round 3: reason=291 → clean
• Lưu ý:
  • Đây là cách lách không chính thức và phụ thuộc vào hành vi không có cam kết từ upstream
  • Các continuation round sẽ tiêu tốn thêm token thực tế
  • Bị giới hạn bởi cửa sổ n và mức trần 3-continuation
  • Chỉ loopback, auth passthrough và được nói là không đọc hay lưu trữ credentials

[GN⁺]

Ý kiến trên Hacker News

• Việc này trông khá nghiêm trọng, và cũng dễ tái hiện bằng codex cli
  Khi đưa một prompt dạng câu đố cần suy luận, đôi khi nó như bị ngắt đột ngột, chỉ dùng đúng 516 token suy nghĩ rồi đưa ra đáp án sai
  Khi dùng 6000~8000 token suy nghĩ thì nó đưa ra đáp án đúng
  Có thể là vấn đề ở phần suy nghĩ thích ứng (adaptive thinking), và điều này cũng là thêm một lý do ủng hộ mô hình local vì không phải lo các thay đổi âm thầm phía server
  Tôi chạy cùng một prompt 10 lần thì 4 lần gặp vấn đề 516 token này, và cả 4 lần đều trả lời sai. Mẫu còn nhỏ, nhưng có vẻ 5.5 xhigh có thể bị cắt ngắn gần một nửa số lần, dẫn đến giảm hiệu năng

  • Tôi cho rằng suy nghĩ thích ứng cũng có vấn đề về mặt triết lý. Nó đoán trước khi suy nghĩ xem nên phân bổ bao nhiêu ngân sách suy nghĩ, nhưng trong bối cảnh LLM, gần như không có cách nào biết trước lượng suy nghĩ cần thiết, tức lượng token sẽ sinh ra
    Không gian bài toán rộng vô hạn, và khó đánh giá cần suy nghĩ bao lâu chỉ dựa trên độ tương đồng giữa các prompt. Mô hình vốn đã dừng suy nghĩ ngay cả trước khi chạm tới ngân sách suy nghĩ
    Tôi không hiểu vì sao lại bỏ nhiều công sức đến vậy để triển khai suy nghĩ thích ứng; có lẽ nên huấn luyện mô hình phát token kết thúc suy nghĩ tốt hơn
    Nó giống một miếng vá tạm. Mô hình nên được huấn luyện để suy luận một lượng phù hợp: suy luận → ước lượng độ bất định còn lại → quyết định có tiếp tục không → suy luận thêm → lặp lại
  • Với mô hình local cũng vẫn phải lo lỗi cấu hình. Ngay cả chuyên gia cũng mắc sai sót, nên hiệu năng mô hình local giữa các nhà cung cấp rất thất thường
  • Tôi tò mò liệu có thấy mẫu hình nào khi kiểm thử theo múi giờ hoặc ngày trong tuần không. Ví dụ có thể xem hiện tượng cắt ngắn có xảy ra thường xuyên hơn vào giờ cao điểm làm việc hay không
  • Nếu người dùng cũng phải trả tiền cho số token bị lãng phí đó, có lẽ nên yêu cầu hoàn tiền

• Gần như mỗi ngày tôi đều gặp cảnh chất lượng tụt theo từng nấc, và thường tôi dùng xhigh
  Trải nghiệm từng phụ thuộc vào khả năng code cực kỳ tỉ mỉ của Codex hồi đầu năm đã biến mất; thỉnh thoảng nó đưa ra những triển khai ngớ ngẩn đến mức khó tin, nên tôi đã chuyển sang Claude cho đến khi OpenAI xử lý nghiêm túc vấn đề này
  Cá nhân tôi đã theo dõi chuyện này vài tháng, nhưng không thấy OpenAI có vẻ xem nó là nghiêm trọng

  • 3 tháng trước Claude trở nên quá ngu nên tôi chuyển sang Codex, còn 6 tháng trước thì ngược lại. Dù là Codex hay Claude thì sớm muộn cả hai cũng sẽ làm mình khốn đốn. Dù vậy Codex có lẽ vẫn đỡ hơn
  • Từ đầu tháng 6, trong trải nghiệm của tôi, độ tin cậy của 5.5 đã giảm xuống ngang mức Claude
    Vì vậy tôi đã chuyển từ 5.5 high → 5.5 xhigh → 5.4 high
    5.4 high hoàn toàn ổn định trong 3 tuần qua, và hiện tôi hài lòng với nó
    Thỉnh thoảng tôi vẫn chạy tác vụ bằng 5.5 xhigh để xem nó đã quay lại trạng thái ổn định 100% chưa, nhưng hiện tôi nghĩ họ đang chờ ra 5.6 hơn là sửa vấn đề độ tin cậy này
  • Tôi không tin đây là vấn đề kỹ thuật. Sửa nó sẽ tốn nhiều tiền, mà người dùng không trả đủ nhiều, nên tôi xem đây là quyết định kinh doanh nhằm hạ hiệu năng

• Cảm giác như déjà vu. Trông y hệt đợt hồi quy hiệu năng Claude Code hồi tháng 4. Khi đó tôi đã hủy đăng ký Claude và chuyển sang Codex
  Giờ tôi đang nghĩ đến việc dùng cả hai theo kiểu tính phí theo token, dùng GLM 5.2 của Fireworks cho phần lớn công việc rồi chỉ trả tiền cho các mô hình lớn khi cần. Nhưng tôi không chắc điểm hòa vốn có hợp lý không

  • Về tính phí theo token, tôi cũng có phản ứng tương tự, nhưng vì về mặt kinh tế cả hai phòng lab đều có lợi khi chuyển khách hàng sang tiêu thụ theo token, nên về nguyên tắc tôi muốn tránh
    Dù không cố ý, tôi không muốn chấp nhận hoặc tạo điều kiện cho một cấu trúc kiếm lợi từ sản phẩm bị giảm chất lượng
    Kể từ khi ChatGPT ra mắt đến nay, mô hình nguồn mở và các môi trường chạy mở, chẳng hạn như Pi, trông hấp dẫn hơn bao giờ hết
  • Đúng vậy. Tôi cũng đã hủy Claude Code và chuyển sang Codex vì chuyện đó
    Giờ tôi đang nghĩ xem làm sao kiếm thêm 65.000 đô la để khỏi phải lo lại mấy chuyện vớ vẩn kiểu này. Tôi hiểu tính kinh tế của những thứ như OpenRouter
    Nó làm tôi nhớ khoảng năm 2008, khi “đám mây” nổi lên như một thuật ngữ marketing. Nó trông như một lớp vỏ bọc để hạ kỳ vọng về rich client và tăng biên lợi nhuận cho công ty bằng mô hình đăng ký, làm xói mòn quyền sở hữu local
    Sau đó tôi chán ngấy sự cuồng nhiệt và chủ nghĩa tuyệt đối về “phần mềm tự do và nguồn mở đích thực”, rồi tự nhủ hồi đó mình còn trẻ và bỏ qua
    Thực ra nhiều mô hình đăng ký ở mức nào đó tôi có thể hiểu hoặc chịu được. Làm phần mềm tốn rất nhiều tiền, và việc định giá nâng cấp Photoshop hằng năm ở mức 200 đô vào năm 2026 có thể không công bằng. Nhưng tùy hứng thay đổi UI đã hoạt động tốt suốt 20 năm và loại bỏ hẳn những thứ như bảng màu cổ điển thì thật ngu ngốc
    Khi đó tôi có thể dùng Codex, công cụ thiết yếu cho công việc mà tôi trả 200 đô mỗi tháng, để tạo một plugin bảng màu cổ điển
    200 đô mỗi tháng có công bằng với lượng token tôi dùng không? Vào những tháng dùng rất nhiều, có lẽ tôi đã dùng khoảng 1 tỷ token
    Nhưng đó chính là vấn đề. Họ sẽ cứ kéo các cần gạt mãi mà không biết cụ thể mức lợi nhuận nào là phù hợp, và nhìn vào mấy dấu hiệu kiểu bói lá trà như kỳ hạn nợ, có vẻ ít nhất sẽ như vậy đến năm 2030 hoặc 2032
    Tôi hoàn toàn không muốn nghĩ về những thứ đó. Tôi không muốn liên tục đánh giá mức ưa thích mô hình và suy giảm hiệu năng, cũng không muốn liên tục cập nhật sắc thái khi nói với AI theo các thử nghiệm backend bí ẩn nào đó đang chạy trên đầu ra mà tôi thực sự được trả tiền để tạo và bảo trì
    AI nằm đâu đó giữa công cụ và cộng sự, nhưng những thay đổi “tính cách” thất thường phát sinh từ việc họ mân mê các núm và cần gạt chưa được hiểu rõ ở giai đoạn suy luận khiến tôi phát điên. Vì vậy tôi muốn chỉ vào cái hộp đặt ở góc phòng và biết chính xác chất lượng đầu ra mà ngoài tôi ra không ai có thể thay đổi
  • Fireworks?
  • Đúng là “hồi quy hiệu năng Claude Code dựa trên cảm giác”. Không nên kỳ vọng hiệu năng nhất quán ở một hệ thống phi tất định. Hoàn toàn không có dữ liệu thực nghiệm nào chứng minh hiệu năng suy giảm
    Thứ gần đây thay đổi theo từng nấc không phải hiệu năng mô hình, mà là lượng than vãn và phàn nàn của các coder

• Tôi thích việc Codex là mã nguồn mở, nên những vấn đề như thế này có thể lộ ra và được xử lý công khai

  • Nhưng đây là hành vi của mô hình, và việc có trình theo dõi issue công khai thì chẳng phải cũng giống Claude Code, chỉ khác là không có mã nguồn sao? Với vấn đề kiểu này, tôi không biết nó khác gì so với https://github.com/anthropics/claude-code
    Nói chung tôi biết ơn vì Codex là mã nguồn mở, nhưng với loại vấn đề này thì mô hình vẫn đóng, nên có vẻ không có nhiều ý nghĩa
  • Nhìn chung tôi cảm thấy OpenAI cởi mở hơn Anthropic rất nhiều và giống một công ty thực thụ hơn. Anthropic chỉ là một hộp đen

• Có thể trí nhớ tôi không tốt, nhưng xét theo lượng token sử dụng và tiêu chuẩn chất lượng mã thì tôi nghĩ 5.3 là tốt nhất. 5.5 hoạt động tốt hơn, nhưng ngốn token kinh khủng

  • Không chỉ mình tôi thấy vậy. Tôi cho rằng 5.3-codex là một mô hình tuyệt vời về cân bằng giữa chất lượng đầu ra và chi phí
    Khác với 5.5 hay Opus, nó đủ rẻ và hiệu quả để dùng cho gần như mọi tác vụ, mà vẫn khá tốt; tôi còn thích nó hơn Sonnet
  • Vài tuần trước, 5.3 đã trở nên không dùng được theo tiêu chuẩn của tôi. Nó hoặc đứng im, hoặc đưa ra câu trả lời tệ hại

• Hình như vài ngày trước có ai đó ở đây nói OpenAI đã giảm được một nửa chi phí tính toán nhờ một tối ưu hóa đột phá, có phải là cái này không?

  • Đó là bài của The Information, nhưng trông không giống một bài viết tốt lắm. Tôi không có cảm giác tác giả là một chuyên gia kỹ thuật hiểu đủ rõ cách LLM hoạt động để có thể đánh giá đáng tin cậy tin đồn nội bộ: https://www.theinformation.com/newsletters/ai-agenda/openai-...
    Nội dung là, theo một người biết về cuộc thảo luận đó, “các kỹ sư OpenAI hồi đầu tháng này đã nói với một số đồng nghiệp rằng nhờ một tối ưu hóa mới phát hiện, họ đã tìm ra cách giảm hơn một nửa chi phí chạy các mô hình hiện có, tức chi phí suy luận”
  • Tôi hiểu tin đồn đó là không phải chính OpenAI, mà là một trong những nhóm tách ra từ OpenAI sau biến cố, có lẽ là Thinking Machines, đã tạo ra bước đột phá và đang đề xuất cho OpenAI. Tôi nghĩ OpenAI vẫn chưa thực sự triển khai nó

• Trong trường hợp của tôi, hiệu ứng này xuất hiện khi nhìn nội dung suy luận được mã hóa theo độ dài chuỗi base64. Nhưng nó không xuất hiện trong token suy luận mà máy chủ báo cáo
  Vì vậy tôi nghĩ đó thuần túy là một phần của mã hóa hoặc làm rối, chứ không phải vấn đề thực sự
  Điểm yếu lớn nhất của GPT là quá trình suy nghĩ bị mã hóa, nên nó còn giống hộp đen hơn Kimi, GLM, DeepSeek. Dù vậy vẫn có thể nhận bản tóm tắt suy nghĩ, nên tuy hơi gượng nhưng vẫn dùng được

• Liệu đây có phải là một trường hợp hiếm hoi mà câu “họ đã làm mô hình ngu đi” không phải ảo tưởng thường thấy của người dùng, mà thực sự là đã làm mô hình ngu đi không?

  • Tôi lại thấy nó giống lỗi hoặc cấu hình sai của engine suy luận hay môi trường chạy agent hơn
    Chi tiết issue không phải bằng chứng cho việc cố ý âm thầm làm yếu đi, mà gần như ngược lại. Nguyên nhân gốc rễ có vẻ thô sơ, và cũng chẳng kín đáo gì khi người dùng phổ thông có thể báo cáo bằng các chi tiết chính xác có thể được xác minh độc lập
    Cụm “ảo tưởng thường thấy của người dùng” vừa không công bằng vừa không hợp gu tôi. Khi thứ bạn có chỉ là các endpoint API như cái bồn rửa ma thuật nuốt context window rồi nhả đầu ra nối tiếp, thì những gì còn lại chỉ là đánh giá chủ quan, suy đoán và nghi ngờ
    Ngay cả khi có bộ kiểm thử mô hình được chuẩn hóa, việc khẳng định là âm thầm làm yếu rốt cuộc vẫn là đọc ý định của những người trong công ty đó. Chất lượng mô hình có thể giảm mà không cần ý định rõ ràng hay hạ cấp hạ tầng nền
    Việc đùa kiểu thuyết âm mưu hoặc xem xét khả năng thực sự bị làm yếu không phải là bệnh tâm thần. Tôi không thích xu hướng lạm dụng thuật ngữ chẩn đoán tâm lý như thế này
    Tất nhiên cũng có những người quá chắc chắn trong các phán đoán kiểu này, và điều đó có thể đúng với họ, nhưng đó là thiểu số. Rốt cuộc chỉ là phóng đại và chẳng giúp ích cho ai

• Buồn cười là họ bán gói đăng ký mô hình frontier rồi theo thời gian nhanh chóng nerf nó mà chẳng ai nói gì
  Nếu lặng lẽ hạ cường độ suy luận ở phía máy chủ thì ít nhất cũng nên giảm giá
  Trong khi đó tôi dùng 5.5-high mỗi ngày trong quy trình đa tác vụ song song, và chỉ vừa đủ dùng hết hạn mức tuần. Tôi không đủ nhanh ở vai trò Human-as-a-Service để đọc theo toàn bộ kế hoạch và triển khai. Mặt đó cũng có thật

• Có vẻ rõ ràng là để tối ưu thông lượng, họ đang gom suy luận suy luận theo bội số 512 token để xử lý batch

  • Suy nghĩ đầu tiên của tôi, nếu lấy llama.cpp làm mốc, là việc điều chỉnh tham số ngân sách suy luận có thể dẫn tới kết quả như thế này. Nhưng nếu OpenAI không công bố thì không có cách nào biết chính xác
    Đây cũng có thể là một cách rất thiếu trung thực để mở rộng theo nhu cầu giờ cao điểm. Tôi biết trong chủ đề này đã có người chế giễu tính chủ quan của cảm nhận về hiệu năng mô hình, nhưng ít nhất trong các thử nghiệm của tôi suốt tháng 5, mô hình có vẻ kém thông minh hơn vào khung giờ Mỹ bắt đầu online
    Trong bài blog của công ty vài tuần trước, tôi cũng cảm thấy một mẫu hình nhất quán hơn vào các khung giờ trùng nhau, nên nghĩ rằng cần nêu điểm này. Lẽ ra tôi nên lưu log phiên để phân tích thêm https://webesque.agency/blog/2026-06-19-llms.html
  • Chẳng phải tiêu chuẩn là dùng continuous batching sao? Nếu dùng continuous batching, tôi thắc mắc vì sao độ dài token sinh ra lại quan trọng, và vì sao phải gom theo độ dài. Nếu không dùng, tôi muốn biết vì sao không dùng và các đánh đổi là gì