Merge pull request d-run#471 from windsonsea/alipay

update alipay text

Author: windsonsea

docs/zh/docs/blogs/2025/ai-infra.md

@@ -98,13 +98,13 @@
 | QPS 突发时如何平滑处理？ | 弹性调度 + 优先级队列，避免请求堆积或超时 |
 | 高并发下缓存与算力如何平衡？ | 热点数据缓存 + 动态算力分配，降低 OPEX |
 
-推理的本质更接近 **支付宝结算引擎** 。
+推理的本质更接近 **支付结算引擎** 。
 
-支付宝作为全球领先的支付平台，日均交易额达万亿级别，其结算引擎需要在高并发、跨银行、跨数据中心的复杂环境下，确保每一笔资金都能精准无误地流转。这与推理过程中需要满足高吞吐、低延迟、可控成本、多租户隔离的要求高度一致。
+支付作为全球常用的交易系统，全球日均交易额达数十万亿级别，其结算引擎需要在高并发、跨银行、跨国、跨数据中心的复杂环境下，确保每一笔资金都能精准无误地流转。这与推理过程中需要满足高吞吐、低延迟、可控成本、多租户隔离的要求高度一致。
 
-在支付宝的结算过程中，采用了 TCC（Try - Confirm - Cancel）事务控制模型，通过业务层补偿机制，实现了高性能、高可用、最终一致性的资金结算方案。
+支付结算领域普遍采用的 TCC（Try-Confirm-Cancel）事务模型，通过 “预执行验证（Try）- 确认生效（Confirm）- 异常回滚（Cancel）” 的三层机制，在高并发场景下实现了 “高性能” 与 “最终一致性” 的平衡。
 
-在推理过程中，也需要类似的机制来保证数据的准确性和系统的稳定性。在处理复杂的推理任务时，可能需要进行多次尝试和验证，就像支付宝在处理交易时，需要进行预授权、确认支付和退款等多个步骤 。
+而推理系统同样需要类似的容错设计：比如处理长上下文请求时，先通过轻量验证确认 Token 格式与算力资源匹配（Try），再调度异构算力执行完整推理（Confirm），若遇节点故障则触发缓存数据复用与任务重分配（Cancel），确保用户请求不中断、结果不偏差。
 
 在工业界，推理是一个分布式交易系统，它不是简单的学术实验中的模型计算。它涉及到多个环节的协同工作，从数据的输入、模型的计算，到结果的输出，每一个环节都需要高效、稳定地运行。它要同时满足 **高吞吐、低延迟、可控成本、多租户隔离** 。
 
@@ -156,7 +156,7 @@ DaoCloud 推出的 DeepSeek 一体机，更是其在 AI 推理领域的又一力
 
 客户一方的 CFO 会立刻上预算 —— 不需要你再去布道、推广、宣传（Evangelism）。
 
-另外，推理层的技术路线各种“降本加速器”，例如：
+另外，推理层的技术路线有各种“降本加速器”，例如：
 
 - MoE 架构：不全启用 → 成本直接大砍
 - 阿姆达尔定律：把串行部分消灭，跑满大集群