股票常见指标与公司财务分析

股票常见指标与公司财务分析

这篇笔记用于理解股票软件里常见指标的含义,并把它们组织成一个分析公司财务数据的框架。指标只能帮助形成判断,不构成投资建议。

1. 行情与交易指标

指标 含义 分析时怎么看
现价 当前或最近成交价格 只反映市场当下报价,不能单独说明公司贵不贵。
今开 当日开盘价 和昨收、现价一起看,判断当天情绪强弱。
昨收 上一个交易日收盘价 是计算当日涨跌幅的基准。
最高 / 最低 当日最高价、最低价 用来观察盘中波动区间。
涨跌额 / 涨跌幅 相对昨收上涨或下跌的金额、比例 涨跌幅体现短期价格变化,不能直接等同于基本面变化。
成交量 成交的股票数量 放量上涨可能表示买盘增强;放量下跌可能表示抛压加大。需结合位置和消息看。
成交额 成交金额 比成交量更适合比较不同股价股票的交易活跃度。
换手率 成交量 / 流通股本 反映流通筹码被交易的频繁程度。高换手通常代表分歧大或关注度高。
振幅 当日最高价与最低价相对昨收的波动幅度 振幅越大,短期不确定性越高。
量比 当前成交速度与过去平均成交速度的比值 量比大于 1 表示成交比平时活跃;极高时要警惕情绪交易。
52 周最高 / 最低 最近一年股价高点和低点 用于观察价格所处历史区间,但不代表估值合理。

2. 估值指标

指标 含义 公式或口径 分析时怎么看
总市值 公司所有股份的市场价值 股价 × 总股本 衡量市场给公司的整体定价。
流通市值 可交易股份对应的市场价值 股价 × 流通股本 更贴近二级市场实际可交易规模。
市盈率 TTM 当前市值 / 最近 12 个月净利润 TTM = trailing twelve months 适合盈利稳定公司;亏损公司市盈率通常无意义。
市盈率 LYR 当前市值 / 上一财年净利润 LYR = last year report 受上一财年一次性因素影响较大。
预测市盈率 当前市值 / 预测未来净利润 通常基于分析师一致预期 适合成长股,但依赖预测质量。
市销率 TTM 当前市值 / 最近 12 个月收入 Price to Sales 常用于尚未稳定盈利的成长公司。越高表示市场对未来增长预期越强。
市净率 当前市值 / 净资产 Price to Book 常用于银行、保险、周期制造等重资产行业;轻资产软件公司参考价值较弱。

估值指标的核心问题

估值指标本质上是在问:现在的价格,买的是多少利润、多少收入、多少资产,以及这些利润和收入未来能不能继续增长。

Envoy Go HTTP Filter

Go HTTP 过滤器 (envoy.filters.http.golang) 允许使用 Go 编写 Envoy HTTP 过滤器。Go 代码被编译为共享库 (.so),在运行时通过 dlopen 加载,并借由 CGo bridge 集成到 Envoy 的 C++ 过滤器链中。

架构

Go HTTP Filter 主要分为两端:

  • C++ 端:负责 DSO 加载、过滤器链集成以及线程安全。
  • Go 端:通过 Go SDK 实现过滤器逻辑,通过 CGo 与 C++ 通信。

ABI 边界由 contrib/golang/common/go/api/api.h 中的共享 C 结构体定义。

1d4a997271052a5a6344e5235da18b13_MD5

DSO (动态共享对象) 加载机制

Go HTTP 过滤器通过 contrib/golang/common/dso/ 中定义的专用 DSO 机制加载 Go 编译的共享库。这与 Envoy 核心扩展中的 dynamic_modules 是两套独立的实现。

核心组件

1. DSO 管理器 (DsoManager)

DsoManager 类 (contrib/golang/common/dso/dso.h) 负责管理共享库的生命周期:

nano-vllm 代码流程

整体架构图

┌─────────────────────────────────────────────────────────────────┐
│                         用户入口层                               │
│  example.py → LLM.generate() → add_request() + step() 循环      │
└─────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│                         引擎层 (Engine)                          │
│  ┌─────────────┐   ┌─────────────┐   ┌──────────────────┐      │
│  │  Scheduler  │ → │ ModelRunner │ → │  BlockManager    │      │
│  │  (调度器)    │   │ (模型执行器) │   │  (KV Cache管理)  │      │
│  └─────────────┘   └─────────────┘   └──────────────────┘      │
└─────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│                         模型层 (Models)                          │
│  Qwen3ForCausalLM → Qwen3Model → [Qwen3DecoderLayer x N]       │
└─────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│                         算子层 (Layers)                          │
│  Attention │ Linear │ LayerNorm │ RoPE │ Activation │ Sampler  │
└─────────────────────────────────────────────────────────────────┘

推理服务流程详解

阶段 1: 初始化阶段

# example.py
llm = LLM(path, enforce_eager=True, tensor_parallel_size=1)

调用链:

时延的建模与测量

本文是 2025年10月出版的《Latency: Reduce delay in software systems》第二章的读书笔记

时延的定律

Little’s Law

利特尔法则(Little’s Law)是排队论和运筹学中最经典、最直观,但也最具威力的定律之一。

Little’s Law 的数学表达式如下所示: $$L = \lambda \times W $$

  • $L$ (Inventory / Queue Length):系统中平均拥有的“东西”数量(比如排队的人数、仓库的库存、处理的任务)
  • $\lambda$ (Throughput / Arrival Rate):单位时间内进入或离开系统的平均数量(吞吐率/到达率)
  • $W$ (Wait Time / Cycle Time):一个“东西”在系统里停留的平均时间(前置时间/等待时间)

需要注意的是,Little’s Law 描述的是一个稳态系统:在一个稳定的系统中,存货数量 = 到达速率 x 停留时间

举个例子,一个咖啡馆内,平均每分钟有 2 个客人进店($\lambda$),每个客人在店里从进门到拿咖啡走人平均停留 10 分钟($W$)。那么,任一时刻店中的停留人数 $L = \lambda \times W$ 为 20 人,即在这 10 分钟内店中累积的人数,第 11 分钟到达速率等于离开速率,系统达到平衡。

在并发系统中,$\lambda$ (吞吐量) 可以理解为每秒处理多少个请求(QPS/TPS),$W$ (响应时间) 可以理解为每个请求平均花多少秒(Latency),$L$ (并发数) 可以理解为在任一给定时刻,已经进入系统但尚未处理完成的请求总数。

在计算机系统中,每一个 $L$ 都不是免费的,它必须占用某种物理资源:

KubeCon North America 2025 Review

KubeCon North America 2025 13号结束了,官网上也有了些会议资料。挑了几个感兴趣的话题总结下。

Dynamic Routing with Multi-Cluster Inference Gateway

https://kccncna2025.sched.com/event/27FeP/ai-inference-without-boundaries-dynamic-routing-with-multi-cluster-inference-gateway-rob-scott-google-daneyon-hansen-soloio?iframe=no&w=100%&sidebar=yes&bg=no

这段时间正好在做 AI 网关,这个话题可以说是“瞌睡了送枕头”。

推理服务和传统 API 流量相比,在 payload,响应时间,后端资源开销上都有着很大的差异(见下图)。 2781cd595fe30c8da311d124a8e4ee35_MD5

因此,推理网关需要做到后端负载感知的调度(传统 API 网关也有类似的方案,尤其是在后端机型不一样,普通的 rr 无法均匀负载时,做后端负载感知动态调权)。在 Gateway 和推理实例间引入了一个 EPP(Endpoint Picker)组件(注:EPP 现在也是 Kubernetes 做推理服务的一个通用组件),采集推理实例的指标来动态选择推理后端。 3462773fb295a9dabdabc886b1de43ca_MD5

benchmark 数据显示,使用推理网关相比传统负载均衡,推理实例间的负载更加均衡,请求排队更少,从而降低了响应时间。

在多集群场景下,这套方案需要解决 3 个问题:

  1. 服务发现:Cluster Inference Services 如何暴露给 Gateway?
  2. 后端选择:Gateway 如何在多集群间分配流量?
  3. 路由模式:流量如何从 Gateway 转发到集群?

第一个问题作者提了 3 个解决方法: fd7a6ffacbfd58fcd6482dd40b861461_MD5

不是关注重点,略过。

第二个问题,简单的 RR 和 Active-Passive 肯定就失去了推理网关负载感知的优势。所以,在 EPP 感知负载之外,Gateway 也得做负载感知。作者也提了两个方法: 1d3df4bac299f39b0c917b886bab2a27_MD5 f4bd518bc6dce2999d5805d5b2d46dac_MD5

从层级上来说,EPP Aggregate Metrics 方案更加简洁,毕竟在 EPP 上还得做二次调度。

最后一个问题,如果 EPP 能跨集群直接访问,direct routing 是最合适的方式,不行的话再加一层网关,使用 Cluster-Local Gateway 做暴露也能访问。